RE: Possible issue with new inauthentic AEAD in extended crypto tests

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

 



> -----Original Message-----
> From: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx>
> Sent: Sunday, February 9, 2020 9:10 AM
> To: Van Leeuwen, Pascal <pvanleeuwen@xxxxxxxxxx>
> Cc: Stephan Mueller <smueller@xxxxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>;
> Linux Crypto Mailing List <linux-crypto@xxxxxxxxxxxxxxx>; Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>; David Miller
> <davem@xxxxxxxxxxxxx>; Ofir Drang <Ofir.Drang@xxxxxxx>
> Subject: Re: Possible issue with new inauthentic AEAD in extended crypto tests
>
> <<< External Email >>>
> On Fri, Feb 7, 2020 at 4:07 PM Van Leeuwen, Pascal
> <pvanleeuwen@xxxxxxxxxx> wrote:
>
> > The "problem" Gilad was referring to is that the _explicit_ part of the  IV appears to be
> > available  from both req->iv and from the AAD scatterbuffer. Which one should you use?
> > API wise I would assume req->iv but from a (our) hardware perspective, it would
> > be more efficient to extract it from the datastream. But is it allowed to assume
> > there is a valid IV stored there? (which implies that it has to match req->iv,
> > otherwise behaviour would deviate from implementations using that)
> >
>
>
> No, it isn't.
>
> The problem that I was referring to was that part of our test suites
> passes different values in req->iv and as part of the AAD,
> in contrast to what we document as the API requirements in the include
> file, my understanding of the relevant standard and
> the single users of this API in the kernel and that the driver I'm
> maintaining fails these tests,
>
But that's the same problem. If they were identical it doesn't matter
which one your driver uses, but because the testsuite now makes
them unequal you have a problem if you happen to use the other one.

> I'm all fine with getting my hands dirty and fixing the driver, I'm
> just suspect fixing a driver to pass a test that misuses the API
> may not actually improve the quality of the driver.
>
> Gilad


Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.


** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **

Rambus Inc.<http://www.rambus.com>




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

  Powered by Linux