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