DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead
@ 2020-08-05 15:15 Arek Kusztal
  2020-08-07 21:49 ` Thomas Monjalon
  0 siblings, 1 reply; 5+ messages in thread
From: Arek Kusztal @ 2020-08-05 15:15 UTC (permalink / raw)
  To: dev
  Cc: akhil.goyal, anoobj, declan.doherty, fiona.trahe, asomalap,
	rnagadheeraj, hemant.agrawal, pablo.de.lara.guarch,
	roy.fan.zhang, 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>
---
v2:
- added description

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

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ea4cfa7..6fe12b0 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -151,3 +151,7 @@ Deprecation Notices
   Python 2 support will be completely removed in 20.11.
   In 20.08, explicit deprecation warnings will be displayed when running
   scripts with Python 2.
+
+* 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``.
-- 
2.1.0


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead
  2020-08-05 15:15 [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead Arek Kusztal
@ 2020-08-07 21:49 ` Thomas Monjalon
  2020-08-31  6:34   ` Kusztal, ArkadiuszX
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Monjalon @ 2020-08-07 21:49 UTC (permalink / raw)
  To: Arek Kusztal
  Cc: dev, akhil.goyal, anoobj, declan.doherty, fiona.trahe, asomalap,
	rnagadheeraj, hemant.agrawal, pablo.de.lara.guarch,
	roy.fan.zhang

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.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead
  2020-08-07 21:49 ` Thomas Monjalon
@ 2020-08-31  6:34   ` Kusztal, ArkadiuszX
  2020-09-01  8:18     ` Thomas Monjalon
  0 siblings, 1 reply; 5+ messages in thread
From: Kusztal, ArkadiuszX @ 2020-08-31  6:34 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: dev, akhil.goyal, anoobj, Doherty, Declan, Trahe, Fiona,
	asomalap, rnagadheeraj, hemant.agrawal, De Lara Guarch, Pablo,
	Zhang, Roy Fan

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.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead
  2020-08-31  6:34   ` Kusztal, ArkadiuszX
@ 2020-09-01  8:18     ` Thomas Monjalon
  2020-09-01 10:57       ` Kusztal, ArkadiuszX
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Monjalon @ 2020-09-01  8:18 UTC (permalink / raw)
  To: Kusztal, ArkadiuszX
  Cc: dev, akhil.goyal, anoobj, Doherty, Declan, Trahe, Fiona,
	asomalap, rnagadheeraj, hemant.agrawal, De Lara Guarch, Pablo,
	Zhang, Roy Fan

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?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead
  2020-09-01  8:18     ` Thomas Monjalon
@ 2020-09-01 10:57       ` Kusztal, ArkadiuszX
  0 siblings, 0 replies; 5+ messages in thread
From: Kusztal, ArkadiuszX @ 2020-09-01 10:57 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: dev, akhil.goyal, anoobj, Doherty, Declan, Trahe, Fiona,
	asomalap, rnagadheeraj, hemant.agrawal, De Lara Guarch, Pablo,
	Zhang, Roy Fan



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

> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-09-01 10:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-05 15:15 [dpdk-dev] [PATCH v2] doc: announce move of aes gmac algorithm to aead Arek Kusztal
2020-08-07 21:49 ` Thomas Monjalon
2020-08-31  6:34   ` Kusztal, ArkadiuszX
2020-09-01  8:18     ` Thomas Monjalon
2020-09-01 10:57       ` Kusztal, ArkadiuszX

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git