Ok, here is one proposal: 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. 2. Have the option of unlocking a keyslot created with a specific option to trigger the function implemented in 1. 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". 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. 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. But please, keep the discussion going by any means, especially for cases where my function 2. is needed when 1. is already available. 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 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
