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

On Thu, Feb 06, 2020 at 11:27:09PM -0800, Eric Biggers wrote:

Yes, for rfc4106 the tests don't pass the same IV in both places.  This is
because I wrote the tests from the perspective of a generic AEAD that doesn't
have this weird IV quirk, and then I added the minimum quirks to get the weird
algorithms like rfc4106 passing.

Since the actual behavior of the generic implementation of rfc4106 is that the
last 8 bytes of the AAD are ignored, that means that currently the tests just
avoid mutating these bytes when generating inauthentic input tests.  They don't
know that they're (apparently) meant to be another copy of the IV.

So it seems we need to clearly define the behavior when the two IV copies don't
match.  Should one or the other be used, should an error be returned, or should
the behavior be unspecified (in which case the tests would need to be updated)?

Unspecified behavior is bad, but it would be easiest for software to use
req->iv, while hardware might want to use the IV in the scatterlist...

Herbert and Stephan, any idea what was intended here?

I think unspecified would be OK here to give the hardware the
maximum latitude.  However, we also don't want it to crash or
do something funny so perhaps generate the test vectors as you
do now but compare it against the generic using two IV values?

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt