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

[Heinz Diehl <htd@fancy-poultry.org>]

On 03.08.2009, Henrik Theiling wrote: 

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

So we'll never know unless someone with enough expertise can tell us the
truth.

> > 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.

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

The weakness is not related to the algorithm itself, but to the IV generator.
I would maybe have used xts in this case and had the harddisk divided in three
partitions with 500GB, using a different key for all of them.

> 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.

Ok, if your data are not likely to get stolen by one of the organisations
with the three huge letters, I would say that it makes no difference what
algorithm or method you are using. I would have choosen the one which
provides the highest speed. I think that 99.9999999% of all people in the
world are not able to do a successful attack on one of the supported
algorithms and operation modes. So it does not matter if you are using it
for wiping a harddisk, storing your data securely or have to send in a
broken harddisk to the servicefolks.

The main weaknesses are often related to a bad passphrase or different
circumstances which makes it easy for an adversary to get it, e.g.
writing down the passphrase or choosing not enough entropy.

> 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.

To know that for shure, this is up to the people who have written this
beautiful piece of software, who have designed the methods/algorithms
by themselves or ones who are able to fully understand the sourcecode.

> > 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.

That was not my intention, they are all listed in this file, and you can
see what you will have to choose from.

> So you decided by speed alone?  Because you think any option is strong
> enough security for you? 

Yes.

> 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).

Multi-layered encryption is just stupid. See Kerckhoff's principle:
http://en.wikipedia.org/wiki/Kerckhoffs%27_principle

With regards to my little knowledge, the algorithm which is most secure per today is serpent,
I probably would have choosen "-c serpent-xts-benbi:sha256 -s 512" and had
the harddisk gotten divided into three partitions of 500GB. This results in
Serpent-256 encryption (256 bits go to XTS).

> > A lot of distributions also use "-c aes-xts-benbi:sha256".
 
> And why do they do so?

That's the question :-)
I simply don't know. We can only guess. There's so much disinformation and
uncertainty out there. I don't know.

PGP WDE e.g. uses (hardcoded) AES-256 in EME mode, and the key is derived
via the STR2KEY function. But _why_ they use it (maybe they think or know
this is the securest possibility?!), I don't know either.

Sorry I can't help you out.