Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: AEAD question
Date: Mon, 22 Jul 2019 09:22:40 -0700	[thread overview]
Message-ID: <20190722162240.GB689@sol.localdomain> (raw)
In-Reply-To: <MN2PR20MB29734143B4A5F5E418D55001CAC40@MN2PR20MB2973.namprd20.prod.outlook.com>

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?  I'm not familiar with that algorithm, so you'll
have to research what the specification says, and what's actually using it.

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.

But again, someone actually has to research this.  Maybe
crypto_aead_setauthsize() should simply reject authsize=0 for all AEADs.

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.

- Eric

  reply	other threads:[~2019-07-22 16:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 12:55 AEAD question Pascal Van Leeuwen
2019-07-22 16:22 ` Eric Biggers [this message]
2019-07-22 22:26   ` Pascal Van Leeuwen
2019-08-06  9:20     ` Pascal Van Leeuwen
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 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=20190722162240.GB689@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox