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:
> >
> > plain 64 is just 64bit unsigned (512b sector number with optional initial
> > 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.
> > > 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 really
> > > know what they're doing?
> >
> > It is not slower (plain uses 64bit too but with masking 32bits out,
> > I guess this is some cryptoloop legacy)
> >
> > plain64 discussion was already in this list - we cannot change plain because
> > 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.
> > I prefer keep small open problem here (only few such systems in fact) to
> > destroying users data for sure.
> Uhm,.. what do you mean?
>
> > (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 ;-)
> > 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 XTS mode:-)
> Are you going to change this someday? I mean to xts?
>
>
> > 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.
> 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.
> 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
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
is so fond of. There can be equally good solutions or the
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
both increase (if it is "secure") and decresee (if it has
flaws) its security. But any attacks on both would be pretty
exotic.
> Right?
See above.
Caveat as before: I am not a cryptographer.
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
