Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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

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?

share|improve this question
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? – doom123 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.

share|improve this answer
Thanks, need to learn linux to understand this. – doom123 Apr 22 '13 at 15:39
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 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? – doom123 Apr 22 '13 at 15:52
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! – doom123 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

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).

share|improve this answer

I will present an initial attempt at a solution at Blackhat Asia 2014:

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."

share|improve this answer
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.

for more info read this:

share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.