Re: [dm-crypt] XTS cipher mode limitations

[Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>]

Hi.

Sorry for re-visiting this issue one (hopefully) last time... but at
least to me not everything was fully clear yet.
And I guess having a final conclusion which we could also put in the FAQ
would be not to bad.

With respect to XTS:

1) I guess we've already concluded that it's one of the securest modes
available (if not the securest),... also protecting against certain
attacks for which the others are vulnerable.


2) There was this IV boundary issue when using just "plain",... but this
is effectively none, if one uses "plain64"... as this is enough for
2^64*512byte volumes.
Right?


3) There was a limitation on the block size, used with XTS, right? But
as we _always_ use 512 byte (even if the device below uses larger
sectors), we're fine anyway.
Right?


4) There was the (general issue) that if an attacker can make
snapshots,... you can only write some amount of data (with the same key)
until probability increases that attacks are possible, right?

Is this only the case when he can make snapshots?

In XTS, this starts to get a problem after about 100TB (IIRC) of data
have been written, right?
So the "solution" to this is: periodic re-encoding


5) Not sure whether I just didn't understand this,... but was'n there
another limit with respect to about 1TB? And what was that about?



So in the end we could put in the FAQ, that with XTS:
- users should use plain64
- periodically re-encode before about 100TB
- 1TB thingy?!


Are there any other general things one should consider?
(Of course I assume, that attackers have no easier way, e.g. via
internet/software exploits or via physical force)



Thanks,
Chris.


btw:
On Wed, 2010-07-28 at 10:42 +0200, Milan Broz wrote:
> Maybe one day it will be there but probably as part of LVM
> (which will use libcryptsetup for key management for encrypted
> logical volumes).
> 
> It is possible to encode some simple function to reencode disk
> in-place. But I would like to have something better, LVM
> already provides most of infrastructure for such block device
> operations. (beware: I am also lvm developer:)
And? Already started coding? ;)


btw2: Point (3) leads me to a different question.
Imagin I have a disk with 4k sectors, put dm-crypt on it,... then the
logical ones are 512 byte sectors, right?
Now I put another layer or a filesystem on top.
What happen's to the alignment now? Will it use 4k or 512 bytes?