[dm-crypt] nuke password to delete luks header

Jonas Meurer jonas at freesources.org
Tue Jan 28 11:28:23 CET 2014

Am 2014-01-27 21:30, schrieb Milan Broz:
> On 01/27/2014 10:04 AM, Jonas Meurer wrote:
>>> For 2, (aka self destroy passphrase) - I tried to read the discussion
>>> again
>>> and I am really not convinced yet we want it.
>> Do you intend to protect the erase feature by asking for a password? 
>> In
>> that
>> case it will be hard to build a nuke wrapper around 'cryptsetup 
>> erase'.
>> Especially if the nuke password should not reveal access to encrypted
>> data
>> and merely allow to erase LUKS header.
> No, only usual YES/no question should (will) be there
> (which can be switched off with batch -q option as in other commands).
> The luksKillSlot is doing exactly the same, just for one keyslot.
> Actually, it is just simple code as
>   for all active keyslots:
>      crypt_destroy_slot()

Great, sounds good to me.

>>> 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.
>> Isn't that a good argument for implementing it properly upstream? ;)
> I think this argument was mentioned by me :) But I think we have found 
> better
> way how to implement it without this feature.
> Avoiding upstream to become bloatware is also important ;-)

You're correct.

I still would prefer the nuke feature being implemented upstream. One 
argument in the discussion was, that the mere existance of this feature 
could bring you in trouble. I would reverse the argument: given that the 
nuke feature destroys evidence of its existance in the luks header, a 
custom wrapper implementations in your initramfs make things worse. It 
is much more suspicious than as standard upstream feature that is 
available on every installation.

But for sure I see that the decision is not easy, and arguments against 
implementing it do exist. If it's your decision to not implement nuke 
feature upstream, then that's the way it is. You're the upstream author 
after all ;)

>> While I see your argument, reencryption takes a lot more time than 
>> using
>> a nuke feature. Both features serve completely different purposes.
> Sure, it was just a complain about features importance...

I see. By the way I used reencryption feature several times, and it 
works like a charm for me.

>> And if you merely want to destroy access to the data, overwriting it 
>> is
>> still
>> better than reencrypting, isn't it?
> Yes, and removing key with "erase" command should do the same quickly 
> as well.

Except that this doesn't protect against header backups, just like you 
mentioned before.

Kind regards,

More information about the dm-crypt mailing list