Schneier, UW Team Show Flaw In TrueCrypt Deniability 225
An anonymous reader writes "Bruce Schneier and colleagues from the University of Washington have figured out a way to break the deniability of TrueCrypt 5.1a's hidden files. What about the spanking-new TrueCrypt 6? Schneier says that 'The new version will definitely close some of the leakages, but it's unlikely that it closed all of them.' Meanwhile, PC World is reporting that the problems Schneier and colleagues found are bigger than just TrueCrypt. Among their discoveries: Word auto-saves the contents of encrypted files to the unencrypted portions of your disk, and this problem should apply to all non-full disk encryption software. Their research paper will appear at Usenix HotSec '08."
Re:And this is exactly why.. (Score:2, Insightful)
Full disk encryption doesn't protect against the threat model that TrueCrypt's hidden files try to. The model there is that you are being forced to give up your key (or stand in contempt of court until you do), which means full disk encryption doesn't help you.
Found? (Score:1, Insightful)
From TFA:
But Schneier, chief security technology officer with British Telecom and researchers from the University of Washington *found* that Microsoft Vista, Word, and Google Desktop each can blow the cover of files using this so-called âoedeniable file systemâ (DFS) feature.
Translation:
Renowned security experts state obvious security flaws of ciphered units and unciphered temporary folders, having nothing to do with plausible deniability
This is what prompts Linus' comments... (Score:2, Insightful)
I like Bruce, I think he's got a lot of good insight, but when he spins up a "white paper" that basically says that applications are doing what they're supposed to be doing, and TrueCrypt isn't changing their native behavior, it does everyone in the "Security" community a disservice.
Bruce, if you're trying to make a point - make it. Don't sit there and *publish* nitpicky crap that basically is a bug (or lacking feature) of the software. You'd be far better to say that security applications do not provide adequate deniability, and then cite the sources.
The fact that this sort of stuff passes for "High academia" makes me weep. Let's try to do more than just scratch the surface and point fingers, shall we?
Don't forget Windows Explorer, too (Score:4, Insightful)
Re:And this is exactly why.. (Score:5, Insightful)
you run at least full disk encryption. If one needs further plausible deniability, THEN you can run truecrypt. Also, cleaning out temp files should be a regular occurrence, as should running on an encrypted swap file/partition.
This is why secutiry needs to be left to the professionals and requires scrutiny. It is very hard to get right and very easy to leave holes. You run full disk encryption, but in many parts of the world, you can be compelled to disclose your keys. So, since your keys are disclosed, you now may as well assume that you never had the encryption in the first place. That puts you right back to square 1 and there is now evidence that you have a hidden volume.
Full disk encryption protects you against the consequences of theft, and for this, deniability has no utility. Deniability protects you against certain governments, and for this, full disk encryption often provides little utility.
Re:Let me get this straight (Score:4, Insightful)
If you want _plausible_ deniability, which is what this is about, then having no history file is only going to arouse suspicion. Open a shell with HISTFILE=/dev/null only when you're running the secret VM, and run the shell command using a GUI+script or some other method that doesn't keep tracks.
Re:Let me get this straight (Score:2, Insightful)
Use 'unset HISTFILE' every terminal that uses the secret volume.
Mount /tmp as a ramdisk.
Encrypt your swap with cryptmount*.
Agreed. You failed to mention things like ~/.thumbnails/ or ~/.gimp/tmp/, to name a few. All-in-all, this is exactly why the only safe thing to do is be paranoid and encrypt the whole thing. Even then, though, I'm not sure how feasible it is to create a plausibly deniable full system. That's the sort of thing that'd seem to be nearly a full time job in itself.
*I'd imagine that actually doing so just makes you look extremely guilty, as it shows a real depth to one's paranoia (just like your disable swap and link ~/.bash_history to /dev/null). And at that point, the most paranoid thing to do with Truecrypt would be to take advantage of the "Plausible Deniability" feature. So, it's sort of a Catch-22: the more you try to patch possible leaks, the more clear it is you're trying to patch possible leaks.