Hi Thomas, -----Original Message----- From: Thomas Monjalon <tho...@monjalon.net> Sent: piątek, 7 sierpnia 2020 23:49 To: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com> Cc: dev@dpdk.org; akhil.go...@nxp.com; ano...@marvell.com; Doherty, Declan <declan.dohe...@intel.com>; Trahe, Fiona <fiona.tr...@intel.com>; asoma...@amd.com; rnagadhee...@marvell.com; hemant.agra...@nxp.com; De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; Zhang, Roy Fan <roy.fan.zh...@intel.com> Subject: Re: [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead
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. Anyway this proposal didn't meet its audience. Because of the lack of ack (3 required), it cannot be accepted.
