Am 2014-01-23 22:26, schrieb Milan Broz:
On 01/21/2014 11:40 PM, Jonas wrote:
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)?
Hi,
as Arno said, let's split this to two parts.
1. Have a secure erase that is easy to use. [...]
2. Have the option of unlocking a keyslot created with a specific
option to trigger the function implemented in 1. [...]
For 1, I think we can introduce new CLI command "erase" (with alias
luksErase)
which will remove all keyslots (in fact it is equivalent of
luksKillSlot called
for all active slots).
In libcryptsetup API it can be extension of existing
crypt_keyslot_destroy() call.
(It can be easily parameter to luksKillSlot but special command is easy
to understand and remember. Moreover, for some possible formats the
keyslot
in command name can be confusing - think TrueCrypt)
(And it should work for future other FDE formats as well. The main use
case
is that it removes master key from device but not ciphertext data
itself.)
This is not controversial and it is easy to use. Also it can be used in
distro
wrappers around cryptsetup. (I can imagine special emergency user login
which
will erase header. IMHO much better solution than 2.)
Great, sounds like a good plan.
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.
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 there is only negligible set of users who really have use for
nuke pwd
(I do not count "toy" cases.) Note the is already way to do it outside
of cryptsetup.
(BTW reencryption (regular key change) is way more better to increase
security - even
if anyone have old header backups, it makes these backups unusable.
And I still have very few reports of cryptsetup-reencrypt success
stories.
I would like remove experimental warning one day.
... While the list is full of nuke passwords mails...
While I see your argument, reencryption takes a lot more time than using
a
nuke feature. Both features serve completely different purposes.
And if you merely want to destroy access to the data, overwriting it is
still
better than reencrypting, isn't it?
Kind regards,
jonas
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
