This has become a very interesting and educational thread. As an answer to Uwe: > What purpose would that serve? Roscoe: > Probably pointless. Could help against the most unskilled of attackers. > (One's who didn't make a copy of your disk and had never read/knew of > cryptsetup features and had not conceived software would do such a > thing). See this article: http://yro.slashdot.org/article.pl?sid=09/02/26/2157256 I was thinking of a situation where the interrogators destroyed the second boot in a multi-boot setup by using the password for the first- which one would have willingfully provided, therefore avoiding any 5th ammendment issues, but I see that anybody with their head about them would have done something about this to begin with. Thanks for the info. On Fri, Jul 17, 2009 at 1:16 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Fri, Jul 17, 2009 at 10:23:57AM +0200, Michael Gebetsroither wrote: > > * Arno Wagner <arno@xxxxxxxxxxx> wrote: > > > On Fri, Jul 17, 2009 at 01:16:04AM +0200, Michael Gebetsroither wrote: > > > > >> Adding txt security features from current intel systems you have > runtime > > >> secure boot, so no one will be able to break into your bootsequence. > > >> > > >> So it will only be possibel to decrypt the data on exactly this box > with > > >> exactly this initrd+kernel. > > >> > > >> Though the attacker can restore the destroyed luks header from > backups. > > > > > > This is what I am talking about. You can try to destroy > > > your LUKS header, but it will not work. The only thing you will > > > accomplish is another round in torture and then another go with > > > the backup. > > > > 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. > > > 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. > > > >> The real problem imho is that with this feature you are actively > > >> destroying evidence. Even trying to to this will get you into _real_ > > >> problems, instead of just refusing to give out the keys or admit that > > >> this isn't just random data. > > > > > > And LUKS is totally unsuitable for it, as the header > > > can be clearly recognized. Nobody can prove otherwise if you > > > use dm-crypt and claim it was with a random key for wiping the > > > drive. This is still problematic, however. The only real solution > > > are a true tamper proof module (very hard to do) or that > > > mythical cyanide pill. > > > > 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. 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. > > 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. > > > >> > Oh, and btw, having cryptographically strong randomness on a drive > is also > > >> > a risk. Come to think of it, I do secure wipoes by mounting with > dm-crypt > > >> > and random password, then overwrite with ordinary prng-randomness. > There is > > >> > no way I can prove I do not have the key or the data was random. But > that > > >> > alone should protect me here. > > >> > > >> I usually do a whipe with dm-crypt + random password followed by dd > with > > >> /dev/zero. > > >> Much less trouble, just in case someone takes a closer look. > > > > > > Basically the same thing I do and I doubt it is much less trouble ;-) > > > > Last time i checked hd delivers all zeros for unwritten sectors. > > Though i doubt that written zeros can't be distinguished from factory > > preset zeros on the pattern level. > > Ah, so you mean you do zero the raw partition afterwards. 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 ;-) > > 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 - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > >
