Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner <arno@wagner.name>]

On Fri, Aug 24, 2012 at 04:01:11PM +0200, Milan Broz wrote:
> On 08/23/2012 09:34 PM, Arno Wagner wrote:
> >> Well, you can have detached LUKS header on USB flash disk (optionally
> >> with the whole boot partition) for example.
> > 
> > That is not really a good idea. LUKS on Flash/SSD may not work 
> > as intended. I just added an entry for that to the FAQ (5.17). 
> > For some scenarios, plain dm-cryp is just the way to go.
> > Of course, it requires some understanding, e.g. a high-entropy
> > passphrase is a must.
> 
> (Where do you want to store that high-entropy passphrase?
> I guess most of people will use... USB disk?)

My head? 
 
> Well, I think it is not that simple. You MUST HAVE high-entropy
> passphrase in plain dmcrypt because encryption key is directly
> computed (hash) from it.

Indeed. 

> Too easy for people to do this step wrong, which causes worse problems
> than flash disk problems.

That is why plain dm-crypt is not for beginners. Most people
will be best served by using LUKS. But unless it is a massive
development or maintanance problem, having plain dm-crypt as 
an option should not be an issue. Or do you see any larger
problems supporting both?

Plain dm-crypt is useful in special situations, for example
for decrypt_derived or when you have very little space. There
are others as well.

> (Moreover, strandards like FIPS140 explicitly forbids any encryption key
> derived directly from passphrases.)

Well, for non-experts that is reasonable. Some people still
may want to derive keys from  high-entropy passphrases.
FIPS140 is important, but it is not everything.
 
> LUKS uses kernel RNG to generate encryption key, always.
> 
> There is currently a lot of effort to ensure that /dev/urandom
> cannot produce weak data even in extreme situations.

Good.
 
> One problem is safe manipulation with keyslot on device, the second is
> separation of metadata information (LUKS keyslots in this case) from data
> device.
> 
> (Dictionary attack is not possible for LUKS device if header is not
> available, but it is possible for plain dm-crypt with weak passphrase.)

As amply warned about in the decumentation. LUKS and plain dm-crypt
have different philosophies: LUKS tries to protect the user at
all cost, while plain dm-crypt gives as much control to the user
as possible. That measn most users should go the LUKS way. 

> I have several notes to this disk/flash/SSD and will post it as separate
> mail...
> 
> But anyway, it all depends on threat model.
> 
> If it is only about securing data when laptop is stolen, no problem to
> use SSD or flash disks. This should be mentioned IMHO because it is
> most common use case.

I agree. What you lose is secure key-management (old keys may 
still work) and reliable wipe by header overwrite. Both do
not matter in the generic stolen-laptop scenario. The first 
may matter if the theft is a targetted attack. The second may
matter if you want to implement active tamper-proofing. 

I will add the "generic stolen Laptop" to the FAQ.
 
Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell