A weak cryptoloop implementation in Linux?
Posted Sep 13, 2004 13:38 UTC (Mon) by schander
Parent article: A weak cryptoloop implementation in Linux?
The known-plaintext attack that is described is not specific to cryptoloop, but to just about any encrypted filesystem that does not pre-whiten the plaintext before encryption. Under no circumstance can this be called a backdoor in cryptoloop.
In any event, there are very simple existing userland fixes that make cryptoloop invulnerable to this kind of dictionary attack:
1) The simplest method involves the use of true cryptographically-random strings (from /dev/random, for example) as the first-level passphrase; encrypt them with a hashed, second-level salted passphrase as the key, and store the encrypted first-level passphrase with the salt. To setup the cryptoloop, just decrypt the encrypted first-level passphrase and use it.
(This is the approach that is taken by both pam_mount, as well as pam_losetup from my project, qryptix. In both cases, the main goal is to use the standard Linux login password (even with insufficient entropy) as the second-level passphrase. But the lack of entropy in the second-level passphrase is compensated for by salting and hashing it, and using it to encrypt a truly-random first-level passphrase. Any dictionary attacks on the second-level passphrase cannot be precomputed, because of the salt. Computing it on the fly will require calculating the hash, which is designed to be very slow.)
It also helped that util-linux-2.11 had another layer of ripemd160 hashing on the passphrase supplied to it, allowing for further whitening (just in case the entropy in /dev/random was inadequate).
2) Cryptoloop is also modular - this also us to iterate it two or more times with independent first-level keys, effectively multiplying the length of the key by the number of iterations. This is also easily supported in userland; qryptix, for instance, supports the use of multiple-iterated cryptoloops fairly trivially (e.g. /dev/hda9<->/dev/loop0<->/dev/loop1...).
With either of these two existing precautions, dictionary-based known-plaintext attacks on the filesystem, of the kind that Jari Ruusu describes, are a complete non-starter.
I fervently hope that Andrew Morton doesn't drop cryptoloop support in 2.6 because of this FUD. Cryptoloop just works, simply and reliably. I haven't ever lost a single bit of data using HVR's 2.4 kerneli patches.
to post comments)