Double Cryptography

So is there a standard for cryptography where a file can be encrypted on such a way that two different keys decrypt to two different, but valid, files? Seems like a foolproof way to hide your ISIS plots from the FBI.

Other urls found in this thread:

blackhat.com/docs/asia-14/materials/Trachtenberg/WP-Asia-14-Trachtenberg-Say-It-Ain't-So-An-Implementation-Of-Deniable-Encryption.pdf
twitter.com/NSFWRedditGif

Bump
That would be great but is that possible?

maki pussy

>a standard
>foolproof way to hide
>bonus: from the FBI
you didn't think this through, did you?

it's been done actually
blackhat.com/docs/asia-14/materials/Trachtenberg/WP-Asia-14-Trachtenberg-Say-It-Ain't-So-An-Implementation-Of-Deniable-Encryption.pdf

In standard RSA, probably not trivially since the public-key is dependent on the private-key.

>two different keys
>two different files
so one key per file?

Don't be retarded. OP clearly means to encrypt two plaintexts into one ciphertext, where the plaintexts can only be recovered with separate keys.

Bump so this doesn't 404, I'm pretty interested if anyone knows of a program to do this. Not really feeling like writing my own and fucking merging all my files together in the process.

can't be done efficiently and also would be fuckin obvious

Would it be obvious though? Take the following oversimplified example.
Say I have two numbers, 5 and 9. I encrypt them by subtracting a key from them. I use 4 and 8 as my keys so the encryption is as follows:
5-4=1
9-8=1
Now I have one encrypted digit (1) and two keys (8 and 4)
Then it's just a matter of adding the right key to the encrypted data to get the original data back.
Obviously this is an oversimplification because it's 3am where I'm at, but wouldn't that be scalable?

Possible with a one-time pad and XOR. Create a random file as long as the longest file, and then generate the "keys" by XOR'ing it with your files. This is possible with smaller keys as well. I'm not here to do your research / implement it for you, OP.

>wouldn't that be scalable?
not really, just try to complicate your example by using 2 words or a series of binary digits and you may see whats the problem

The keys at least have to be as big as the data, so to encrypt a 4GB volume you need 2x4GB worth of keys in addition to the 4GB encrypted volume

TrueCrypt / VeraCrypt hidden volume.

That's an interesting way to do it. Would there be a way to guarantee that you get specific keys as outputs? That would allow for a user to use specific passwords to decrypt the files.

I'm thinking an os or file system that gives you different environments based on the decrypt password entered

You can also create a hidden operating system with TrueCrypt or VeraCrypt.

This. Both results have to make sense or the feds would obviously get suspicious as to why you encrypted a garbled mess

There's no standard, and what you're asking is very improbable and would require a nearly impossible hash collision that coincidentally is your second file.

No, you're retarded and have no clue what you're talking about.

You could approach it in the same way as Shamir's Secret Sharing Scheme. The idea is that an infinite number of polynomials of degree 2 can be drawn through 2 points, but a 3rd defines it. Including n points for a polynomial of degree n would leave one point undefined. If you include the first points in your ciphertext and have only the remaining ones unknown, you could encrypt two different files into just one ciphertext.

I like that idea, that actually makes some sense

>No, you're retarded and have no clue what you're talking about.
Possibly. Do you mind explaining the difference between a hidden volume and what OP is asking? I must be missing something.

OP here, what I was talking about is having encrypted data that decrypts into one file with one key, and another file with a different key.

I'll create a quick reference implementation, the rest of this thread is useless retards so far.

I have a better idea, encrypt all your files and make them unlockable by using a program starting at boot. This program will be a fake ransomware asking for money, that grants access to your files every time you put the password. So you can tell to whoever wants to control your files that you just got a virus. But I don't know if it's possible encrypting a full volume and still be believable

Also:
>be raided by FBI
>fake ransomware pops out asking for something like 2 BTC in order to unlock files
>they pay it because it's taxpayers money
>"hacker" who made the virus is oddly unreachable and the BTC address is actually yours
>profit

Obviously it takes some precautions in order to not disclose your identity with the BTC address

"Alright sir we'll just need to inspect your device"

>they clone your drive and give it back to you
>they find out you're full of shit
>party van shows up the next day

The 5th amendment protects you from having to reveal your key. It's not settled law yet, but it will be as soon as the supreme court looks at the issue. Until then, just use a luks partition on a computer that never connects to the internet.

You could also hide files within jpegs, but the FBI knows about that already. Ultimately, very few crimes are broken open by digital forensics. You should put more effort into traditional opsec, I.e. don't post shit like this on a forum that doesn't respect your privacy.

What forumdo you know that respects your privacy?
I'll flip my shift if you say I2P or other deepweb.

off and never to be seen again

>no true scottsman

Literally anything is better than this shithole. They lull people into thinking you're anonymous and then log IPs and block tor exit nodes.

Am literally ready to fall asleep, will write tomorrow. Algorithm is planned out.

suuuuuure. lets keep it real, you won't

Go back to lainchan! You paranoid creep!

>a file can be encrypted on such a way that two different keys decrypt to two different, but valid, files?


Yes and no. First of all I'd like to answer this:

>So is there a standard for cryptography where a file can be encrypted on such a way that two different keys decrypt to two different, but valid, files?

What you are describing is called: "indistinguishable under chosen plaintext attack" (IND-CPA) in cryptography.

In your scenario you would send someone (often called "oracle") two texts and it answers with one cypher text and you have no idea which of the texts he choose.

This is - however - difficult to realize practically.


It's not about making two files that lead to the same cyphertext. This can be done easily by padding them to the same length, choosing a random cyphertext and creating two keys that encrypt them in that way.

This is basically what this guy described:
But this won't help you.
Because if can secretly exchange the keys after the message was created, you can also secretly exchange the message. There is no gain.


I'm afraid it's not that easy..

>This is - however - difficult to realize practically.

To be more accurate:
It's prooven that CPA-secure encryption cannot be deterministic.

This was pointed out by Goldwasser & Micali in their paper "Probabilistic Encryption and How to Play Mental Poker Keeping Secret All Partial Information", 1982 (they even got the Turing Award for it).


But cryptography is a difficult to talk about if you don't have some basic conepts.

I can only encourage you to get a good book about the fundamentals of crypotgraphy and read about it.