From: Eric Biggers <ebiggers@kernel.org>
To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"agk@redhat.com" <agk@redhat.com>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"gmazyland@gmail.com" <gmazyland@gmail.com>
Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation
Date: Thu, 8 Aug 2019 01:30:59 -0700 [thread overview]
Message-ID: <20190808083059.GB5319@sol.localdomain> (raw)
In-Reply-To: <MN2PR20MB29733EEF59CCD754256D5621CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
On Wed, Aug 07, 2019 at 04:14:22PM +0000, Pascal Van Leeuwen wrote:
> > > > In your case, we are not dealing with known plaintext attacks,
> > > >
> > > Since this is XTS, which is used for disk encryption, I would argue
> > > we do! For the tweak encryption, the sector number is known plaintext,
> > > same as for EBOIV. Also, you may be able to control data being written
> > > to the disk encrypted, either directly or indirectly.
> > > OK, part of the data into the CTS encryption will be previous ciphertext,
> > > but that may be just 1 byte with the rest being the known plaintext.
> > >
> >
> > The tweak encryption uses a dedicated key, so leaking it does not have
> > the same impact as it does in the EBOIV case.
> >
> Well ... yes and no. The spec defines them as seperately controllable -
> deviating from the original XEX definition - but in most practicle use cases
> I've seen, the same key is used for both, as having 2 keys just increases
> key storage requirements and does not actually improve effective security
> (of the algorithm itself, implementation peculiarities like this one aside
> :-), as XEX has been proven secure using a single key. And the security
> proof for XTS actually builds on that while using 2 keys deviates from it.
>
This is a common misconception. Actually, XTS needs 2 distinct keys to be a
CCA-secure tweakable block cipher, due to another subtle difference from XEX:
XEX (by which I really mean "XEX[E,2]") builds the sequence of masks starting
with x^1, while XTS starts with x^0. If only 1 key is used, the inclusion of
the 0th power in XTS allows the attack described in Section 6 of the XEX paper
(https://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf).
Of course, it's debatable what this means *in practice* to the usual XTS use
cases like disk encryption, for which CCA security may not be critical... But
technically, single-key XTS isn't secure under as strong an attack model as XEX.
- Eric
next prev parent reply other threads:[~2019-08-08 8:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 5:50 [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation Ard Biesheuvel
2019-08-07 7:28 ` Pascal Van Leeuwen
2019-08-07 13:17 ` Ard Biesheuvel
2019-08-07 13:52 ` Pascal Van Leeuwen
2019-08-07 15:39 ` Ard Biesheuvel
2019-08-07 16:14 ` Pascal Van Leeuwen
2019-08-07 16:50 ` Ard Biesheuvel
2019-08-07 20:22 ` Pascal Van Leeuwen
2019-08-08 8:30 ` Eric Biggers [this message]
2019-08-08 9:31 ` Pascal Van Leeuwen
2019-08-08 12:52 ` Milan Broz
2019-08-08 13:23 ` Pascal Van Leeuwen
2019-08-08 17:15 ` Eric Biggers
2019-08-09 9:17 ` Pascal Van Leeuwen
2019-08-09 17:17 ` Eric Biggers
2019-08-09 20:29 ` Pascal Van Leeuwen
2019-08-09 20:56 ` Eric Biggers
2019-08-09 21:33 ` Pascal Van Leeuwen
2019-08-09 22:04 ` Eric Biggers
2019-08-09 23:01 ` Pascal Van Leeuwen
2019-08-07 8:08 ` Milan Broz
2019-08-08 11:53 ` Milan Broz
2019-08-09 18:52 ` Ard Biesheuvel
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=20190808083059.GB5319@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=agk@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dm-devel@redhat.com \
--cc=gmazyland@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=pvanleeuwen@verimatrix.com \
--cc=snitzer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).