[dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

Henrik Theiling theiling at absint.com
Mon Aug 3 18:16:41 CEST 2009


Thank you for you interesting reply!

Heinz Diehl writes:
>> It seems cbc-essiv is susceptible to watermarking (according to
>> Wikipedia, which claims that no IV obfuscation algorithm protects
>> against this except in the initial block.  Unfortunately, I cannot
>> verify this, so it sounds bad to me.
> ESSIV has been develop to address this problem and is not prone to
> watermarking. The developer of ESSIV is here on the list, and maybe
> you're lucky and he will explain this a little bit closer to you.

Yes, I know he is on this list.  And I know it was invented for that
purpose.  But still, Wikipedia claims:

> To protect against the watermarking attack, a stream cipher is often
> used to generate the IVs from the key, so that an adversary cannot
> predict them. In particular, the ESSIV approach discussed below uses
> a block cipher in CTR mode to generate the IVs. Another option would
> supplement this IV with a hash function applied to every block but
> the first. However, neither of these options guards against the
> decryption attack above.
Q: http://en.wikipedia.org/wiki/Disk_encryption_theory

Quite obviously not all is true that's written out there, but there we
are: I just do not know. If any trustworthy person told me that the
above is rubbish, it would be fine with me.

>> And then, xts-plain is said to become weaker on large disks, and some
>> crypto implementations warn about this weakness for disks as small as
>> 500GB.  So what's the alternative?
> So they who has raised these claims you described above didn't provide an
> explanation for their statements?

IIRC, the weakness itself was discussed on this list a few months ago.
Here's another source:

> According to the IETF NIST submission[0] for the tweakable block
> cipher xts (and I paraphrase here, as the document prohibits direct
> quotation): the proof yields strong security guarantees as long as
> the same key is not used to encrypt much more than 1 terabyte of
> data. Up until this point, no attack can succeed with probability
> better than approximately one in eight quadrillion. However this
> security guarantee deteriorates as more data is encrypted with the
> same key. With a petabyte the attack success probability rate
> decreases to *at most* eight in a trillion, with an exabyte, the
> success probability is reduced to *at most* eight in a million.
Q: http://tinyurl.com/np9wum

I'd like to use an algorithm without such a weakness.

>> I don't seem to be able to make a decision on my own, so I'd like to
>> ask for help.
> We shall decide for you?

No, of course not!  I'd be very happy with pointers to more
information so I can judge myself which problems are bad for me and
how I can avoid them.

> That's generally a bad idea. There's only one person with the whole
> knowledge, and that's you.

I'd love that to be true!  But I do not have all knowledge concerning
the likelihoods of the attacks, and also lack knowledge about how to
avoid the weaknesses.

> I don't know why you want to have your harddisk encrypted, ...
> what kind of data you have, how important they are for yourself and
> others, how the potentially encrypted harddisk is secured else, and
> so on and so on...

There is no immediate threat or strict confidentiality involved, but
I'd like to keep all my data private, e.g. in case it is stolen, and
because it's easily done.  Plus very secure erasure of encrypted hard
disks is very quick by overwriting the keys (in case I don't want to
use them anymore).  Further, if a disk is broken, I can send it in
without companies being able to read plain text.

But I'd like to avoid mistakes of using a weak encryption algorithm,
so I would like to understand what are the pros and cons for cbc-essiv
or xts-plain or any other alternative.

> You can take a look at dm-crypt.c to find out what methods of IV
> generation are supported by LUKS/dmcrypt.

Encryption algorithms are very complex beasts, and I do not think from
reading source code I could see any subtle weaknesses myself.

>  -c twofish-cbc-essiv:sha256
> in case it gets lost or stolen, to prevent the thieves from getting
> access to my money. I decided to use just this algorithm because I
> did some benchmarking and it performed best (the major drag on a
> Laptop is the slow harddisk).

So you decided by speed alone?  Because you think any option is strong
enough security for you?  Speed is not really an issue for me -- any
simple option is very propably fast enough for me (except maybe
multi-layered encryption, which would seem like overkill to me).

I read a lot of manuals, all using one or another particular setting
for -c, but without explaining why exactly that one was chosen for the
examples.  Is feels arbitrary.  E.g. I used aes-cbc-essiv:sha256
before, because I found this recommendation in a manuals.  But now I
have larger disks and, of course, there are new algorithms and more
understanding of old ones, so now the recommendation might not be
valid anymore (it was without explanation in the first place).

> A lot of distributions also use "-c aes-xts-benbi:sha256".

And why do they do so?


More information about the dm-crypt mailing list