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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
