All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] XTS cipher mode limitations (FAQ additions)
Date: Sun, 22 Aug 2010 14:50:32 +0200	[thread overview]
Message-ID: <1282481432.3241.44.camel@fermat.scientia.net> (raw)
In-Reply-To: <20100821002257.GA12482@tansi.org>

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

Hi Arno.

Thanks for that =)

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.

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.


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 <link to Are there any problems with "plain"
IV? What is "plain64"?>)? Other wise people may miss that it's ok to use
it with > 2TB when plain 64 is used.



May I suggest that all occurrences of e.g. 2 TB are replaced by e.g. 2
TiB?


May I further suggest, that in all references to 2TB, we add "(= 2^32 *
512 bytes)"?
There's always that problem that one never knows whether TB really means
TB or TiB.


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


> > - periodically re-encode before about 100TB
> > - 1TB thingy?!
> 
> No sure it makes sense. But I can put it in there.

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.

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



> Was there a literature reference for the attack? 
> If I out this into the FAQ, then I need to 
> get it right as it is something more complicated and the
> data exposure is low enough that most people rightfully 
> 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...


Cheers,
Chris.

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

  reply	other threads:[~2010-08-22 12:50 UTC|newest]

Thread overview: 55+ 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                           ` Christoph Anton Mitterer [this message]
2010-08-23  0:46                             ` [dm-crypt] XTS cipher mode limitations (FAQ additions) 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

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=1282481432.3241.44.camel@fermat.scientia.net \
    --to=christoph.anton.mitterer@physik.uni-muenchen.de \
    --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.