From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
"anoobj@marvell.com" <anoobj@marvell.com>,
"shallyv@marvell.com" <shallyv@marvell.com>,
"Doherty, Declan" <declan.doherty@intel.com>,
"Zhang, Roy Fan" <roy.fan.zhang@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms
Date: Wed, 29 Jul 2020 16:20:52 +0000 [thread overview]
Message-ID: <SN6PR11MB28804430BD5979D2FC95CB8EE4700@SN6PR11MB2880.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20200729142219.13376-1-arkadiuszx.kusztal@intel.com>
Hi Arek,
Small typo below.
> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Wednesday, July 29, 2020 3:22 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; anoobj@marvell.com;
> shallyv@marvell.com; Doherty, Declan <declan.doherty@intel.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms
>
> This is proposal to move AES-GMAC algorithm to AEAD set
> of algorithms. It is however not 100% conformant GMAC as instead of aad pointer
> data to be authenticated is passed normally and aead.data.length field
> is used to specify length of data to be authenticated.
> Reason behind this move is that GMAC is variant of GCM so it may
> simplify implementations that are using these algorithms (mainly IPsec).
> AES-GMAC therefore needs to be removed from auth algorithms.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> lib/librte_cryptodev/rte_crypto_sym.h | 15 +++++++++++----
> lib/librte_cryptodev/rte_cryptodev.c | 4 ++--
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
> index f29c980..1b43c6e 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -255,8 +255,6 @@ enum rte_crypto_auth_algorithm {
> /**< AES-CBC-MAC algorithm. Only 128-bit keys are supported. */
> RTE_CRYPTO_AUTH_AES_CMAC,
> /**< AES CMAC algorithm. */
> - RTE_CRYPTO_AUTH_AES_GMAC,
> - /**< AES GMAC algorithm. */
> RTE_CRYPTO_AUTH_AES_XCBC_MAC,
> /**< AES XCBC algorithm. */
>
> @@ -414,6 +412,8 @@ enum rte_crypto_aead_algorithm {
> /**< AES algorithm in GCM mode. */
> RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
> /**< Chacha20 cipher with poly1305 authenticator */
> + RTE_CRYPTO_AEAD_AES_GMAC,
> + /**< AES-GCM algorithm in GMAC mode. */
> RTE_CRYPTO_AEAD_LIST_END
> };
>
> @@ -468,7 +468,7 @@ struct rte_crypto_aead_xform {
> uint16_t length;
> /**< Length of valid IV data.
> *
> - * - For GCM mode, this is either:
> + * - For GCM and GMAC mode, this is either:
> * 1) Number greater or equal to one, which means that IV
> * is used and J0 will be computed internally, a minimum
> * of 16 bytes must be allocated.
> @@ -490,6 +490,8 @@ struct rte_crypto_aead_xform {
> * For CCM mode, this is the length of the actual AAD, even though
> * it is required to reserve 18 bytes before the AAD and padding
> * at the end of it, so a multiple of 16 bytes is allocated.
> + *
> + * For RTE_CRYPTO_AEAD_AES_GMAC this field should be set to 0.
> */
> };
>
> @@ -584,7 +586,10 @@ struct rte_crypto_sym_op {
> uint32_t length;
> /**< The message length, in bytes, of the source buffer
> * on which the cryptographic operation will be
> - * computed. This must be a multiple of the block size
> + * computed.
> + *
> + * For RTE_CRYPTO_AEAD_AES_GMAC this is length of data to be
> + * authenticated.
> */
> } data; /**< Data offsets and length for AEAD */
> struct {
> @@ -617,6 +622,8 @@ struct rte_crypto_sym_op {
> * needed for authenticated cipher mechanisms (CCM and
> * GCM)
> *
> + * For GCM this field is unused
[Fiona] typo GCM->GMAC
next prev parent reply other threads:[~2020-07-29 16:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 14:22 Arek Kusztal
2020-07-29 14:36 ` Kusztal, ArkadiuszX
2020-07-29 16:20 ` Trahe, Fiona [this message]
2020-07-31 14:33 ` Doherty, Declan
2020-08-05 4:27 ` Kusztal, ArkadiuszX
2020-09-22 19:17 ` Akhil Goyal
2020-09-28 9:32 ` Trahe, Fiona
2020-09-01 8:13 ` Zhang, Roy Fan
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=SN6PR11MB28804430BD5979D2FC95CB8EE4700@SN6PR11MB2880.namprd11.prod.outlook.com \
--to=fiona.trahe@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=anoobj@marvell.com \
--cc=arkadiuszx.kusztal@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=roy.fan.zhang@intel.com \
--cc=shallyv@marvell.com \
/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).