Re: nuke password to delete luks header

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey,

Am 15.01.2014 21:27, schrieb Milan Broz:
> 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.

Milan, have you made your decision yet, whether you add the nuke feature
to libcryptsetup (and cryptsetup util)?

Sorry to raising this topic again ;-p

> 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?

I agree with all your points here, except the last one. Here I'm with
Arno: the nuke feature should remove evidence of its existance when
being used.

Kind regards,
 jonas


_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux