[dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Arek Kusztal]

This patch adds an option to support both IV (of all supported sizes)
and J0 when using Galois Counter Mode of crypto operation.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index c80e90e..126d9f3 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
 		 *
 		 * - For block ciphers in CTR mode, this is the counter.
 		 *
-		 * - For GCM mode, this is either the IV (if the length
-		 * is 96 bits) or J0 (for other sizes), where J0 is as
-		 * defined by NIST SP800-38D. Regardless of the IV
-		 * length, a full 16 bytes needs to be allocated.
-		 *
 		 * - For CCM mode, the first byte is reserved, and the
 		 * nonce should be written starting at &iv[1] (to allow
 		 * space for the implementation to write in the flags
@@ -184,9 +179,6 @@ struct rte_crypto_cipher_xform {
 		 * of the counter (which must be the same as the block
 		 * length of the cipher).
 		 *
-		 * - For GCM mode, this is either 12 (for 96-bit IVs)
-		 * or 16, in which case data points to J0.
-		 *
 		 * - For CCM mode, this is the length of the nonce,
 		 * which can be in the range 7 to 13 inclusive.
 		 */
@@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
 		 * specified as number of bytes from start of crypto
 		 * operation (rte_crypto_op).
 		 *
-		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
-		 *   for AES-GMAC, this is the authentication
-		 *   Initialisation Vector (IV) value.
+		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
+		 *   this is the authentication Initialisation Vector
+		 *   (IV) value. For AES-GMAC IV description please refer
+		 *   to the field `length` in iv struct.
 		 *
 		 * - For KASUMI in F9 mode and other authentication
 		 *   algorithms, this field is not used.
@@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
 		 * - For KASUMI in F9 mode and other authentication
 		 *   algorithms, this field is not used.
 		 *
+		 * - For GMAC mode, this is either:
+		 * 1) Number greater or equal to one, which means that IV
+		 *    is used and J0 will be computed internally, 16 bytes
+		 *    needs to be allocated.
+		 * 2) Zero, in which case data points to J0. In this case
+		 *    16 bytes of J0 should be passed where J0 is defined
+		 *    by NIST SP800-38D.
+		 *
 		 */
 	} iv;	/**< Initialisation vector parameters */
 
@@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
 		 * specified as number of bytes from start of crypto
 		 * operation (rte_crypto_op).
 		 *
-		 * - For GCM mode, this is either the IV (if the length
-		 * is 96 bits) or J0 (for other sizes), where J0 is as
-		 * defined by NIST SP800-38D. Regardless of the IV
-		 * length, a full 16 bytes needs to be allocated.
-		 *
 		 * - For CCM mode, the first byte is reserved, and the
 		 * nonce should be written starting at &iv[1] (to allow
 		 * space for the implementation to write in the flags
@@ -401,8 +397,13 @@ struct rte_crypto_aead_xform {
 		uint16_t length;
 		/**< Length of valid IV data.
 		 *
-		 * - For GCM mode, this is either 12 (for 96-bit IVs)
-		 * or 16, in which case data points to J0.
+		 * - For GCM mode, this is either:
+		 * 1) Number greater or equal to one, which means that IV
+		 *    is used and J0 will be computed internally, 16 bytes
+		 *    needs to be allocated.
+		 * 2) Zero, in which case data points to J0. In this case
+		 *    16 bytes of J0 should be passed where J0 is defined
+		 *    by NIST SP800-38D.
 		 *
 		 * - For CCM mode, this is the length of the nonce,
 		 * which can be in the range 7 to 13 inclusive.
-- 
2.1.0

[dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Arek Kusztal]

This patch adds an option to support both IV (of all supported sizes)
and J0 when using Galois Counter Mode of crypto operation.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index c80e90e..126d9f3 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
 		 *
 		 * - For block ciphers in CTR mode, this is the counter.
 		 *
-		 * - For GCM mode, this is either the IV (if the length
-		 * is 96 bits) or J0 (for other sizes), where J0 is as
-		 * defined by NIST SP800-38D. Regardless of the IV
-		 * length, a full 16 bytes needs to be allocated.
-		 *
 		 * - For CCM mode, the first byte is reserved, and the
 		 * nonce should be written starting at &iv[1] (to allow
 		 * space for the implementation to write in the flags
@@ -184,9 +179,6 @@ struct rte_crypto_cipher_xform {
 		 * of the counter (which must be the same as the block
 		 * length of the cipher).
 		 *
-		 * - For GCM mode, this is either 12 (for 96-bit IVs)
-		 * or 16, in which case data points to J0.
-		 *
 		 * - For CCM mode, this is the length of the nonce,
 		 * which can be in the range 7 to 13 inclusive.
 		 */
@@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
 		 * specified as number of bytes from start of crypto
 		 * operation (rte_crypto_op).
 		 *
-		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
-		 *   for AES-GMAC, this is the authentication
-		 *   Initialisation Vector (IV) value.
+		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
+		 *   this is the authentication Initialisation Vector
+		 *   (IV) value. For AES-GMAC IV description please refer
+		 *   to the field `length` in iv struct.
 		 *
 		 * - For KASUMI in F9 mode and other authentication
 		 *   algorithms, this field is not used.
@@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
 		 * - For KASUMI in F9 mode and other authentication
 		 *   algorithms, this field is not used.
 		 *
+		 * - For GMAC mode, this is either:
+		 * 1) Number greater or equal to one, which means that IV
+		 *    is used and J0 will be computed internally, 16 bytes
+		 *    needs to be allocated.
+		 * 2) Zero, in which case data points to J0. In this case
+		 *    16 bytes of J0 should be passed where J0 is defined
+		 *    by NIST SP800-38D.
+		 *
 		 */
 	} iv;	/**< Initialisation vector parameters */
 
@@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
 		 * specified as number of bytes from start of crypto
 		 * operation (rte_crypto_op).
 		 *
-		 * - For GCM mode, this is either the IV (if the length
-		 * is 96 bits) or J0 (for other sizes), where J0 is as
-		 * defined by NIST SP800-38D. Regardless of the IV
-		 * length, a full 16 bytes needs to be allocated.
-		 *
 		 * - For CCM mode, the first byte is reserved, and the
 		 * nonce should be written starting at &iv[1] (to allow
 		 * space for the implementation to write in the flags
@@ -401,8 +397,13 @@ struct rte_crypto_aead_xform {
 		uint16_t length;
 		/**< Length of valid IV data.
 		 *
-		 * - For GCM mode, this is either 12 (for 96-bit IVs)
-		 * or 16, in which case data points to J0.
+		 * - For GCM mode, this is either:
+		 * 1) Number greater or equal to one, which means that IV
+		 *    is used and J0 will be computed internally, 16 bytes
+		 *    needs to be allocated.
+		 * 2) Zero, in which case data points to J0. In this case
+		 *    16 bytes of J0 should be passed where J0 is defined
+		 *    by NIST SP800-38D.
 		 *
 		 * - For CCM mode, this is the length of the nonce,
 		 * which can be in the range 7 to 13 inclusive.
-- 
2.1.0

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Trahe, Fiona]

Hi Arek,

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, April 17, 2019 8:37 AM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] cryptodev: add an option to support both iv and J0 for GCM
> 
> This patch adds an option to support both IV (of all supported sizes)
> and J0 when using Galois Counter Mode of crypto operation.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
>  1 file changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
> index c80e90e..126d9f3 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
>  		 *
>  		 * - For block ciphers in CTR mode, this is the counter.
>  		 *
> -		 * - For GCM mode, this is either the IV (if the length
> -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> -		 * defined by NIST SP800-38D. Regardless of the IV
> -		 * length, a full 16 bytes needs to be allocated.
> -		 *
>  		 * - For CCM mode, the first byte is reserved, and the
>  		 * nonce should be written starting at &iv[1] (to allow
>  		 * space for the implementation to write in the flags
> @@ -184,9 +179,6 @@ struct rte_crypto_cipher_xform {
>  		 * of the counter (which must be the same as the block
>  		 * length of the cipher).
>  		 *
> -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> -		 * or 16, in which case data points to J0.
> -		 *
>  		 * - For CCM mode, this is the length of the nonce,
>  		 * which can be in the range 7 to 13 inclusive.
>  		 */
> @@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
>  		 * specified as number of bytes from start of crypto
>  		 * operation (rte_crypto_op).
>  		 *
> -		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
> -		 *   for AES-GMAC, this is the authentication
> -		 *   Initialisation Vector (IV) value.
> +		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
> +		 *   this is the authentication Initialisation Vector
> +		 *   (IV) value. For AES-GMAC IV description please refer
> +		 *   to the field `length` in iv struct.
>  		 *
>  		 * - For KASUMI in F9 mode and other authentication
>  		 *   algorithms, this field is not used.
> @@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
>  		 * - For KASUMI in F9 mode and other authentication
>  		 *   algorithms, this field is not used.
>  		 *
> +		 * - For GMAC mode, this is either:
> +		 * 1) Number greater or equal to one, which means that IV
> +		 *    is used and J0 will be computed internally, 16 bytes
> +		 *    needs to be allocated.
[Fiona] IVs greater than 16 bytes can be used, right? If so change 
to "a minimum of 16 bytes must be allocated". Same below.

> +		 * 2) Zero, in which case data points to J0. In this case
> +		 *    16 bytes of J0 should be passed where J0 is defined
> +		 *    by NIST SP800-38D.
> +		 *
>  		 */
>  	} iv;	/**< Initialisation vector parameters */
> 
> @@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
>  		 * specified as number of bytes from start of crypto
>  		 * operation (rte_crypto_op).
>  		 *
> -		 * - For GCM mode, this is either the IV (if the length
> -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> -		 * defined by NIST SP800-38D. Regardless of the IV
> -		 * length, a full 16 bytes needs to be allocated.
> -		 *
>  		 * - For CCM mode, the first byte is reserved, and the
>  		 * nonce should be written starting at &iv[1] (to allow
>  		 * space for the implementation to write in the flags
> @@ -401,8 +397,13 @@ struct rte_crypto_aead_xform {
>  		uint16_t length;
>  		/**< Length of valid IV data.
>  		 *
> -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> -		 * or 16, in which case data points to J0.
> +		 * - For GCM mode, this is either:
> +		 * 1) Number greater or equal to one, which means that IV
> +		 *    is used and J0 will be computed internally, 16 bytes
> +		 *    needs to be allocated.
> +		 * 2) Zero, in which case data points to J0. In this case
> +		 *    16 bytes of J0 should be passed where J0 is defined
> +		 *    by NIST SP800-38D.
>  		 *
>  		 * - For CCM mode, this is the length of the nonce,
>  		 * which can be in the range 7 to 13 inclusive.
> --
> 2.1.0

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Trahe, Fiona]

Hi Arek,

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, April 17, 2019 8:37 AM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] cryptodev: add an option to support both iv and J0 for GCM
> 
> This patch adds an option to support both IV (of all supported sizes)
> and J0 when using Galois Counter Mode of crypto operation.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
>  1 file changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
> index c80e90e..126d9f3 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
>  		 *
>  		 * - For block ciphers in CTR mode, this is the counter.
>  		 *
> -		 * - For GCM mode, this is either the IV (if the length
> -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> -		 * defined by NIST SP800-38D. Regardless of the IV
> -		 * length, a full 16 bytes needs to be allocated.
> -		 *
>  		 * - For CCM mode, the first byte is reserved, and the
>  		 * nonce should be written starting at &iv[1] (to allow
>  		 * space for the implementation to write in the flags
> @@ -184,9 +179,6 @@ struct rte_crypto_cipher_xform {
>  		 * of the counter (which must be the same as the block
>  		 * length of the cipher).
>  		 *
> -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> -		 * or 16, in which case data points to J0.
> -		 *
>  		 * - For CCM mode, this is the length of the nonce,
>  		 * which can be in the range 7 to 13 inclusive.
>  		 */
> @@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
>  		 * specified as number of bytes from start of crypto
>  		 * operation (rte_crypto_op).
>  		 *
> -		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
> -		 *   for AES-GMAC, this is the authentication
> -		 *   Initialisation Vector (IV) value.
> +		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
> +		 *   this is the authentication Initialisation Vector
> +		 *   (IV) value. For AES-GMAC IV description please refer
> +		 *   to the field `length` in iv struct.
>  		 *
>  		 * - For KASUMI in F9 mode and other authentication
>  		 *   algorithms, this field is not used.
> @@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
>  		 * - For KASUMI in F9 mode and other authentication
>  		 *   algorithms, this field is not used.
>  		 *
> +		 * - For GMAC mode, this is either:
> +		 * 1) Number greater or equal to one, which means that IV
> +		 *    is used and J0 will be computed internally, 16 bytes
> +		 *    needs to be allocated.
[Fiona] IVs greater than 16 bytes can be used, right? If so change 
to "a minimum of 16 bytes must be allocated". Same below.

> +		 * 2) Zero, in which case data points to J0. In this case
> +		 *    16 bytes of J0 should be passed where J0 is defined
> +		 *    by NIST SP800-38D.
> +		 *
>  		 */
>  	} iv;	/**< Initialisation vector parameters */
> 
> @@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
>  		 * specified as number of bytes from start of crypto
>  		 * operation (rte_crypto_op).
>  		 *
> -		 * - For GCM mode, this is either the IV (if the length
> -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> -		 * defined by NIST SP800-38D. Regardless of the IV
> -		 * length, a full 16 bytes needs to be allocated.
> -		 *
>  		 * - For CCM mode, the first byte is reserved, and the
>  		 * nonce should be written starting at &iv[1] (to allow
>  		 * space for the implementation to write in the flags
> @@ -401,8 +397,13 @@ struct rte_crypto_aead_xform {
>  		uint16_t length;
>  		/**< Length of valid IV data.
>  		 *
> -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> -		 * or 16, in which case data points to J0.
> +		 * - For GCM mode, this is either:
> +		 * 1) Number greater or equal to one, which means that IV
> +		 *    is used and J0 will be computed internally, 16 bytes
> +		 *    needs to be allocated.
> +		 * 2) Zero, in which case data points to J0. In this case
> +		 *    16 bytes of J0 should be passed where J0 is defined
> +		 *    by NIST SP800-38D.
>  		 *
>  		 * - For CCM mode, this is the length of the nonce,
>  		 * which can be in the range 7 to 13 inclusive.
> --
> 2.1.0

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Kusztal, ArkadiuszX]

Hi Fiona,

> [Fiona] IVs greater than 16 bytes can be used, right? If so change to "a minimum of 16 bytes must be >allocated". Same below.

[AK] - yes, this comment may be misleading, of course it means 16 bytes minimum. This is because of legacy reasons, i.e. aesni-gcm once had formation of pre-counter block inside the PMD using the existing buffer (when len(iv)==12), hence need for 16 bytes allocation. Some other drivers still can behave in similar fashion so it probably has to stay for a while.
I will send v2.

> -----Original Message-----
> From: Trahe, Fiona
> Sent: Wednesday, April 17, 2019 1:38 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH] cryptodev: add an option to support both iv and J0 for
> GCM
> 
> Hi Arek,
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Wednesday, April 17, 2019 8:37 AM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; De Lara
> > Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Kusztal, ArkadiuszX
> > <arkadiuszx.kusztal@intel.com>
> > Subject: [PATCH] cryptodev: add an option to support both iv and J0
> > for GCM
> >
> > This patch adds an option to support both IV (of all supported sizes)
> > and J0 when using Galois Counter Mode of crypto operation.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/librte_cryptodev/rte_crypto_sym.h | 37
> > ++++++++++++++++++-----------------
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > b/lib/librte_cryptodev/rte_crypto_sym.h
> > index c80e90e..126d9f3 100644
> > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > @@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
> >  		 *
> >  		 * - For block ciphers in CTR mode, this is the counter.
> >  		 *
> > -		 * - For GCM mode, this is either the IV (if the length
> > -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> > -		 * defined by NIST SP800-38D. Regardless of the IV
> > -		 * length, a full 16 bytes needs to be allocated.
> > -		 *
> >  		 * - For CCM mode, the first byte is reserved, and the
> >  		 * nonce should be written starting at &iv[1] (to allow
> >  		 * space for the implementation to write in the flags @@ -
> 184,9
> > +179,6 @@ struct rte_crypto_cipher_xform {
> >  		 * of the counter (which must be the same as the block
> >  		 * length of the cipher).
> >  		 *
> > -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> > -		 * or 16, in which case data points to J0.
> > -		 *
> >  		 * - For CCM mode, this is the length of the nonce,
> >  		 * which can be in the range 7 to 13 inclusive.
> >  		 */
> > @@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
> >  		 * specified as number of bytes from start of crypto
> >  		 * operation (rte_crypto_op).
> >  		 *
> > -		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
> > -		 *   for AES-GMAC, this is the authentication
> > -		 *   Initialisation Vector (IV) value.
> > +		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
> > +		 *   this is the authentication Initialisation Vector
> > +		 *   (IV) value. For AES-GMAC IV description please refer
> > +		 *   to the field `length` in iv struct.
> >  		 *
> >  		 * - For KASUMI in F9 mode and other authentication
> >  		 *   algorithms, this field is not used.
> > @@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
> >  		 * - For KASUMI in F9 mode and other authentication
> >  		 *   algorithms, this field is not used.
> >  		 *
> > +		 * - For GMAC mode, this is either:
> > +		 * 1) Number greater or equal to one, which means that IV
> > +		 *    is used and J0 will be computed internally, 16 bytes
> > +		 *    needs to be allocated.
> [Fiona] IVs greater than 16 bytes can be used, right? If so change to "a
> minimum of 16 bytes must be allocated". Same below.
> 
> > +		 * 2) Zero, in which case data points to J0. In this case
> > +		 *    16 bytes of J0 should be passed where J0 is defined
> > +		 *    by NIST SP800-38D.
> > +		 *
> >  		 */
> >  	} iv;	/**< Initialisation vector parameters */
> >
> > @@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
> >  		 * specified as number of bytes from start of crypto
> >  		 * operation (rte_crypto_op).
> >  		 *
> > -		 * - For GCM mode, this is either the IV (if the length
> > -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> > -		 * defined by NIST SP800-38D. Regardless of the IV
> > -		 * length, a full 16 bytes needs to be allocated.
> > -		 *
> >  		 * - For CCM mode, the first byte is reserved, and the
> >  		 * nonce should be written starting at &iv[1] (to allow
> >  		 * space for the implementation to write in the flags @@ -
> 401,8
> > +397,13 @@ struct rte_crypto_aead_xform {
> >  		uint16_t length;
> >  		/**< Length of valid IV data.
> >  		 *
> > -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> > -		 * or 16, in which case data points to J0.
> > +		 * - For GCM mode, this is either:
> > +		 * 1) Number greater or equal to one, which means that IV
> > +		 *    is used and J0 will be computed internally, 16 bytes
> > +		 *    needs to be allocated.
> > +		 * 2) Zero, in which case data points to J0. In this case
> > +		 *    16 bytes of J0 should be passed where J0 is defined
> > +		 *    by NIST SP800-38D.
> >  		 *
> >  		 * - For CCM mode, this is the length of the nonce,
> >  		 * which can be in the range 7 to 13 inclusive.
> > --
> > 2.1.0

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Kusztal, ArkadiuszX]

Hi Fiona,

> [Fiona] IVs greater than 16 bytes can be used, right? If so change to "a minimum of 16 bytes must be >allocated". Same below.

[AK] - yes, this comment may be misleading, of course it means 16 bytes minimum. This is because of legacy reasons, i.e. aesni-gcm once had formation of pre-counter block inside the PMD using the existing buffer (when len(iv)==12), hence need for 16 bytes allocation. Some other drivers still can behave in similar fashion so it probably has to stay for a while.
I will send v2.

> -----Original Message-----
> From: Trahe, Fiona
> Sent: Wednesday, April 17, 2019 1:38 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH] cryptodev: add an option to support both iv and J0 for
> GCM
> 
> Hi Arek,
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Wednesday, April 17, 2019 8:37 AM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; De Lara
> > Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Kusztal, ArkadiuszX
> > <arkadiuszx.kusztal@intel.com>
> > Subject: [PATCH] cryptodev: add an option to support both iv and J0
> > for GCM
> >
> > This patch adds an option to support both IV (of all supported sizes)
> > and J0 when using Galois Counter Mode of crypto operation.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/librte_cryptodev/rte_crypto_sym.h | 37
> > ++++++++++++++++++-----------------
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> > b/lib/librte_cryptodev/rte_crypto_sym.h
> > index c80e90e..126d9f3 100644
> > --- a/lib/librte_cryptodev/rte_crypto_sym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> > @@ -152,11 +152,6 @@ struct rte_crypto_cipher_xform {
> >  		 *
> >  		 * - For block ciphers in CTR mode, this is the counter.
> >  		 *
> > -		 * - For GCM mode, this is either the IV (if the length
> > -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> > -		 * defined by NIST SP800-38D. Regardless of the IV
> > -		 * length, a full 16 bytes needs to be allocated.
> > -		 *
> >  		 * - For CCM mode, the first byte is reserved, and the
> >  		 * nonce should be written starting at &iv[1] (to allow
> >  		 * space for the implementation to write in the flags @@ -
> 184,9
> > +179,6 @@ struct rte_crypto_cipher_xform {
> >  		 * of the counter (which must be the same as the block
> >  		 * length of the cipher).
> >  		 *
> > -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> > -		 * or 16, in which case data points to J0.
> > -		 *
> >  		 * - For CCM mode, this is the length of the nonce,
> >  		 * which can be in the range 7 to 13 inclusive.
> >  		 */
> > @@ -306,9 +298,10 @@ struct rte_crypto_auth_xform {
> >  		 * specified as number of bytes from start of crypto
> >  		 * operation (rte_crypto_op).
> >  		 *
> > -		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
> > -		 *   for AES-GMAC, this is the authentication
> > -		 *   Initialisation Vector (IV) value.
> > +		 * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
> > +		 *   this is the authentication Initialisation Vector
> > +		 *   (IV) value. For AES-GMAC IV description please refer
> > +		 *   to the field `length` in iv struct.
> >  		 *
> >  		 * - For KASUMI in F9 mode and other authentication
> >  		 *   algorithms, this field is not used.
> > @@ -325,6 +318,14 @@ struct rte_crypto_auth_xform {
> >  		 * - For KASUMI in F9 mode and other authentication
> >  		 *   algorithms, this field is not used.
> >  		 *
> > +		 * - For GMAC mode, this is either:
> > +		 * 1) Number greater or equal to one, which means that IV
> > +		 *    is used and J0 will be computed internally, 16 bytes
> > +		 *    needs to be allocated.
> [Fiona] IVs greater than 16 bytes can be used, right? If so change to "a
> minimum of 16 bytes must be allocated". Same below.
> 
> > +		 * 2) Zero, in which case data points to J0. In this case
> > +		 *    16 bytes of J0 should be passed where J0 is defined
> > +		 *    by NIST SP800-38D.
> > +		 *
> >  		 */
> >  	} iv;	/**< Initialisation vector parameters */
> >
> > @@ -383,11 +384,6 @@ struct rte_crypto_aead_xform {
> >  		 * specified as number of bytes from start of crypto
> >  		 * operation (rte_crypto_op).
> >  		 *
> > -		 * - For GCM mode, this is either the IV (if the length
> > -		 * is 96 bits) or J0 (for other sizes), where J0 is as
> > -		 * defined by NIST SP800-38D. Regardless of the IV
> > -		 * length, a full 16 bytes needs to be allocated.
> > -		 *
> >  		 * - For CCM mode, the first byte is reserved, and the
> >  		 * nonce should be written starting at &iv[1] (to allow
> >  		 * space for the implementation to write in the flags @@ -
> 401,8
> > +397,13 @@ struct rte_crypto_aead_xform {
> >  		uint16_t length;
> >  		/**< Length of valid IV data.
> >  		 *
> > -		 * - For GCM mode, this is either 12 (for 96-bit IVs)
> > -		 * or 16, in which case data points to J0.
> > +		 * - For GCM mode, this is either:
> > +		 * 1) Number greater or equal to one, which means that IV
> > +		 *    is used and J0 will be computed internally, 16 bytes
> > +		 *    needs to be allocated.
> > +		 * 2) Zero, in which case data points to J0. In this case
> > +		 *    16 bytes of J0 should be passed where J0 is defined
> > +		 *    by NIST SP800-38D.
> >  		 *
> >  		 * - For CCM mode, this is the length of the nonce,
> >  		 * which can be in the range 7 to 13 inclusive.
> > --
> > 2.1.0

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Akhil Goyal]

> >
> > This patch adds an option to support both IV (of all supported sizes)
> > and J0 when using Galois Counter Mode of crypto operation.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++---------------
> --
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> >
> 
> I believe this patch is for 19.08

Applied to dpdk-next-crypto

Thanks.

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Trahe, Fiona]

Hi Akhil,
Yes, it's intended for 19.08

> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, April 17, 2019 12:34 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: RE: [PATCH] cryptodev: add an option to support both iv and J0 for GCM
> 
> >
> > This patch adds an option to support both IV (of all supported sizes)
> > and J0 when using Galois Counter Mode of crypto operation.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> >
> 
> I believe this patch is for 19.08

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Trahe, Fiona]

Hi Akhil,
Yes, it's intended for 19.08

> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, April 17, 2019 12:34 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: RE: [PATCH] cryptodev: add an option to support both iv and J0 for GCM
> 
> >
> > This patch adds an option to support both IV (of all supported sizes)
> > and J0 when using Galois Counter Mode of crypto operation.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> >
> 
> I believe this patch is for 19.08

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Akhil Goyal]

> 
> This patch adds an option to support both IV (of all supported sizes)
> and J0 when using Galois Counter Mode of crypto operation.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
>  1 file changed, 19 insertions(+), 18 deletions(-)
> 

I believe this patch is for 19.08

Re: [dpdk-dev] [PATCH] cryptodev: add an option to support both iv and J0 for GCM

[Akhil Goyal]

> 
> This patch adds an option to support both IV (of all supported sizes)
> and J0 when using Galois Counter Mode of crypto operation.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
>  1 file changed, 19 insertions(+), 18 deletions(-)
> 

I believe this patch is for 19.08