15

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?

valentinas
  • 1,048
  • 8
  • 10
onetuser
  • 281
  • 2
  • 6
  • 2
    What ever happened to "I can't recall my password". – k to the z Apr 22 '13 at 15:27
  • 5
    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
  • 5
    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
  • Soldering Iron Anal-ogies eh? – NULLZ May 13 '13 at 11:58
  • 1
    @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
  • 2
    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
  • Hmm... Soldering iron Man is a pretty serious threat. Would cutting off your tongue be considered an option? – hola May 28 '21 at 15:45

7 Answers7

19

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.

lynks
  • 10,647
  • 5
  • 30
  • 54
  • 1
    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 http://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
  • 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
  • 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! – onetuser Apr 24 '13 at 16:32
  • To continue the discussion: i've created a new question. http://security.stackexchange.com/questions/35826/making-undeterminable-containers-inside-existing-file-system Shortly, if we create some file system on the original partion (too keep openly some files here), and then use a few loopback devices inside it, then original file system's metadata will be erased, wich indirectly indicates that there are hidden containers on the disk. How to avoid it? – onetuser May 13 '13 at 11:13
  • I have found a solution. Make open/hidden TrueCrypt containers on a disk. Put there some data. Make loopback device inside the disk. TC headers are kept in the begining and the end of the disk, so they wont be affected. Under tortures give both TC passwords. Thats all. 1. "Why is disk filled with random data?" It is truecrypt container. 2. "Give your passwords". Here they are. 3. "What? Only gay porn? Is there anything also?" Nope, truecrypt allows only 2 containers, sorry. – onetuser May 16 '13 at 17:12
  • Yep that would probably do it. You have to make sure your access patterns are realistic (set all disks to noatime so file access time is not written to disk to make this easier, you can just say you are worried about disk lifetime). – lynks May 16 '13 at 17:13
  • The above question about fs data is still actual. About fs in truecrypt containers now. Ok, will have to search infoabout fs sturcture for myself. – onetuser May 22 '13 at 10:25
  • 1
    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? – watchowl Feb 18 '14 at 13:15
  • dd if=/dev/urandom ... is about 10x slower than openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt </dev/zero | pv --progress --eta --rate --bytes --size $(</proc/partitions awk '$4=="sda" {print sprintf("%.0f",$3*1024)}') | dd of=/dev/sda bs=2M (source, beware "sda " is present twice in this command). Just check by yourself dd speed with sudo kill -USR1 $(pgrep ^dd) (check in dd standard output). – KrisWebDev Mar 19 '16 at 21:48
  • @loopbackbee you're correct about the filesystem header - I mention the crypt header, which is typically a set of data structures which exist before the encrypted region starts. In LUKS, this contains things like a master-salt, passphrase slots etc (you can have multiple passphrases per LUKS partition). But in plain-mode, I guess you're absolutely right, now that I think about it. – lynks Jun 07 '21 at 08:06