On 01/14/2014 05:30 AM, Arno Wagner wrote: > I think that in your scenario, "nuke" does not have any real > advantages over just not having the passphrase, and that one > is dangerous. Well, this idea is not new and I responded very similar months ago. http://code.google.com/p/cryptsetup/issues/detail?id=110#c1 But seems there is a lot of people in disagreement. I was quite surprised that most of people from our university security&crypto lab I met today and asked (to have some other opinions) said that despite "nuke password" has very limited use it is worth to have something like that... Sigh... :) 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. Anyway, you have to manually create such key. And cryptsetup never blocked you from shooting yourself in the foot if you really want. ... >From the pure technical POV (ignoring the use case discussion) https://raw.github.com/offensive-security/cryptsetup-nuke-keys/master/cryptsetup_1.6.1+nuke_keys.diff The principle is ok (it should be implemented on libcryptsetup level, so it works from every GUI extension etc). But I do not like the details: - we do not need additional luksAddNuke command, switch like "--use-slot-destruction-key" option to luksAddKey is enough - I do not like that special key is all zeroes. (This is sometimes used for testing etc). IMHO "nuke key" should be linked to exact header key (if you copy this keyslot area to another LUKS header it should not work there). To be extra paranoid, I think nuke key should be randomized. This can be done e.g. if nuke key contains some salt, part of real key fingerprint (from LUKS header) and some magic string. - I think that "nuke" keyslot should remain active. (not really sure about this) Opinions? Thanks, Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
