A weak cryptoloop implementation in Linux?

Posted Sep 13, 2004 13:38 UTC (Mon) by schander (guest, #24686)
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

A weak cryptoloop implementation in Linux?

Posted Dec 12, 2004 22:56 UTC (Sun) by markus76 (guest, #26625) [Link]

first of all, really "true cryptographically-random strings" would be directly derived from radioactive decay (which is purely random by nature), not from something inside a computer which is pseudo-random at best.

setting up several layers of encrypted block-devices is not the idea of cryptoloop both from a plain user's point of view and the ppl who introduced it into mainline kernels. it may work, but it is clumsy and unefficient.

nobody said one could lose data when using mainline cryptoloop, it's just a Bad Idea to do so. at least for data you want to be secure, anyway, and what is the point of using cryptoloop if your data is not secure? btw, when jari speaks of _equivalent_ to back door he means _equivalent_ to back door and not back door itself. should be obvious, but i got the impression that ppl increasingly start reacting to some kind of pavlov's bell instead of using their brain in the first place (no offense intended, just venting needed).

mainline cryptoloop is just not to be recommended if you want your data secure. a certain researcher in cryptography (whom i won't mention here, since he's got too much public attention already about just the same "trivial" topic we speak about) also points out these disadvantages of cryptoloop when it comes to security, he's given talks about it on security conferences, wrote articles, .... - what more info do you need?

if you want your data secure and want to stick with cryptoloop for the fun of it, that's fine with me. but don't try to evangelise mere users to believe cryptoloop is subject to some kind of bashing contest! it is not! let ppl make up their own minds, their data is their stuff, and turf.

cryptoloop is not a bad idea basically speaking, but it really needs to be fixed if it is to be used for the stuff is was made for: securing your data and not giving crypto(loop) a bad name.

/amen :-)