* Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Fri, Jul 17, 2009 at 10:23:57AM +0200, Michael Gebetsroither wrote: >> With todays technology it wouldn't be possible, but be aware that the >> next round of trusted computing is already specified. >> The next round completes the cycle as T13 specified a direct binding for >> the HD to the TPM. >> So it wouldn't be possible to restore the destroyed header from backup. > > I have now followed this TPM idea for something like a decade. So far > they have not produced anything really practical. The idea is sound, > but as soon as an implementation becomes usable, DRM raises its > ugly head and the thing falls apart again because nobody wants it. With todays intel boards (executiv series + >Q8400) it's perfectly possibel. The project in question is tboot.sf.net >> It would be rather short sighted to not include the possibility, e.g a >> bitfield per key-slot for the next luks spec. > > What for? If the HDD is tried to the TPM, have the HDD do the encryption > and do without LUKS. LUKS is for software only and not a TPM replacement. It would be wise to see HW encryption as just nice to have in addition. There are much way too many things that can (and will go wrong) in consumer grade crypto systems. >> Right, unfortunately one feature not supported by luks. >> It would be very nice to include the possibility of deniability in the >> next luks (even if this includes the loss of the isLuks/luksUUID >> functions when this feature is enabled). >> Hidden volumes would be desireable too, though would require a bit more >> thinking. > > Again, wrong system. LUKS does not try to hide. You can look at TrueCrypt, > which already does this to some degree. Truecrypts ondisk layout is not as nice as i want it to be. > Note however, that perfect hiding > is not really possible as long as you require some level of usability. > After all the passphrase has to be input at some time and you should > also get an error if it is wrong (after some time to slow down > brute-forcing). Anyways, the clsoest thing to deniability a partition > encrypter without steganography can give you is already there: Just > use plain dm-crypt. What i'd like to implement is some sort of LUKS, but with an option of deniability. The feature thats really missing fron plain dm-crypt is the possibility to complain about wrong password. Multiple key-slots would be nice too, so i though about something similar to luks but with encrypted header. > Also, even having an effective TPM and not disclosing its keys could > get you thrown in jail in some places. If this really is secure, it > could just lead to the hardware being outlawed in some countries. > If not, I would strongly suspecty there is a backdoor. TPM's are unfortunately not tamper proof. > Ah, so you mean you do zero the raw partition afterwards. Right. > Well, if you live in those countries, this may be a good idea. > Personally, I don't bother. Peter Gutman does recommend random data > overwrites and so I can justify them ;-) With todays high density disks (1, 2TB) i haven't even heard of a successfull recovery of even a single overwrite of the data ;). michael -- It's already too late! --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
