Hi, I'm a crypto implementer and want to run a crypto file system under Linux. I'm looking at loop_aes and I like its simple design and installation. I have a few comments about the cryptography. - The docs in several places advice generating the AES key from a password and a "salt". I think the docs should advise using a passphrase generated by selecting words at random from a dictionary, rather than a password. <http://www.diceware.com> gives a good way to do this. I've implemented the diceware algorithm on a web page: http://www.nightsong.com/crypto/dice.php the phrase generator is written in client side Javascript, so the server never sees your phrase or the seed entropy that you supply. - The method of generating AES CBC initialization vectors for file system blocks has some minor weaknesses: - the IV for a disk sector is simply the sector number, so if an attacker can copy your hard drive without your knowledge, then you change something (e.g. update a database field) and the attacker reads the disk again, he can tell the exact location (in AES blocks) of the first change in the sector. Colin Plumb has a clever method (used in Peter Gutmann's SFS) for computing an IV based on the whole contents of the sector: http://groups.google.com/groups?selm=7gicpf%24k21%241%40scream.auckland.ac.nz - Since the IV is just an increasing integer sequence, it's not completely implausible that some file has sectors whose first AES blocks, when xor'd with their sector numbers, give the same IV. Suppose file A begins on sector 536 and its first four 32-bit words are 0 0 0 1. File B begins on sector 537 and its first four words are all zero. This means both files get the same IV and if their next several blocks are equal, the attacker can tell that. Colin's scheme helps that; encrypting the IV (with a different key than the FS key) before using it would help too. - If you have two file systems encrypted with the same key, they get the same set of IV's and the attacker can find all the sectors that are pairwise equal (or have common prefixes) between the two FS's. In fact if any common prefixes exist, that tells the attacker that both encrypted FS's probably have the same key, also not a good thing. Using separate salts helps with this prob but is inconvenient if the FS's are removable (such as CD-roms). Maybe a mount option could be added to use the cd-rom volume ID as a salt, so the user doesn't have to type a salt at mount time. When writing the CD you'd generate a random string to use as the volume ID. I also have a question: suppose I have a normal ext3 file system on a partition. Can I unmount it, encrypt it in place with aespipe, and then mount it through the loopback fs? I don't have another free partition to transfer to. Thanks/regards Paul Rubin Fort GNOX Cryptography - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
