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. 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. May I suggest that all occurrences of e.g. 2 TB are replaced by e.g. 2 TiB? 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. > > 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. > > - 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... Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt