# Is there an encryption algorithm that allows for a single payload to have two different outputs based on the password?

Suppose I have some confidential information that is encrypted and I'm forced/compelled to disclose that password.

My goal is to make that decrypted payload seem meaningful / and the password valid.

Is there any such algorithm that allows for a different password to be applied to the same payload, so that the alternate decrypted data is disclosed?

• Jan 23, 2017 at 16:22
• Why not use a one time pad? You could make them believe that you had the great idea of using one time pad to protect your application and then encrypted both the fake message and the one time pad for added security... Jan 23, 2017 at 16:28
• Steganography would seem to prove the existence of a solution, though it may be difficult to explain to the relevant authorities why you needed to password protect your cat pictures. Jan 23, 2017 at 16:34
• @BrianDrummond: That is why you hide the secret plans in legal porn. Jan 23, 2017 at 18:32
• It's called plausibly deniable encryption, en.wikipedia.org/wiki/Deniable_encryption Jan 24, 2017 at 11:35

With many common algorithms, by changing the key, it is quite possible to get any arbitrary data in the first block. Where you run into trouble is when the data is longer than they key block size. The rest of the data (beyond the first block) would look random after swapping keys, assuming you are using a secure chaining method. You could use an insecure chaining method, but I wouldn't recommend it.

You could use XOR OTP encryption. This is different from most encryption where the key is mathematically re-used. With OTP (One Time Pad), the key is the same length as the data. With XOR (one of the most common OTP) you have the flexibility to arbitrarily produce the desired message.

To start, create files of equal length:

• original message
• random data (the real key)

XOR together gives you

• encrypted message

then take

• fake message
• encrypted message

XOR together gives you

• fake key

To decrypt, take

• encrypted message
• real or fake key

XOR them to get

• real or fake message

As @Alpha3031 commented, you could actually encrypt one message (e.g. the fake one) with traditional AES, (more common, and requires a smaller key file) and then use XOR (less common) to produce the other. (e.g. the real message?)

XOR can be applied to any files that are sufficiently unpredictable/random. (e.g. encrypted data)

• Should do the trick, except that that I wonder how you will convince the entity forcing you to give your data that this is really how you are encrypting everything :S Jan 23, 2017 at 16:32
• Depends on the context. There are situations where XOR OTP is most appropriate. (splitting a message into two parts, e.g. two online backup services) However, in many cases I'd be hard-pressed to find a reason against simply using AES. Jan 23, 2017 at 16:49
• This would work, but you would need to store the real key, and fake key (both the same size as the message) in some way where the folks asking you to disclose can only find the fake key, while you still have access to the real key for when you want to access the real contents. Jan 23, 2017 at 23:55
• @JesseM It's possible to use the ciphertext from the real data as your OTP key. Could go the opposite way as well: AES encrypt innocuous data, some of which, when encrypted (probably using a different password) used as a OTP key for your super secret stuff. Jan 24, 2017 at 0:45
• @Gudradain: That's what tweakable OTP is for. It's not really possible to prove anymore which keys have been used. Having unused OTP pads is normal so ... Jan 24, 2017 at 16:59

The theoretical question here is a size/entropy question. The key rule is that the entropy of the encrypted message is the same as the entropy of the initial message. If the algorithm involves no compression, the size of the encrypted message is the size of the original message.

For the encrypted message to be decoded in two different ways depending on the key you need that it contains 2 different messages. A way would be to encrypt a real message with one key and a fake message with another key, and combine both encoded messages (after padding the shorter) for example with one byte from each. Provided you add a known id at the beginning of the messages before crypting them, at decode time, the algorithm could only give back the message that had the correct initial ID.

The problem is that there two different messages + some additional info. And having an encrypted message longer than the initial one is not that plausible...

That's the reason why I know no algorithm implementing plausible deniability, but only containers, that is a complete encrypted filesystem. This was implemented in the excellent TrueCrypt before its support was discontinued. Fortunately, a fork of the project still offers it, VeraCrypt.

VeraCrypt actually offers hidden volumes. In fact a part of the empty space of a normal volume is used to store a distinct volume with a distinct key. When you present a key, an attempt is made to find a hidden volume, if not to find a normal volume. When you open the normal volume in normal mode, nothing allows to guess that it also contains a hidden volume, simply it has some unused space which is no surprise for a file system. Of course, if you write a lot of data in that mode, you will overwrite and definitely destroy the hidden volume data. But a special mode exist to give both keys and use the external volume with no risk of overwriting the internal one.

Above was the technical part. But plausible deniability also requires the content of the external container to be worth it, because the capability of hidden containers is a well known feature. IMHO, there are two acceptable ways:

• Sort your information in 3 classes, simple, sensitive and secret and store them accordingly: simple outside the container, sensitive in the external part (use the double password access) and secret in the hidden part. That way as the external container contains more than innocent files the existence of a hidden container is not evident. But you must actually use the external container, at least as much as the inner one and be prepared to disclose its content

• Use the external container as your main storage. That is a common usage on corporate laptops, because it ensures that in case of theft or loss of the laptop, no confidential information are immediately accessible (addresses the confidentiality part of security...). The backside is that you should mount the container as a single one at boot, and in normal usage immediately unmount it to remount it manually in dual mode.

And depending of who the adversary is VeraCrypt pages about plausible deniability and security requirements for hidden volumes has additional advices, such as only using the hidden volume when booting from a read only CD/DVD...

As usual technical security is only a part of global security. If the information is sensitive enough that you can fear for your physical integrity, you should use physical security measures and not rely of plausible deniability alone: it is a nice tool that can help to hide secure information but not a magical silver bullet. Only Snake Oil Company can provide those...

• I'm not sure this really answers the question. The example given involves having two different plaintexts mapping to two different ciphertexts. Steganography is one such mechanism that I think is more applicable. Jan 23, 2017 at 20:35
• The problem with TrueCrypt/VeraCrypt is that it only gives information-theoretical deniability. In the real world, use of those programs is prima face evidence that you've got a hidden volume, and someone compelling you to disclose your password won't put the \$5 wrench away until you've provided two passwords.
– Mark
Jan 23, 2017 at 21:49
• @Mark Except that I'll bet a whole lot of people use non-hidden volumes only. Jan 24, 2017 at 1:20
• @immibis Not people that are likely to be subject to rubber-hose cryptography, though. Jan 24, 2017 at 2:25
• @Mark: Pedantic note, but it's actually not even information-theoretic deniability, only computational deniability. i.e. with enough processing time you would be able to disprove the denial; it's not outright impossible, just impractical. Jan 24, 2017 at 7:46

## Cryptographic Camouflage

CA technologies has patented a technology known as Cryptographic Camouflage.

A sensitive point in public key cryptography is how to protect the private key. We outline a method of protecting private keys using cryptographic camouflage. Specifically, we do not encrypt the private key with a password that is too long for exhaustive attack. Instead, we encrypt it so that only one password will decrypt it correctly, but many passwords will decrypt it to produce a key that looks valid enough to fool an attacker. For certain applications, this method protects a private key against dictionary attack, as a smart card does, but entirely in software.

So yes, you can take a message (in this case, a key), and encrypt it in such a manner that there is one correct key and many "fake" keys that produce false plaintext.

What you're asking for is how to implement plausible deniability on top of secret-based encryption. While there are no specific algorithms to do that, you can easily implement that on application level - just combine two symmetric containers in one, and attempt each password on each container.

I remember TrueCrypt had such feature in the past, although not sure about whether their implementation did something like I suggest or implemented it otherwise.

• Note that this is only really useful if either (1) you're using a very well known piece of software that is commonly used for only providing a single level of encryption (as is the case for truecrypt) or (2) your software provides unlimited levels of encryption (or at least enough different levels that it is unlikely you've chosen to use it for the full number of levels offered) and you're using more than just 2. Otherwise, it will be pretty obvious that you have the extra data because you've chosen to use software that provides the facility to hide extra data... Jan 26, 2017 at 8:58

Yes, with caveats.

Requirements:

1) You provide the encryption program, it will not be able to stand up to careful scrutiny.

2) The fake message must be text or something like it--low entropy.

3) The is a size restriction on the fake message--it probably needs to be at least close to the size of the real one, if the real one is binary the fake must be substantially larger. Any given pair of fake & real messages can be tried, if the sizes are wrong they will be refused.

Algorithm:

The output encrypted file will always be exactly the size of the fake input file. This looks like it's simply encrypting it but in reality both the fake and real files are compressed before encrypting, the encrypted file is padded with gibberish to the size of the fake file. If the two files add up to more than the uncompressed fake size they are rejected.

To extract the file you take the supplied password and decrypt the real file and run it through the decompressor. If the decompressor has a problem you try again on the fake file. If the decompressor still has a problem you simply output gibberish in the size of the input file.

As @Serge Ballesta has already noted, the information content of the encrypted message cannot be smaller than the information content of the true message plus the information content of the fake message. Thus, any encrypted message that is significantly larger than the fake message would be automatically suspicious.

On the other hand, please remember that human-readable content has lots of redundancy, which is basically "free information storage place". To name some examples: hiding messages in pictures and sound or altering the text through synonyms, phrasing, etc. In this light, the "special password" would be to pass the ordinarily decrypted file through some additional decoder (usually also encrypted, so that it looks like noise).

To give an easy concrete example (to make sure it's clear: it's just an example to illustrate the idea, please do not use it anywhere), imagine a simple substitution cipher in which each letter has multiple representations to avoid frequency analysis. However, instead of picking random substitution, you pick the one dictated by the cipher text of the hidden message (which should look random enough).

Hope this helps ;-)

If you allow some "cheating".

Encryption:

• Encript them
• Escape their bytes as esadecimal text (characters from 0 to 9 and from A to F)
• Take one character from 1 payload and 1 character from another payload. Every third byte is outputted randomly.
• since payloads may have different lenght when a esadecimal text ends it will have the character "G" and then as many random characters as needed.

The password is composed like the following:

• 127 bit to decrypt the stream
• 1 bit to select the payload
• 128 bit to decrypt the payload.

Basically you get 1 packet with the size of 3 payloads, it has to be decripted, then you need to select a group of bytes and decrypt it too.

Decryption:

• Decprypt the stream using the first part of the password
• Select the payload (every first or second character every 3 characters)
• Unescape characters
• decrypt the packet too.

It is obvious that this format of file has 2 payloads inside, what it is not obvious is that you can put inside it rubbish and only 1 real payload instead of 2.