Disk encryption best practices?
Jens Lechtenboerger
I'm about to encrypt my disk with loop-aes, and I'm wondering
whether this is a clever move:
1. The introduction (in German) at
http://wiki.chaostreff.ch/index.php/Festplattenverschl%C3%BCsselung
recommends not to use AES but to prefer Twofish.
In addition, GnuPG uses CAST5 as default for symmetric
encryption.
What is the state-of-the-art here?
2. The text at http://mareichelt.de/pub/texts.cryptoloop.php
warns against mainline cryptoloop:
"Both cryptoloop and dm-crypt in kernels prior to 2.6.10 are
vulnerable, and even recent dm-crypt still suffers from a weak
crypto implementation."
What is weak here?
3. The German Linux-Magazin 10/06 (http://www.linux-magazin.de)
features an article by Peter Gutmann and Christian Ney, where
they analyze different types of crypto filesystems. They
recommend Truecrypt, dm-crypt is second, and they essentially
warn against loop-aes:
They state that the code is complex and written in such a way
that it is difficult to judge whether it does what it is supposed
to do. In addition, return values are never checked (e.g., when
computing encryption keys), which might lead to a key consisting
of just zeros. However, the code is so sloppy that programs are
more likely to crash with null-pointer dereferences than to use
empty keys. Besides, they complain that by default passwords are
not salted and password hash iterations are not used.
The part about code quality sounds scary. Opinions?
Concerning salting and iterations, for my root partition, I just
have to uncomment to lines in build-initrd.sh, right?
Concerning Example 2 in the loop-aes README (partition backed
loop with gpg encrypted keys), I get salting and iterations with
the gpg patch provided with loop-aes, right?
I'm curious...
Jens
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
Gisle Sælensminde
>Hi there,
>
>I'm about to encrypt my disk with loop-aes, and I'm wondering
>whether this is a clever move:
>
>1. The introduction (in German) at
> http://wiki.chaostreff.ch/index.php/Festplattenverschl%C3%BCsselung
> recommends not to use AES but to prefer Twofish.
> In addition, GnuPG uses CAST5 as default for symmetric
> encryption.
>
> What is the state-of-the-art here?
>
>
>
AES has no known weaknesses, is quite fast, and is the most analyzed of
those algorithms, so
most cryprographers would recommend AES. Twofish was one of the five
final algorithms in
the AES competition, and is quite well analyzed as well, but less than
AES (or Rijndael, as it was
known as during the competition). Twofish has gained some popularity in
the open source circles,
and can as well be used instead of AES, but there is no reason to
recomend it over AES/Rijndael.
CAST5 was also a candidate for AES, but did not make it to the final,
and is thus less well analyzed
than the other. That is not saying that it is broken in any way, but I
would prefere AES or Twofish.
>2. The text at http://mareichelt.de/pub/texts.cryptoloop.php
> warns against mainline cryptoloop:
> "Both cryptoloop and dm-crypt in kernels prior to 2.6.10 are
> vulnerable, and even recent dm-crypt still suffers from a weak
> crypto implementation."
>
> What is weak here?
>
>
>
A weak IV scheme made it possible for an attacker with access to the raw
storage to see
which bytes of a block that was the first modified, but not see what the
change was. Newer loop-aes
implementations has fixed this problem.
Jari Ruusu
> 1. The introduction (in German) at
> http://wiki.chaostreff.ch/index.php/Festplattenverschl%C3%BCsselung
> recommends not to use AES but to prefer Twofish.
> In addition, GnuPG uses CAST5 as default for symmetric
> encryption.
>
> What is the state-of-the-art here?
Both AES and twofish are good. AES is little bit faster.
> 2. The text at http://mareichelt.de/pub/texts.cryptoloop.php
> warns against mainline cryptoloop:
> "Both cryptoloop and dm-crypt in kernels prior to 2.6.10 are
> vulnerable, and even recent dm-crypt still suffers from a weak
> crypto implementation."
>
> What is weak here?
http://marc.theaimsgroup.com/?l=linux-kernel&m=107719798631935&w=2
Above mentioned IV computation weakness is fixed in newer dm-crypt versions,
but the IV is still non-changing (for same sector number), which leaks
location of changed data in some unusual situations. In normal use that is
not a big problem.
> 3. The German Linux-Magazin 10/06 (http://www.linux-magazin.de)
> features an article by Peter Gutmann and Christian Ney, where
> they analyze different types of crypto filesystems. They
> recommend Truecrypt, dm-crypt is second, and they essentially
> warn against loop-aes:
I tried to look for that Linux-Magazin article, but I didn't find it
on-line. Do you have a URL for it?
> They state that the code is complex and written in such a way
> that it is difficult to judge whether it does what it is supposed
> to do.
In other words, they didn't spend enough time to understand it.
> In addition, return values are never checked (e.g., when
> computing encryption keys),
Prototype for that particular key setup function:
extern void aes_set_key(aes_context *, const unsigned char [], const int, const int);
It returns void type, so there isn't much return value to check.
> which might lead to a key consisting of just zeros.
No it doesn't.
> However, the code is so sloppy that programs are
> more likely to crash with null-pointer dereferences than to use
> empty keys.
What null-pointer dereferences? That code has been running on my boxes for
more than 5 years, and during that time it has NEVER dereferenced
null-pointer. That pointer math looks kinky, especially when runtime key
scrubbing is enabled, but to my knowledge it is 100% correct.
> Besides, they complain that by default passwords are
> not salted and password hash iterations are not used.
Loop-AES has supported salted+iterated passphrase hashing for many years.
For long time, the recommended way has been to use gpg encrypted key files.
gpg does salted+iterated passphrase hashing as a countermeasure against
optimized dictionary attacks.
Maybe they just didn't bother to read the README file?
> The part about code quality sounds scary. Opinions?
Difficult to understand? Maybe.
Bad quality? Definitely no.
> Concerning salting and iterations, for my root partition, I just
> have to uncomment to lines in build-initrd.sh, right?
> Concerning Example 2 in the loop-aes README (partition backed
> loop with gpg encrypted keys), I get salting and iterations with
> the gpg patch provided with loop-aes, right?
Please leave those PSEED= and ITERCOUNTK= commented out in build-initrd.sh
script. They had some use many years ago, and they are still there for sake
of compatibility. There might still be someone using them.
gpg does passphrase salting + iterations for you. Even unpatched gpg does
that. The gpg patch makes gpg do 128 times more iterations that normally
while still being compatible with RFC2440 spec.
You do NOT want to do salting+iterations again in losetup/mount for second
time, because actual loop encryption keys that gpg decrypts for you are high
quality random keys that originally came from /dev/random.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
Jens Lechtenboerger
> [...]
> I tried to look for that Linux-Magazin article, but I didn't find it
> on-line. Do you have a URL for it?
I'm afraid it's not available online.
Many thanks for your answers.
Jens
Jari Ruusu
> Jens Lechtenboerger wrote:
> > 3. The German Linux-Magazin 10/06 (http://www.linux-magazin.de)
> > features an article by Peter Gutmann and Christian Ney, where
> > they analyze different types of crypto filesystems. They
> > recommend Truecrypt, dm-crypt is second, and they essentially
> > warn against loop-aes:
>
> I tried to look for that Linux-Magazin article, but I didn't find it
> on-line. Do you have a URL for it?
Christian Ney was kind enough to send me english language draft of the
article. It might not be exactly what was printed, but at least I have
something to quote and respond to.
Quote from the article:
| Loop AES is available as a series of Linux kernel patches
One patch for 2.6 kernels, one patch for 2.4 kernels, or alternatively,
outside of kernel tree buildable kernel module that builds for all recent
2.6, 2.4, 2.2, and 2.0 kernels. Module version doesn't need any kernel
patching.
| the behaviour of the encryption can change radically depending on which
| compile or runtime configuration options are chosen
Compile time configuration options do not change on-disk format. Having
optimized assembler implementations available for popular processors (x86
and amd64) and instruction set extensions (VIA padlock) are good things to
have.
Runtime configuration options are needed for compatibility with old on-disk
formats. Killing compatibility with old on-disk formats is not responsible
thing to do.
| the code makes it quite difficult to pin down exactly what's going on, or
| whether it's actually doing what it's supposed to be doing.
The code is difficult to read, I agree.
Short version of what it does, is here:
http://mail.nl.linux.org/linux-crypto/2006-05/msg00049.html
| LoopAES uses an unsalted hash of the password, applying a single iteration
| of a hash function like SHA-256 or SHA-512 to obtain the disk key
[snip]
| makes it trivially vulnerable to a precomputed dictionary attack
That obsolete code path is there for backward compatibility only. All
examples in the README file and losetup man page use version 3 multi-key
mode, and none of above applies to those examples. For many years, the
recommended way has been to use gpg encrypted key files. gpg uses
salted+iterated key setup, so precomputed dictionary attacks won't work.
| Data is encrypted with AES in CBC mode <<<kernel-2.6.15.diff, line 737>>>,
| with a confusing array of IV-processing options using either the raw
| sector number or an MD5 hash as the IV.
Raw sector number IV is there for backward compatibility only.
| no function return codes are ever checked, so if anything goes wrong the
| code continues with all-zero keys or unencrypted data.
aes_set_key(), aes_encrypt(), and aes_decrypt() functions return void type.
To check return value of void returning function would be a bug that
compiler would refuse to compile. Those functions never return any error
because they do not have any error situations that can make them return
failed status.
If above mentioned functions, or other kernel called driver hooks, are
passed invalid pointers, then pointer dereferencing will cause kernel mode
exception, and the process will cease executing with kernel "Oops", and the
function never returns. As for RAM pre-allocations that are done at loop
device set up time, all pointers are checked at least once at allocation
time, but not thereafter.
This claim of "continues with all-zero keys or unencrypted data" is
completely bogus.
My conclusion of this article's loop-AES section is that the technical
review was done in hurry, and for some unknown reason seems to focus on bits
that were obsoleted years ago. Maybe the reason of such mistake is because
the source code does not have explicit comments about which sections of code
are for handling obsolete compatibility bits.