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