RE: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
> Sent: Thursday, August 8, 2019 10:31 AM
> To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>
> Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; linux-crypto@xxxxxxxxxxxxxxx;
> herbert@xxxxxxxxxxxxxxxxxxx; agk@xxxxxxxxxx; snitzer@xxxxxxxxxx; dm-devel@xxxxxxxxxx;
> gmazyland@xxxxxxxxx
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV generation
> 
> 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).
> 
Interesting ... I'm not a cryptographer, just a humble HW engineer specialized
in implementing crypto. I'm basing my views mostly on the Liskov/Minematsu
"Comments on XTS", who assert that using 2 keys in XTS was misguided. 
(and I never saw any follow-on comments asserting that this view was wrong ...)
On not avoiding j=0 in the XTS spec they actually comment:
"This difference is significant in security, but has no impact on effectiveness 
for practical applications.", which I read as "not relevant for normal use".

In any case, it's frequently *used* with both keys being equal for performance
and key storage reasons.

> 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.
> 
Well, technically the XTS specification does not actually mandate that j should
start at 0 (!), although that's what the vectors and example code suggest ...

> - Eric

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux