On 01/21/2014 11:40 PM, Jonas wrote: >> But what I really want to avoid is that every distribution will >> add some random patches implementing something like this. >> >> It is perhaps better to implement and document this upstream. > > Milan, have you made your decision yet, whether you add the nuke feature > to libcryptsetup (and cryptsetup util)? Hi, as Arno said, let's split this to two parts. > 1. Have a secure erase that is easy to use. [...] > > 2. Have the option of unlocking a keyslot created with a specific > option to trigger the function implemented in 1. [...] For 1, I think we can introduce new CLI command "erase" (with alias luksErase) which will remove all keyslots (in fact it is equivalent of luksKillSlot called for all active slots). In libcryptsetup API it can be extension of existing crypt_keyslot_destroy() call. (It can be easily parameter to luksKillSlot but special command is easy to understand and remember. Moreover, for some possible formats the keyslot in command name can be confusing - think TrueCrypt) (And it should work for future other FDE formats as well. The main use case is that it removes master key from device but not ciphertext data itself.) This is not controversial and it is easy to use. Also it can be used in distro wrappers around cryptsetup. (I can imagine special emergency user login which will erase header. IMHO much better solution than 2.) For 2, (aka self destroy passphrase) - I tried to read the discussion again and I am really not convinced yet we want it. BTW original patch is INCOMPLETE and DANGEROUS. (For example, did anyone think about cryptsetup-reencrypt? Guess what will happen if user try to *reencrypt* device with this destroy passphrase? Try it... or better not ;-) And there are more missing code which just do not convince me that it was properly thought-out work. I think there is only negligible set of users who really have use for nuke pwd (I do not count "toy" cases.) Note the is already way to do it outside of cryptsetup. (BTW reencryption (regular key change) is way more better to increase security - even if anyone have old header backups, it makes these backups unusable. And I still have very few reports of cryptsetup-reencrypt success stories. I would like remove experimental warning one day. ... While the list is full of nuke passwords mails... One would remember http://bikeshed.com/ ... ehm, sorry :-D) ... Whatever, I can implement 1) easily (even in 1.6.4). The 2) is question for next version (1.7) but as I said - my current opinion is still it is not worth to do it. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
