DPDK patches and discussions
 help / color / mirror / Atom feed
From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
To: dev@dpdk.org
Cc: akhil.goyal@nxp.com, fiona.trahe@intel.com, anoobj@marvell.com,
	shallyv@marvell.com, declan.doherty@intel.com,
	roy.fan.zhang@intel.com, konstantin.ananyev@intel.com,
	Arek Kusztal <arkadiuszx.kusztal@intel.com>
Subject: [dpdk-dev] [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms
Date: Wed, 29 Jul 2020 16:22:19 +0200	[thread overview]
Message-ID: <20200729142219.13376-1-arkadiuszx.kusztal@intel.com> (raw)

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
+				 *
 				 * Specifically for CCM (@ref RTE_CRYPTO_AEAD_AES_CCM),
 				 * the caller should setup this field as follows:
 				 *
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 1dd795b..e14fd09 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -129,7 +129,6 @@ const char *
 rte_crypto_auth_algorithm_strings[] = {
 	[RTE_CRYPTO_AUTH_AES_CBC_MAC]	= "aes-cbc-mac",
 	[RTE_CRYPTO_AUTH_AES_CMAC]	= "aes-cmac",
-	[RTE_CRYPTO_AUTH_AES_GMAC]	= "aes-gmac",
 	[RTE_CRYPTO_AUTH_AES_XCBC_MAC]	= "aes-xcbc-mac",
 
 	[RTE_CRYPTO_AUTH_MD5]		= "md5",
@@ -162,7 +161,8 @@ const char *
 rte_crypto_aead_algorithm_strings[] = {
 	[RTE_CRYPTO_AEAD_AES_CCM]	= "aes-ccm",
 	[RTE_CRYPTO_AEAD_AES_GCM]	= "aes-gcm",
-	[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
+	[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305",
+	[RTE_CRYPTO_AEAD_AES_GMAC] = "aes-gmac"
 };
 
 /**
-- 
2.1.0


             reply	other threads:[~2020-07-29 14:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 14:22 Arek Kusztal [this message]
2020-07-29 14:36 ` Kusztal, ArkadiuszX
2020-07-29 16:20 ` Trahe, Fiona
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=20200729142219.13376-1-arkadiuszx.kusztal@intel.com \
    --to=arkadiuszx.kusztal@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --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).