[PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes

[PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes

[Arek Kusztal]

This patchset introduces some of changes discussed on mailing list for 22.07 release in cryptodev asym.

Key changes:

- It fixes API for RSA (expescially signature paddings)
- Adds Elliptic-Curve Diffie-Hellman
- Adds Eliiptic-Curve point verification
- Adds RSA missing padding fields
- Adds asym op flags
- Fixes many API comments (like EC curves)

v4:
- fixed shared build problem
- added ABI ignore entry for xform

Arek Kusztal (12):
  cryptodev: redefine ec group enum
  cryptodev: separate key exchange operation enum
  cryptodev: remove comment about using ephemeral key in dsa
  cryptodev: clarify usage of private key in dh
  cryptodev: move dh type from xform to dh op
  cryptodev: add elliptic curve diffie hellman
  cryptodev: add public key verify option
  cryptodev: add asym op flags
  cryptodev: clarify usage of rsa padding hash
  cryptodev: move RSA padding into separate struct
  cryptodev: clarify rsa verify with none padding
  cryptodev: add salt length and optional label

 app/test/test_cryptodev_asym.c               |  63 ++++----
 devtools/libabigail.abignore                 |   3 +
 drivers/common/cpt/cpt_ucode_asym.h          |   4 +-
 drivers/crypto/cnxk/cnxk_ae.h                |   8 +-
 drivers/crypto/octeontx/otx_cryptodev_ops.c  |   4 +-
 drivers/crypto/openssl/rte_openssl_pmd.c     |  17 +--
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |  33 +---
 drivers/crypto/qat/qat_asym.c                |  12 +-
 lib/cryptodev/rte_crypto_asym.h              | 217 ++++++++++++++++++++-------
 lib/cryptodev/rte_cryptodev.c                |  15 +-
 lib/cryptodev/rte_cryptodev.h                |   4 +-
 lib/cryptodev/version.map                    |   1 +
 12 files changed, 237 insertions(+), 144 deletions(-)

-- 
2.13.6

[PATCH v4 01/12] cryptodev: redefine ec group enum

[Arek Kusztal]

- EC enum was renamed to rte_crypto_curve_id.
Elliptic curve enum name was incorrectly associated
with a group (it comes from the current tls registry name).
- Clarified comments about TLS deprecation.
Some curves included are deprecated with TLS 1.3.
Comments to address it were added.
- Clarified FFDH groups usage.
Elliptic curves IDs in TLS are placed in the same registry
as FFDH. Cryptodev does not assign specific groups, and
if specific groups would be assigned by DPDK, it cannot be
TLS SupportedGroups registry, as it would conflict with
other protocols like IPSec.
- Added IANA reference.
Only few selected curves are included in previously
referenced rfc8422. IANA reference is added instead.
- Removed UNKNOWN ec group.
There is no default value, and there is no UNKNOWN
elliptic curve.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index cd24d4b07b..87df9b2ce3 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -38,16 +38,20 @@ extern const char *
 rte_crypto_asym_op_strings[];
 
 /**
- * TLS named curves
- * https://tools.ietf.org/html/rfc8422
+ * List of elliptic curves. This enum aligns with
+ * TLS "Supported Groups" registry (previously known  as
+ * NamedCurve registry). FFDH groups are not, and will not
+ * be included in this list.
+ * Deprecation a for selected curve in TLS does not deprecate
+ * the selected curve in Cryptodev.
+ * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
  */
-enum rte_crypto_ec_group {
-	RTE_CRYPTO_EC_GROUP_UNKNOWN  = 0,
+enum rte_crypto_curve_id {
 	RTE_CRYPTO_EC_GROUP_SECP192R1 = 19,
 	RTE_CRYPTO_EC_GROUP_SECP224R1 = 21,
 	RTE_CRYPTO_EC_GROUP_SECP256R1 = 23,
 	RTE_CRYPTO_EC_GROUP_SECP384R1 = 24,
-	RTE_CRYPTO_EC_GROUP_SECP521R1 = 25,
+	RTE_CRYPTO_EC_GROUP_SECP521R1 = 25
 };
 
 /**
@@ -294,7 +298,7 @@ struct rte_crypto_dsa_xform {
  *
  */
 struct rte_crypto_ec_xform {
-	enum rte_crypto_ec_group curve_id;
+	enum rte_crypto_curve_id curve_id;
 	/**< Pre-defined ec groups */
 };
 
-- 
2.13.6

[PATCH v4 02/12] cryptodev: separate key exchange operation enum

[Arek Kusztal]

- Separated key exchange enum from asym op type.
Key exchange and asymmetric crypto operations like signatures,
encryption/decryption should not share same operation enum as
its use cases are unrelated and mutually exclusive.
Therefore op_type was separate into:
1) operation type
2) key exchange operation type

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c               | 52 +++++++++++++++-------------
 drivers/crypto/openssl/rte_openssl_pmd.c     | 10 +++---
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 18 +++++-----
 lib/cryptodev/rte_crypto_asym.h              | 45 +++++++++++++++---------
 lib/cryptodev/rte_cryptodev.c                | 14 +++++---
 lib/cryptodev/rte_cryptodev.h                |  4 ++-
 lib/cryptodev/version.map                    |  1 +
 7 files changed, 84 insertions(+), 60 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 573af2a537..491ba2c1b9 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -976,27 +976,30 @@ static inline void print_asym_capa(
 
 	for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
 		/* check supported operations */
-		if (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
-			printf(" %s",
-					rte_crypto_asym_op_strings[i]);
+		if (rte_cryptodev_asym_xform_capability_check_optype(capa, i)) {
+			if (capa->xform_type == RTE_CRYPTO_ASYM_XFORM_DH)
+				printf(" %s", rte_crypto_asym_ke_strings[i]);
+			else
+				printf(" %s", rte_crypto_asym_op_strings[i]);
 		}
-		switch (capa->xform_type) {
-		case RTE_CRYPTO_ASYM_XFORM_RSA:
-		case RTE_CRYPTO_ASYM_XFORM_MODINV:
-		case RTE_CRYPTO_ASYM_XFORM_MODEX:
-		case RTE_CRYPTO_ASYM_XFORM_DH:
-		case RTE_CRYPTO_ASYM_XFORM_DSA:
-			printf(" modlen: min %d max %d increment %d",
-					capa->modlen.min,
-					capa->modlen.max,
-					capa->modlen.increment);
+	}
+	switch (capa->xform_type) {
+	case RTE_CRYPTO_ASYM_XFORM_RSA:
+	case RTE_CRYPTO_ASYM_XFORM_MODINV:
+	case RTE_CRYPTO_ASYM_XFORM_MODEX:
+	case RTE_CRYPTO_ASYM_XFORM_DH:
+	case RTE_CRYPTO_ASYM_XFORM_DSA:
+		printf(" modlen: min %d max %d increment %d",
+				capa->modlen.min,
+				capa->modlen.max,
+				capa->modlen.increment);
+	break;
+	case RTE_CRYPTO_ASYM_XFORM_ECDSA:
+	case RTE_CRYPTO_ASYM_XFORM_ECPM:
+	default:
 		break;
-		case RTE_CRYPTO_ASYM_XFORM_ECDSA:
-		case RTE_CRYPTO_ASYM_XFORM_ECPM:
-		default:
-			break;
-		}
-		printf("\n");
+	}
+	printf("\n");
 }
 
 static int
@@ -1064,7 +1067,7 @@ test_dh_gen_shared_sec(struct rte_crypto_asym_xform *xfrm)
 	asym_op = op->asym;
 
 	/* Setup a xform and op to generate private key only */
-	xform.dh.type = RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE;
+	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
 	xform.next = NULL;
 	asym_op->dh.priv_key.data = dh_test_params.priv_key.data;
 	asym_op->dh.priv_key.length = dh_test_params.priv_key.length;
@@ -1146,7 +1149,7 @@ test_dh_gen_priv_key(struct rte_crypto_asym_xform *xfrm)
 	asym_op = op->asym;
 
 	/* Setup a xform and op to generate private key only */
-	xform.dh.type = RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE;
+	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE;
 	xform.next = NULL;
 	asym_op->dh.priv_key.data = output;
 	asym_op->dh.priv_key.length = sizeof(output);
@@ -1229,7 +1232,7 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
 	 * using test private key
 	 *
 	 */
-	xform.dh.type = RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE;
+	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE;
 	xform.next = NULL;
 
 	asym_op->dh.pub_key.data = output;
@@ -1319,9 +1322,10 @@ test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)
 	/* Setup a xform chain to generate
 	 * private key first followed by
 	 * public key
-	 */xform.dh.type = RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE;
+	 */
+	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE;
 	pub_key_xform.xform_type = RTE_CRYPTO_ASYM_XFORM_DH;
-	pub_key_xform.dh.type = RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE;
+	pub_key_xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE;
 	xform.next = &pub_key_xform;
 
 	asym_op->dh.pub_key.data = out_pub_key;
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index d80e1052e2..86f285ef79 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1697,7 +1697,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 	int ret = 0;
 
 	if (sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE)) {
+			(1 << RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE)) {
 		/* compute shared secret using peer public key
 		 * and current private key
 		 * shared secret = peer_key ^ priv_key mod p
@@ -1754,9 +1754,9 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 	 * then first set DH with user provided private key
 	 */
 	if ((sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE)) &&
+			(1 << RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE)) &&
 			!(sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE))) {
+			(1 << RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE))) {
 		/* generate public key using user-provided private key
 		 * pub_key = g ^ priv_key mod p
 		 */
@@ -1790,7 +1790,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 		return 0;
 	}
 
-	if (sess->u.dh.key_op & (1 << RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE)) {
+	if (sess->u.dh.key_op & (1 << RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE)) {
 		const BIGNUM *pub_key = NULL;
 
 		OPENSSL_LOG(DEBUG, "%s:%d update public key\n",
@@ -1805,7 +1805,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 	}
 
 	if (sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE)) {
+			(1 << RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE)) {
 		const BIGNUM *priv_key = NULL;
 
 		OPENSSL_LOG(DEBUG, "%s:%d updated priv key\n",
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 1cb07794bd..724492c7cb 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -533,10 +533,10 @@ static const struct rte_cryptodev_capabilities openssl_pmd_capabilities[] = {
 			.xform_capa = {
 				.xform_type = RTE_CRYPTO_ASYM_XFORM_DH,
 				.op_types =
-				((1<<RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE) |
-				(1 << RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE |
+				((1<<RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE) |
+				(1 << RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE |
 				(1 <<
-				RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE))),
+				RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE))),
 				{
 				.modlen = {
 				/* value 0 symbolizes no limit on min length */
@@ -1006,16 +1006,16 @@ static int openssl_set_asym_session_parameters(
 		 * DH Priv key generate, or both
 		 * public and private key generate
 		 */
-		asym_session->u.dh.key_op = (1 << xform->dh.type);
+		asym_session->u.dh.key_op = (1 << xform->dh.ke_type);
 
-		if (xform->dh.type ==
-			RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE) {
+		if (xform->dh.ke_type ==
+			RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE) {
 			/* check if next is pubkey */
 			if ((xform->next != NULL) &&
 				(xform->next->xform_type ==
 				RTE_CRYPTO_ASYM_XFORM_DH) &&
-				(xform->next->dh.type ==
-				RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE)
+				(xform->next->dh.ke_type ==
+				RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE)
 				) {
 				/*
 				 * setup op as pub/priv key
@@ -1023,7 +1023,7 @@ static int openssl_set_asym_session_parameters(
 				 */
 				asym_session->u.dh.key_op |=
 				(1 <<
-				RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE);
+				RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE);
 			}
 		}
 		asym_session->u.dh.dh_key = dh;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 87df9b2ce3..e496588c7a 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -33,6 +33,10 @@ struct rte_cryptodev_asym_session;
 extern const char *
 rte_crypto_asym_xform_strings[];
 
+/** asym key exchange operation type name strings */
+extern const char *
+rte_crypto_asym_ke_strings[];
+
 /** asym operations type name strings */
 extern const char *
 rte_crypto_asym_op_strings[];
@@ -113,16 +117,22 @@ enum rte_crypto_asym_op_type {
 	/**< Signature Generation operation */
 	RTE_CRYPTO_ASYM_OP_VERIFY,
 	/**< Signature Verification operation */
-	RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
-	/**< DH Private Key generation operation */
-	RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
-	/**< DH Public Key generation operation */
-	RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
-	/**< DH Shared Secret compute operation */
 	RTE_CRYPTO_ASYM_OP_LIST_END
 };
 
 /**
+ * Asymmetric crypto key exchange operation type
+ */
+enum rte_crypto_asym_ke_type {
+	RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE,
+	/**< Private Key generation operation */
+	RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE,
+	/**< Public Key generation operation */
+	RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
+	/**< Shared Secret compute operation */
+};
+
+/**
  * Padding types for RSA signature.
  */
 enum rte_crypto_rsa_padding_type {
@@ -260,7 +270,7 @@ struct rte_crypto_modinv_xform {
  *
  */
 struct rte_crypto_dh_xform {
-	enum rte_crypto_asym_op_type type;
+	enum rte_crypto_asym_ke_type ke_type;
 	/**< Setup xform for key generate or shared secret compute */
 	rte_crypto_uint p;
 	/**< Prime modulus data */
@@ -397,26 +407,27 @@ struct rte_crypto_rsa_op_param {
 struct rte_crypto_dh_op_param {
 	rte_crypto_uint pub_key;
 	/**<
-	 * Output generated public key when xform type is
-	 * DH PUB_KEY_GENERATION.
-	 * Input peer public key when xform type is DH
-	 * SHARED_SECRET_COMPUTATION
+	 * Output - generated public key, when dh xform ke_type is
+	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE.
 	 *
+	 * Input - peer's public key, when dh xform ke_type is
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
 	 */
 
 	rte_crypto_uint priv_key;
 	/**<
-	 * Output generated private key if xform type is
-	 * DH PRIVATE_KEY_GENERATION
-	 * Input when xform type is DH SHARED_SECRET_COMPUTATION.
+	 * Output - generated private key, when dh xform ke_type is
+	 * RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE.
 	 *
+	 * Input - private key, when dh xform ke_type is one of:
+	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE,
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
 	 */
 
 	rte_crypto_uint shared_secret;
 	/**<
-	 * Output with calculated shared secret
-	 * when dh xform set up with op type = SHARED_SECRET_COMPUTATION.
-	 *
+	 * Output - calculated shared secret when dh xform ke_type is
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
 	 */
 };
 
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index e16e6802aa..cc614b0f72 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -177,10 +177,16 @@ const char *rte_crypto_asym_op_strings[] = {
 	[RTE_CRYPTO_ASYM_OP_ENCRYPT]	= "encrypt",
 	[RTE_CRYPTO_ASYM_OP_DECRYPT]	= "decrypt",
 	[RTE_CRYPTO_ASYM_OP_SIGN]	= "sign",
-	[RTE_CRYPTO_ASYM_OP_VERIFY]	= "verify",
-	[RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE]	= "priv_key_generate",
-	[RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE] = "pub_key_generate",
-	[RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE] = "sharedsecret_compute",
+	[RTE_CRYPTO_ASYM_OP_VERIFY]	= "verify"
+};
+
+/**
+ * Asymmetric crypto key exchange operation strings identifiers.
+ */
+const char *rte_crypto_asym_ke_strings[] = {
+	[RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE] = "priv_key_generate",
+	[RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE] = "pub_key_generate",
+	[RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE] = "sharedsecret_compute"
 };
 
 /**
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 2c2c2edeb7..7d683fd728 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -168,7 +168,9 @@ struct rte_cryptodev_asymmetric_xform_capability {
 	/**< Transform type: RSA/MODEXP/DH/DSA/MODINV */
 
 	uint32_t op_types;
-	/**< bitmask for supported rte_crypto_asym_op_type */
+	/**< bitmask for supported rte_crypto_asym_op_type or
+	 * rte_crypto_asym_ke_type
+	 */
 
 	__extension__
 	union {
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index f0abfaa47d..dbf1f62199 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -108,6 +108,7 @@ EXPERIMENTAL {
 
 	#added in 22.07
 	rte_cryptodev_session_event_mdata_set;
+	rte_crypto_asym_ke_strings;
 };
 
 INTERNAL {
-- 
2.13.6

[PATCH v4 03/12] cryptodev: remove comment about using ephemeral key in dsa

[Arek Kusztal]

- Removed comment that stated DSA can be used with Diffie
Hellman ephemeral key.
DH and DSA integration allowed to use ephemeral keys for
random integer, but not for private keys.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index e496588c7a..eb753b4016 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -292,13 +292,7 @@ struct rte_crypto_dsa_xform {
 	rte_crypto_uint g;
 	/**< Generator of the subgroup */
 	rte_crypto_uint x;
-	/**< x: Private key of the signer in octet-string network
-	 * byte order format.
-	 * Used when app has pre-defined private key.
-	 * Valid only when xform chain is DSA ONLY.
-	 * if xform chain is DH private key generate + DSA, then DSA sign
-	 * compute will use internally generated key.
-	 */
+	/**< x: Private key of the signer */
 };
 
 /**
-- 
2.13.6

[PATCH v4 04/12] cryptodev: clarify usage of private key in dh

[Arek Kusztal]

- Clarified usage of private key in Diffie-Hellman.
CSRNG capable device should generate private key and then
use it for public key generation.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index eb753b4016..619c0614bf 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -416,6 +416,11 @@ struct rte_crypto_dh_op_param {
 	 * Input - private key, when dh xform ke_type is one of:
 	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE,
 	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+	 *
+	 * In case priv_key.length is 0 and xform type is set with
+	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE, CSRNG capable
+	 * device will generate a private key and use it for public
+	 * key generation.
 	 */
 
 	rte_crypto_uint shared_secret;
-- 
2.13.6

[PATCH v4 05/12] cryptodev: move dh type from xform to dh op

[Arek Kusztal]

- Moved dh operation type to dh operation struct.
Operation type (PUBLIC_KEY_GENERATION, SHARED_SECRET) should
be free to choose for any operation. One xform/session should
be enough to perform both DH operations, if op_type would be xform
member, session would have to be to be created twice for the same
group. Similar problem would be observed in sessionless case.
Additionally, it will help extend DH to support Elliptic Curves.
- Changed order of Diffie-Hellman operation phases.
Now it corresponds with the order of operations.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c               | 11 +++++-----
 drivers/crypto/openssl/rte_openssl_pmd.c     | 15 ++++++--------
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 27 -------------------------
 lib/cryptodev/rte_crypto_asym.h              | 30 +++++++++++++---------------
 4 files changed, 25 insertions(+), 58 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 491ba2c1b9..9d044c65b2 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1067,8 +1067,8 @@ test_dh_gen_shared_sec(struct rte_crypto_asym_xform *xfrm)
 	asym_op = op->asym;
 
 	/* Setup a xform and op to generate private key only */
-	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
 	xform.next = NULL;
+	asym_op->dh.ke_type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
 	asym_op->dh.priv_key.data = dh_test_params.priv_key.data;
 	asym_op->dh.priv_key.length = dh_test_params.priv_key.length;
 	asym_op->dh.pub_key.data = (uint8_t *)peer;
@@ -1149,8 +1149,8 @@ test_dh_gen_priv_key(struct rte_crypto_asym_xform *xfrm)
 	asym_op = op->asym;
 
 	/* Setup a xform and op to generate private key only */
-	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE;
 	xform.next = NULL;
+	asym_op->dh.ke_type = RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE;
 	asym_op->dh.priv_key.data = output;
 	asym_op->dh.priv_key.length = sizeof(output);
 
@@ -1232,9 +1232,9 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
 	 * using test private key
 	 *
 	 */
-	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE;
 	xform.next = NULL;
 
+	asym_op->dh.ke_type = RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE;
 	asym_op->dh.pub_key.data = output;
 	asym_op->dh.pub_key.length = sizeof(output);
 	/* load pre-defined private key */
@@ -1323,15 +1323,14 @@ test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)
 	 * private key first followed by
 	 * public key
 	 */
-	xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE;
 	pub_key_xform.xform_type = RTE_CRYPTO_ASYM_XFORM_DH;
-	pub_key_xform.dh.ke_type = RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE;
 	xform.next = &pub_key_xform;
 
+	asym_op->dh.ke_type = RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE;
 	asym_op->dh.pub_key.data = out_pub_key;
 	asym_op->dh.pub_key.length = sizeof(out_pub_key);
 	asym_op->dh.priv_key.data = out_prv_key;
-	asym_op->dh.priv_key.length = sizeof(out_prv_key);
+	asym_op->dh.priv_key.length = 0;
 
 	ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, &sess);
 	if (ret < 0) {
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index 86f285ef79..750479c33f 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1692,12 +1692,12 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 		struct openssl_asym_session *sess)
 {
 	struct rte_crypto_dh_op_param *op = &cop->asym->dh;
+	struct rte_crypto_asym_op *asym_op = cop->asym;
 	DH *dh_key = sess->u.dh.dh_key;
 	BIGNUM *priv_key = NULL;
 	int ret = 0;
 
-	if (sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE)) {
+	if (asym_op->dh.ke_type == RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE) {
 		/* compute shared secret using peer public key
 		 * and current private key
 		 * shared secret = peer_key ^ priv_key mod p
@@ -1753,10 +1753,8 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 	 * if user provides private key,
 	 * then first set DH with user provided private key
 	 */
-	if ((sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE)) &&
-			!(sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE))) {
+	if (asym_op->dh.ke_type == RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE &&
+			op->priv_key.length) {
 		/* generate public key using user-provided private key
 		 * pub_key = g ^ priv_key mod p
 		 */
@@ -1790,7 +1788,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 		return 0;
 	}
 
-	if (sess->u.dh.key_op & (1 << RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE)) {
+	if (asym_op->dh.ke_type == RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE) {
 		const BIGNUM *pub_key = NULL;
 
 		OPENSSL_LOG(DEBUG, "%s:%d update public key\n",
@@ -1804,8 +1802,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 				op->pub_key.data);
 	}
 
-	if (sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE)) {
+	if (asym_op->dh.ke_type == RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE) {
 		const BIGNUM *priv_key = NULL;
 
 		OPENSSL_LOG(DEBUG, "%s:%d updated priv key\n",
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 724492c7cb..2bb3520bfd 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -999,33 +999,6 @@ static int openssl_set_asym_session_parameters(
 			DH_free(dh);
 			goto err_dh;
 		}
-
-		/*
-		 * setup xfrom for
-		 * public key generate, or
-		 * DH Priv key generate, or both
-		 * public and private key generate
-		 */
-		asym_session->u.dh.key_op = (1 << xform->dh.ke_type);
-
-		if (xform->dh.ke_type ==
-			RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE) {
-			/* check if next is pubkey */
-			if ((xform->next != NULL) &&
-				(xform->next->xform_type ==
-				RTE_CRYPTO_ASYM_XFORM_DH) &&
-				(xform->next->dh.ke_type ==
-				RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE)
-				) {
-				/*
-				 * setup op as pub/priv key
-				 * pair generationi
-				 */
-				asym_session->u.dh.key_op |=
-				(1 <<
-				RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE);
-			}
-		}
 		asym_session->u.dh.dh_key = dh;
 		asym_session->xfrm_type = RTE_CRYPTO_ASYM_XFORM_DH;
 		break;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 619c0614bf..88bc34dc8c 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -270,8 +270,6 @@ struct rte_crypto_modinv_xform {
  *
  */
 struct rte_crypto_dh_xform {
-	enum rte_crypto_asym_ke_type ke_type;
-	/**< Setup xform for key generate or shared secret compute */
 	rte_crypto_uint p;
 	/**< Prime modulus data */
 	rte_crypto_uint g;
@@ -399,33 +397,33 @@ struct rte_crypto_rsa_op_param {
  * @note:
  */
 struct rte_crypto_dh_op_param {
-	rte_crypto_uint pub_key;
-	/**<
-	 * Output - generated public key, when dh xform ke_type is
-	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE.
-	 *
-	 * Input - peer's public key, when dh xform ke_type is
-	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
-	 */
-
+	enum rte_crypto_asym_ke_type ke_type;
+	/**< Key exchange operation type */
 	rte_crypto_uint priv_key;
 	/**<
-	 * Output - generated private key, when dh xform ke_type is
+	 * Output - generated private key when ke_type is
 	 * RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE.
 	 *
-	 * Input - private key, when dh xform ke_type is one of:
+	 * Input - private key when ke_type is one of:
 	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE,
 	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
 	 *
-	 * In case priv_key.length is 0 and xform type is set with
+	 * In case priv_key.length is 0 and ke_type is set with
 	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE, CSRNG capable
 	 * device will generate a private key and use it for public
 	 * key generation.
 	 */
-
+	rte_crypto_uint pub_key;
+	/**<
+	 * Output - generated public key when ke_type is
+	 * RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE.
+	 *
+	 * Input - peer's public key when ke_type is
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+	 */
 	rte_crypto_uint shared_secret;
 	/**<
-	 * Output - calculated shared secret when dh xform ke_type is
+	 * Output - calculated shared secret when ke_type is
 	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
 	 */
 };
-- 
2.13.6

[PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman

[Arek Kusztal]

- Added elliptic curve Diffie-Hellman parameters.
Point multiplication allows the user to process every phase of
ECDH, but for phase 1, user should not really care about the generator.
The user does not even need to know what the generator looks like,
therefore setting ec xform would make this work.

Cc: mdr@ashroe.eu

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 devtools/libabigail.abignore    |  3 +++
 lib/cryptodev/rte_crypto_asym.h | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..6d174b291f 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -27,6 +27,9 @@
 ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
 [suppress_type]
         name = rte_crypto_asym_op
+; Ignore changes to rte_crypto_asym_xform_type, asymmetric crypto API is experimental
+[suppress_type]
+        name = rte_crypto_asym_xform_type
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ; Temporary exceptions till next major ABI version ;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 88bc34dc8c..f61a2ddce8 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -99,6 +99,8 @@ enum rte_crypto_asym_xform_type {
 	/**< Elliptic Curve Digital Signature Algorithm
 	 * Perform Signature Generation and Verification.
 	 */
+	RTE_CRYPTO_ASYM_XFORM_ECDH,
+	/**< Elliptic Curve Diffie Hellman */
 	RTE_CRYPTO_ASYM_XFORM_ECPM,
 	/**< Elliptic Curve Point Multiplication */
 	RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
@@ -429,6 +431,41 @@ struct rte_crypto_dh_op_param {
 };
 
 /**
+ * Elliptic Curve Diffie-Hellman Operations params.
+ */
+struct rte_crypto_ecdh_op_param {
+	enum rte_crypto_asym_ke_type ke_type;
+	/**< Key exchange operation type */
+	rte_crypto_uint priv_key;
+	/**<
+	 * Output - generated private key when ke_type is
+	 * RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE.
+	 *
+	 * Input - private key when ke_type is one of:
+	 * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+	 *
+	 * In case priv_key.length is 0 and ke_type is set with
+	 * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE, CSRNG capable
+	 * device will generate private key and use it for public
+	 * key generation.
+	 */
+	struct rte_crypto_ec_point pub_key;
+	/**<
+	 * Output - generated public key when ke_type is
+	 * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
+	 *
+	 * Input - peer's public key when ke_type is
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+	 */
+	struct rte_crypto_ec_point shared_secret;
+	/**<
+	 * Output - calculated shared secret when ke_type is
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+	 */
+};
+
+/**
  * DSA Operations params
  *
  */
@@ -566,6 +603,7 @@ struct rte_crypto_asym_op {
 		struct rte_crypto_mod_op_param modex;
 		struct rte_crypto_mod_op_param modinv;
 		struct rte_crypto_dh_op_param dh;
+		struct rte_crypto_ecdh_op_param ecdh;
 		struct rte_crypto_dsa_op_param dsa;
 		struct rte_crypto_ecdsa_op_param ecdsa;
 		struct rte_crypto_ecpm_op_param ecpm;
-- 
2.13.6

[PATCH v4 07/12] cryptodev: add public key verify option

[Arek Kusztal]

- Added key exchange public key verify option.
For some elliptic curves public point in DH exchange
needs to be checked, if it lays on the curve.
Modular exponentiation needs certain checks as well, though
mathematically much easier.
This commit adds verify option to asym_op operations.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 11 ++++++++---
 lib/cryptodev/rte_cryptodev.c   |  3 ++-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index f61a2ddce8..ae3ca31a89 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -130,8 +130,12 @@ enum rte_crypto_asym_ke_type {
 	/**< Private Key generation operation */
 	RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE,
 	/**< Public Key generation operation */
-	RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
+	RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE,
 	/**< Shared Secret compute operation */
+	RTE_CRYPTO_ASYM_KE_PUB_KEY_VERIFY
+	/**< Public Key Verification - can be used for
+	 * elliptic curve point validation.
+	 */
 };
 
 /**
@@ -455,8 +459,9 @@ struct rte_crypto_ecdh_op_param {
 	 * Output - generated public key when ke_type is
 	 * RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE.
 	 *
-	 * Input - peer's public key when ke_type is
-	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE.
+	 * Input - peer's public key, when ke_type is one of:
+	 * RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE,
+	 * RTE_CRYPTO_ASYM_KE_EC_PUBLIC_KEY_VERIFY.
 	 */
 	struct rte_crypto_ec_point shared_secret;
 	/**<
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index cc614b0f72..42f3221052 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -186,7 +186,8 @@ const char *rte_crypto_asym_op_strings[] = {
 const char *rte_crypto_asym_ke_strings[] = {
 	[RTE_CRYPTO_ASYM_KE_PRIV_KEY_GENERATE] = "priv_key_generate",
 	[RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE] = "pub_key_generate",
-	[RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE] = "sharedsecret_compute"
+	[RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE] = "sharedsecret_compute",
+	[RTE_CRYPTO_ASYM_KE_PUB_KEY_VERIFY] = "pub_ec_key_verify"
 };
 
 /**
-- 
2.13.6

[PATCH v4 08/12] cryptodev: add asym op flags

[Arek Kusztal]

- Added flags to rte_crypto_asym_op struct.
It may be shared between different algorithms.
- Added Diffie-Hellman padding flags.
Diffie-Hellman padding is used in certain protocols,
in others, leading zero bytes need to be stripped.
Even same protocol may use a different approach - most
glaring example is TLS1.2 - TLS1.3.
For ease of use, and to avoid additional copy
on certain occasions, driver should be able to return both.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index ae3ca31a89..a215f4499d 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -41,6 +41,19 @@ rte_crypto_asym_ke_strings[];
 extern const char *
 rte_crypto_asym_op_strings[];
 
+#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_NO_PADDING		RTE_BIT32(0)
+/**<
+ * Flag to denote public key will be returned without leading zero bytes
+ * and if the flag is not set, public key will be padded to the left with
+ * zeros to the size of the underlying algorithm (default)
+ */
+#define RTE_CRYPTO_ASYM_FLAG_SHARED_KEY_NO_PADDING	RTE_BIT32(1)
+/**<
+ * Flag to denote shared secret will be returned without leading zero bytes
+ * and if the flag is not set, shared secret will be padded to the left with
+ * zeros to the size of the underlying algorithm (default)
+ */
+
 /**
  * List of elliptic curves. This enum aligns with
  * TLS "Supported Groups" registry (previously known  as
@@ -613,6 +626,8 @@ struct rte_crypto_asym_op {
 		struct rte_crypto_ecdsa_op_param ecdsa;
 		struct rte_crypto_ecpm_op_param ecpm;
 	};
+	uint16_t flags;
+	/**< Asymmetric crypto operation flags */
 };
 
 #ifdef __cplusplus
-- 
2.13.6

[PATCH v4 09/12] cryptodev: clarify usage of rsa padding hash

[Arek Kusztal]

- Clarified usage of RSA padding hash.
It was not specified how to use hash for PKCS1_5
padding. This could lead to incorrect implementation.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index a215f4499d..363fbf87c7 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -395,10 +395,29 @@ struct rte_crypto_rsa_op_param {
 	/**< RSA padding scheme to be used for transform */
 
 	enum rte_crypto_auth_algorithm md;
-	/**< Hash algorithm to be used for data hash if padding
-	 * scheme is either OAEP or PSS. Valid hash algorithms
-	 * are:
+	/**<
+	 * RSA padding hash algorithm
+	 * Valid hash algorithms are:
 	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+	 *
+	 * When a specific padding type is selected, the following rule apply:
+	 * - RTE_CRYPTO_RSA_PADDING_NONE:
+	 * This field is ignored by the PMD
+	 *
+	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
+	 * For sign operation, this field is used to determine value
+	 * of the DigestInfo structure, therefore specifying which algorithm
+	 * was used to create the message digest.
+	 * For encryption/decryption, this field is ignored for this
+	 * padding type.
+	 *
+	 * - RTE_CRYPTO_RSA_PADDING_OAEP
+	 * This field shall be set with the hash algorithm used
+	 * in the padding scheme
+	 *
+	 * - RTE_CRYPTO_RSA_PADDING_PSS
+	 * This field shall be set with the hash algorithm used
+	 * in the padding scheme (and to create the input message digest)
 	 */
 
 	enum rte_crypto_auth_algorithm mgf1md;
-- 
2.13.6

[PATCH v4 10/12] cryptodev: move RSA padding into separate struct

[Arek Kusztal]

- move RSA padding into separate struct.
More padding members should be added into padding,
therefore having separate struct for padding parameters will
make this more readable.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c              | 10 ++--
 drivers/common/cpt/cpt_ucode_asym.h         |  4 +-
 drivers/crypto/cnxk/cnxk_ae.h               |  8 +--
 drivers/crypto/octeontx/otx_cryptodev_ops.c |  4 +-
 drivers/crypto/openssl/rte_openssl_pmd.c    |  2 +-
 drivers/crypto/qat/qat_asym.c               | 12 ++---
 lib/cryptodev/rte_crypto_asym.h             | 80 ++++++++++++++++-------------
 7 files changed, 63 insertions(+), 57 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 9d044c65b2..7bd7cde16e 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -94,7 +94,7 @@ queue_ops_rsa_sign_verify(void *sess)
 	asym_op->rsa.message.length = rsaplaintext.len;
 	asym_op->rsa.sign.length = 0;
 	asym_op->rsa.sign.data = output_buf;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+	asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
 
 	debug_hexdump(stdout, "message", asym_op->rsa.message.data,
 		      asym_op->rsa.message.length);
@@ -126,7 +126,7 @@ queue_ops_rsa_sign_verify(void *sess)
 
 	/* Verify sign */
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_VERIFY;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+	asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
 
 	/* Process crypto operation */
 	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -185,7 +185,7 @@ queue_ops_rsa_enc_dec(void *sess)
 	asym_op->rsa.cipher.data = cipher_buf;
 	asym_op->rsa.cipher.length = 0;
 	asym_op->rsa.message.length = rsaplaintext.len;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+	asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
 
 	debug_hexdump(stdout, "message", asym_op->rsa.message.data,
 		      asym_op->rsa.message.length);
@@ -217,7 +217,7 @@ queue_ops_rsa_enc_dec(void *sess)
 	asym_op = result_op->asym;
 	asym_op->rsa.message.length = 0;
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_DECRYPT;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+	asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
 
 	/* Process crypto operation */
 	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -414,7 +414,7 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym *ts_params,
 		}
 
 		xform_tc.rsa.key_type = key_type;
-		op->asym->rsa.pad = data_tc->rsa_data.padding;
+		op->asym->rsa.padding.type = data_tc->rsa_data.padding;
 
 		if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT) {
 			asym_op->rsa.message.data = data_tc->rsa_data.pt.data;
diff --git a/drivers/common/cpt/cpt_ucode_asym.h b/drivers/common/cpt/cpt_ucode_asym.h
index f5d91f2583..1105a0c125 100644
--- a/drivers/common/cpt/cpt_ucode_asym.h
+++ b/drivers/common/cpt/cpt_ucode_asym.h
@@ -327,7 +327,7 @@ cpt_rsa_prep(struct asym_op_params *rsa_params,
 	/* Result buffer */
 	rlen = mod_len;
 
-	if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+	if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
 		/* Use mod_exp operation for no_padding type */
 		vq_cmd_w0.s.opcode.minor = CPT_MINOR_OP_MODEX;
 		vq_cmd_w0.s.param2 = exp_len;
@@ -412,7 +412,7 @@ cpt_rsa_crt_prep(struct asym_op_params *rsa_params,
 	/* Result buffer */
 	rlen = mod_len;
 
-	if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+	if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
 		/*Use mod_exp operation for no_padding type */
 		vq_cmd_w0.s.opcode.minor = CPT_MINOR_OP_MODEX_CRT;
 	} else {
diff --git a/drivers/crypto/cnxk/cnxk_ae.h b/drivers/crypto/cnxk/cnxk_ae.h
index 10854c79c8..0562f72270 100644
--- a/drivers/crypto/cnxk/cnxk_ae.h
+++ b/drivers/crypto/cnxk/cnxk_ae.h
@@ -288,7 +288,7 @@ cnxk_ae_rsa_prep(struct rte_crypto_op *op, struct roc_ae_buf_ptr *meta_buf,
 	dptr += in_size;
 	dlen = total_key_len + in_size;
 
-	if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+	if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
 		/* Use mod_exp operation for no_padding type */
 		w4.s.opcode_minor = ROC_AE_MINOR_OP_MODEX;
 		w4.s.param2 = exp_len;
@@ -347,7 +347,7 @@ cnxk_ae_rsa_crt_prep(struct rte_crypto_op *op, struct roc_ae_buf_ptr *meta_buf,
 	dptr += in_size;
 	dlen = total_key_len + in_size;
 
-	if (rsa_op.pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+	if (rsa_op.padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
 		/*Use mod_exp operation for no_padding type */
 		w4.s.opcode_minor = ROC_AE_MINOR_OP_MODEX_CRT;
 	} else {
@@ -675,7 +675,7 @@ cnxk_ae_dequeue_rsa_op(struct rte_crypto_op *cop, uint8_t *rptr,
 		memcpy(rsa->cipher.data, rptr, rsa->cipher.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_DECRYPT:
-		if (rsa->pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
 			rsa->message.length = rsa_ctx->n.length;
 			memcpy(rsa->message.data, rptr, rsa->message.length);
 		} else {
@@ -695,7 +695,7 @@ cnxk_ae_dequeue_rsa_op(struct rte_crypto_op *cop, uint8_t *rptr,
 		memcpy(rsa->sign.data, rptr, rsa->sign.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
-		if (rsa->pad == RTE_CRYPTO_RSA_PADDING_NONE) {
+		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
 			rsa->sign.length = rsa_ctx->n.length;
 			memcpy(rsa->sign.data, rptr, rsa->sign.length);
 		} else {
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index d5851d9987..914b17decf 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -736,7 +736,7 @@ otx_cpt_asym_rsa_op(struct rte_crypto_op *cop, struct cpt_request_info *req,
 		memcpy(rsa->cipher.data, req->rptr, rsa->cipher.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_DECRYPT:
-		if (rsa->pad == RTE_CRYPTO_RSA_PADDING_NONE)
+		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE)
 			rsa->message.length = rsa_ctx->n.length;
 		else {
 			/* Get length of decrypted output */
@@ -753,7 +753,7 @@ otx_cpt_asym_rsa_op(struct rte_crypto_op *cop, struct cpt_request_info *req,
 		memcpy(rsa->sign.data, req->rptr, rsa->sign.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
-		if (rsa->pad == RTE_CRYPTO_RSA_PADDING_NONE)
+		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE)
 			rsa->sign.length = rsa_ctx->n.length;
 		else {
 			/* Get length of decrypted output */
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index 750479c33f..72301e02fb 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1894,7 +1894,7 @@ process_openssl_rsa_op(struct rte_crypto_op *cop,
 	int ret = 0;
 	struct rte_crypto_asym_op *op = cop->asym;
 	RSA *rsa = sess->u.r.rsa;
-	uint32_t pad = (op->rsa.pad);
+	uint32_t pad = (op->rsa.padding.type);
 	uint8_t *tmp;
 
 	cop->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 479d5308cf..5dd355d007 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -345,7 +345,7 @@ rsa_set_pub_input(struct rte_crypto_asym_op *asym_op,
 	alg_bytesize = qat_function.bytesize;
 
 	if (asym_op->rsa.op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT) {
-		switch (asym_op->rsa.pad) {
+		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
 			SET_PKE_LN(cookie->input_array, asym_op->rsa.message,
 					alg_bytesize, 0);
@@ -358,7 +358,7 @@ rsa_set_pub_input(struct rte_crypto_asym_op *asym_op,
 		}
 		HEXDUMP("RSA Message", cookie->input_array[0], alg_bytesize);
 	} else {
-		switch (asym_op->rsa.pad) {
+		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
 			SET_PKE_LN(cookie->input_array, asym_op->rsa.sign,
 					alg_bytesize, 0);
@@ -454,7 +454,7 @@ rsa_set_priv_input(struct rte_crypto_asym_op *asym_op,
 
 	if (asym_op->rsa.op_type ==
 			RTE_CRYPTO_ASYM_OP_DECRYPT) {
-		switch (asym_op->rsa.pad) {
+		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
 			SET_PKE_LN(cookie->input_array, asym_op->rsa.cipher,
 				alg_bytesize, 0);
@@ -469,7 +469,7 @@ rsa_set_priv_input(struct rte_crypto_asym_op *asym_op,
 
 	} else if (asym_op->rsa.op_type ==
 			RTE_CRYPTO_ASYM_OP_SIGN) {
-		switch (asym_op->rsa.pad) {
+		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
 			SET_PKE_LN(cookie->input_array, asym_op->rsa.message,
 				alg_bytesize, 0);
@@ -529,7 +529,7 @@ rsa_collect(struct rte_crypto_asym_op *asym_op,
 		} else {
 			uint8_t *rsa_result = asym_op->rsa.cipher.data;
 
-			switch (asym_op->rsa.pad) {
+			switch (asym_op->rsa.padding.type) {
 			case RTE_CRYPTO_RSA_PADDING_NONE:
 				rte_memcpy(rsa_result,
 						cookie->output_array[0],
@@ -547,7 +547,7 @@ rsa_collect(struct rte_crypto_asym_op *asym_op,
 		if (asym_op->rsa.op_type == RTE_CRYPTO_ASYM_OP_DECRYPT) {
 			uint8_t *rsa_result = asym_op->rsa.message.data;
 
-			switch (asym_op->rsa.pad) {
+			switch (asym_op->rsa.padding.type) {
 			case RTE_CRYPTO_RSA_PADDING_NONE:
 				rte_memcpy(rsa_result,
 					cookie->output_array[0],
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 363fbf87c7..76fabc61b5 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -236,6 +236,47 @@ struct rte_crypto_rsa_priv_key_qt {
 };
 
 /**
+ * RSA padding type
+ */
+struct rte_crypto_rsa_padding {
+	enum rte_crypto_rsa_padding_type type;
+	/**< RSA padding scheme to be used for transform */
+	enum rte_crypto_auth_algorithm md;
+	/**<
+	 * RSA padding hash algorithm
+	 * Valid hash algorithms are:
+	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+	 *
+	 * When a specific padding type is selected, the following rules apply:
+	 * - RTE_CRYPTO_RSA_PADDING_NONE:
+	 * This field is ignored by the PMD
+	 *
+	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
+	 * When signing an operation this field is used to determine value
+	 * of the DigestInfo structure, therefore specifying which algorithm
+	 * was used to create the message digest.
+	 * When doing encryption/decryption this field is ignored for this
+	 * padding type.
+	 *
+	 * - RTE_CRYPTO_RSA_PADDING_OAEP
+	 * This field shall be set with the hash algorithm used
+	 * in the padding scheme
+	 *
+	 * - RTE_CRYPTO_RSA_PADDING_PSS
+	 * This field shall be set with the hash algorithm used
+	 * in the padding scheme (and to create the input message digest)
+	 */
+	enum rte_crypto_auth_algorithm mgf1md;
+	/**<
+	 * Hash algorithm to be used for mask generation if the
+	 * padding scheme is either OAEP or PSS. If the padding
+	 * scheme is unspecified a data hash algorithm is used
+	 * for mask generation. Valid hash algorithms are:
+	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+	 */
+};
+
+/**
  * Asymmetric RSA transform data
  *
  * Structure describing RSA xform params
@@ -391,43 +432,8 @@ struct rte_crypto_rsa_op_param {
 	 * All data is in Octet-string network byte order format.
 	 */
 
-	enum rte_crypto_rsa_padding_type pad;
-	/**< RSA padding scheme to be used for transform */
-
-	enum rte_crypto_auth_algorithm md;
-	/**<
-	 * RSA padding hash algorithm
-	 * Valid hash algorithms are:
-	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
-	 *
-	 * When a specific padding type is selected, the following rule apply:
-	 * - RTE_CRYPTO_RSA_PADDING_NONE:
-	 * This field is ignored by the PMD
-	 *
-	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
-	 * For sign operation, this field is used to determine value
-	 * of the DigestInfo structure, therefore specifying which algorithm
-	 * was used to create the message digest.
-	 * For encryption/decryption, this field is ignored for this
-	 * padding type.
-	 *
-	 * - RTE_CRYPTO_RSA_PADDING_OAEP
-	 * This field shall be set with the hash algorithm used
-	 * in the padding scheme
-	 *
-	 * - RTE_CRYPTO_RSA_PADDING_PSS
-	 * This field shall be set with the hash algorithm used
-	 * in the padding scheme (and to create the input message digest)
-	 */
-
-	enum rte_crypto_auth_algorithm mgf1md;
-	/**<
-	 * Hash algorithm to be used for mask generation if
-	 * padding scheme is either OAEP or PSS. If padding
-	 * scheme is unspecified data hash algorithm is used
-	 * for mask generation. Valid hash algorithms are:
-	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
-	 */
+	struct rte_crypto_rsa_padding padding;
+	/**< RSA padding information */
 };
 
 /**
-- 
2.13.6

[PATCH v4 11/12] cryptodev: clarify rsa verify with none padding

[Arek Kusztal]

- Clarified where should output be stored of signature
decryption with padding none.
PMD is not able to know what padding algorithm was used,
therefore decrypted signature should be returned to the user.
- Removed incorrect big-endian constraints.
Not all data in RSA can be treated as big endian integer,
therefore some of the constraints were lifted.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 76fabc61b5..d31642680f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -398,8 +398,6 @@ struct rte_crypto_rsa_op_param {
 	 * (i.e. must be at least RSA key size). The message.length
 	 * field should be 0 and will be overwritten by the PMD
 	 * with the decrypted length.
-	 *
-	 * All data is in Octet-string network byte order format.
 	 */
 
 	rte_crypto_param cipher;
@@ -414,7 +412,8 @@ struct rte_crypto_rsa_op_param {
 	 * at least RSA key size). The cipher.length field should
 	 * be 0 and will be overwritten by the PMD with the encrypted length.
 	 *
-	 * All data is in Octet-string network byte order format.
+	 * When RTE_CRYPTO_RSA_PADDING_NONE and RTE_CRYPTO_ASYM_OP_VERIFY
+	 * selected, this is an output of decrypted signature.
 	 */
 
 	rte_crypto_param sign;
@@ -428,8 +427,6 @@ struct rte_crypto_rsa_op_param {
 	 * with enough memory to hold signature output (i.e. must be
 	 * at least RSA key size). The sign.length field should
 	 * be 0 and will be overwritten by the PMD with the signature length.
-	 *
-	 * All data is in Octet-string network byte order format.
 	 */
 
 	struct rte_crypto_rsa_padding padding;
-- 
2.13.6

[PATCH v4 12/12] cryptodev: add salt length and optional label

[Arek Kusztal]

- Added salt length and optional label.
Common parameters to PSS and OAEP padding for RSA.
- Changed RSA hash padding fields names.
Now it corresponds to the RSA documents.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index d31642680f..a755eaff7b 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -241,7 +241,7 @@ struct rte_crypto_rsa_priv_key_qt {
 struct rte_crypto_rsa_padding {
 	enum rte_crypto_rsa_padding_type type;
 	/**< RSA padding scheme to be used for transform */
-	enum rte_crypto_auth_algorithm md;
+	enum rte_crypto_auth_algorithm hash;
 	/**<
 	 * RSA padding hash algorithm
 	 * Valid hash algorithms are:
@@ -266,7 +266,7 @@ struct rte_crypto_rsa_padding {
 	 * This field shall be set with the hash algorithm used
 	 * in the padding scheme (and to create the input message digest)
 	 */
-	enum rte_crypto_auth_algorithm mgf1md;
+	enum rte_crypto_auth_algorithm mgf1hash;
 	/**<
 	 * Hash algorithm to be used for mask generation if the
 	 * padding scheme is either OAEP or PSS. If the padding
@@ -274,6 +274,21 @@ struct rte_crypto_rsa_padding {
 	 * for mask generation. Valid hash algorithms are:
 	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
 	 */
+	uint16_t pss_saltlen;
+	/**<
+	 * RSA PSS padding salt length
+	 *
+	 * Used only when RTE_CRYPTO_RSA_PADDING_PSS padding is selected,
+	 * otherwise ignored.
+	 */
+	rte_crypto_param oaep_label;
+	/**<
+	 * RSA OAEP padding optional label
+	 *
+	 * Used only when RTE_CRYPTO_RSA_PADDING_OAEP padding is selected,
+	 * otherwise ignored. If label.data == NULL, a default
+	 * label (empty string) is used.
+	 */
 };
 
 /**
-- 
2.13.6

RE: [PATCH v4 01/12] cryptodev: redefine ec group enum

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:04 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 01/12] cryptodev: redefine ec group enum
> 
> - EC enum was renamed to rte_crypto_curve_id.
> Elliptic curve enum name was incorrectly associated
> with a group (it comes from the current tls registry name).
> - Clarified comments about TLS deprecation.
> Some curves included are deprecated with TLS 1.3.
> Comments to address it were added.
> - Clarified FFDH groups usage.
> Elliptic curves IDs in TLS are placed in the same registry
> as FFDH. Cryptodev does not assign specific groups, and
> if specific groups would be assigned by DPDK, it cannot be
> TLS SupportedGroups registry, as it would conflict with
> other protocols like IPSec.
> - Added IANA reference.
> Only few selected curves are included in previously
> referenced rfc8422. IANA reference is added instead.
> - Removed UNKNOWN ec group.
> There is no default value, and there is no UNKNOWN
> elliptic curve.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 02/12] cryptodev: separate key exchange operation enum

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:04 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 02/12] cryptodev: separate key exchange operation
> enum
> 
> - Separated key exchange enum from asym op type.
> Key exchange and asymmetric crypto operations like signatures,
> encryption/decryption should not share same operation enum as
> its use cases are unrelated and mutually exclusive.
> Therefore op_type was separate into:
> 1) operation type
> 2) key exchange operation type
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 03/12] cryptodev: remove comment about using ephemeral key in dsa

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 03/12] cryptodev: remove comment about using
> ephemeral key in dsa
> 
> - Removed comment that stated DSA can be used with Diffie
> Hellman ephemeral key.
> DH and DSA integration allowed to use ephemeral keys for
> random integer, but not for private keys.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 04/12] cryptodev: clarify usage of private key in dh

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 04/12] cryptodev: clarify usage of private key in dh
> 
> - Clarified usage of private key in Diffie-Hellman.
> CSRNG capable device should generate private key and then
> use it for public key generation.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 05/12] cryptodev: move dh type from xform to dh op

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 05/12] cryptodev: move dh type from xform to dh op
> 
> - Moved dh operation type to dh operation struct.
> Operation type (PUBLIC_KEY_GENERATION, SHARED_SECRET) should
> be free to choose for any operation. One xform/session should
> be enough to perform both DH operations, if op_type would be xform
> member, session would have to be to be created twice for the same
> group. Similar problem would be observed in sessionless case.
> Additionally, it will help extend DH to support Elliptic Curves.
> - Changed order of Diffie-Hellman operation phases.
> Now it corresponds with the order of operations.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>; mdr@ashroe.eu
> Subject: [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman
> 
> - Added elliptic curve Diffie-Hellman parameters.
> Point multiplication allows the user to process every phase of
> ECDH, but for phase 1, user should not really care about the generator.
> The user does not even need to know what the generator looks like,
> therefore setting ec xform would make this work.
> 
> Cc: mdr@ashroe.eu
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 07/12] cryptodev: add public key verify option

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 07/12] cryptodev: add public key verify option
> 
> - Added key exchange public key verify option.
> For some elliptic curves public point in DH exchange
> needs to be checked, if it lays on the curve.
> Modular exponentiation needs certain checks as well, though
> mathematically much easier.
> This commit adds verify option to asym_op operations.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 08/12] cryptodev: add asym op flags

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 08/12] cryptodev: add asym op flags
> 
> - Added flags to rte_crypto_asym_op struct.
> It may be shared between different algorithms.
> - Added Diffie-Hellman padding flags.
> Diffie-Hellman padding is used in certain protocols,
> in others, leading zero bytes need to be stripped.
> Even same protocol may use a different approach - most
> glaring example is TLS1.2 - TLS1.3.
> For ease of use, and to avoid additional copy
> on certain occasions, driver should be able to return both.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 09/12] cryptodev: clarify usage of rsa padding hash

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 09/12] cryptodev: clarify usage of rsa padding hash
> 
> - Clarified usage of RSA padding hash.
> It was not specified how to use hash for PKCS1_5
> padding. This could lead to incorrect implementation.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 10/12] cryptodev: move RSA padding into separate struct

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 10/12] cryptodev: move RSA padding into separate struct
> 
> - move RSA padding into separate struct.
> More padding members should be added into padding,
> therefore having separate struct for padding parameters will
> make this more readable.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 11/12] cryptodev: clarify rsa verify with none padding

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 11/12] cryptodev: clarify rsa verify with none padding
> 
> - Clarified where should output be stored of signature
> decryption with padding none.
> PMD is not able to know what padding algorithm was used,
> therefore decrypted signature should be returned to the user.
> - Removed incorrect big-endian constraints.
> Not all data in RSA can be treated as big endian integer,
> therefore some of the constraints were lifted.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 12/12] cryptodev: add salt length and optional label

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:05 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 12/12] cryptodev: add salt length and optional label
> 
> - Added salt length and optional label.
> Common parameters to PSS and OAEP padding for RSA.
> - Changed RSA hash padding fields names.
> Now it corresponds to the RSA documents.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>

RE: [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes

[Zhang, Roy Fan]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 5:04 AM
> To: dev@dpdk.org
> Cc: gakhil@marvell.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes
> 
> This patchset introduces some of changes discussed on mailing list for 22.07
> release in cryptodev asym.
> 
> Key changes:
> 
> - It fixes API for RSA (expescially signature paddings)
> - Adds Elliptic-Curve Diffie-Hellman
> - Adds Eliiptic-Curve point verification
> - Adds RSA missing padding fields
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
> 
> v4:
> - fixed shared build problem
> - added ABI ignore entry for xform
> 
> Arek Kusztal (12):
>   cryptodev: redefine ec group enum
>   cryptodev: separate key exchange operation enum
>   cryptodev: remove comment about using ephemeral key in dsa
>   cryptodev: clarify usage of private key in dh
>   cryptodev: move dh type from xform to dh op
>   cryptodev: add elliptic curve diffie hellman
>   cryptodev: add public key verify option
>   cryptodev: add asym op flags
>   cryptodev: clarify usage of rsa padding hash
>   cryptodev: move RSA padding into separate struct
>   cryptodev: clarify rsa verify with none padding
>   cryptodev: add salt length and optional label
> 
>  app/test/test_cryptodev_asym.c               |  63 ++++----
>  devtools/libabigail.abignore                 |   3 +
>  drivers/common/cpt/cpt_ucode_asym.h          |   4 +-
>  drivers/crypto/cnxk/cnxk_ae.h                |   8 +-
>  drivers/crypto/octeontx/otx_cryptodev_ops.c  |   4 +-
>  drivers/crypto/openssl/rte_openssl_pmd.c     |  17 +--
>  drivers/crypto/openssl/rte_openssl_pmd_ops.c |  33 +---
>  drivers/crypto/qat/qat_asym.c                |  12 +-
>  lib/cryptodev/rte_crypto_asym.h              | 217 ++++++++++++++++++++-----
> --
>  lib/cryptodev/rte_cryptodev.c                |  15 +-
>  lib/cryptodev/rte_cryptodev.h                |   4 +-
>  lib/cryptodev/version.map                    |   1 +
>  12 files changed, 237 insertions(+), 144 deletions(-)
> 
> --
> 2.13.6
Series-acked-by: Fan Zhang <roy.fan.zhang@intel.com>

Re: [PATCH v4 06/12] cryptodev: add elliptic curve diffie hellman

[Ray Kinsella]

Arek Kusztal <arkadiuszx.kusztal@intel.com> writes:

> - Added elliptic curve Diffie-Hellman parameters.
> Point multiplication allows the user to process every phase of
> ECDH, but for phase 1, user should not really care about the generator.
> The user does not even need to know what the generator looks like,
> therefore setting ec xform would make this work.
>
> Cc: mdr@ashroe.eu
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  devtools/libabigail.abignore    |  3 +++
>  lib/cryptodev/rte_crypto_asym.h | 38 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 41 insertions(+)
>

Acked-by: Ray Kinsella <mdr@ashroe.eu>

RE: [EXT] [PATCH v4 08/12] cryptodev: add asym op flags

[Akhil Goyal]

> -----Original Message-----
> From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, May 31, 2022 9:35 AM
> To: dev@dpdk.org
> Cc: Akhil Goyal <gakhil@marvell.com>; roy.fan.zhang@intel.com; Arek Kusztal
> <arkadiuszx.kusztal@intel.com>
> Subject: [EXT] [PATCH v4 08/12] cryptodev: add asym op flags
> 
> External Email
> 
> ----------------------------------------------------------------------
> - Added flags to rte_crypto_asym_op struct.
> It may be shared between different algorithms.
> - Added Diffie-Hellman padding flags.
> Diffie-Hellman padding is used in certain protocols,
> in others, leading zero bytes need to be stripped.
> Even same protocol may use a different approach - most
> glaring example is TLS1.2 - TLS1.3.
> For ease of use, and to avoid additional copy
> on certain occasions, driver should be able to return both.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index ae3ca31a89..a215f4499d 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -41,6 +41,19 @@ rte_crypto_asym_ke_strings[];
>  extern const char *
>  rte_crypto_asym_op_strings[];
> 
> +#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_NO_PADDING
> 	RTE_BIT32(0)
> +/**<
> + * Flag to denote public key will be returned without leading zero bytes
> + * and if the flag is not set, public key will be padded to the left with
> + * zeros to the size of the underlying algorithm (default)
> + */
> +#define RTE_CRYPTO_ASYM_FLAG_SHARED_KEY_NO_PADDING	RTE_BIT32(1)
> +/**<
> + * Flag to denote shared secret will be returned without leading zero bytes
> + * and if the flag is not set, shared secret will be padded to the left with
> + * zeros to the size of the underlying algorithm (default)
> + */
> +
>  /**
>   * List of elliptic curves. This enum aligns with
>   * TLS "Supported Groups" registry (previously known  as
> @@ -613,6 +626,8 @@ struct rte_crypto_asym_op {
>  		struct rte_crypto_ecdsa_op_param ecdsa;
>  		struct rte_crypto_ecpm_op_param ecpm;
>  	};
> +	uint16_t flags;
> +	/**< Asymmetric crypto operation flags */

Reference of flags missing. I think, it was highlighted in previous version also.

>  };
> 
>  #ifdef __cplusplus
> --
> 2.13.6

RE: [EXT] [PATCH v4 02/12] cryptodev: separate key exchange operation enum

[Akhil Goyal]

>  /**
> diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
> index 2c2c2edeb7..7d683fd728 100644
> --- a/lib/cryptodev/rte_cryptodev.h
> +++ b/lib/cryptodev/rte_cryptodev.h
> @@ -168,7 +168,9 @@ struct rte_cryptodev_asymmetric_xform_capability {
>  	/**< Transform type: RSA/MODEXP/DH/DSA/MODINV */
> 
>  	uint32_t op_types;
> -	/**< bitmask for supported rte_crypto_asym_op_type */
> +	/**< bitmask for supported rte_crypto_asym_op_type or
> +	 * rte_crypto_asym_ke_type
> +	 */

How is this supposed to work?
Ke_type and op_type are 2 separate enums which can have same value.
How will the user identify which one to use?
Shouldn't we split this too?

> 
>  	__extension__
>  	union {
> diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
> index f0abfaa47d..dbf1f62199 100644
> --- a/lib/cryptodev/version.map
> +++ b/lib/cryptodev/version.map
> @@ -108,6 +108,7 @@ EXPERIMENTAL {
> 
>  	#added in 22.07
>  	rte_cryptodev_session_event_mdata_set;
> +	rte_crypto_asym_ke_strings;
>  };
> 
>  INTERNAL {
> --
> 2.13.6

RE: [EXT] [PATCH v4 00/12] cryptodev: rsa, dh, ecdh changes

[Akhil Goyal]

> This patchset introduces some of changes discussed on mailing list for 22.07
> release in cryptodev asym.
> 
> Key changes:
> 
> - It fixes API for RSA (expescially signature paddings)
> - Adds Elliptic-Curve Diffie-Hellman
> - Adds Eliiptic-Curve point verification
> - Adds RSA missing padding fields
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
> 
> v4:
> - fixed shared build problem
> - added ABI ignore entry for xform

The Documentation is still not updated for these changes.
Please update doc/guides/prog_guide/cryptodev_lib.rst
And doc/guides/cryptodevs/features/default.ini (for ECDH)

Also update release notes (ECDH).


> 
> Arek Kusztal (12):
>   cryptodev: redefine ec group enum
>   cryptodev: separate key exchange operation enum
>   cryptodev: remove comment about using ephemeral key in dsa
>   cryptodev: clarify usage of private key in dh
>   cryptodev: move dh type from xform to dh op
>   cryptodev: add elliptic curve diffie hellman
>   cryptodev: add public key verify option
>   cryptodev: add asym op flags
>   cryptodev: clarify usage of rsa padding hash
>   cryptodev: move RSA padding into separate struct
>   cryptodev: clarify rsa verify with none padding
>   cryptodev: add salt length and optional label
> 
>  app/test/test_cryptodev_asym.c               |  63 ++++----
>  devtools/libabigail.abignore                 |   3 +
>  drivers/common/cpt/cpt_ucode_asym.h          |   4 +-
>  drivers/crypto/cnxk/cnxk_ae.h                |   8 +-
>  drivers/crypto/octeontx/otx_cryptodev_ops.c  |   4 +-
>  drivers/crypto/openssl/rte_openssl_pmd.c     |  17 +--
>  drivers/crypto/openssl/rte_openssl_pmd_ops.c |  33 +---
>  drivers/crypto/qat/qat_asym.c                |  12 +-
>  lib/cryptodev/rte_crypto_asym.h              | 217 ++++++++++++++++++++-------
>  lib/cryptodev/rte_cryptodev.c                |  15 +-
>  lib/cryptodev/rte_cryptodev.h                |   4 +-
>  lib/cryptodev/version.map                    |   1 +
>  12 files changed, 237 insertions(+), 144 deletions(-)
> 
> --
> 2.13.6

RE: [EXT] [PATCH v4 01/12] cryptodev: redefine ec group enum

[Akhil Goyal]

> - EC enum was renamed to rte_crypto_curve_id.
> Elliptic curve enum name was incorrectly associated
> with a group (it comes from the current tls registry name).
> - Clarified comments about TLS deprecation.
> Some curves included are deprecated with TLS 1.3.
> Comments to address it were added.
> - Clarified FFDH groups usage.
> Elliptic curves IDs in TLS are placed in the same registry
> as FFDH. Cryptodev does not assign specific groups, and
> if specific groups would be assigned by DPDK, it cannot be
> TLS SupportedGroups registry, as it would conflict with
> other protocols like IPSec.
> - Added IANA reference.
> Only few selected curves are included in previously
> referenced rfc8422. IANA reference is added instead.
> - Removed UNKNOWN ec group.
> There is no default value, and there is no UNKNOWN
> elliptic curve.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
The Patch do not apply cleanly. Please fix.

RE: [EXT] [PATCH v4 02/12] cryptodev: separate key exchange operation enum

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 31, 2022 1:47 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH v4 02/12] cryptodev: separate key exchange
> operation enum
> 
> >  /**
> > diff --git a/lib/cryptodev/rte_cryptodev.h
> > b/lib/cryptodev/rte_cryptodev.h index 2c2c2edeb7..7d683fd728 100644
> > --- a/lib/cryptodev/rte_cryptodev.h
> > +++ b/lib/cryptodev/rte_cryptodev.h
> > @@ -168,7 +168,9 @@ struct rte_cryptodev_asymmetric_xform_capability {
> >  	/**< Transform type: RSA/MODEXP/DH/DSA/MODINV */
> >
> >  	uint32_t op_types;
> > -	/**< bitmask for supported rte_crypto_asym_op_type */
> > +	/**< bitmask for supported rte_crypto_asym_op_type or
> > +	 * rte_crypto_asym_ke_type
> > +	 */
> 
> How is this supposed to work?
> Ke_type and op_type are 2 separate enums which can have same value.
> How will the user identify which one to use?
[Arek] - by algorithm - xform_type.
> Shouldn't we split this too?
[Arek] - for me both options are ok. For some SM2 may be bit challenging here, but in such situations we should have different op types for KE and OP. This would spare this API from having one op with majority of fields unused.
Though it may be split too, not big problem.
  
> 
> >
> >  	__extension__
> >  	union {
> > diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
> > index f0abfaa47d..dbf1f62199 100644
> > --- a/lib/cryptodev/version.map
> > +++ b/lib/cryptodev/version.map
> > @@ -108,6 +108,7 @@ EXPERIMENTAL {
> >
> >  	#added in 22.07
> >  	rte_cryptodev_session_event_mdata_set;
> > +	rte_crypto_asym_ke_strings;
> >  };
> >
> >  INTERNAL {
> > --
> > 2.13.6

RE: [EXT] [PATCH v4 02/12] cryptodev: separate key exchange operation enum

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Tuesday, May 31, 2022 3:50 PM
> To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH v4 02/12] cryptodev: separate key exchange
> operation enum
> 
> 
> 
> > -----Original Message-----
> > From: Akhil Goyal <gakhil@marvell.com>
> > Sent: Tuesday, May 31, 2022 1:47 PM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > Subject: RE: [EXT] [PATCH v4 02/12] cryptodev: separate key exchange
> > operation enum
> >
> > >  /**
> > > diff --git a/lib/cryptodev/rte_cryptodev.h
> > > b/lib/cryptodev/rte_cryptodev.h index 2c2c2edeb7..7d683fd728 100644
> > > --- a/lib/cryptodev/rte_cryptodev.h
> > > +++ b/lib/cryptodev/rte_cryptodev.h
> > > @@ -168,7 +168,9 @@ struct rte_cryptodev_asymmetric_xform_capability {
> > >  	/**< Transform type: RSA/MODEXP/DH/DSA/MODINV */
> > >
> > >  	uint32_t op_types;
> > > -	/**< bitmask for supported rte_crypto_asym_op_type */
> > > +	/**< bitmask for supported rte_crypto_asym_op_type or
> > > +	 * rte_crypto_asym_ke_type
> > > +	 */
> >
> > How is this supposed to work?
> > Ke_type and op_type are 2 separate enums which can have same value.
> > How will the user identify which one to use?
> [Arek] - by algorithm - xform_type.
> > Shouldn't we split this too?
> [Arek] - for me both options are ok. For some SM2 may be bit challenging here,
[Arek] - wanted to say here that I prefer not to split it.
> but in such situations we should have different op types for KE and OP. This
> would spare this API from having one op with majority of fields unused.
> Though it may be split too, not big problem.
> 
> >
> > >
> > >  	__extension__
> > >  	union {
> > > diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
> > > index f0abfaa47d..dbf1f62199 100644
> > > --- a/lib/cryptodev/version.map
> > > +++ b/lib/cryptodev/version.map
> > > @@ -108,6 +108,7 @@ EXPERIMENTAL {
> > >
> > >  	#added in 22.07
> > >  	rte_cryptodev_session_event_mdata_set;
> > > +	rte_crypto_asym_ke_strings;
> > >  };
> > >
> > >  INTERNAL {
> > > --
> > > 2.13.6

RE: [EXT] [PATCH v4 02/12] cryptodev: separate key exchange operation enum

[Akhil Goyal]

> > >  /**
> > > diff --git a/lib/cryptodev/rte_cryptodev.h
> > > b/lib/cryptodev/rte_cryptodev.h index 2c2c2edeb7..7d683fd728 100644
> > > --- a/lib/cryptodev/rte_cryptodev.h
> > > +++ b/lib/cryptodev/rte_cryptodev.h
> > > @@ -168,7 +168,9 @@ struct rte_cryptodev_asymmetric_xform_capability {
> > >  	/**< Transform type: RSA/MODEXP/DH/DSA/MODINV */
> > >
> > >  	uint32_t op_types;
> > > -	/**< bitmask for supported rte_crypto_asym_op_type */
> > > +	/**< bitmask for supported rte_crypto_asym_op_type or
> > > +	 * rte_crypto_asym_ke_type
> > > +	 */
> >
> > How is this supposed to work?
> > Ke_type and op_type are 2 separate enums which can have same value.
> > How will the user identify which one to use?
> [Arek] - by algorithm - xform_type.

Ok got it. But please update the comments to clarify this confusion that this
Based on xform type


> > Shouldn't we split this too?
> [Arek] - for me both options are ok. For some SM2 may be bit challenging here,
> but in such situations we should have different op types for KE and OP. This
> would spare this API from having one op with majority of fields unused.
> Though it may be split too, not big problem.