Re: plausible deniability with LUKS ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 21 May 2006 22:39:01 +0100
"Sarah Dean" <sdean12@xxxxxxxxxxx> wrote:

>...
> Not entirely true; if you read the paragraph following the above in
> FreeOTFE's documentation, you'll see that I agree with you - it *is*
> pretty improbable, which is exactly why FreeOTFE doesn't rely on this.

You're right, I didn't read the part informing about the support for hidden
volumes, sorry.
So if you mount a "normal" volume, the space that is occupied by the hidden
volume is shown as free space ?
Thus writing to this disk would overwrite the hidden volume, if the hidden
volume is not emphatically protected.
If so, I guess that this is pretty much the same as it is with the truecrypt
hidden volumes, right ?

>...
> 
> "Plausible deniability" should certainly be possible with
> LUKS/dm-crypt, by using a LUKS/dm-crypt "outer" volume, initilized
> appropriately and using dm-crypt to create "inner" volumes at suitable
> offsets, as needed.
> 
> Any filesystem may be used for either the "outer" and "inner" volumes,
> with "inner" volumes being further nested, if required.

If you mean that the inner volume resides in a file on the outer volume, there
is a problem with deniability.
(One would have to justify a tremendous "unknown" file that occupies like 90%
of the disk :P)
Since you talked about using an offset for the inner volume, I
guess that you meant that the inner volume directly resides on the same
partition as the outer one does. 
Thus, for better understanding, it would look like the following:

disk-partition:
|   outer volume      |   inner volume     |  outer volume continuing |

So if I use dm-crypt for the inner volume, it is not identifiable since it does
not have a header (or anything similar).
However, I do not think that it is possible to use a journaling file system on
the outer volume for the following reasons:

If the hidden volume is created, it interferes with the outer volume.
Thus if you mount the outer volume the outer filesystem will miss some of its
journals and either be unuseable or create new journals and overwrite parts of
the hidden volume (which might be actually wanted in some cases).

To avoid the problem, the OTFE could map the outer volume segments together so
that it looks like a continuous partition to the filesystem.
Unfortunately, this would also allow to locate the hidden volume.
(A volume should be hidden in a way that it cannot be found if one doesn't know
it's exact position.)

Assuming that we have a non journaling filesystem on the outer volume, it might
be possible to create a hidden volume and overwrite parts of the outer volume
filesystem.
If the hidden volume is pretty large (which I want), there might be a chance
that by creating the hidden volume, significant parts of the outer volume
filesystem are overwritten.

If I create the outer volume filesystem with a tool, I could control where it
deposits it's information.
Such a tool might also be used to safely mount the outer volume lateron in such
a way that it doesn't overwrite the hidden volume if one writes to the outer
volume.
AFAIK this is also the way how truecrypt support for hidden volumes works.

Hence I do not think that one can use any filesystem for the outer volume.
I also think that it would be a lot of work to implement hidden volume support
for dm-crypt.

I would be very interrested how exactly you implemented hidden volume support in
FreeOTFE.
It would be just great if you prove me wrong.

greets,
Stefan

---------------------------------------------------------------------
 - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux