public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Gilad Ben-Yossef <gilad@benyossef.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	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: Tue, 28 Jan 2020 04:15:11 +0100	[thread overview]
Message-ID: <3730881.07ufDO6WFW@tauon.chronox.de> (raw)
In-Reply-To: <20200128023455.GC960@sol.localdomain>

Am Dienstag, 28. Januar 2020, 03:34:55 CET schrieb Eric Biggers:

Hi Eric,

> On Mon, Jan 27, 2020 at 10:04:26AM +0200, Gilad Ben-Yossef wrote:
> > 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?
> 
> My understanding is that all crypto API functions that take scatterlists
> only forbid zero-length scatterlist elements in the part of the scatterlist
> that's actually passed to the API call.  The input to these functions is
> never simply a scatterlist, but rather a (scatterlist, length) pair. 
> Algorithms shouldn't look beyond 'length', so in the case of 'length == 0',
> they shouldn't look at the scatterlist at all -- which may be just a NULL
> pointer.
> 
> If that's the case, there's no problem with this test code.

I agree with your assessment. Not only when looking at cipher or template 
implementations, but also when looking at the scatterwalk API the SGL length 
field is processed first. If the length field is insufficient then the SGL is 
not processed.
> 
> I'm not sure the comment in aead.h is relevant here.  It sounds like it's
> warning about not providing an empty scatterlist element for the AAD when
> it's followed by a nonempty scatterlist element for the plaintext.  I'm not
> sure it's meant to also cover the case where both are empty.

The statement here (and maybe it could be updated) refers to a valid SGL with 
a size > 0, but where the first SGL entry points to a NULL buffer. This is an 
invalid use of an SGL.

Specifically for AEAD, the SGL must have the form of (assoc data || 
plaintext). As the AAD is not required for a successful cipher operation, the 
caller of the crypto API must guarantee the AAD is either non-NULL or the SGL 
must start with the plaintext as the first entry.
> 
> Herbert and Stephan, any thoughts on what was intended?
> 
> - Eric



Ciao
Stephan



  reply	other threads:[~2020-01-28  3:15 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 [this message]
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

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=3730881.07ufDO6WFW@tauon.chronox.de \
    --to=smueller@chronox.de \
    --cc=Ofir.Drang@arm.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gilad@benyossef.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /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