[dm-crypt] Encrypt all partitions with dm-crypt
arno at wagner.name
Fri Aug 24 16:47:55 CEST 2012
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?)
> 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.
> 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.
> One problem is safe manipulation with keyslot on device, the second is
> separation of metadata information (LUKS keyslots in this case) from data
> (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
> 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 Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt