linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Ofir Drang <ofir.drang@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] crypto: testmgr - sync both RFC4106 IV copies
Date: Wed, 4 Mar 2020 11:58:53 -0800	[thread overview]
Message-ID: <20200304195853.GA1005@sol.localdomain> (raw)
In-Reply-To: <CAOtvUMd6Ak3n-ABO1h440BoDASJUvh+-9PwEGFi-WzA=g84kLg@mail.gmail.com>

On Wed, Mar 04, 2020 at 03:48:47PM +0200, Gilad Ben-Yossef wrote:
> 
> >
> > > +     const unsigned int aad_tail_size = suite->skip_aad_iv ? aad_ivsize : 0;
> > >       const unsigned int authsize = vec->clen - vec->plen;
> > >
> > >       if (prandom_u32() % 2 == 0 && vec->alen > aad_tail_size) {
> > >                /* Mutate the AAD */
> > >               flip_random_bit((u8 *)vec->assoc, vec->alen - aad_tail_size);
> > > +             if (suite->auth_aad_iv)
> > > +                     memcpy((u8 *)vec->iv,
> > > +                            (vec->assoc + vec->alen - aad_ivsize),
> > > +                            aad_ivsize);
> >
> > Why sync the IV copies here?  When 'auth_aad_iv', we assume the copy of the IV
> > in the AAD (which was just corrupted) is authenticated.  So we already know that
> > decryption should fail, regardless of the other IV copy.
> 
> Nope. We know there needs to be a copy of the IV in the AAD and we know the IV
> should be included in calculating in the authentication tag. We don't know which
> copy of the IV will be used by the implementation.
> 
> Case in point - the ccree driver actually currently uses the copy of
> the IV passed via
> req->iv for calculating the IV contribution to the authentication tag,
> not the one in the AAD.
> 
> And what happens then if you don't do this copy than is that you get
> an unexpected
> decryption success where the test expects failure, because the driver
> fed the HW the
> none mutated copy of the IV from req->iv and not the mutated copy
> found in the AAD.

Okay, well in that case I don't see any difference between the two flags.  This
is because changing the IV *must* affect the authentication tag for *any* AEAD
algorithm, otherwise it's not actually authenticated encryption.

So why don't we just use a single flag 'aad_iv' that's set on rfc4106, rfc4309,
rfc4543, and rfc7539esp?  This flag would mean that the last bytes of the AAD
buffer must contain another copy of the IV for the behavior to be well-defined.

> > > @@ -2208,6 +2220,10 @@ static void generate_aead_message(struct aead_request *req,
> > >       /* Generate the AAD. */
> > >       generate_random_bytes((u8 *)vec->assoc, vec->alen);
> > >
> > > +     if (suite->auth_aad_iv && (vec->alen > ivsize))
> > > +             memcpy(((u8 *)vec->assoc + vec->alen - ivsize), vec->iv,
> > > +                    ivsize);
> >
> > Shouldn't this be >= ivsize, not > ivsize?
> Indeed.
> 
> > And doesn't the IV need to be synced
> > in both the skip_aad_iv and auth_aad_iv cases?
> 
> Nope, because in the skip_aad_iv case we never mutate the IV, so no
> point in copying.

But even if the IV isn't mutated, both copies still need to be the same, right?
We seem to have concluded that the behavior should be implementation-defined
when they're different, so that's the logical consequence...

- Eric

  reply	other threads:[~2020-03-04 19:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 12:09 [PATCH v2] crypto: testmgr - sync both RFC4106 IV copies Gilad Ben-Yossef
2020-03-04  0:06 ` Eric Biggers
2020-03-04 13:48   ` Gilad Ben-Yossef
2020-03-04 19:58     ` Eric Biggers [this message]
2020-03-04 22:46       ` Eric Biggers

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=20200304195853.GA1005@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=davem@davemloft.net \
    --cc=geert+renesas@glider.be \
    --cc=gilad@benyossef.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ofir.drang@arm.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 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).