DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
	"anoobj@marvell.com" <anoobj@marvell.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>,
	"asomalap@amd.com" <asomalap@amd.com>,
	"rnagadheeraj@marvell.com" <rnagadheeraj@marvell.com>,
	"hemant.agrawal@nxp.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
Date: Tue, 1 Sep 2020 10:57:08 +0000	[thread overview]
Message-ID: <CY4PR11MB18301C534C3DA84288FE56079F2E0@CY4PR11MB1830.namprd11.prod.outlook.com> (raw)
In-Reply-To: <10057334.se6I27zTtR@thomas>



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

> 


      reply	other threads:[~2020-09-01 10:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05 15:15 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 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY4PR11MB18301C534C3DA84288FE56079F2E0@CY4PR11MB1830.namprd11.prod.outlook.com \
    --to=arkadiuszx.kusztal@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=asomalap@amd.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=rnagadheeraj@marvell.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).