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.

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?

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?
–
doom123Apr 22 '13 at 15:59

4

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 zApr 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!
–
UfoguyJan 19 '14 at 13:17

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
–
lynksApr 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?
–
doom123Apr 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.
–
lynksApr 22 '13 at 16:20

1

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!
–
doom123Apr 24 '13 at 16:32

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

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 jimbobNov 14 '14 at 21:59

1

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 LabsNov 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.
–
MarkNov 15 '14 at 3:26