diff mbox series

[v2] cryptodev: add an option to support both iv and J0 for GCM

Message ID 20190417155751.11096-1-arkadiuszx.kusztal@intel.com (mailing list archive)
State Accepted, archived
Delegated to: akhil goyal
Headers
Series [v2] cryptodev: add an option to support both iv and J0 for GCM |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/intel-Performance-Testing success Performance Testing PASS
ci/mellanox-Performance-Testing success Performance Testing PASS

Commit Message

Arkadiusz Kusztal April 17, 2019, 3:57 p.m. UTC 
  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>
---
Note: This patch is intended for 19.08 release

 lib/librte_cryptodev/rte_crypto_sym.h | 37 ++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 18 deletions(-)

Comments

Fiona Trahe April 18, 2019, 11:48 a.m. UTC | #1 
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, April 17, 2019 4:58 PM
> 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 v2] 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>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Anoob Joseph May 4, 2019, 7:03 p.m. UTC | #2 
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Arek Kusztal
> Sent: Wednesday, April 17, 2019 9:28 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; fiona.trahe@intel.com;
> pablo.de.lara.guarch@intel.com; Arek Kusztal <arkadiuszx.kusztal@intel.com>
> Subject: [dpdk-dev] [PATCH v2] 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>
Acked-by: Anoob Joseph <anoobj@marvell.com>
diff mbox series

Patch

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index c80e90e..bfce84a 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, a minimum
+		 *    of 16 bytes must 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, a minimum
+		 *    of 16 bytes must 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.