Is plausible deniability actually feasible for encrypted volumes/disks?

Question

Based on Is it possible to tell if hard drive is encrypted?, is it actually possible to hide a volume in practice? According to this answer TrueCrypt is the only well-known disk encryption software that does not have a signature. And even with TrueCrypt it seems unlikely to be able to convince anybody that you just happen to have a file of exactly modulo 512 bytes, corresponding to no known binary format, with an extremely high level of entropy. And in the case of full-disk encryption, isn't it astronomically unlikely that the entire disk will be filled with highly random data, even straight from the factory?

---

It seems like it's debatable whether even TrueCrypt hidden volumes can be created and used in a way that provides plausible deniability of their existence.

Answer 1

TL;DR: No, plausible deniability is a weak argument to protect a data. Building privacy based on plausible deniability is unwise. (Also, read the first quote below)

TrueCrypt is not the only popular disk encryption solution that can be used to encrypt a disk cryptsetup can be used with -c and -h to produce an encrypted disk that looks like random noise (given that the specified cipher with -c is used in XTS mode).

(I have added this point to the linked answer as a comment)

I have (almost) no experience with TrueCrypt therefore I'm writing the answer from the cryptsetup point of view. A point of view that is very well defined by Arno Wagner in his awesome cryptsetup FAQ:

why should "I do not have a hidden partition" be any more plausible than "I forgot my crypto key" or "I wiped that partition with random data, nothing in there"? I do not see any reason.

In summary, we are talking about plausible deniability, which is different from simple deniability in the fact that an attacker already know that something may exist he just cannot prove it.

• If you throw your disk into the closest river that's plain deniability, until the moment someone finds the disk.
• plausible deniability enters the scene when the attacker is in possession of your disk but he cannot prove what is on it. It is just as if your shirt had a blood stain (and therefore you looked like a murderer), all DNA tests point that it is human, but no matter how hard the police tries to match it against a DNA database they cannot find a match. You have a human blood stain, but it can pretty much be blood from someone that is very alive and well.

Imagine that you have a LUKS partition, but you really forgot the password. Someone may give up or may do nasty things to you to force you to give the password. He cannot prove that you have the key, neither he cannot prove that you do not have. It depends on his intent and willingness to do nasty things to you.

Nothing is different with a disk that contains random noise. It can be an encrypted disk! And the willingness of the attacker to do nasty things to you is a much stronger point than the ability to prove that the disk is an encrypted disk or not.

Now imagine the attacker as being a law enforcing government agency, and you will see that "doing nasty things to you" may simply be keeping you in prison on "suspicion" of something. I live in the UK so it calls for another quote from Arno Wagner:

[encryption without LUKS] has limited value against the authorities. In civilized countries, they cannot force you to give up a crypto-key anyways. In quite a few countries around the world, they can force you to give up the keys (using imprisonment or worse to pressure you, sometimes without due process), and in the worst case, they only need a nebulous "suspicion" about the presence of encrypted data. Sometimes this applies to everybody, sometimes only when you are suspected of having "illicit data" (definition subject to change) and sometimes specifically when crossing a border. Note that this is going on in countries like the US and the UK, to different degrees and sometimes with courts restricting what the authorities can actually demand.

All above is considering that an attacker cannot prove that the disk is an encrypted disk, i.e. that plausible deniability works.

Bruce Schneier argues in his paper about TrueCrypt and DFS (Deniable File System) that there are environment cues around partitions that look like random noise that defeat plausible deniability. Whether you believe the paper's arguments is your call (I do not), but it gives yet another sight on how plausible deniability is a weak defence.

References:

• Sections 2.4 and 5.8 from cryptsetup FAQ - Arno Wagner
• Defeating Encrypted and Deniable File Systems - Czekis, Hilaire, Koscher, Gribble, Kohno, Schneier

Answer 2

I fully disagree with arguments here given against plausible deniability.

First, plausible deniability doesn't apply just to whole encrypted DISKS and PARTITIONS but also to encrypted FILES (with encrypted hidden VOLUMES), for example in TrueCrypt. Using encrypted disks or partitions has no significant advantage against single files/volumes, for example the presence of a very suspicious encrypted partition is easily detectable and an investigator/attacker examining your PC can easily determine that you KNOW and LIKELY USE encryption tools such as LUKS or TrueCrypt. So the answer "I securely erased that disk/partition, no cryptography here" is no more believable than saying "that TrueCrypt file doesn't contain an hidden volume, because I don't need that added security. The proof? Look at the contents, they are confidential but not critical nor illegal, here is the password".

Second, if you are asked for a password and you answer "I forgot my crypto key" you appear as a NON-COOPERATIVE suspect whereas if you give one you can't be accused of that and the whole burden of the charge of lying is on the investigator/attacker. Moreover, how much is credible that you FORGOT a password on a BIG crypted file or on A DOZEN of crypted files that you still KEEP on your computer? Plausible deniability is even more important if you live in a "democratic" country, where you can't be forced to provide a password: by giving an (harmless) password you can't be accused of lack of cooperation with the investigators, on the contrary if you don't give it you appear less credible and more suspicious.

Third, there are countries, like UK, where the judge can keep you in JAIL for a long time if you don't give him ONE password. Again, with plausible deniability you can give him the "harmless" password and you can't be charged of impeding the justice and jailed.

Fourth, if you have plausible deniability you can always CHOOSE to assert that no hidden information does exist and no second password does exist OR (for example if you are waterborded) admitting they exist and give them the second and "true" password. Plausible deniability gives you ONE MORE CHOICE that you can't have without.

My frank opinion: the opposition to plausible deniability is likely given by the long-time opposition a lot of Linux supporters did against TrueCrypt, that was done just for license issues albeit disguised for technical reasons. An easy-to-use and effective plausible deniability is likely the best feature in TrueCrypt but a lot of Linux users, which didn't find TC in their distribution, get used to crypt with tools without it (for many years LUKS had no plausible deniability support) and get used to say that "plausible deniability is worthless or harmful". It was a case of "sour grapes" that still goes on. And I find really disconcerting that a cryptsetup\LUKS developer, after the usual trite statements about plausible deniability, refuses to give any information, in a FAQ!, about the implementation of plausible deniability in that tool. Huge lack of professionalism here.

My STRONG advice: USE PLAUSIBLE DENIABILITY (especially with hidden volumes), better with a proven tool such as TrueCrypt 7.1a (look carefully at its successors, like VeraCrypt or Ciphershed, but don't use them until they are PLAUSIBLY audited!).

Answer 3

With TrueCrypt you allocate a file to hold an encrypted disk image. But that disk image doesn't have to fill the file completely. TrueCrypt keeps all the actually allocated encrypted sectors at the front of the file, meaning the sectors at the end of the partition are just random bytes that hold nothing. Unless you can decrypt the partition, you have no idea how many sectors in the file are allocated to the partition, and how many are just filled with random data.

TrueCrypt supports writing another encrypted partition in those unallocated sectors. You can create another one there if you want.

Let's say that you allocate 10 MB for the TrueCrypt file. If you only keep 7MB of data in the partition, you still have 3MB of random sectors. You could plausibly create a 2MB partition in there, or not. And if you did create a second partition, you could deny that it exists. Without the key, no-one can prove it exists.

Answer 4

I recommend you look at RubberhoseFS. It is a discontinued project, but features some really cool techniques with which it is truly possible to say "I only have 2 partitions of data, here are the passwords", and no one will be able to prove that there is in fact a third or fourth one.

It works roughly on the following principle:

1. A file of fixed size is created, regardless of how much actual content is intended to be in it. This file is split into blocks, initialised to random noise.
2. A fixed number of "aspects" (views) is created, regardless of how many are actually used.
3. Each aspect holds one symmetric master key protected by a password (or a key); one lattice key generator encrypted by the key; and one map of blocks used by that aspect (initially empty, until data is written to it), also encrypted by the key
4. If a block is referenced by a map of one aspect, it holds data encrypted by a key generated by the aspect's "Lattice Generator", seeded by the block sequence number (i.e. if this is the 3rd block of that aspect, the lattice generator will be seeded with "3". If the block is not referenced by any aspect, it contains random noise.

I have written a specification for my own project I would like to work on when I have time, based primarily on RubberhoseFS: https://github.com/programagor/wrenchcrypt/blob/3ab9fa0bae2d74d65c762630ddd6026196fa15a5/README