Ok, here is one proposal:[snip]
Lets split this discussion. I think this simplifies things.
1. Have a secure erase that is easy to use. This will
help anybody that is not a technical person but
needs to securely get rid of a luks header fast when
still free to act as thay chose.
This can just be a key-slot kill for all slots or the like.
It can also be a full header erase.
Maybe "cryptsetup luksEraseAll" or something like it
and requiring a "YES" like luksFormat.
I think having 1. generally is good, as it is a dedicated operation
that really does only one thing and does it well, namely making
the LUKS container irrecoverable while the user is still free to
act as they chose. The journalist from the example would only need
to memorize this one command ad an emergency "red button".
I agree. Also, the same journalist could create an alias (say alias EMERGENCY="/sbin/cryptsetup luksEraseAll /dev/sda"), set a NOPASSWD option ini /etc/sudoers (if he's using sudo) and have a
$ sudo EMERGENCY
that triggers (1).
Even faster, and pretty useful to him
Even faster, and pretty useful to him
2. Have the option of unlocking a keyslot created with a specific
option to trigger the function implemented in 1.
[snip]
For 2. all the pros and cons apply though. I would at the very
least make its presence a compile-time option and put very strong
warnings that this is dangerous in the documentation. It may still
be desirable to not have 2. at all (I think it is so, as it does more
harm than good), as it really is only something useful when already
not free to act or under close superwision of what command one types.
And that is a situation that is highly problematic and we cannot even
come close to help the user mastering this situation.
While it's actually not a "command", that a person is typing, but just a password, a question comes to mind:
Once you get to the password prompt, it's clear you have an encrypted disk. So, unless you're really, really, really in trouble you'd never use the "wipe" password.
Three cases come to mind:
1) you have something really, really illegal on your HD and you get stopped at a security checkpoint. In this case, (a) you're an idiot who took that kind of stuff on a laptop instead of having a clean laptop and retrieving it via a secure connection and (b) even if you wipe your hard drive you're in big trouble, because they'll know you did it.
Three cases come to mind:
1) you have something really, really illegal on your HD and you get stopped at a security checkpoint. In this case, (a) you're an idiot who took that kind of stuff on a laptop instead of having a clean laptop and retrieving it via a secure connection and (b) even if you wipe your hard drive you're in big trouble, because they'll know you did it.
2) Your life is in danger and somebody wants something from your laptop: what do you think will happen then, if you wipe your key?
The only real time you're going to need such functionality is if you have data on your computer, you know someone's coming and your computer is turned _off_: you have very little time, so you just boot, type in the wipe password and unplug.
In this case, though, it's not enough wiping the keyslots: you'd have to wipe the entire header, because otherwise the only thing that "someone" will see is you not giving them the correct password.
As tool-makers we have a responsibility to balance functionality
and risks as we understand the tool better than most of the users.
Of course, the user may understand the situation he finds himself
in better than we do (or not), but that is why it is a balance.
Neither "deny everything even a bit riksy" nor "allow everything"
is morally right for a tool that is mainly used by non-experts.
I believe that the best course of action in this case would be to implement it as "highly experimental not guaranteed[1]" with a (or a couple of) compile flag, but at least we can give the users a choice. And, with a compile flag, very few people are going to be able to put that in place.
I must admit I did not read the 60+ emails in the whole discussion, so I might have repeated something someone had already said.
If so, please disregard it :)
Cheers,
Claudio
If so, please disregard it :)
Cheers,
Claudio
[1] Not guaranteed because of the issues with SSDs.
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
