From: Eric Biggers <ebiggers@kernel.org>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Stephan Mueller <smueller@chronox.de>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
David Miller <davem@davemloft.net>,
Ofir Drang <Ofir.Drang@arm.com>
Subject: Re: Possible issue with new inauthentic AEAD in extended crypto tests
Date: Thu, 6 Feb 2020 23:27:09 -0800 [thread overview]
Message-ID: <20200207072709.GB8284@sol.localdomain> (raw)
In-Reply-To: <CAOtvUMeVXTDvH5bxVFemYmD9rpZ=xX3MkypAGyZn5VROw6sgZg@mail.gmail.com>
On Wed, Feb 05, 2020 at 04:48:16PM +0200, Gilad Ben-Yossef wrote:
> Probably another issue with my driver, but just in case -
> include/crypot/aead.h says:
>
> * The scatter list pointing to the input data must contain:
> *
> * * for RFC4106 ciphers, the concatenation of
> * associated authentication data || IV || plaintext or ciphertext. Note, the
> * same IV (buffer) is also set with the aead_request_set_crypt call. Note,
> * the API call of aead_request_set_ad must provide the length of the AAD and
> * the IV. The API call of aead_request_set_crypt only points to the size of
> * the input plaintext or ciphertext.
>
> I seem to be missing the place where this is handled in
> generate_random_aead_testvec()
> and generate_aead_message()
>
> We seem to be generating a random IV for providing as the parameter to
> aead_request_set_crypt()
> but than have other random bytes set in aead_request_set_ad() - or am
> I'm missing something again?
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?
- Eric
next prev parent reply other threads:[~2020-02-07 7:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-27 8:04 Possible issue with new inauthentic AEAD in extended crypto tests Gilad Ben-Yossef
2020-01-28 2:34 ` Eric Biggers
2020-01-28 3:15 ` Stephan Mueller
2020-01-28 3:38 ` Herbert Xu
2020-01-28 7:24 ` Gilad Ben-Yossef
2020-01-28 21:12 ` Eric Biggers
2020-01-29 11:28 ` Gilad Ben-Yossef
[not found] ` <2f3e874fae2242d99f4e4095ae42eb75@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-01-29 13:28 ` Van Leeuwen, Pascal
2020-02-05 14:48 ` Gilad Ben-Yossef
2020-02-07 7:27 ` Eric Biggers [this message]
2020-02-07 7:56 ` Stephan Mueller
2020-02-07 11:50 ` Gilad Ben-Yossef
2020-02-07 12:29 ` Stephan Mueller
2020-02-09 8:04 ` Gilad Ben-Yossef
[not found] ` <7f68982502574b03931e7caad965e76f@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-10 8:03 ` Van Leeuwen, Pascal
[not found] ` <3b65754206a049e596efeb76619eef5c@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-07 14:30 ` Van Leeuwen, Pascal
[not found] ` <70156395ce424f41949feb13fd9f978b@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-07 14:07 ` Van Leeuwen, Pascal
2020-02-07 14:29 ` Stephan Mueller
2020-02-07 15:36 ` Van Leeuwen, Pascal
[not found] ` <0795c353d60547539d23cd6db805f579@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-02-07 15:50 ` Van Leeuwen, Pascal
2020-02-09 8:09 ` Gilad Ben-Yossef
2020-02-10 8:05 ` Van Leeuwen, Pascal
2020-02-10 11:04 ` Herbert Xu
[not found] ` <b5a529fd1abd46ea881b18c387fcd4dc@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-01-29 0:18 ` Van Leeuwen, Pascal
2020-01-29 1:26 ` Stephan Mueller
[not found] ` <11489dad16d64075939db69181b5ecbb@MN2PR20MB2973.namprd20.prod.outlook.com>
2020-01-29 8:40 ` Van Leeuwen, Pascal
2020-01-29 12:54 ` Stephan Mueller
2020-01-29 13:42 ` Van Leeuwen, Pascal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200207072709.GB8284@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=Ofir.Drang@arm.com \
--cc=davem@davemloft.net \
--cc=geert@linux-m68k.org \
--cc=gilad@benyossef.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox