On Wed, Jan 15, 2014 at 11:00:32 CET, Jonas Meurer wrote: > Am 2014-01-15 07:01, schrieb Arno Wagner: > >Huh? I think you do not understand my arguments at all. > > > >A) It puts people in danger > > > >[...] > > > >I do not think I need to repeat how dangerous, disconnected from > >reality and stupid this approach is, do I? Your "analysis" shows > >perfectly why having a "nuke" option is not a good idea. People > >will start taking risks (carrying sensitive data, trying to nuke > >in a dangersous situation) they would otherwise not take because > >they will wrongly think this method protects them. > > > >Here is a real-world scenario: You do not nuke, but you pretend > >to give a password, yet it is invalid. Guess what, before > >a forensic examination, this behaves exactly the same as "nuke"! > >After a forensic examination, they _will_ suspect you of having > >nuked the password in the nukle case. Not good at all. > > I fail to see the point of your "dangerous" argument. Obviously. And there is the problem. > A lot of things/tools/techniques are able to put people in danger. Yes. But there are tools aimed at the general public and tools aimed at experts. Quite a few things you cannot even buy if you are not a qualified expert. LUKS is used by a lot of people that are not experts, just look at the mailing list. > Still > they're useful. With the same logic, you could argument against > cryptography in general. People could actually forget the password > and see themselves confronted with a bad evil person/institution/ > state who tries to force them to tell the password. Yes. They could. That is why I strongly recommend not having encrypted data in the first place when going into these kinds of situations. And I am not the only one recommending that. See, for example: https://www.aclunc.org/blog/privacy-your-laptop-international-borders > There's quite some situation where being accused of having nuked > the password is not a problem at all. In german law for example, > you're not required to help investigative authorities with their > investigations. Actually, it's not a criminal action to destroy > your data. Indeed it is, if the data itself is criminal. But that > has to be proved first, which might be much harder in case that > it's not recoverable anymore. > > As I tried to explain above, I still see legitimate scenarios > for using a nuke password function. Yes, obviously you do. I, frankly, do not. Not at all. And I have been thinking about this one for a few years, see, again, the mailing list archives. All scenarios I have seen so far where either highly constructed or did not require extension of the current functionality. "Nuke" has just one real use: To trick an attacker in real-time. To do that sucessfully requires either talent and training or a lot of luck. The tecnical part is a minor part. Many people will fail to see that. And if it fails, consequences can be bad. > In cases where using the feature makes things worse, people > should not use it. But this decision has to be made by the > individuals themselves. Not implementing a feature because > people could use it in a stupid way is not an argument, is it? That is not the argument. The argument is that a function aimed at experts should not be placed into the hands of non-experts because they cannot evaluate the associated risks. This is not an argument that they are stupid. But you would not allow ordinary people to drive race-cars or use explosives or presciption-medicine like antibiotics and just rely on them to know what they are doing. The problem is that literally non-experts cannot see the dangers of expert functionality anbd quite often cannot see the limitations of their understanding and some will not err on the side of caution. > I agree with you, that controversal features need some extra > protection and documentation. But this can be fixed easily: > the process of setting a nuke password could include a big > fat warning and point to further documentation. Yes, "ARE YOU SURE YOU WANT TO NURKE YOUR PASSWORD AND MAKE THE DATA PERMANENTLY INACESSIBLE?" That is going to work well when used in a "nuke"-situation. And putting it just into the documentation is or set-up is _NOT_ enough. For reference, see the mailing-list archive. There is a wide selection of people asking for help after they have overlooked even the strongest warnings, up to and including people that ignored the warning on luksFormat that requires you to confirm with an uppercase "YES". This is basically impossible to fix well without negating the intended functionality. > The argument against false sense of security again could be > used for every security technique. People do need to understand > the limitations of security and cryptography. Actually, they do when they want to do advanced stuff, like tricking law-enforcement in real-time. That is not a beginners game at all and one that it is best not to play. > That's what > documentation is for (and by the way: your FAQ is a great > example of doing documentation right. Thanks for your work on > it!) Thank you! Arno > >[...] > >Nuke is a bit like carrying a gun: Instead of running away (which > >is a surprising effective strategy), people will try to stay and > >fight. This may work sometimes and will get them killed sometimes. > >Running away or avoiding the situation in the first place is > >much, much safer. This risk analysis is different for somebody > >that has a) training in using a gun in a fight and b) authorization > >to use a gun in certain situations and training in recognizing > >these situations. > > Phew! If it at all, nuke passwords are a defensive weapon. And > then, Actually, I don't like the comparison at all. Would you > compare cryptography with an armor? Then, this again could encourage > people to be more brave, to stay and fight, whatever. > > >Security is hard. One very important thing is to make sure > >non-experts cannot shoot themselves in the foot easily. > > I agree with you on that to some extent. But ... > > >"nuke" makes that far more easy as non-experts do not understand > >its implications, and hence it has no place in a tool aimed > >at the general public. > > I don't agree on that, as I tried to explain above. Sorry if my > arguments don't come straight. I try my best to explain, but > writing in a non-native language implicates some limitations :( > > Kind regards, > jonas > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- 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
