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,
jonas
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
