On Sun, Aug 22, 2010 at 02:50:32PM +0200, Christoph Anton Mitterer wrote: > Hi Arno. > > Thanks for that =) > > On Sat, 2010-08-21 at 02:22 +0200, Arno Wagner wrote: > > > 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. > > I know this will probably lead to some discussion ;) ... but should we > perhaps suggest this in the FAQ? > E.g. something like a section "Which mode should one use?", and then XTS > withstands currently most known attacks, it has been standardised by > IEEE (1619 IIRC). etc. pp. > Perhaps also than one should use plain64 in all kernels supporting it, > and at least when device > 2TB. I think the item "What about XTS mode?" already covers that. > btw: In the question "Can I resize a dm-crypt or LUKS partition?", you > say one should not use it with > 2TB. > May I suggest to add a (see <link to Are there any problems with "plain" > IV? What is "plain64"?>)? Other wise people may miss that it's ok to use > it with > 2TB when plain 64 is used. Added. > May I suggest that all occurrences of e.g. 2 TB are replaced by e.g. 2 > TiB? Since I typically insist on that, I should have done this in the first place. Diexed also for MB and kB. (No GB in there) > > May I further suggest, that in all references to 2TB, we add "(= 2^32 * > 512 bytes)"? > There's always that problem that one never knows whether TB really means > TB or TiB. Instead changed all 2TB to 2TiB. > > > 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. > Perhap we can add this to the FAQ, too. > People may have read about it,... but don't know whether it's a problem > or not. So telling them "no everything's fine as long as our blocky are > smaller than xxxx bytes) can be a good idea. > Especially as the wikipedia article contains some FUD about this. Added. > > > - periodically re-encode before about 100TB > > > - 1TB thingy?! > > > > No sure it makes sense. But I can put it in there. > > I'd suggest so,... for people with the highest paranoia ;) > Perhaps with a note, that this is probably not such a big problem for > many scenarios. > > Also adding that this is a general problem, what one can do against it, > and the rough values when it is estimated to become a problem (e.g. for > XTS). > > > > > 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. > Uhm... no idea unfortunately... Well, if it comes up again, I can look at it. I will however not start to distribute my own FUD and I am not a good enough cryptographer for a really thorough analysis of the issue. I am willing to read a paper on it if somebody else provides the link ;-) 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
