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

[Thomas Monjalon <thomas@monjalon.net>]

31/08/2020 08:34, Kusztal, ArkadiuszX:
> From: Thomas Monjalon <thomas@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@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.

> 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?