Linux-Crypto Archive on lore.kernel.org
 help / color / Atom feed
From: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
To: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	Eric Biggers <ebiggers@kernel.org>
Subject: RE: AEAD question
Date: Tue, 6 Aug 2019 09:20:52 +0000
Message-ID: <MN2PR20MB2973743A8887D20AC6104DC0CAD50@MN2PR20MB2973.namprd20.prod.outlook.com> (raw)
In-Reply-To: <MN2PR20MB2973B95A0C91380CF881FF25CAC40@MN2PR20MB2973.namprd20.prod.outlook.com>

Herbert,

The discussion below still lacks some resolution ...

What is boils down to is: what should an authenc AEAD driver do when it
gets a setauthsize request of zero?

It could either return -EINVAL on the setauthsize request as AEAD with
an authsize of zero makes no sense at all and only allowing a limited 
subset of authsizes seems to be commonplace.
Or it could process the request without appending or verifying the 
authenticator (basically throwing away the authentication result!).

I have a strong preference for the former, as the latter would require
workarounds in the inside-secure driver for a corner case that does
not make any practicle sense (without the authenticator, it is not an
AEAD in the first place, why authenticate and throw away the result?), 
but the current generic implementation does seem to process this.

Consistent behavior here is important for the fuzz testing by testmgr.

Regards,
Pascal

> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of
> Pascal Van Leeuwen
> Sent: Tuesday, July 23, 2019 12:27 AM
> To: Eric Biggers <ebiggers@kernel.org>
> Cc: linux-crypto@vger.kernel.org; Herbert Xu <herbert@gondor.apana.org.au>;
> davem@davemloft.net
> Subject: RE: AEAD question
> 
> > -----Original Message-----
> > From: Eric Biggers <ebiggers@kernel.org>
> > Sent: Monday, July 22, 2019 6:23 PM
> > To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> > Cc: linux-crypto@vger.kernel.org; Herbert Xu <herbert@gondor.apana.org.au>;
> davem@davemloft.net
> > Subject: Re: AEAD question
> >
> > On Mon, Jul 22, 2019 at 12:55:39PM +0000, Pascal Van Leeuwen wrote:
> > > Eric & Herbert,
> > >
> > > I noticed the testmgr fuzz tester generating (occasionally, see previous mail) tests
> cases with
> > > authsize=0 for the AEAD ciphers. I'm wondering if that is intentional. Or actually,
> I'm wondering
> > > whether that should be considered a legal case.
> > > To me, it doesn't seem to make a whole lot of sense to do *authenticated* encryption
> and then
> > > effectively throw away the authentication result ... (it's just a waste of power
> and/or cycles)
> > >
> > > The reason for this question is that supporting this requires some specific workaround
> in my
> > > driver (yet again). And yes, I'm aware of the fact that I can advertise I don't
> support zero length
> > > authentication tags, but then probably/likely testmgr will punish me for that instead.
> > >
> >
> > As before you're actually talking about the "authenc" template for IPSec and not
> > about AEADs in general, right?
> >
> Hmmm .... for the time being yes. At the time I wrote that, I was still expecting all
> AEAD's to be
> somewhat consistent in this respect (as our hardware is), but actually I've just been
> trying to
> reverse engineer the GCM template and IIRC it indeed does not allow an authsize of 0.
> Or anything below 4 bytes, actually.
> 
> >  I'm not familiar with that algorithm, so you'll
> > have to research what the specification says, and what's actually using it.
> >
> To the best of my knowledge, there is no formal specification of any such thing. There are
> protocols that use it (e.g. IPsec) which have restrictions but other protocols beyond my
> knowledge may have other restrictions ... 0 seems very unlikely though ...
> 
> > Using an AEAD with authsize=0 is indeed silly, but perhaps someone using that in
> > some badly designed protocol where authentication is optional.  Also AFAICS from
> > the code, any authsize fits naturally into the algorithm; i.e., excluding 0
> > would be a special case.
> >
> Again, looking at the GCM template, excluding certain authsizes is certainly not
> something out of the ordinary.
> 
> > But again, someone actually has to research this.  Maybe
> > crypto_aead_setauthsize() should simply reject authsize=0 for all AEADs.
> >
> IMHO that would make sense. Without authentication, it's not an AEAD.
> And actually executing the MAC and then throwing away the *full* result is really
> silly. More likely to be some programming mistake than actually intended use.
> (but if someone knows of an actual use case for that, please do correct me)
> 
> > What we should *not* do, IMO, is remove it from the tests and allow
> > implementations to do whatever they want.  If it's wrong we should fix it
> > everywhere, so that the behavior is consistent.
> >
> Oh, I fully agree there. All implementations should still respond the same.
> 
> > - Eric
> 
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
> www.insidesecure.com

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 12:55 Pascal Van Leeuwen
2019-07-22 16:22 ` Eric Biggers
2019-07-22 22:26   ` Pascal Van Leeuwen
2019-08-06  9:20     ` Pascal Van Leeuwen [this message]
2019-08-09  2:57       ` Herbert Xu
  -- strict thread matches above, loose matches on Subject: below --
2016-10-26 16:17 AEAD Question Juan Pablo Nariño Mendoza
2016-10-26 16:32 ` Stephan Mueller
2016-10-27  8:05   ` Juan Pablo Nariño Mendoza

Reply instructions:

You may reply publically 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=MN2PR20MB2973743A8887D20AC6104DC0CAD50@MN2PR20MB2973.namprd20.prod.outlook.com \
    --to=pvanleeuwen@verimatrix.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --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

Linux-Crypto Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-crypto/0 linux-crypto/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-crypto linux-crypto/ https://lore.kernel.org/linux-crypto \
		linux-crypto@vger.kernel.org
	public-inbox-index linux-crypto

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-crypto


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git