On Tue, 8 Sep 2009 11:21:12 +0200 Marco <listwo...@gmail.com> wrote: > I am about to encrypt my external hard drive. I found the howtos > http://de.gentoo-wiki.com/wiki/DM-Crypt and > http://de.gentoo-wiki.com/wiki/DM-Crypt/Daten-Partition_verschl%C3%BCsseln > (sorry, German...). They give a good understanding of how to do the > stuff, but I am unsure about which cipher to use. LRW is considered > insecure in some cases so thus it should be replaced by XTS which is > experimental though... Furthermore, if using XTS is used, there is > different options like xts-plain, xts-benbi, xts-essiv:sha256. Which > option is preferable? What about the key size? Is there any relation > between key size and block size of the file system in terms of data > security?
I might be wrong here, since I'm not a crypto expert, so feel free to correct, but here's how I see it... From dm-crypt.c: Different IV generation algorithms: plain: the initial vector is the 32-bit little-endian version of the sector number, padded with zeros if neccessary. essiv: "encrypted sector|salt initial vector", the sector number is encrypted with the bulk cipher using a salt as key. The salt should be derived from the bulk cipher's key via hashing. benbi: the 64-bit "big-endian 'narrow block'-count", starting at 1 (needed for LRW-32-AES and possible other narrow block modes) null: the initial vector is always zero. Provides compatibility with obsolete loop_fish2 devices. Do not use for new devices. IV (Initialization Vector) is just a piece of random data to mix with stuff-to-encrypt for a disk block, so two blocks, encrypted by the same key won't look the same. Obviously, you need to know it to get the data back. Some sort of "salt" for a stream ciphers, but it doesn't get recorded anywhere, being calculated on-the-fly by one of the above methods. Note that 'always zero' approach would produce unsalted data, so not only the blocks can be identified, but also swapped - root-owned data can be pushed into some /tmp file (say, at night), which will be accessible by some malicious code after you'll enter the key. Plain and benbi seem to be simple counters, second one is probably just a multiple of the first, counting cipher blocks instead of disk blocks. These rule out the former case, but allow to write similar blocks of data, which can later be easily found on disk, especially if the length of data between them is known, since IV is absolutely predictable. ESSIV, on the other hand, uses the hash of these counters with the key itself to salt IV, so it seem to rule out all the aforementioned vulnerabilities. Hash strength here ensures that it can't be turned into former 'plain counters' case due to hash collision. XTS/LRW/CBC/... are methods to encrypt the single data block to a disk block. Since data is read in blocks, block also seem to be the atomic unit of data encryption - everything is en-/decrypted in whole blocks when read/written from/to disk. These methods further divide the disk block into a smaller units to ensure that there won't be a (similar to the above) case when two similar, say, 16-byte pieces in a single 512k disk block would look identical, otherwise some data with such watermarks can be generated and proven to be on this disk - whole blocks can be marked with them, so they can later be found, along with any known data between them. They also mix the key with some generated salt for these units. CBC relies on plain data, so it can be broken by crafted data. LRW also seem to suffer from some known vulnerabilities, so XTS seem to be the best and recommended one. And the first part of some definition like "serpent-lrw-benbi" is a cipher itself - the method of mixing the key with data, so they can't be easily separated. There are plenty of cipher benchmarks out there (openssl has one built-in) and the vulnerabilities are quite known. Rijndael, known as AES, being the standard, is very fast, but is a subject to all sort of scrutiny. Last thing I heard is that AES-256 is actually easier to break (although it hasn't gone that far) than AES-128, but that stuff can be easily found on a regular newsfeeds. -- Mike Kazantsev // fraggod.net
signature.asc
Description: PGP signature