All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>
To: Milan Broz <mbroz@redhat.com>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Efficacy of xts over 1TB
Date: Mon, 26 Jul 2010 00:37:44 +0200	[thread overview]
Message-ID: <1280097464.3309.192.camel@fermat.scientia.net> (raw)
In-Reply-To: <4C4C4192.60908@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]

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?
And wouldn't this have a negative impact on the security?


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



> 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 ;)

 
Nevertheless,... it all comes down to:
1) Devices smaller than 2TB are also secure with "plain"....
2) larger devices have to use plain64 in order to avoid the same IV
begin used after the boundary
3) No other currently known weakness in XTS and/or it's IV generation
algo.
4) XTS is the most secure mode at the moment?

Right?


Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

  reply	other threads:[~2010-07-25 22:37 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 [this message]
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           ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner
2010-07-26 20:47             ` 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
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=1280097464.3309.192.camel@fermat.scientia.net \
    --to=christoph.anton.mitterer@physik.uni-muenchen.de \
    --cc=dm-crypt@saout.de \
    --cc=mbroz@redhat.com \
    /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.