Linux version of TrueCrypt Hidden OS

[psusi]

I'm sure if the police cared enough to seize your computer and inspect it, that they wouldn't have any old idiot analyzing it. You may as well just keep any sensitive files buried in a hidden directory in .Trash or something if that were the case.

[jwhendy]

@psusi:

It's not about whether the inspecting individual is an idiot or not. That's the whole point of plausible deniability. Take these two examples:

Example 1:
/------------------------\
|                        |
|                        |
| Encrypted Container    |
|        [2GB]           |
|                        | 
\------------------------/


Example 2:
/--------------------------------------------------\                   
|                            /-------------------\ |
| Encrypted Outer Container  |  Encrypted Inner  | |
| Container [2GB Tot]        | Container [500MB] | |
|                            \-------------------/ |
\--------------------------------------------------/

The point is that an examining individual will image the disk and look at the bits. An encrypted single container appears no differently than an encrypted outer container with a hidden inner container; it just all looks random.

Hence the key is that upon revealing the outer container with some data that appears sensitive, one is able to provide a plausible display of having revealed all there is to reveal.

Again, if suspicion of a hidden partition exists, things might get complicated. Without being able to detect it, however, plausible deniability remains intact. Read TrueCrypt's documentation. They cover all this stuff and how to maintain plausible deniability. For example, they state that if an examiner is taking regular images of the drive over a prolonged period of time, they will be able to note (perhaps) that the hidden partition's bits change (if you use it). This creates suspicion because it supposedly looks like free space in an encrypted container... but the bits changed. This leads to investigators wondering if it's not free space but a hidden volume.

And lastly, if there is a chance of beating... no: plausible deniability is probably not much of a concern. One is better being able to simply destroy the USB drive that held the only key.

[jwhendy]

[deleted]: forums were lagging and led to posting twice in a row.

[bodhi.zazen]

"plausible deniability" is nothing more then a crypt within a crypt. You can do the same thing with any encryption, if you "need" to boot another OS, which I doubt, use KVM.

[jwhendy]

"plausible deniability" is nothing more then a crypt within a crypt.

I've wondered about this. Can you verify this somehow? If the "crypt" within a "crypt" shows up as any kind of partition in the table, would your statement be false? Same goes for a "crypt" (TrueCrypt file) inside a "crypt" (an "outer" TC file). If one decrypted the first container, the second file could be found.

I'd actually love for your statement to be the case. I just haven't heard anyone show how it's the case. You need to have a situation where there's no possible way to see the second/inner encrypted blob. It needs to be indistinguishable from, essentially, the random free space of the parent crypt.

Perhaps an easy way would be for someone to write out the steps to create this so we know what's involved. How does it work with respect to the partition table and LVM at installation time?

[bodhi.zazen]

I've wondered about this. Can you verify this somehow? If the "crypt" within a "crypt" shows up as any kind of partition in the table, would your statement be false? Same goes for a "crypt" (TrueCrypt file) inside a "crypt" (an "outer" TC file). If one decrypted the first container, the second file could be found.

I'd actually love for your statement to be the case. I just haven't heard anyone show how it's the case. You need to have a situation where there's no possible way to see the second/inner encrypted blob. It needs to be indistinguishable from, essentially, the random free space of the parent crypt.

Perhaps an easy way would be for someone to write out the steps to create this so we know what's involved. How does it work with respect to the partition table and LVM at installation time?

Try it yourself. Make a crypt and add a crypt within it. Take a look at the raw data from the disk.

[jwhendy]

Try it yourself. Make a crypt and add a crypt within it. Take a look at the raw data from the disk.

I don't even know how to do that yet... I'm just getting into encryption and haven't "taken the plunge yet." All the tutorials I've read for dm-crypt/LUKS, though, refer to applying encryption to a partition. If you mean "create a partition and another partition inside of it" then I don't think it will be plausibly deniable. Being able to identify from the output of fdisk that two partitions exist in which one is the Extended "container" and another is a logical partition inside shows that something exists in there. I don't think this is what TrueCrypt or FreeOTFE are doing when they discuss hidden partitions.

Again, could you briefly describe what you mean by "a crypt." Volume/partition (primary, extended/logical)? An encrypted file?

[psusi]

"Plausible deniability" = "I swear, that 200gb file of random garbage is just random garbage. Doesn't everybody keep large files of random data around? Pay no attention to that link on the desktop that says decrypt random garbage file".

Seriously, it isn't any more deniable just because it's encrypted twice.

[jwhendy]

@psusi:

This is frustrating. You really aren't getting it.

Perhaps Wikipedia will help?

In cryptography, deniable encryption may be used to describe steganographic techniques, where the very existence of an encrypted file or message is deniable in the sense that an adversary cannot prove that an encrypted message exists.

...The owner of the encrypted data may reveal one or more keys to decrypt certain information from it, and then deny that more keys exist, a statement which cannot be disproven without knowledge of all encryption keys involved. The existence of "hidden" data within the overtly encrypted data is then deniable in the sense that it cannot be proven to exist.

In other words (as I've already said), the entire point is that the investigator never gets to the point where he/she asks, "What's that 200gb file laying there?" One decrypts one thing and no matter what tools are used, no second thing can be detected. Look at the graphic above. Only you know that there is a nested volume/container hidden there. To any analysis tool, however, it just looks like one lump of random bits.

To think of it another way... imagine that a partition existed on your disk and no record of it existed... anywhere. Not in fstab, not detectable by any analysis tools, not shown with any fdisk or parted tools... nothing can detect it. But you know it exists and by simply typing "mount /dev/sd15 /mnt" you can mount it whenever you want. That's plausible deniability. Without specifically knowing it exists... there's no way of finding out otherwise.

Again, the whole point is that plausible deniability only works if these two look identical
- 1 encrypted container
- 1 encrypted container with another container (not file) inside

[psusi]

Stenography involves things like subtly altering every xth pixel of an image. If you don't know what to look for, then it just looks like an image.

When you have a large file that appears to contain random data, that is pretty obviously an encrypted file. If you can mount it by clicking an icon on your desktop, then typing in a password, then there pretty good record of its existence right there.

Just because the container is in another container makes no difference; if you can see that there is a container there, you're going to wonder what's inside.