# Truly deniable encryption

What tools can be used to make truly deniable encryption? Suppose, authorities can use any force to make you open your passwords.

Truecrypt can have only one hidden container, which means that authorities will not stop, until you reveal this second password, even if you did not create hidden container.

So, is there any way to create many hidden containers, so that authorities could not even tell how many passwords they should beat out of you. And it is desirable that this way should be secure enough against other, more intelligent decryption methods like statistical analysis of used clusters and so on.

Here http://en.wikipedia.org/wiki/Deniable_encryption i've found info about rubberhose, but it is not maintained since 2000, so i dont know how much it is reliable.

Another way I found is to write to hard disk with different offsets using for example similar scripts http://sourceforge.net/projects/stlth/files/

But this way, as far as i understand, data is not mixed physically, so it is vulnerable to that smart statistics methods. I.e. if authorities see that you heavily used the part of drive that is not revealed using passwords you already gave then they continue to try to get the passwords. Rubberhose, accorging to documentation, has protection against these methods, but the project is too old.

What another tools could you advise to make several hidden containers on disk?

• What ever happened to "I can't recall my password". – k to the z Apr 22 '13 at 15:27
• Maybe someone's mom would be satisfied with this answer, but not the man with a soldering-iron who knows that you must give him exactly one more password as in case of truecrypt. Are you sure that your body will hold out longer than your tongue? – onetuser Apr 22 '13 at 15:59
• Ha. Sorry. I thought we were in a situation where it was a legal requirement and there wasn't the threat of torture. – k to the z Apr 22 '13 at 19:41
• @doom123 The solution to not reveal the password would be to make yourself forget the password and destroy the keyfiles. You'll still have to deal with the soldering iron though! – Ufoguy Jan 19 '14 at 13:17
• I've not been interrogated with a soldering-iron during the last 40 years. The fact that you seem to worry about this becoming a reality for you suggests that you should not write on the internet about it. I mean, seriously, are you the head of a terror cell, or why do you think anyone cares enough about your petty secrets to torture you? – Damon Nov 16 '14 at 20:29

If you write random bytes to an entire device, and then create a headerless (no LUKS or TrueCrypt) encrypted block at a random point on the device, then this is not something that can be detected.

For example on Linux;

1. Take a 100GB HDD.
2. Fill it with random data:

dd if=/dev/urandom of=/dev/sda bs=4K

3. Create an encrypted loopback device at a 'random' point on the disk:

losetup --offset $RNDOFFSET --sizelimit 5G -e aes -k 256 /dev/loop0 /dev/sda 4. Make your filesystem: mkfs.ext4 /dev/loop0 5. And mount it: mount /dev/loop0 /mnt/secret The purpose of all this is that encrypted data should be indistinguishable from random bytes. This way your encrypted 5GB block is camouflaged against the random noise. Any crypto-disk headers, such as LUKS, would show clearly where the block resides, so bare encryption must be used. Provided you keep $RNDOFFSET secret (don't go writing it to your fstab) the presence of an encrypted filesystem should be very difficult to detect.

And you can always say that the device is just a scratchpad or swap area that you use with a key that is randomly generated at each boot.

• With the exception of losetup, each of those commands is pretty easy to understand; dd is just for copying data, and I use it here to copy random bytes onto the HDD, mkfs is equivalent to 'format' on windows, and is just used to create a file system, mount does not really have a windows equivalent but is pretty much like assigning a drive letter (eg X:) to your encrypted filesystem so that you can read and write to it normally. For more info on losetup head over to en.wikipedia.org/wiki/Loop_device Also drop by the DMZ (chat at the top of this page) for any related queries – lynks Apr 22 '13 at 15:45
• Thanks. 1. Is it possible to create several filesystems at different points on disk with linux system commands only? In a way they wont interrupt each other. At few points you can keep relatively inoffensive data that can satisfy a foe. 2. We need to fill random data periodically so that the foe wont be able to detect what bytes are used more often (method that uses magnetic tails that are higher on used bytes or smth. like that). Hence, to keep real data we need mount file systems first. Can we fill remain space with linux commands only? Or some utils are required? – onetuser Apr 22 '13 at 15:52
• 1. Yep, but you will need to use one of more EBRs to create an unlimited number of filesystems. This is because each partition can only contain one filesystem at a time. 2. Yes you can write to the 'background noise' without disturbing the encrypted block, just through careful use of the dd command and the bs and count options. – lynks Apr 22 '13 at 16:20
• Sorry, i ment not file systems on disk, but serveral loopback devices. File systems are created in each of them, according to your answer. Ok, looks like it is possible, thanks! – onetuser Apr 24 '13 at 16:32
• I don't get the point of using a random offset. Any filesystem header should look indistinguishable under AES encryption, whatever its location. What's the advantage of avoiding the start of the disk? – goncalopp Feb 18 '14 at 13:15

Disclaimer: I'm the author of cryptsetup-deluks and grub-crypto-deluks.

Deniable encryption is only a part of the solution. There's no perfect solution to protect yourself and your data if you get caugth by an adversary. You can hardly avoid the suspicion of encryption, even if the adversary can't prove it. I'll list the issues and solutions.

## Defeating torture

Torture in this case is also known as rubber-hose cryptanalysis. The good news is that torture is often inefficient. Your resistance to torture is key, or at least your ability to provide unverifiable fake facts (like the key to a decrypt a decoy O.S.). Ideally, to stop torture, you should also be able to prove that you can't decrypt the data.

Deniable encryption doesn't solve the rubber-hose problem.

Solutions fall in 2 categories. See Technology that can survive a “Rubber-Hose attack” for details.

1. You don't have the key: the key could be split and its parts owned by several friends or hidden servers, acting as authenticators to check that you are not in a rubber-hose situation.
2. The key was destroyed: self-destructed (alarm system) or manually destroyed (chompable microSD card, etc). Harder to put in place and time-critical, but more resistant to yourself after torture.

Don't use an (unencrypted) LUKS header, it's not deniable.

Solutions:

• Plain encryption: (plain dm-crypt, losetup, etc) DON'T use it unless you have a very strong password. It has no protection against brute-force attack, rainbow-table attack and the password can't be changed unless you re-encrypt the whole payload data. Something you can do to harden plain encryption is to use the password to decrypt a given sector, and use this decrypted sector as the key to decrypt the payload data; but the drawback is that you have to remember a randomly-chosen sector number. The recommended Linux tool for plain encryption is cryptsetup --type plain as it is maintained.
• Truecrypt/Veracrypt: Truecrypt header is deniable, especially when used as full disk encryption. Truecrypt uses a salt and a fixed number of password hash iterations (PBKDF2) to decrypt the header containing the key so it's not prone to rainbow-table attack and consideraly slows down brute-force attacks. However, the fixed number of hash iterations makes it less evolutive against brute-forcing than LUKS (as computing power increases, the number of password hash iterations should increase). Compared to LUKS, Truecrypt has no support for multiple keys and no GRUB (Linux bootloader) support.
• DeLUKS: A Deniable version of LUKS, for Linux. Mostly like Truecrypt, but with a support for GRUB bootloader, cryptsetup, multiple keys and an evolutive number of hash iterations.

Of course, you wouldn't put your data in a file called Hey I'm encrypted.bin. But even with full disk encryption, the simple existence of random-looking data could be used against you. See: In The UK, You Will Go To Jail Not Just For Encryption, But For Astronomical Noise, Too.

It's worth to note that, whatever the solution, there must be at least 1 decoy (fake) O.S. on your computer to not look totally suspicious.

Solutions have various levels of credibility and none is pefect. So, how do you explain this random-looking data?

• Manually generated random data:
• Disk wipe: That's the n°1 explaination for a fully-encrypted drive. But is it sufficient?
• Noise recording: It could be a file containing astronomical noise. You'd better have a capture device.
• Etc.
• By-default software behavior:
• Truecrypt/Veracrypt hidden volume: Truecrypt always wipes a newly created encrypted volume payload with random data. So it leads to a suspicion about the existence of an hidden volume in the Truecrypt container, that can't be proven under good circumstances.
• Steganography: This is the practice of concealing a file, message, image, or video within another file, message, image, or video. Impractical for system encryption, so it's better used for transmitting messages rather than storing them.
• Hardware solutions:
• Hardware-encrypted drives: The presence of random data could be due to the manufacturer initial wipe. But these drives may not be optimized to be used in a deniable encryption way.
• Low-level data storage: We could imagine to write data to the drive with a low magnetic level, near the noise level, to make the data appear as 0 under normal circumstances. I don't know any proof of concept of this.
• "Cloud"-stored data: Not really practical if it doesn't fit in your RAM size and needs to be written to your local disk. Moreover, it can be subject to a block cipher mode attack if the adversary has access to the encrypted data.

System encryption is key to protect your data. Don't forget that your RAM is sometimes written to the on-disk swap and that your system keeps logs and tracks of opened files, etc. So it's advisable to use system encryption, and a bootloader that supports it.

At this time, all major O.S. bootloaders don't support natively plain encryption or deniable encryption headers. So the presence of a bootloader supporting deniable encryption can be used against you.

The known bootloaders with deniable encryption support are:

• Veracrypt bootloader: Plausible, you think?

HEY, I'm an encrypted system, and trust me, there's no hidden volume!

• grub-crypto: (a bootloader that supports plain-mode encryption) At least the GUI looks like GRUB but the binary code betrays it.
• grub-crypto-deluks: (grub-crypto fork with DeLUKS support) Same as grub-crypto.

Solutions:

• Decoy deniably-encrypted O.S.: You explain the presence of the bootloader because there is another, decoy, encrypted O.S. And you only give the key to open this decoy O.S.
• Loading the initramfs from a Live O.S.: I don't know if it's even feasible. The idea it to use cryptsetup in plain-mode from a Live CD to decrypt the real O.S. Then you load the initramfs from the Live O.S. (and not from GRUB) to boot the real O.S.
• Bootloader on a stick: The bootloader with deniable encryption support is put on an USB stick. I don't believe in this but some people believe it is safer. It supposes your USB stick won't be seized along with your computer.

Currently inexistant solutions:

• Deniable encryption support in mainstream bootloaders: Unless you're a GRUB developer, you can just vote on the 2+ years old grub pull requests to merge grub-crypto.
• Toolbox bootloader: It would be helpful to have a toolbox bootloader (like GRUBS Reanimated USB Boot Stick), with, among other functionalities, the deniable encryption support. The presence of this special bootloader version would be explained by the other functionalities.

• "In The UK, You Will Go To Jail Not Just For Encryption, But For Astronomical Noise, Too." I can only hope no one will go to jail because there is a /dev/random on their computer.... – Calmarius May 4 '18 at 15:00

Under OP's circumstances, the best approach is storage that can easily be destroyed, perhaps even while the adversary is watching. Micro SD cards are quite small and thin. It would take only a few seconds to destroy one by chewing, and then spit out. OP might well be punished, but there would be no point in torture (for a password, anyway).

• Alternatively, the password could be on paper that is easily destroyed. Something not likely to be memorized. – Bryan Field Oct 31 '16 at 21:00

Outline of my talk

We are interested in the ability to lie convincingly about the contents of an encrypted file, a variation of "deniable encryption" from the cryptography literature. A reasonable scenario may involve a businessman traveling through dangerous territory with sensitive documents, who, if kidnapped or under duress, wants to be able to convincingly lie to his kidnappers about the contents of his documents.

We will thus release a tool that allows users to encrypt a text in such a way that it can be decrypted not just to the original text (using the correct key), but also to other possible texts (using decoy keys). For example, with one key, the text might decrypt to "Don't cry for me Argentina", but with the right key, it would decrypt to "Don't try to meet Angelina."

• Ari - I have updated your answer, as link only answers aren't useful here. This is the sort of detail we expect in an answer. Admittedly, this one does seem a lot like self promotion, so what I'd like to see is some of the content from the talk once you have presented it - you can come back and edit it in. – Rory Alsop Feb 17 '14 at 22:24

Use the LUKS Nuke method, it will destroy the LUKS header - which includes the key used for decryption - upon entering a specific password.

Once the adversary enters this Nuke Password, the LUKS header will be destroyed and it will be impossible to decrypt the drive even if the real decryption password is beaten out of you, since the header is not existent anymore.

• What prevents the adversary from cloning the encrypted hard drive first before typing any passwords? (E.g., if a nuke password is given, just copy the clone again); – dr jimbob Nov 14 '14 at 21:59
• First law in forensics is to make a read-only clone so multiple tries may be attempted. Upon finding the LUKS header trashed, they'd be smart enough to put 2 and 2 together to look 4 more answers from you. They've seen enough Wile E Coyotes out there who always are trying to out-trick themselves. – Fiasco Labs Nov 15 '14 at 2:30
• If your adversary is using a vanilla copy of Cryptsetup, entering the "nuke" password will simply give an "incorrect password" error rather than destroying anything. – Mark Nov 15 '14 at 3:26

A bit of thermite on the drive rigged in such a way that any unauthorised access sets it off and melts the drive. Good luck recovering anything from that. A device rigged to send a large EMP towards your drives will accomplish the same thing.

Of course this will probably get you in jail for destruction of evidence/obstruction of justice or something related.

You can also keep data wanted by government x in a country hostile to x (so if you have lots of data against the USA keep it in Russia/China since they will most likely give the USA the finger and vice versa, data against Putin is probably quite safe in the USA).

Or there is also steganography which can conceal encrypted data in pictures/movies of your cat. The simplest and easily detectable algorithm would make a bmp with the least important bit containing the encrypted data. Visually such an image will look a tad uglier than the original but the difference is close to non perceptible. Real steganography software uses much more advanced algorithms and is thus also much harder to find.

• Welcome to infosec SE. I have to say, you're not really answering the question. Do you have a good grasp of the concept? You're mentioning physical destruction. The asker didn't. That is in no way deniable. Like you said you'll go to jail. And it's ste-ga-nography, stenography is shorthand writing. – J.A.K. Jan 15 '17 at 23:30
• Image steganography has been and continue to be much researched together with analysis (ways of detection). My humble personal view is that hiding informations that way is very efficient in terns of stegobit embedding rates but not sufficiently secure with respect to resourceful adversaries. But that trade-off is in conformance to the Principle of No Free Lunch. If however the volume of materials to be hidden is very small, a good linguistic steganography might be applied IMHO. (I recently wrote such a software: s13.zetaboards.com/Crypto/topic/9024439/1/ ) – Mok-Kong Shen Jan 16 '17 at 15:07
• Unfortunately I do understand the concept. The only truly sure way to make it impossible to prove that some data existed is to physically destroy the drive at the very least. Why do you think various 3 letter agencies don't just wipe the drives and auction them off when they buy new ones but destroy them? – Mr. C Feb 2 '17 at 0:27