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] Cryptographic issues with SSD-technology and wide-block encryption modes
Date: Wed, 6 Feb 2013 14:06:57 +0100	[thread overview]
Message-ID: <20130206130657.GC12351@tansi.org> (raw)
In-Reply-To: <51125218.6090709@gmail.com>

On Wed, Feb 06, 2013 at 01:52:40PM +0100, Milan Broz wrote:
> On 02/06/2013 11:32 AM, Arno Wagner wrote:
> 
> > On Wed, Feb 06, 2013 at 11:06:11AM +0100, Stavros Kousidis wrote:
> >> One essential issue that concerns full disk encryption on SSDs, that I
> >> have not seen in a mail discussion here so far (might be there and I
> >> simply missed it), is the distribution of an uncontrollable amount of
> >> copies of SSD-page contents (~4096 Bytes) where only a limited number of
> >> blocks (~16 Bytes) have changed.  This is initiated by local changes in
> >> userspace data and technically due to the complex nature of the flash
> >> translation layer (mainly wear leveling techniques), the narrow-block
> >> encryption modes (here: XTS) and sector-wise constant IVs.  In
> >> Cipher-block chaining mode the position where a bit-flip happened is
> >> visible in principle.
> > 
> > I am aware of that issue. However, XTS mode should lead to a full sector
> > (512 Bytes) chage even if only one bit is changed. That is the whole
> > point of modes like XTS, EME, etc.
> 
> I am afraid this is not true for XTS. blocks inside XTS can be processed
> in parallel (so they cannot depend on each other) so the effect can be

Hmm. You are right, my mistake. I sort-of assumed XTS was not
weaker than CBC for this particular attack without really
checking. One look at the definition makes it very obvious 
though.

> exactly opposite - first bit change in (the same) sector using e.g. CBC
> will change the whole ciphertext sector, while with XTS only first
> encryption block (16 bytes) is changed.
> I tried to show it here http://mbroz.fedorapeople.org/talks/DevConf2012/img6.jpg
> 
> But despite that, XTS is usually better. 

I agree. And attacks were attackers have repeated access to the
ciphertext, but not the plaintext are quite rare anyways. And
even then, usually nothing aignificant is gained. 

> But it would be nice to have
> some not patent encumbered wide mode (no code changes needed, just someone
> have to invent it and add to crypto API :-)

Indeed. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

  reply	other threads:[~2013-02-06 13:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.6.1360140726.2399.dm-crypt@saout.de>
2013-02-06 10:06 ` [dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes Stavros Kousidis
2013-02-06 10:32   ` Arno Wagner
2013-02-06 12:52     ` Milan Broz
2013-02-06 13:06       ` Arno Wagner [this message]
2013-02-06 11:07   ` Matthias Schniedermeyer
2013-02-06 12:45     ` Arno Wagner
2013-02-06 13:18     ` Stavros Kousidis
2013-02-06 12:38   ` Milan Broz
2013-02-06 13:34     ` Stavros Kousidis
2013-02-06 14:08       ` Milan Broz
2013-02-06 13:59     ` Stavros Kousidis
2013-02-09 14:20       ` Alex Elsayed
     [not found] <mailman.1.1360494001.22742.dm-crypt@saout.de>
2013-02-12  8:47 ` Stavros Kousidis
2013-02-12 12:41   ` Arno Wagner
     [not found] <mailman.1.1360148402.2056.dm-crypt@saout.de>
2013-02-06 13:22 ` Stavros Kousidis
2013-02-06  8:52 Stavros Kousidis

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=20130206130657.GC12351@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.