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, 26 Jul 2010 10:53:20 +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 4A8C51218320 for ; Mon, 26 Jul 2010 10:53:20 +0200 (CEST) Date: Mon, 26 Jul 2010 10:53:19 +0200 From: Arno Wagner Message-ID: <20100726085319.GC12550@tansi.org> References: <20100725103458.GA26486@tansi.org> <4C4C2D3C.40306@redhat.com> <1280063664.3309.119.camel@fermat.scientia.net> <4C4C4192.60908@redhat.com> <1280097464.3309.192.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: <1280097464.3309.192.camel@fermat.scientia.net> Subject: Re: [dm-crypt] Efficacy of xts over 1TB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Mon, Jul 26, 2010 at 12:37:44AM +0200, Christoph Anton Mitterer wrote: > On Sun, 2010-07-25 at 15:52 +0200, Milan Broz wrote: > > not talking about encryption mode security, just about plain IV: > >=20 > > plain 64 is just 64bit unsigned (512b sector number with optional initi= al > > offset), sector are also 64bit, so limit is the same like maximum block > > device in Linux currently. > Well but as far as I understand, this means that the same IV could be > used in multiple sectors (after the 32bit), right? Err, no? That would be "after 64 bit". > And wouldn't this have a negative impact on the security? If you go over 64 bit sector numbers, definitely. However it is hard to quantify how large this impact would be. =20 > > > 2) Is plain64 solwer than the the normal plain? If not,... and even > > > if,.. wouldn't it be better to let "plain" be what currently "plain64" > > > is and to add a e.g. "plain32" or so, which people can use if the rea= lly > > > know what they're doing? > >=20 > > It is not slower (plain uses 64bit too but with masking 32bits out, > > I guess this is some cryptoloop legacy) > >=20 > > plain64 discussion was already in this list - we cannot change plain be= cause > > of backward compatibility (Imagine old 4TB LUKS device ("plain" iv mode= in header) > > - after this change everything above 2TB is garbage.) > I see... what about this idea: > In newer releases of cryptsetup, give a warning whenever people use > "plain" suggesting them to use "plain64"?! I like this approach. =20 > > I prefer keep small open problem here (only few such systems in fact) to > > destroying users data for sure. > Uhm,.. what do you mean? >=20 > > (I can add warning/hint to cryptsetup binary if using large device.) > Ah ^^... > Wouldn't it be better to always warn, even on devices smaller than the > limit for plain? I mean luks devices are easily resizeable so people > could run into that problem later. I think this is out of scope. Somebody rezising an encrypted device without looking into the limits of the encryption used, is asking for trouble. Also there will be a FAQ entry on resizing ;-) =20 > > Default modes in cryptsetup now use essiv:sha256 (no problem here). > > Mainly for backward compatibility (best compatible/safe mode, > > e.g. RHEL/CentOS5 do not have XTS yet), otherwise I personally prefer X= TS mode:-) > Are you going to change this someday? I mean to xts? >=20 >=20 > > You have to set -c cipher-mode-plain manually, I expect you know what > > are you doing then. > Well,... I've also thought I knew what I did,.. but apparently not ;) Hehe. Crypto is hard. =20 > Nevertheless,... it all comes down to: > 1) Devices smaller than 2TB are also secure with "plain".... Yes. > 2) larger devices have to use plain64 in order to avoid the same IV > begin used after the boundary Yes. > 3) No other currently known weakness in XTS and/or it's IV generation > algo. Yes.=20 > 4) XTS is the most secure mode at the moment? No. That is a judgement call. It is quite possible that cbc-essiv is just as secure. For "most secure mode" you need an increment in security compared to other modes. And that may also very likely=20 depend on the attack scenatio, i.e. some mode may be more secure under scenario A and some other mode under scenario B. Also what "more secure" means is variable. Don't go for that "best xyz" idiocity that modern advertizement=20 is so fond of. There can be equally good solutions or the=20 difference can be small enough not to matter. It seems to me the latter is currently the case for XTS and cbc-essiv. However XTS is surely going to be analyzed and attacked with more effort, being more widely used, which can=20 both increase (if it is "secure") and decresee (if it has=20 flaws) its security. But any attacks on both would be pretty=20 exotic. > Right? See above. Caveat as before: I am not a cryptographer. Arno --=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