Jens Lechtenboerger wrote: > 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 - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
