All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Efficacy of xts over 1TB
Date: Mon, 26 Jul 2010 10:53:19 +0200	[thread overview]
Message-ID: <20100726085319.GC12550@tansi.org> (raw)
In-Reply-To: <1280097464.3309.192.camel@fermat.scientia.net>

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

  parent reply	other threads:[~2010-07-26  8:53 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-22 14:57 [dm-crypt] Efficacy of xts over 1TB David Santamaría Rogado
2010-07-25 10:34 ` Arno Wagner
2010-07-25 11:18   ` Christoph Anton Mitterer
2010-07-25 12:29     ` Heinz Diehl
2010-07-25 12:25   ` Milan Broz
2010-07-25 13:14     ` Christoph Anton Mitterer
2010-07-25 13:52       ` Milan Broz
2010-07-25 22:37         ` Christoph Anton Mitterer
2010-07-26  0:14           ` Milan Broz
2010-07-26 20:38             ` Christoph Anton Mitterer
2010-07-27  8:46               ` [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt Milan Broz
2010-07-27 10:47                 ` Arno Wagner
2010-07-27 14:17                   ` Christoph Anton Mitterer
2010-07-27 16:08                     ` Arno Wagner
2010-07-27 14:15                 ` Christoph Anton Mitterer
2010-07-27 15:45                   ` Mario 'BitKoenig' Holbe
2010-07-27 15:55                     ` Milan Broz
2010-07-27 18:59                       ` Christoph Anton Mitterer
2010-07-27 19:37                         ` Arno Wagner
2010-07-27 18:58                     ` Christoph Anton Mitterer
2010-07-27 19:35                       ` Mario 'BitKoenig' Holbe
2010-07-28  8:42                     ` Milan Broz
2010-08-20 21:11                       ` [dm-crypt] XTS cipher mode limitations Christoph Anton Mitterer
2010-08-21  0:22                         ` Arno Wagner
2010-08-22 12:50                           ` [dm-crypt] XTS cipher mode limitations (FAQ additions) Christoph Anton Mitterer
2010-08-23  0:46                             ` Arno Wagner
2010-08-25  9:36                               ` Christoph Anton Mitterer
2010-08-22 12:56                           ` [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) Christoph Anton Mitterer
2010-08-22 16:01                             ` Arno Wagner
2010-08-22 21:57                               ` Christoph Anton Mitterer
2010-08-23  7:14                                 ` [dm-crypt] tool to account the written number of bytes to a block device Milan Broz
2010-08-25  9:27                                   ` Christoph Anton Mitterer
2010-08-24 16:19                           ` [dm-crypt] XTS cipher mode limitations Ramius
2010-07-26  8:53           ` Arno Wagner [this message]
2010-07-26 20:47             ` [dm-crypt] Efficacy of xts over 1TB Christoph Anton Mitterer
2010-07-26 21:01               ` Arno Wagner
2010-07-26 21:28                 ` Christoph Anton Mitterer
2010-07-26 21:35                   ` Arno Wagner
2010-07-25 22:52         ` Christoph Anton Mitterer
2010-07-26  9:42           ` Mario 'BitKoenig' Holbe
2010-07-26 18:09             ` Arno Wagner
2010-07-27 18:16               ` [dm-crypt] Including the FAQ in the tarball? Christoph Anton Mitterer
2010-07-27 18:23                 ` Arno Wagner
2010-07-29  8:17                 ` Heinz Diehl
2010-07-25 15:32       ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner
2010-07-25 22:48         ` Christoph Anton Mitterer
2010-07-25 23:42           ` Milan Broz
2010-07-26 18:35             ` Christoph Anton Mitterer
2010-07-25 15:28     ` Arno Wagner
2010-07-25 18:11       ` Milan Broz
2010-07-26  9:04   ` Mario 'BitKoenig' Holbe
2010-07-27 18:21     ` Christoph Anton Mitterer
2010-07-27 21:02       ` Mario 'BitKoenig' Holbe
2010-07-26  9:17 ` Mario 'BitKoenig' Holbe
2010-07-27 18:42 ` David Santamaría Rogado
  -- strict thread matches above, loose matches on Subject: below --
2010-07-25 22:25 Ietf Nist
2010-07-25 22:41 ` Christoph Anton Mitterer
2010-07-26 21:07 Arno Wagner
2010-07-26 21:31 ` Christoph Anton Mitterer
2010-07-26 21:45   ` Arno Wagner
2010-07-26 21:42 ` Christoph Anton Mitterer
2010-07-26 22:55   ` Arno Wagner
2010-07-26 23:42   ` Mario 'BitKoenig' Holbe
2010-07-27 10:21     ` Arno Wagner
2010-08-15 17:26     ` Uwe Menges
2010-08-15 22:10       ` Arno Wagner
2010-08-16 11:44         ` Mario 'BitKoenig' Holbe
2010-08-16 12:39           ` Arno Wagner
2010-08-16 12:55         ` octane indice
2010-08-16 14:21           ` Arno Wagner
2010-08-21 20:45             ` Christoph Anton Mitterer
2010-08-21 23:14               ` Arno Wagner
2010-08-22  0:46                 ` Christoph Anton Mitterer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100726085319.GC12550@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.