Re: [dm-crypt] Re2: nuke password to delete luks header

[Arno Wagner <arno@wagner.name>]

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@wagner.name
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