On Tue, Jan 14, 2014 at 23:42:44 CET, Jonas Meurer wrote: > Am 14.01.2014 08:39, schrieb Arno Wagner: > > On Tue, Jan 14, 2014 at 06:01:38 CET, Jim O'Gorman wrote: > > [...] > >> I understand that you are concerned about the risk of being sent to jail > >> but I am not sure that concern is inline with what we are encountering in > >> the real world. If you look at the ACLU's guidance on the matter, > >> https://www.aclunc.org/blog/privacy-your-laptop-international-borders, the > >> risk of jail is not even mentioned. > > > > I recommend you read that page again: > > > > "This can put you in a very bad situation - disclosing the data or lying > > to law enforcement. Lying to US Customs or other law enforcement officer > > may result in criminal prosecution. Just ask Martha Stewart, who was > > indicted, under Title 18, United States Code, Section 1001, for lying > > to federal government agents." > > > > Now, a security professional will just stay truthful, understanding > > this. An ordinary person may lie and thereby land themselves in very > > hot water. > > While I get your arguments, I fail to understand why you oppose against > implementing the nuke password feature to cryptsetup. Huh? I think you do not understand my arguments at all. A) It puts people in danger B) It is unneeded, the function it actually can do is already there C) KISS applies. What more do you need? > From a theoretic point of view, this feature might not add much security > to your computer. But reality is more than just theory, and as Jim > clearly pointed out (and I agree with him), there's at least some > situations - at least for some people - where the nuke password feature > makes a whole lot of sense. Actually, none of _my_ points was theoretical. I pointed out that the arguments for a "nuke" option are theoretical and disconnected from the real world. > Also consider that there's many officials and (police) officers that > dont' know nothing about encryption techniques. Now imagine a situation > where one of these officers/officials powers on your laptop and asks you > to enter the password just before he's going to seize it. These > situations do happen (I know for sure). And they as well happen in > countries that don't send you to prison for denying to give them your > password. > While your supersafe password might be unbreakable for the forensics, > you will sleep much more soundly at night when you where able to nuke > all keyslots before, won't you? 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. Or, as Jim said, just say you do not know the password. But here you need a good reason. He had one ("my employer knows"), and his scheme allows giving the password to, e.g., free an employee from prison and there was not even the least bit of trickery or lying involved. > Thanks to Jim for describing realworld szenarios where the nuke password > feature might be of help. I would love to see it implemented upstream, > and am considering to add it to the Debian package a least. He did not. Actually, his process with nuke is more complicated (needs a header restore) than without (just needs a password transfer) and the people it applies to are not only security experts, they know well not to lie to any government agents and not to try to trick them (by nuking in real-time) and they can provide the password (impossible after a real-time nuking) if really needed. That keeps the associated risks under control. 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. Security is hard. One very important thing is to make sure non-experts cannot shoot themselves in the foot easily. "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. 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
