All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Pascal van Leeuwen <pascalvanl@gmail.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH] crypto: testmgr - Improve randomization of params for AEAD fuzz testing
Date: Mon, 29 Jul 2019 17:55:33 -0700	[thread overview]
Message-ID: <20190730005532.GL169027@gmail.com> (raw)
In-Reply-To: <MN2PR20MB2973302B66749E5E6EC4F444CADC0@MN2PR20MB2973.namprd20.prod.outlook.com>

On Tue, Jul 30, 2019 at 12:37:06AM +0000, Pascal Van Leeuwen wrote:
> > > You're the expert, but shouldn't there be some priority to the checks
> > > being performed? To me, it seems reasonable to do things like length
> > > checks prior to even *starting* decryption and authentication.
> > > Therefore, it makes more sense to get -EINVAL than -EBADMSG in this
> > > case. IMHO you should only get -EBADMSG if the message was properly
> > > formatted, but the tags eventually mismatched. From a security point
> > > of view it can be very important to have a very clear distinction
> > > between those 2 cases.
> > >
> > 
> > Oh, I see.  Currently the fuzz tests assume that if encryption fails with an
> > error (such as EINVAL), then decryption fails with that same error.
> > 
> Ah ok, oops. It should really log the error that was returned by the
> generic decryption instead. Which should just be a matter of annotating
> it back to vec.crypt_error?
> 

It doesn't do the generic decryption yet though, only the generic encryption.

> > Regardless of what we think the correct decryption error is, running the
> > decryption test at all in this case is sort of broken, since the ciphertext
> > buffer was never initialized.
> >
> You could consider it broken or just some convenient way of getting
> vectors that don't authenticate without needing to spend any effort ...
> 

It's not okay for it to be potentially using uninitialized memory though, even
if just in the fuzz tests.

> > So for now we probably should just sidestep this
> > issue by skipping the decryption test if encryption failed, like this:
> > 
> > diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> > index 96e5923889b9c1..0413bdad9f6974 100644
> > --- a/crypto/testmgr.c
> > +++ b/crypto/testmgr.c
> > @@ -2330,10 +2330,12 @@ static int test_aead_vs_generic_impl(const char *driver,
> >  					req, tsgls);
> >  		if (err)
> >  			goto out;
> > -		err = test_aead_vec_cfg(driver, DECRYPT, &vec, vec_name, cfg,
> > -					req, tsgls);
> > -		if (err)
> > -			goto out;
> > +		if (vec.crypt_error != 0) {
> > +			err = test_aead_vec_cfg(driver, DECRYPT, &vec, vec_name,
> > +						cfg, req, tsgls);
> > +			if (err)
> > +				goto out;
> > +		}
> >  		cond_resched();
> >  	}
> >  	err = 0;
> > 
> > I'm planning to (at some point) update the AEAD tests to intentionally generate
> > some inauthentic inputs, but that will take some more work.
> > 
> > - Eric
> >
> I believe that's a rather essential part of verifying AEAD decryption(!)
> 

Agreed, which is why I am planning to work on it :-).  Actually a while ago I
started a patch for it, but there are some issues I haven't had time to address
quite yet:
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/commit/?h=wip-crypto&id=687f4198ba09032c60143e0477b48f94c5714263

- Eric

  reply	other threads:[~2019-07-30  0:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24  9:35 [PATCH] crypto: testmgr - Improve randomization of params for AEAD fuzz testing Pascal van Leeuwen
2019-07-28 17:30 ` Eric Biggers
2019-07-29  9:10   ` Pascal Van Leeuwen
2019-07-29 16:10     ` Pascal Van Leeuwen
2019-07-29 18:23       ` Eric Biggers
2019-07-29 22:31         ` Pascal Van Leeuwen
2019-07-29 18:17     ` Eric Biggers
2019-07-29 22:16       ` Pascal Van Leeuwen
2019-07-29 22:31         ` Herbert Xu
2019-07-29 22:49           ` Pascal Van Leeuwen
2019-07-29 23:53             ` Eric Biggers
2019-07-30  0:37               ` Pascal Van Leeuwen
2019-07-30  0:55                 ` Eric Biggers [this message]
2019-07-30  1:26                   ` Pascal Van Leeuwen
2019-07-30  4:26                     ` Eric Biggers
2019-07-30 10:24                       ` Pascal Van Leeuwen
2019-07-30  0:17         ` Eric Biggers
2019-07-30  0:30           ` Pascal Van Leeuwen

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=20190730005532.GL169027@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=pascalvanl@gmail.com \
    --cc=pvanleeuwen@verimatrix.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.