Re: [dm-crypt] XTS cipher mode limitations (FAQ additions)

[Arno Wagner <arno@wagner.name>]

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