From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tansi.org (ns.km10532-04.keymachine.de [87.118.102.195]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 23 Aug 2010 02:46:38 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by tansi.org (Postfix) with ESMTPA id 03AA01218347 for ; Mon, 23 Aug 2010 02:46:38 +0200 (CEST) Date: Mon, 23 Aug 2010 02:46:35 +0200 From: Arno Wagner Message-ID: <20100823004635.GA19317@tansi.org> References: <1280097464.3309.192.camel@fermat.scientia.net> <4C4CD361.4080000@redhat.com> <1280176686.3266.106.camel@fermat.scientia.net> <4C4E9CF4.3030308@redhat.com> <1280240110.11350.11.camel@etppc09.garching.physik.uni-muenchen.de> <4C4FED84.3040201@redhat.com> <1282338708.3231.53.camel@fermat.scientia.net> <20100821002257.GA12482@tansi.org> <1282481432.3241.44.camel@fermat.scientia.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1282481432.3241.44.camel@fermat.scientia.net> Subject: Re: [dm-crypt] XTS cipher mode limitations (FAQ additions) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Sun, Aug 22, 2010 at 02:50:32PM +0200, Christoph Anton Mitterer wrote: > Hi Arno. >=20 > Thanks for that =3D) >=20 > 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. >=20 > 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. =20 > 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 IV? What is "plain64"?>)? Other wise people may miss that it's ok to use > it with > 2TB when plain 64 is used. Added. =20 > 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=20 the first place. Diexed also for MB and kB. (No GB in there) =20 >=20 > May I further suggest, that in all references to 2TB, we add "(=3D 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.=20 =20 > > > 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. =20 =20 > > > - periodically re-encode before about 100TB > > > - 1TB thingy?! > >=20 > > No sure it makes sense. But I can put it in there. >=20 > 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. >=20 > 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). >=20 >=20 >=20 > > Was there a literature reference for the attack?=20 > > If I out this into the FAQ, then I need to=20 > > get it right as it is something more complicated and the > > data exposure is low enough that most people rightfully=20 > > 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=20 however not start to distribute my own FUD and I am=20 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 =20 --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.nam= e=20 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=20 "news" is "something that hardly ever happens." -- Bruce Schneier=20