[abalashov]

I have another pedantic concern, along different lines. Strictly speaking, decryption function y = f(x) produces deterministic output y based on the application of an algorithm to key x.

Most encryption software, including TrueCrypt, will complain if you provide the wrong key. I object to this behaviour strenuously. What if it stopped doing that? What if it just gave you whatever output would arise from feeding key x into the algorithm? It would be upon the court to show that the resulting incoherent mass of bytes does not contain "satisfactory" output, which requires them to show what the satisfactory output ought to be, which means they must have some idea of what they're looking for to begin with and the ability to show that it exists on the encrypted medium to begin with. This would be problematic in most cases.

[drostie]

Well, it's not actually too problematic. Usually there are forms of metadata which persist and can store this sort of information. So let's assume that you didn't go for whole-drive encryption, and your text editor shows in its recent history "/media/truecrypt1/where-I-buried-him.txt", written on the evening of the murder: so the police believe that somewhere on your computer is a text document revealing where the victim was buried. And since it's my story, we'll suppose that you're completely innocent and that this is a fictional story you've been writing for the last three months, but you're worried that your bizarre murder fiction sounds eerily similar to the circumstances that the other guy died, and might tend to sound incriminating or character-assassinating to a jury.

Even if TrueCrypt didn't protect their encryption with a message-authentication code, the police would still notice that you had given them a decrypted file without a filesystem on it -- much less a filesystem containing /media/truecrypt1/where-I-buried-him.txt . If they have already convinced a judge to force you to decrypt the file, they could just tell the judge "this person is being uncooperative!" and your hijinks will get you nowhere.

Now suppose that they do not have this, but convince the judge that since you have TrueCrypt, and this is the only random-looking file on your computer, that this is probably your TrueCrypt archive. They convince the judge to threaten you with contempt if you don't decrypt it, through whatever means they have available to them. Well, TrueCrypt containers are always meant to be directories -- i.e. they always hold file systems -- and so you'd best decrypt this container into a file system! But that severely restricts your defense.

TrueCrypt will let you do something different: to provide a 'wrong key' which indeed decrypts the device to a valid file system. This is their 'hidden volume' system.

I'm kind of mixed in my reaction to TrueCrypt's hidden partitions, for other reasons. But they address the problem that you've identified, and I haven't figured out a better solution.

[tjoff]

Well, TrueCrypt containers are always meant to be directories -- i.e. they always hold file systems -- and so you'd best decrypt this container into a file system! But that severely restricts your defense.

TrueCrypt is not meant to hold file systems any more than a hard drive is. There is nothing stopping you from not creating a file system on your truecrypt volume and just storing garbage in it - or use another encryption software on top of it.

TrueCrypts hidden-volume feature is quite meaningless in most cases (my opinion) due to the way it is likely used. If you present a decryption key that gives access to a filesystem that does not match what was expected then you are in trouble.

Especially the hidden OS feature... So you have been using this laptop on multiple occasions the last week (of which we have proof) but according to the filesystem you presented to us this system haven't been used for over a month.

The same goes for a hidden volume. Unless you actively use it as often as you use your device (which is really cumbersome to do right) you might just be better of without it since exposing it will tell them way more than you want to tell them (for starters it will tell them that you are actively lying and having made precautions in order to try and get away with lying).

[drostie]

Your last paragraph is actually the "mixed reactions" that I was having. It seems like for hidden volumes to work right, you need to constantly be using the outer volume. That's fine, there are plenty of applications you might want to encrypt but might not need to hide from the police -- passwords and emails, perhaps, or legally-downloaded-and-possessed pornography, or a journal, or something like those.

The problem is, due to what I guess is something of a flaw in the central idea, you ultimately have to provide the password for your inner volume when you do all of these things which don't involve it. So now your private data is split up over two drives, which is at least somewhat questionable, and also the "mundane" drive requires the "important" password.

This may be acceptable if you're collecting a small cache of text documents which you believe could harm a corporation -- then you say "no, I don't have those articles, see, this really is just my porn stash, please don't hurt me. But a criminal or a government -- no, they're willing to be patient and they're perhaps willing to peek at your password input prompts with webcams or audio-recordings. They would know that there's an extra password being entered every time you decrypt that file.

[hippich]

Truecrypt do not allow this (yet).

There is another cool utility - encfs. It have magic option "--anykey". Basically, it stops verification of key hash and always tries to decrypt with key you provided. Thing is - it will show you only correctly decrypted files. So, by using different passwords you essentially create layers of encrypted files, where each layer is decrypted by different password..

Truth is - if something did not decrypt, LEO will see it, but I do not see how they could prove you provided wrong password intentionally, and not at some point changed password to new one, and old been forgot. This essentially will happen when you use different password - you will receive no error and empty container where you can start add personal files..

[andylei]

> which means they must have some idea of what they're looking for to begin with and the ability to show that it exists on the encrypted medium to begin with

this is not a pedantic side concern, but is in fact, the key component of the government's ability to compel evidence production. if they cannot show that they know what's on your hard drive, that you control it, and that what's on your hard drive is incriminating, they cannot compel you to decrypt it.

so yeah, if you gave them a bad key and your decryption algo returned garbage, they'd certainly lock you up for contempt (given the aforementioned conditions were true).

[DennisP]

That'll be a problem when people really do forget their passphrases. Given that they've been through a lot of excietment, what with getting arrested and maybe jailed for a while, and they're often asked for the passphrase a significant amount of time after the computer is confiscated, that could well happen.

[jberryman]

You might be interested in

http://en.wikipedia.org/wiki/Deniable_encryption

[freehunter]

And then you'd have to hope that the 1 in 1e100 chance doesn't come along where your passkey changes your hard drive into a Windows 95 computer filled with US nuclear secrets.

[kmm]

dm-crypt does this. I don't know the internals of the algorithms used, so I don't know whether that is just a feature of the userspace software or it is impossible to verify the decryption was succesful. I presume it depends on whether a hash or a header are stored somewhere.