RE: [dm-devel] xts fuzz testing and lack of ciphertext stealing support

[Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>]

> -----Original Message-----
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Sent: Saturday, July 27, 2019 7:39 AM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> Cc: Horia Geanta <horia.geanta@nxp.com>; Milan Broz <gmazyland@gmail.com>; Herbert Xu <herbert@gondor.apana.org.au>; dm-
> devel@redhat.com; linux-crypto@vger.kernel.org
> Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support
> 
> On Sat, 27 Jul 2019 at 00:43, Pascal Van Leeuwen
> <pvanleeuwen@verimatrix.com> wrote:
> >
> > > -----Original Message-----
> > > From: Horia Geanta <horia.geanta@nxp.com>
> > > Sent: Friday, July 26, 2019 9:59 PM
> > > To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > Cc: Milan Broz <gmazyland@gmail.com>; Herbert Xu <herbert@gondor.apana.org.au>; dm-devel@redhat.com; linux-
> > > crypto@vger.kernel.org
> > > Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support
> > >
> > > On 7/26/2019 1:31 PM, Pascal Van Leeuwen wrote:
> > > > Ok, find below a patch file that adds your vectors from the specification
> > > > plus my set of additional vectors covering all CTS alignments combined
> > > > with the block sizes you desired. Please note though that these vectors
> > > > are from our in-house home-grown model so no warranties.
> > > I've checked the test vectors against caam (HW + driver).
> > >
> > > Test vectors from IEEE 1619-2007 (i.e. up to and including "XTS-AES 18")
> > > are fine.
> > >
> > > caam complains when /* Additional vectors to increase CTS coverage */
> > > section starts:
> > > alg: skcipher: xts-aes-caam encryption test failed (wrong result) on test vector 9, cfg="in-place"
> > >
> > > (Unfortunately it seems that testmgr lost the capability of dumping
> > > the incorrect output.)
> > >
> > > IMO we can't rely on test vectors if they are not taken
> > > straight out of a spec, or cross-checked with other implementations.
> > >
> >
> > First off, I fully agree with your statement, which is why I did not post this as a straight
> > patch. The problem is that specification vectors usually (or actuaclly, always) don't cover
> > all the relevant corner cases needed for verification. And "reference" implementations
> > by academics are usually shady at best as well.
> >
> > In this particular case, the reference vectors only cover 5 out of 16 possible alignment
> > cases and the current situation proves that this is not sufficient. As we have 2 imple-
> > mentations (or actually more, if you count the models used for vector generation)
> > that are considered to be correct that disagree on results.
> >
> > Which is very interesting, because which one is correct? I know that our model and
> > hardware implementation were independently developed (by 2 different engineers)
> > from the IEEE spec and match on results. And our hardware has been used "out in
> > the field" for many years already in disk controllers from major silicon vendors.
> > But that's still not a guarantee .... So how do we resolve this? Majority vote? ;-)
> >
> 
> Thanks for the additional test vectors. They work fine with my SIMD
> implementations for ARM [0], so this looks like it might be a CAAM
> problem, not a problem with the test vectors.
> 
Thanks for the heads up! As the engineer actually responsible for our hardware
implementation, I can now sleep at night again :-)

Not that I was too worried - the design has been in active use for nearly 12 years
already without any known issues, but still ...

> I will try to find some time today to run them through OpenSSL to double check.
> 
> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=xts-cts

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