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

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

 



> -----Original Message-----
> From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> Sent: Thursday, July 25, 2019 8:22 AM
> To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>
> Cc: Milan Broz <gmazyland@xxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; dm-devel@xxxxxxxxxx; linux-
> crypto@xxxxxxxxxxxxxxx; Horia Geanta <horia.geanta@xxxxxxx>
> Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support
> 
> > >
> > > Actually, that spec has a couple of test vectors. Unfortunately, they
> > > are all rather short (except the last one in the 'no multiple of 16
> > > bytes' paragraph, but unfortunately, that one is in fact a multiple of
> > > 16 bytes)
> > >
> > > I added them here [0] along with an arm64 implementation for the AES
> > > instruction based driver. Could you please double check that these
> > > work against your driver?
> > >
> > I got XTS working with the inside-secure driver and these (and all other) vectors pass :-)
> >
> 
> Excellent, thanks for the report. May I add your Tested-by when I post
> the patch? (just the one that adds the test vectors)
> 
Sure, feel free

> > > That would establish a ground truth against
> > > which we can implement the generic version as well.
> > >
> > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=xts-cts
> > >
> > > > Besides that, I'd be happy to generate some testvectors from our defacto-standard
> > > > implementation ;-)
> > > >
> > >
> > > One or two larger ones would be useful, yes.
> > >
> > I'll see if I can extract some suitable vectors from our verification suite ...
> >
> 
> Great. Once available, I'll run them against my implementations and report back.
>
Just wondering ... do you have any particular requirements on the sizes?
>From my implementation's perspective, it doesn't make a whole lot of sense to test vectors 
of more than 3 times the cipher block size, but then I realized that you probably need
larger vectors due to the loop unrolling you do for the vector implementations?
You also don't want them to be too big as they take up space in the kernel image ...

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