Re: [gentoo-user] Luks: Which cipher to use

[Mike Kazantsev]

On Tue, 8 Sep 2009 11:21:12 +0200
Marco <listworks@×××××.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