[dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: wtorek, 1 września 2020 10:19
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>
> Cc: dev at dpdk.org; akhil.goyal at nxp.com; anoobj at marvell.com; Doherty,
> Declan <declan.doherty at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>;
> asomalap at amd.com; rnagadheeraj at marvell.com; hemant.agrawal at nxp.com;
> De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>; Zhang, Roy Fan
> <roy.fan.zhang at intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm
> to aead
> 
> 31/08/2020 08:34, Kusztal, ArkadiuszX:
> > From: Thomas Monjalon <thomas at monjalon.net>
> > > 05/08/2020 17:15, Arek Kusztal:
> > > > This patch announces removal of RTE_CRYPTO_AUTH_AES_GMAC from
> > > > rte_crypto_auth_algorithm and addition of
> RTE_CRYPTO_AEAD_AES_GMAC
> > > > to rte_crypto_aead_algorithm.
> > > > AES-GMAC is variation of AES-GCM algorithm with the difference
> > > > that it does not perform encryption. As a matter of fact
> > > > internally there is no difference between GMAC and GCM except for
> > > > the way how data is passed.
> > > > Moving GMAC to AEAD can simplify way of implementing this
> > > > alogrithm for example in IPsec (RFC4543).
> > > >
> > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal at intel.com>
> > > > ---
> > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > +* cryptodev: ``RTE_CRYPTO_AUTH_AES_GMAC`` will no longer be
> > > > +included in
> > > > +  ``enum rte_crypto_auth_algorithm``. It will be included in
> > > > +  ``enum rte_crypto_aead_algorithm`` as
> ``RTE_CRYPTO_AEAD_AES_GMAC``.
> > >
> > > I wonder whether this move shows a problem in classification of the
> > > crypto algorithms.
> >
> > [Arek] - it is not particularly bad that GMAC is auth algorithm, it really depends
> on lib (openssl PMD internally uses conformant approach I have suggested in
> other mail).
> > But from what I currently see GMAC as AEAD is preferred way, I think this
> subject may be back in future.
> 
> The strange thing is that AEAD is a kind of authentication, isn't it?
> I would see it as a subset of auth algos.

[Arek] - AEAD is indeed kind of authentication but only combined with encryption hence it is distinct category.
GMAC though is this peculiar case where there is no encryption even if algorithm is perfectly capable of it.
So GMAC potentially can be both.
> 
> > Anyway this proposal didn't meet its audience.
> > Because of the lack of ack (3 required), it cannot be accepted.
> 
> Indeed. Why others did not approve?
> What is the consequence?

[Arek] - rfc4543 is the one I see most of a confusion comes from (not all crypto protocols standardizes GMAC).
It specifies ENCR_NULL_AUTH_GMAC as "companion to AES GCM ESP" (1) and "combined mode algorithm" (3) -> so implementation may be facilitated
when GMAC and GCM would be in the same category as both share same features -> both "combined-algorithm" not "combined" ESP-GCM and integrity ESP-GMAC.
On the other hand  aforementioned rfc does not explicitly specify transport mode (AH) GMAC as "combined" but it seems that people probably care less as AH comes with its own set of problems (like natural dislike of NAT),
so probably using AEAD for it would not be a main issue.

>