[RFC] cryptodev: move AES-GMAC to aead algorithms
diff mbox series

Message ID 20200729142219.13376-1-arkadiuszx.kusztal@intel.com
State Changes Requested
Delegated to: akhil goyal
Headers show
Series
  • [RFC] cryptodev: move AES-GMAC to aead algorithms
Related show

Checks

Context Check Description
ci/Intel-compilation fail Compilation issues
ci/checkpatch warning coding style issues

Commit Message

Kusztal, ArkadiuszX July 29, 2020, 2:22 p.m. UTC
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(-)

Comments

Kusztal, ArkadiuszX July 29, 2020, 2:36 p.m. UTC | #1
Hi All,

I would give bit more introduction to this change:
Right now AES-GMAC is auth only algorithm (previously it was cipher+auth -> GCM + GMAC),
but since it is variant of AES-GCM implementation it should probably be AEAD right now (people often wondering why at all it is auth instead of AEAD).
There are few possible implementations let me introduce two of them:
1) As in this patch GMAC is added to AEAD enum, aad_len is set to 0, aad_pointer is unused and authentication length is set in aead.data.length - this is probably the easiest one, but not totally conformant to GMAC spec.
2) Another option could be to use GCM only and add new field aad_len in rte_crypto_sym_op, so when cipher_len == 0 GMAC is used -> this would be conformant implementation but bit trickier.

Sorry if I not included someone in cc list.

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Wednesday, July 29, 2020 4: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
> +				 *
>  				 * 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
Trahe, Fiona July 29, 2020, 4:20 p.m. UTC | #2
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
Doherty, Declan July 31, 2020, 2:33 p.m. UTC | #3
On 29/07/2020 3:22 PM, Arek Kusztal wrote:
> 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>
> ---
..
> 

I think  this makes sense in light of how AES-GMAC support is specified 
in the IPsec GMAC rfc (https://tools.ietf.org/html/rfc4543)

Acked-by: Declan Doherty <declan.doherty@intel.com>
Kusztal, ArkadiuszX Aug. 5, 2020, 4:27 a.m. UTC | #4
Hi Akhil,

@Akhil: Is there a chance getting this change into 20.11?

Any more comments or anyone see any potential issues with this approach?

Regards,
Arek

-----Original Message-----
From: Doherty, Declan <declan.doherty@intel.com> 
Sent: piątek, 31 lipca 2020 16:34
To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; anoobj@marvell.com; shallyv@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>
Subject: Re: [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms

On 29/07/2020 3:22 PM, Arek Kusztal wrote:
> 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>
> ---
..
> 

I think  this makes sense in light of how AES-GMAC support is specified in the IPsec GMAC rfc (https://tools.ietf.org/html/rfc4543)

Acked-by: Declan Doherty <declan.doherty@intel.com>
Zhang, Roy Fan Sept. 1, 2020, 8:13 a.m. UTC | #5
> -----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>

Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Akhil Goyal Sept. 22, 2020, 7:17 p.m. UTC | #6
Hi Arek,

> 
> Hi Akhil,
> 
> @Akhil: Is there a chance getting this change into 20.11?
> 
> Any more comments or anyone see any potential issues with this approach?
> 

I am ok to take this patch in 20.11 release. Could you please send a new version
With complete patch, removing all references of RTE_CRYPTO_AUTH_AES_GMAC.

Please explain in the release notes and deprecation notice as well.


> Subject: Re: [PATCH] [RFC] cryptodev: move AES-GMAC to aead algorithms
> 
> On 29/07/2020 3:22 PM, Arek Kusztal wrote:
> > 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>
> > ---
> ..
> >
> 
> I think  this makes sense in light of how AES-GMAC support is specified in the
> IPsec GMAC rfc
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.iet
> f.org%2Fhtml%2Frfc4543&amp;data=02%7C01%7Cakhil.goyal%40nxp.com%7Cf
> 0aec031674e4832272108d838f7e961%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637321984712376305&amp;sdata=OgaLnAqcAGg1xzD8QfSWn%
> 2F9Qa8vOkqEiZutDZcz5JLo%3D&amp;reserved=0)
> 
> Acked-by: Declan Doherty <declan.doherty@intel.com>

Patch
diff mbox series

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"
 };
 
 /**