Jari Ruusu wrote: > 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. -- 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/
