On Sun, Sep 13, 2009 at 10:13:03AM +0200, Milan Broz wrote: > (this time replying private intentionally:-) > > Arno Wagner wrote: > > I think this is the wrong approach. LUKS is not designed to hide > > at all and trying to make it capable of doing so is very likely > > a lot harder than to use something else, esoecially as several > > solutions are already available. > > Hi Arno, > thanks for this answer - I had some conversation with Ivan > and told him to ask in list to prove that it is not good idea > - my opinion was exactly the same - LUKS is not designed for this. Indeed. > > Incidentially, using plain dm-crypt with a single zero-overwrite > > of the decrypted device already works very well. I, for example, > > use plain dm-crypt with a random key and zero overwrite to > > erase devices and partitions. This is indistinguishable from > > a denied encrypted volume. It is not feasible to hide the > > encrypted data istelf, so this is as far as it goes. > > Exactly. And you can even map "hidden volume" this way - format fake > (full) encrypted device, and when you activate hidden volume, mask this > part with zero or error mapping to prevent overwrite. (Detecting correct > key and offset for hidden volume is easy - something like returning > correct signature with blkid and scan some expected offsets). But this > require hide also all traces of mounting/scanning for/whatever such volume > in host system etc. And I am very skeptic about this mode. I have had a superficial look at this some time ago. The very least you need to do is wipe all logs, as some messages about the hidden volume may well end in some of them. In addition, there may be dangling symlinks, leftover devices in /dev/mapper/<...> and other hints that your large "random overwrite" area is actually in use. Of course the presence of some specialized handling software is a strong hint. I think in most cases you will miss something. > > If you want more, use TrueCrypt > ... > BTW idea was also allow to use other on-disk formats in libcryptsetup > (than LUKS), in future - new API should allow it. > > First candidate was Truecrypt (for now, just to open container, not > format), unfortunately their non GPL-compatible license will not allow me > to implement that without risk of violating license. (basically I need > only on-disk data structures in header but without reading their code it > is impossible...) > > Do you think that I should try to somehow integrate Truecrypt containers > compatibility (for open)? Would it be useful? I don't think so. Maybe write a wrapper about their own utilities that has a LUKS-compatible commandline and can either call LUKS or the Truecrypt stuff, depending on a small format detector. That would probably be sufficient for most uses and far less effort that to support a foreign format. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
