linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Possible issue with new inauthentic AEAD in extended crypto tests
@ 2020-01-27  8:04 Gilad Ben-Yossef
  2020-01-28  2:34 ` Eric Biggers
  0 siblings, 1 reply; 28+ messages in thread
From: Gilad Ben-Yossef @ 2020-01-27  8:04 UTC (permalink / raw)
  To: Linux Crypto Mailing List, Eric Biggers
  Cc: Geert Uytterhoeven, Herbert Xu, David Miller, Ofir Drang

Hi,

I've ran into some problems when enabling the extended crypto tests
after commit 49763fc6b1af ("crypto: testmgr - generate inauthentic
AEAD test vectors").
After looking into the matter, I've found something that seems like a
possible problem with the tests, but I am not sure and would
appreciate your consideration:

include/crypto/aead.h has this piece of wisdom to offer:

"* It is important to note that if multiple scatter gather list entries form
 * the input data mentioned above, the first entry must not point to a NULL
 * buffer. If there is any potential where the AAD buffer can be NULL, the
 * calling code must contain a precaution to ensure that this does not result
 * in the first scatter gather list entry pointing to a NULL buffer."

However, in generate_random_aead_testvec() we have:

        /* AAD, plaintext, and ciphertext lengths */
        total_len = generate_random_length(maxdatasize);
        if (prandom_u32() % 4 == 0)
                vec->alen = 0;
        else
                vec->alen = generate_random_length(total_len);
        vec->plen = total_len - vec->alen;
        vec->clen = vec->plen + authsize;

Which later calls into generate_aead_message() that has:

                int i = 0;
                struct scatterlist src[2], dst;
                u8 iv[MAX_IVLEN];
                DECLARE_CRYPTO_WAIT(wait);

                /* Generate a random plaintext and encrypt it. */
                sg_init_table(src, 2);
                if (vec->alen)
                        sg_set_buf(&src[i++], vec->assoc, vec->alen);
                if (vec->plen) {
                        generate_random_bytes((u8 *)vec->ptext, vec->plen);
                        sg_set_buf(&src[i++], vec->ptext, vec->plen);
                }
                sg_init_one(&dst, vec->ctext, vec->alen + vec->clen);
                memcpy(iv, vec->iv, ivsize);
                aead_request_set_callback(req, 0, crypto_req_done, &wait);
                aead_request_set_crypt(req, src, &dst, vec->plen, iv);
                aead_request_set_ad(req, vec->alen);
                vec->crypt_error = crypto_wait_req(crypto_aead_encrypt(req),
                                                   &wait);


When both vec->alen and vec->plen are 0, which can happen as
generate_random_bytes will happily generate  zero length from time to
time,
we seem to be getting a scatterlist with the first entry (as well as
the 2nd) being a NULL.

This seems to violate the words of wisdom from aead.h and much more
important to me crashes the ccree driver :-)

Is there anything I am missing or is this a valid concern?

Thanks!
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2020-02-10 11:04 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).