Re: [dm-crypt] XTS cipher mode limitations

[Arno Wagner <arno@wagner.name>]

Hi Chris,

hope I remember this right.

On Fri, Aug 20, 2010 at 11:11:48PM +0200, Christoph Anton Mitterer wrote:
> 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.

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

Yes. Although plain64 is not available on older kernels.
 

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

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

Yes. Not an XTS-related problem though, but general
for block encryption as needed with filesystems.

> Is this only the case when he can make snapshots?

Yes, the attacker needs all data, as he/she is looking for collisons.
If I understand thios right, the attacker does however not need to
store all date, a, say, 128 bit hash and a 64 bit block number
would be enough. That is 24 Byte/Block and for, say, 100TB, 
this is about 5TB. Then the attackler would need to search 
for duplicates in the hash part (i.e. about 3TB). Quite 
a bit of effort for very little data exposure.

> In XTS, this starts to get a problem after about 100TB (IIRC) of data
> have been written, right?

Depending on paranoia level:  1....1000TB
Note that is risks exposing that two single disk blocks have 
the same content, which generally is not a problem at all. 

Also note that the attacker needs to store 

> So the "solution" to this is: periodic re-encoding

Or ignore it, as it does not help the attacker in most cases
and an the attacker has massive effort (storing a lot of TBs of
data and then checking for matches).
 
> 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?

No. It is just that below 1TB the possibility for this attack is
low enouigh to effectively be zero. 
  
> So in the end we could put in the FAQ, that with XTS:
> - users should use plain64

Only for volumes > 2TB. Already in there.

> - periodically re-encode before about 100TB
> - 1TB thingy?!

No sure it makes sense. But I can put it in there.

Was there a literature reference for the attack? 
If I out this into the FAQ, then I need to 
get it right as it is something more complicated and the
data exposure is low enough that most people rightfully 
will not care and most attackers will not be able to do it
anyways due to the high anount of storage needed.
 
> 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)

Not that I can see at the moment.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier