Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

TrueCrypt already has this feature: http://www.truecrypt.org/hiddenvolume


Ah well...at least I thought of something worth doing :)


More people should learn from this attitude. This is what I say every time I have an idea, and I later found out someone already built a startup around it (happens quite a lot, since I spend half my waking time thinking of startups).


Indeed. It means you possibly have a head for good ideas. You should be far, far more worried if nobody else has beaten you to the punch on any of your ideas, because that would tend to indicate that your ideas are either impractical or of low quality.


Presumably the UK police are aware of this feature, which could lead to a more interesting situation when you can't prove that you've really unlocked to the deepest level.


My understanding of the feature is that is is impossible to verify whether or not you are using a hidden volume within a TC encrypted volume.

Although file-hosted TrueCrypt volumes (containers) do not contain any kind of "signature" either (until decrypted, they appear to consist solely of random data), they cannot provide this kind of plausible deniability, because there is practically no plausible explanation for the existence of a file containing solely random data. However, plausible deniability can still be achieved with a file-hosted TrueCrypt volume (container) by creating a hidden volume within it.

http://www.truecrypt.org/docs/?s=plausible-deniability


Clarification: it's impossible to determine if a hidden volume exists in a TrueCrypt volume. It is trivial to determine whether a given password unlocks the main, hidden, or neither volume.


How is it trivial to verify whether a password unlocks something the existence of which is impossible to verify?


Data about the hidden volume is encrypted and kept in the second 512 bytes of the volume, where as data about the normal volume is in the first 512 bytes. If there is no hidden volume, the second 512 bytes are purely random data.

It's impossible to tell an encrypted volume header apart from random data. It's very much "try, and if you fail, you either have the wrong key or the volume doesn't exist".


I'm surprised that no one has mentioned Rubberhose Deniable Encryption by Julian Assange of Wikileaks fame. That's the entire concept.

Page: http://iq.org/~proff/rubberhose.org/

Description: http://iq.org/~proff/rubberhose.org/current/src/doc/maruguid...


This seems stale though. It's "currently available for Linux 2.2"?


Very stale. He moved on to other things:) But the code is available.


Seems like you're giving the police a lot of credit, but maybe not. Regardless, there's really no way to prove anything either way, is there?


I've met a couple of people who actually deal with computer forensics for the police and they are seriously smart people and totally on top of their game. So while you're average cop might not understand the details, they have forensics guy who certainly do.

As to proving anything, my understanding is that it is theoretically impossible to prove, but sometimes bugs in the implementation or various user mistakes mean that you can, in practice, sometimes get a good indication that something is hidden,


It's very very annoying to use, and can cause data loss.


How is it annoying to use? You have to enter 2 passwords instead of 1... Is that it?

As for the data loss, if you only enter the first password, it will let you overwrite the space where the hidden encrypted volume is stored yes. How else would it work? If it didn't let you do this, it would be obvious that a hidden container exists...




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: