[v2] doc: announce move of aes gmac algorithm to aead

  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>
---
v2:
- added description

 doc/guides/rel_notes/deprecation.rst | 4 ++++
 1 file changed, 4 insertions(+)
  

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.
Anyway this proposal didn't meet its audience.
Because of the lack of ack (3 required), it cannot be accepted.
  

Hi Thomas,

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net> 
Sent: piątek, 7 sierpnia 2020 23:49
To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
Cc: dev@dpdk.org; akhil.goyal@nxp.com; anoobj@marvell.com; Doherty, Declan <declan.doherty@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>; asomalap@amd.com; rnagadheeraj@marvell.com; hemant.agrawal@nxp.com; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Zhang, Roy Fan <roy.fan.zhang@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.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.
Anyway this proposal didn't meet its audience.
Because of the lack of ack (3 required), it cannot be accepted.
  

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?
  

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: wtorek, 1 września 2020 10:19
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Cc: dev@dpdk.org; akhil.goyal@nxp.com; anoobj@marvell.com; Doherty,
> Declan <declan.doherty@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> asomalap@amd.com; rnagadheeraj@marvell.com; hemant.agrawal@nxp.com;
> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Zhang, Roy Fan
> <roy.fan.zhang@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@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.

[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.

>