On Wed, Jan 15, 2014 at 21:27:07 CET, Milan Broz wrote: > 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... :) Indeed. > But what I really want to avoid is that every distribution will > add some random patches implementing something like this. That would be even worse, agreed. > 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. > ... Well, yes. So lets just keep clear warnings in place (the FAQ already has one, just need to modify it a bit.) Then we can at least say "we told you so"... > >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 agree. > - 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 is the best option. > - I think that "nuke" keyslot should remain active. > (not really sure about this) > > Opinions? If we want to do this right, the nuke key must be gone after nuking. If we allow to just have a nuke-keyslot, the key-slot would need to stay active. But what would be the use of that? Hence I think the nuke key itself needs to be nuked as well, because while otherwise the owner could not be forced to give up an "unlock"-key, they could still be forced to give up that they know the nuke-key. Or, if, say, they do not input it themselves, the attacker could verify that it was indeed a nuke key. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
