On Thu, Jan 23, 2014 at 22:26:42 CET, Milan Broz wrote:
> 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.
This should work well and allow anybody to do a reliable erase.
> (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.)
Indeed. The future-proofness is one argument for this that I
had not thought about, but it is a good one.
> 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.)
Or have anybody that wants it write a wrapper around cryptsetup
that triggers the erase on a specific passphrase. For the situations
described that is about as good as integrating it. In fact it is
better as it is simpler and customizable and there is no need to mess
with key-slot semantics.
> For 2, (aka self destroy passphrase) - I tried to read the discussion
> again and I am really not convinced yet we want it.
Same here. I think it is about half for, half against, but the "for"
have really weak arguments. The idea of this feature and the reality
are vastly different. With an "erase" command people can however
script whatever they want and it is still going to work with future
versions of cryptsetup.
> 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?
Simple: 1. Reencrypt all data
2. Erase all keyslots
That is the "ultra-slow" variant of destroying the data ;-)
> Try it... or better not ;-) And there are more missing code which just
> do not convince me that it was properly thought-out work.
>
> 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...
> One would remember http://bikeshed.com/ ... ehm, sorry :-D)
>
> ...
>
> Whatever, I can implement 1) easily (even in 1.6.4).
>
> The 2) is question for next version (1.7) but as I said - my current
> opinion is still it is not worth to do it.
Same here. And with 1) there is really no reason to patch
cryptsetup anymore. Wrappers are a lot easier with it.
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
----
A good decision is based on knowledge and not on numbers. - Plato
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
