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

[PATCH 00/40] 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
- Removes LIST_END enumerators (ABI issue - supressed asym_xform)
- Adds Eliiptic-Curve point verification (DH verification - but will be used only for EC)
- Adds RSA missing padding fields.
- Adds asym op flags
- Fixes many API comments (like EC curves)

Commits are grouped by functionality, and mostly independent.

Arek Kusztal (40):
  cryptodev: redefine ec group enum
  cryptodev: remove list end enumerators
  test/crypto: remove list end enumerators
  cryptodev: reduce number of comments in asym xform
  test/crypto: removed asym xform none
  cryptodev: separate key exchange operation enum
  crypto/openssl: separate key exchange operation enum
  test/crypto: separate key exchange operation enum
  cryptodev: remove unnecessary zero assignement
  cryptodev: remove comment about using ephemeral key in dsa
  cryptodev: remove asym crypto next xform
  crypto/openssl: remove asym crypto next xform
  test/crypto: remove asym crypto next xform
  app/test-crypto-perf: remove asym crypto next xform
  app/test-eventdev: remove asym crypto next xform
  cryptodev: move dh type from xform to dh op
  crypto/openssl: move dh type from xform to dh op
  test/crypto: move dh type from xform to dh op
  cryptodev: changed order of dh fields
  cryptodev: add elliptic curve diffie hellman
  cryptodev: add public key verify option
  cryptodev: move RSA padding into separate struct
  crypto/qat: move RSA padding into separate struct
  crypto/openssl: move RSA padding into separate struct
  crypto/octeontx: move RSA padding into separate struct
  crypto/cnxk: move RSA padding into separate struct
  common/cpt: move RSA padding into separate struct
  test/crypto: move RSA padding into separate struct
  cryptodev: add salt length and optional label
  cryptodev: reduce rsa struct to only necessary fields
  crypto/qat: reduce rsa struct to only necessary fields
  crypto/openssl: reduce rsa struct to only necessary fields
  crypto/octeontx: reduce rsa struct to only necessary fields
  crypto/cnxk: reduce rsa struct to only necessary fields
  common/cpt: reduce rsa struct to only necessary fields
  test/crypto: reduce rsa struct to only necessary fields
  cryptodev: add asym op flags
  cryptodev: clarify usage of private key in dh
  crypto/openssl: generate dh private key
  test/crypto: added test for dh priv key generation

 app/test-crypto-perf/cperf_ops.c             |   1 -
 app/test-eventdev/test_perf_common.c         |   1 -
 app/test/test_cryptodev_asym.c               | 117 +++++----
 app/test/test_cryptodev_dh_test_vectors.h    |   1 -
 app/test/test_cryptodev_dsa_test_vectors.h   |   1 -
 app/test/test_cryptodev_mod_test_vectors.h   |   2 -
 app/test/test_cryptodev_rsa_test_vectors.h   |   2 -
 app/test/test_event_crypto_adapter.c         |   4 -
 devtools/libabigail.abignore                 |   2 +
 drivers/common/cpt/cpt_ucode_asym.h          |  12 +-
 drivers/crypto/cnxk/cnxk_ae.h                |  44 ++--
 drivers/crypto/octeontx/otx_cryptodev_ops.c  |  26 +-
 drivers/crypto/openssl/rte_openssl_pmd.c     |  47 ++--
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |  33 +--
 drivers/crypto/qat/qat_asym.c                |  28 +--
 lib/cryptodev/rte_crypto_asym.h              | 342 ++++++++++++++++-----------
 lib/cryptodev/rte_cryptodev.c                |  15 +-
 17 files changed, 358 insertions(+), 320 deletions(-)

-- 
2.13.6

[PATCH 01/40] cryptodev: redefine ec group enum

[Arek Kusztal]

- EC enum was renamed to rte_crypto_curve_id.
Elliptic curve enum name is incorrectly associated
with group (it comes from 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 in the same registry
as FFDH. Cryptodev does not assign specific groups, and
if specific groups would be assigned to enum 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..7206652458 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 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 02/40] cryptodev: remove list end enumerators

[Arek Kusztal]

- Removed LIST_END enumerators from asymmetric crypto API.
Adding new enum entries would require moving
LIST_END down, therefore changing its assigned number.
This would cause problems to ABI stability, so these
enums were removed.

Cc: mdr@ashroe.eu

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

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 79ff15dc4e..f1945ce3b7 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -27,6 +27,8 @@
 ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is experimental
 [suppress_type]
         name = rte_crypto_asym_op
+[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 7206652458..a474b6acd1 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -95,10 +95,8 @@ enum rte_crypto_asym_xform_type {
 	/**< Elliptic Curve Digital Signature Algorithm
 	 * Perform Signature Generation and Verification.
 	 */
-	RTE_CRYPTO_ASYM_XFORM_ECPM,
+	RTE_CRYPTO_ASYM_XFORM_ECPM
 	/**< Elliptic Curve Point Multiplication */
-	RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
-	/**< End of list */
 };
 
 /**
@@ -117,9 +115,8 @@ enum rte_crypto_asym_op_type {
 	/**< DH Private Key generation operation */
 	RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
 	/**< DH Public Key generation operation */
-	RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
+	RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE
 	/**< DH Shared Secret compute operation */
-	RTE_CRYPTO_ASYM_OP_LIST_END
 };
 
 /**
@@ -134,9 +131,8 @@ enum rte_crypto_rsa_padding_type {
 	 */
 	RTE_CRYPTO_RSA_PADDING_OAEP,
 	/**< RSA PKCS#1 OAEP padding scheme */
-	RTE_CRYPTO_RSA_PADDING_PSS,
+	RTE_CRYPTO_RSA_PADDING_PSS
 	/**< RSA PKCS#1 PSS padding scheme */
-	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
 };
 
 /**
-- 
2.13.6

[PATCH 03/40] test/crypto: remove list end enumerators

[Arek Kusztal]

- Removed LIST_END enumerators from asymmetric crypto structs.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 573af2a537..9fdeba3004 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -532,7 +532,7 @@ test_one_case(const void *test_case, int sessionless)
 		printf("  %u) TestCase %s %s\n", test_index++,
 			tc.modex.description, test_msg);
 	} else {
-		for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+		for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
 			if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
 				if (tc.rsa_data.op_type_flags & (1 << i)) {
 					if (tc.rsa_data.key_exp) {
@@ -974,7 +974,7 @@ static inline void print_asym_capa(
 			rte_crypto_asym_xform_strings[capa->xform_type]);
 	printf("operation supported -");
 
-	for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+	for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
 		/* check supported operations */
 		if (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
 			printf(" %s",
-- 
2.13.6

[PATCH 04/40] cryptodev: reduce number of comments in asym xform

[Arek Kusztal]

- Reduced number of comments in asymmetric xform.
Information describing basic functionality of well known
algorithms are unnecessary.
- Added information about data memory lifetime.
It was specified how user should work with private data,
and it is user's responsability to clear it.
- Removed NONE asymetric xform.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index a474b6acd1..0251e8caae 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -55,46 +55,29 @@ enum rte_crypto_curve_id {
 };
 
 /**
- * Asymmetric crypto transformation types.
- * Each xform type maps to one asymmetric algorithm
- * performing specific operation
- *
+ * Asymmetric crypto algorithm static data.
+ * Data that may be used more than once (e.g. RSA private key).
+ * It is the USER responsibility to keep track of private data memory
+ * lifetime and security of the this data in xform. The same way
+ * it is the USER responsibility to call cryptodev session_clear()
+ * function if a session was created. If session-less not used
+ * xform data should be cleared after successful session creation.
  */
 enum rte_crypto_asym_xform_type {
-	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
+	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED,
 	/**< Invalid xform. */
-	RTE_CRYPTO_ASYM_XFORM_NONE,
-	/**< Xform type None.
-	 * May be supported by PMD to support
-	 * passthrough op for debugging purpose.
-	 * if xform_type none , op_type is disregarded.
-	 */
 	RTE_CRYPTO_ASYM_XFORM_RSA,
-	/**< RSA. Performs Encrypt, Decrypt, Sign and Verify.
-	 * Refer to rte_crypto_asym_op_type
-	 */
+	/**< RSA */
 	RTE_CRYPTO_ASYM_XFORM_DH,
-	/**< Diffie-Hellman.
-	 * Performs Key Generate and Shared Secret Compute.
-	 * Refer to rte_crypto_asym_op_type
-	 */
+	/**< Diffie-Hellman */
 	RTE_CRYPTO_ASYM_XFORM_DSA,
-	/**< Digital Signature Algorithm
-	 * Performs Signature Generation and Verification.
-	 * Refer to rte_crypto_asym_op_type
-	 */
+	/**< Digital Signature Algorithm */
 	RTE_CRYPTO_ASYM_XFORM_MODINV,
-	/**< Modular Multiplicative Inverse
-	 * Perform Modular Multiplicative Inverse b^(-1) mod n
-	 */
+	/**< Modular Multiplicative Inverse */
 	RTE_CRYPTO_ASYM_XFORM_MODEX,
-	/**< Modular Exponentiation
-	 * Perform Modular Exponentiation b^e mod n
-	 */
+	/**< Modular Exponentiation */
 	RTE_CRYPTO_ASYM_XFORM_ECDSA,
-	/**< Elliptic Curve Digital Signature Algorithm
-	 * Perform Signature Generation and Verification.
-	 */
+	/**< Elliptic Curve Digital Signature Algorithm */
 	RTE_CRYPTO_ASYM_XFORM_ECPM
 	/**< Elliptic Curve Point Multiplication */
 };
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index e16e6802aa..691625bd04 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -160,7 +160,6 @@ rte_crypto_aead_operation_strings[] = {
  * Asymmetric crypto transform operation strings identifiers.
  */
 const char *rte_crypto_asym_xform_strings[] = {
-	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
 	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
 	[RTE_CRYPTO_ASYM_XFORM_MODEX]	= "modexp",
 	[RTE_CRYPTO_ASYM_XFORM_MODINV]	= "modinv",
-- 
2.13.6

[PATCH 05/40] test/crypto: removed asym xform none

[Arek Kusztal]

- Removed asymetric crypto NONE xform.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 9fdeba3004..62d710b0a0 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -288,7 +288,6 @@ test_cryptodev_asym_ver(struct rte_crypto_op *op,
 		break;
 	case RTE_CRYPTO_ASYM_XFORM_DH:
 	case RTE_CRYPTO_ASYM_XFORM_DSA:
-	case RTE_CRYPTO_ASYM_XFORM_NONE:
 	case RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED:
 	default:
 		break;
@@ -440,7 +439,6 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym *ts_params,
 		break;
 	case RTE_CRYPTO_ASYM_XFORM_DH:
 	case RTE_CRYPTO_ASYM_XFORM_DSA:
-	case RTE_CRYPTO_ASYM_XFORM_NONE:
 	case RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED:
 	default:
 		snprintf(test_msg, ASYM_TEST_MSG_LEN,
-- 
2.13.6

[PATCH 06/40] cryptodev: separate key exchange operation enum

[Arek Kusztal]

- separated key exchange enum.
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>
---
 lib/cryptodev/rte_crypto_asym.h | 24 +++++++++++++++++-------
 lib/cryptodev/rte_cryptodev.c   | 14 ++++++++++----
 2 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 0251e8caae..0fc9f49b87 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[];
@@ -94,12 +98,18 @@ 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 */
+};
+
+/**
+ * Asymmetric crypto key exchange operation type
+ */
+enum rte_crypto_asym_ke_type {
+	RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE,
+	/**< Private Key generation operation */
+	RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
+	/**< Public Key generation operation */
+	RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
+	/**< Shared Secret compute operation */
 };
 
 /**
@@ -239,7 +249,7 @@ struct rte_crypto_modinv_xform {
  *
  */
 struct rte_crypto_dh_xform {
-	enum rte_crypto_asym_op_type type;
+	enum rte_crypto_asym_ke_type type;
 	/**< Setup xform for key generate or shared secret compute */
 	rte_crypto_uint p;
 	/**< Prime modulus data */
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 691625bd04..af58f49d07 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -176,10 +176,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_PRIVATE_KEY_GENERATE] = "priv_key_generate",
+	[RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE] = "pub_key_generate",
+	[RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE] = "sharedsecret_compute"
 };
 
 /**
-- 
2.13.6

[PATCH 07/40] crypto/openssl: separate key exchange operation enum

[Arek Kusztal]

- Key exchange is now separate enumerator.
This commit reflects changes to the asymmetric crypto API

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/openssl/rte_openssl_pmd.c     | 10 +++++-----
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 12 ++++++------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index d80e1052e2..2a3930df0a 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_PUBLIC_KEY_GENERATE)) &&
 			!(sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE))) {
+			(1 << RTE_CRYPTO_ASYM_KE_PRIVATE_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_PUBLIC_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_PRIVATE_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..c975ef640a 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_PRIVATE_KEY_GENERATE) |
+				(1 << RTE_CRYPTO_ASYM_KE_PUBLIC_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 */
@@ -1009,13 +1009,13 @@ static int openssl_set_asym_session_parameters(
 		asym_session->u.dh.key_op = (1 << xform->dh.type);
 
 		if (xform->dh.type ==
-			RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE) {
+			RTE_CRYPTO_ASYM_KE_PRIVATE_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)
+				RTE_CRYPTO_ASYM_KE_PUBLIC_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_PUBLIC_KEY_GENERATE);
 			}
 		}
 		asym_session->u.dh.dh_key = dh;
-- 
2.13.6

[PATCH 08/40] test/crypto: separate key exchange operation enum

[Arek Kusztal]

- Key exchange is now separate enum.
This commit reflects changes to the asymmetric crypto API

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 62d710b0a0..0098b6bf65 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -530,7 +530,7 @@ test_one_case(const void *test_case, int sessionless)
 		printf("  %u) TestCase %s %s\n", test_index++,
 			tc.modex.description, test_msg);
 	} else {
-		for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
+		for (i = 0; i <= RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE; i++) {
 			if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
 				if (tc.rsa_data.op_type_flags & (1 << i)) {
 					if (tc.rsa_data.key_exp) {
@@ -972,7 +972,7 @@ static inline void print_asym_capa(
 			rte_crypto_asym_xform_strings[capa->xform_type]);
 	printf("operation supported -");
 
-	for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
+	for (i = 0; i <= RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE; i++) {
 		/* check supported operations */
 		if (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
 			printf(" %s",
@@ -1062,7 +1062,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.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;
@@ -1144,7 +1144,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.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
 	xform.next = NULL;
 	asym_op->dh.priv_key.data = output;
 	asym_op->dh.priv_key.length = sizeof(output);
@@ -1227,7 +1227,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.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
 	xform.next = NULL;
 
 	asym_op->dh.pub_key.data = output;
@@ -1317,9 +1317,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.type = RTE_CRYPTO_ASYM_KE_PRIVATE_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.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
 	xform.next = &pub_key_xform;
 
 	asym_op->dh.pub_key.data = out_pub_key;
-- 
2.13.6

[PATCH 09/40] cryptodev: remove unnecessary zero assignement

[Arek Kusztal]

- removed unnecessary zero assignement in rsa padding enum.
Even it is set correctly it should be made consistent with
other enums in cryptodev. Therefore assignement to zero was
removed.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 0fc9f49b87..270619acf2 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -116,11 +116,12 @@ enum rte_crypto_asym_ke_type {
  * Padding types for RSA signature.
  */
 enum rte_crypto_rsa_padding_type {
-	RTE_CRYPTO_RSA_PADDING_NONE = 0,
+	RTE_CRYPTO_RSA_PADDING_NONE,
 	/**< RSA no padding scheme */
 	RTE_CRYPTO_RSA_PADDING_PKCS1_5,
-	/**< RSA PKCS#1 PKCS1-v1_5 padding scheme. For signatures block type 01,
-	 * for encryption block type 02 are used.
+	/**< RSA PKCS#1 PKCS1-v1_5 padding scheme.
+	 * For signatures block type 01, for encryption
+	 * block type 02 are used.
 	 */
 	RTE_CRYPTO_RSA_PADDING_OAEP,
 	/**< RSA PKCS#1 OAEP padding scheme */
-- 
2.13.6

[PATCH 10/40] 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 270619acf2..1652a434a5 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -272,13 +272,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 11/40] cryptodev: remove asym crypto next xform

[Arek Kusztal]

- removed asymnetric crypto xform next field.
Rationale behind having chaining in symmetric crypto
was a fact that encryption and authentication are usually
done on the same set of data independent of algorithm.
HW usually will be able to handle it in one PCI call.
In asymmetric there is no such relation between algorithms,
therefore next field would be useless.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 1652a434a5..b355cbe5fa 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
  * Structure describing asym xforms.
  */
 struct rte_crypto_asym_xform {
-	struct rte_crypto_asym_xform *next;
-	/**< Pointer to next xform to set up xform chain.*/
 	enum rte_crypto_asym_xform_type xform_type;
 	/**< Asymmetric crypto transform */
 
-- 
2.13.6

[PATCH 12/40] crypto/openssl: remove asym crypto next xform

[Arek Kusztal]

- removed asymnetric crypto xform next field.
This commit reflects asymmetric crypto API changes

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/openssl/rte_openssl_pmd_ops.c | 26 --------------------------
 1 file changed, 26 deletions(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index c975ef640a..a1be96bf1d 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -808,13 +808,6 @@ static int openssl_set_asym_session_parameters(
 {
 	int ret = 0;
 
-	if ((xform->xform_type != RTE_CRYPTO_ASYM_XFORM_DH) &&
-		(xform->next != NULL)) {
-		OPENSSL_LOG(ERR, "chained xfrms are not supported on %s",
-			rte_crypto_asym_xform_strings[xform->xform_type]);
-		return -1;
-	}
-
 	switch (xform->xform_type) {
 	case RTE_CRYPTO_ASYM_XFORM_RSA:
 	{
@@ -1007,25 +1000,6 @@ static int openssl_set_asym_session_parameters(
 		 * public and private key generate
 		 */
 		asym_session->u.dh.key_op = (1 << xform->dh.type);
-
-		if (xform->dh.type ==
-			RTE_CRYPTO_ASYM_KE_PRIVATE_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_KE_PUBLIC_KEY_GENERATE)
-				) {
-				/*
-				 * setup op as pub/priv key
-				 * pair generationi
-				 */
-				asym_session->u.dh.key_op |=
-				(1 <<
-				RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE);
-			}
-		}
 		asym_session->u.dh.dh_key = dh;
 		asym_session->xfrm_type = RTE_CRYPTO_ASYM_XFORM_DH;
 		break;
-- 
2.13.6

[PATCH 13/40] test/crypto: remove asym crypto next xform

[Arek Kusztal]

- removed asymnetric crypto xform next field.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c             | 100 -----------------------------
 app/test/test_cryptodev_dh_test_vectors.h  |   1 -
 app/test/test_cryptodev_dsa_test_vectors.h |   1 -
 app/test/test_cryptodev_mod_test_vectors.h |   2 -
 app/test/test_cryptodev_rsa_test_vectors.h |   2 -
 app/test/test_event_crypto_adapter.c       |   4 --
 6 files changed, 110 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 0098b6bf65..9e5d5e4f27 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -318,7 +318,6 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym *ts_params,
 
 	int ret, status = TEST_SUCCESS;
 
-	xform_tc.next = NULL;
 	xform_tc.xform_type = data_tc->modex.xform_type;
 
 	cap_idx.type = xform_tc.xform_type;
@@ -1063,7 +1062,6 @@ test_dh_gen_shared_sec(struct rte_crypto_asym_xform *xfrm)
 
 	/* Setup a xform and op to generate private key only */
 	xform.dh.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;
 	asym_op->dh.pub_key.data = (uint8_t *)peer;
@@ -1145,7 +1143,6 @@ test_dh_gen_priv_key(struct rte_crypto_asym_xform *xfrm)
 
 	/* Setup a xform and op to generate private key only */
 	xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
-	xform.next = NULL;
 	asym_op->dh.priv_key.data = output;
 	asym_op->dh.priv_key.length = sizeof(output);
 
@@ -1228,7 +1225,6 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
 	 *
 	 */
 	xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
-	xform.next = NULL;
 
 	asym_op->dh.pub_key.data = output;
 	asym_op->dh.pub_key.length = sizeof(output);
@@ -1288,94 +1284,6 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
 }
 
 static int
-test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)
-{
-	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
-	struct rte_mempool *op_mpool = ts_params->op_mpool;
-	struct rte_mempool *sess_mpool = ts_params->session_mpool;
-	uint8_t dev_id = ts_params->valid_devs[0];
-	struct rte_crypto_asym_op *asym_op = NULL;
-	struct rte_crypto_op *op = NULL, *result_op = NULL;
-	void *sess = NULL;
-	int ret, status = TEST_SUCCESS;
-	uint8_t out_pub_key[TEST_DH_MOD_LEN];
-	uint8_t out_prv_key[TEST_DH_MOD_LEN];
-	struct rte_crypto_asym_xform pub_key_xform;
-	struct rte_crypto_asym_xform xform = *xfrm;
-
-	/* set up crypto op data structure */
-	op = rte_crypto_op_alloc(op_mpool, RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
-	if (!op) {
-		RTE_LOG(ERR, USER1,
-			"line %u FAILED: %s",
-			__LINE__, "Failed to allocate asymmetric crypto "
-			"operation struct");
-		status = TEST_FAILED;
-		goto error_exit;
-	}
-	asym_op = op->asym;
-	/* Setup a xform chain to generate
-	 * private key first followed by
-	 * public key
-	 */
-	xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
-	pub_key_xform.xform_type = RTE_CRYPTO_ASYM_XFORM_DH;
-	pub_key_xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
-	xform.next = &pub_key_xform;
-
-	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);
-
-	ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, &sess);
-	if (ret < 0) {
-		RTE_LOG(ERR, USER1,
-				"line %u FAILED: %s", __LINE__,
-				"Session creation failed");
-		status = (ret == -ENOTSUP) ? TEST_SKIPPED : TEST_FAILED;
-		goto error_exit;
-	}
-
-	/* attach asymmetric crypto session to crypto operations */
-	rte_crypto_op_attach_asym_session(op, sess);
-
-	RTE_LOG(DEBUG, USER1, "Process ASYM operation");
-
-	/* Process crypto operation */
-	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
-		RTE_LOG(ERR, USER1,
-			"line %u FAILED: %s",
-			__LINE__, "Error sending packet for operation");
-		status = TEST_FAILED;
-		goto error_exit;
-	}
-
-	while (rte_cryptodev_dequeue_burst(dev_id, 0, &result_op, 1) == 0)
-		rte_pause();
-
-	if (result_op == NULL) {
-		RTE_LOG(ERR, USER1,
-			"line %u FAILED: %s",
-			__LINE__, "Failed to process asym crypto op");
-		status = TEST_FAILED;
-		goto error_exit;
-	}
-	debug_hexdump(stdout, "priv key:",
-			out_prv_key, asym_op->dh.priv_key.length);
-	debug_hexdump(stdout, "pub key:",
-			out_pub_key, asym_op->dh.pub_key.length);
-
-error_exit:
-	if (sess != NULL)
-		rte_cryptodev_asym_session_free(dev_id, sess);
-	if (op != NULL)
-		rte_crypto_op_free(op);
-
-	return status;
-}
-
-static int
 test_mod_inv(void)
 {
 	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
@@ -1611,12 +1519,6 @@ test_dh_keygenration(void)
 			dh_test_params.priv_key.length);
 
 	RTE_LOG(INFO, USER1,
-		"Test Public and Private key pair generation\n");
-
-	status = test_dh_gen_kp(&dh_xform);
-	TEST_ASSERT_EQUAL(status, 0, "Test failed");
-
-	RTE_LOG(INFO, USER1,
 		"Test Public Key Generation using pre-defined priv key\n");
 
 	status = test_dh_gen_pub_key(&dh_xform);
@@ -1828,7 +1730,6 @@ test_ecdsa_sign_verify(enum curve curve_id)
 	asym_op = op->asym;
 
 	/* Setup asym xform */
-	xform.next = NULL;
 	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECDSA;
 	xform.ec.curve_id = input_params.curve;
 
@@ -2030,7 +1931,6 @@ test_ecpm(enum curve curve_id)
 	asym_op = op->asym;
 
 	/* Setup asym xform */
-	xform.next = NULL;
 	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECPM;
 	xform.ec.curve_id = input_params.curve;
 
diff --git a/app/test/test_cryptodev_dh_test_vectors.h b/app/test/test_cryptodev_dh_test_vectors.h
index fe7510dcd3..078719072d 100644
--- a/app/test/test_cryptodev_dh_test_vectors.h
+++ b/app/test/test_cryptodev_dh_test_vectors.h
@@ -63,7 +63,6 @@ struct dh_test_param dh_test_params = {
 };
 
 struct rte_crypto_asym_xform dh_xform = {
-	.next = NULL,
 	.xform_type = RTE_CRYPTO_ASYM_XFORM_DH,
 	.dh = {
 		.p = {
diff --git a/app/test/test_cryptodev_dsa_test_vectors.h b/app/test/test_cryptodev_dsa_test_vectors.h
index bbcb0d7297..cc60f50b5c 100644
--- a/app/test/test_cryptodev_dsa_test_vectors.h
+++ b/app/test/test_cryptodev_dsa_test_vectors.h
@@ -91,7 +91,6 @@ struct dsa_test_param dsa_test_params = {
 };
 
 struct rte_crypto_asym_xform dsa_xform = {
-	.next = NULL,
 	.xform_type = RTE_CRYPTO_ASYM_XFORM_DSA,
 	.dsa = {
 		.p = {
diff --git a/app/test/test_cryptodev_mod_test_vectors.h b/app/test/test_cryptodev_mod_test_vectors.h
index 807ca7a47e..bcd4d5248b 100644
--- a/app/test/test_cryptodev_mod_test_vectors.h
+++ b/app/test/test_cryptodev_mod_test_vectors.h
@@ -1045,7 +1045,6 @@ uint8_t mod_inv[] = {
 
 /* MODEX vector. 8< */
 struct rte_crypto_asym_xform modex_xform = {
-	.next = NULL,
 	.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
 	.modex = {
 		.modulus = {
@@ -1061,7 +1060,6 @@ struct rte_crypto_asym_xform modex_xform = {
 /* >8 End of MODEX vector. */
 
 struct rte_crypto_asym_xform modinv_xform = {
-	.next = NULL,
 	.xform_type = RTE_CRYPTO_ASYM_XFORM_MODINV,
 	.modinv = {
 		.modulus = {
diff --git a/app/test/test_cryptodev_rsa_test_vectors.h b/app/test/test_cryptodev_rsa_test_vectors.h
index 04539a1ecf..e769dec1f4 100644
--- a/app/test/test_cryptodev_rsa_test_vectors.h
+++ b/app/test/test_cryptodev_rsa_test_vectors.h
@@ -346,7 +346,6 @@ uint8_t rsa_qInv[] = {
 
 /** rsa xform using exponent key */
 struct rte_crypto_asym_xform rsa_xform = {
-	.next = NULL,
 	.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA,
 	.rsa = {
 		.n = {
@@ -367,7 +366,6 @@ struct rte_crypto_asym_xform rsa_xform = {
 
 /** rsa xform using quintuple key */
 struct rte_crypto_asym_xform rsa_xform_crt = {
-	.next = NULL,
 	.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA,
 	.rsa = {
 		.n = {
diff --git a/app/test/test_event_crypto_adapter.c b/app/test/test_event_crypto_adapter.c
index 2ecc7e2cea..feb1d86c00 100644
--- a/app/test/test_event_crypto_adapter.c
+++ b/app/test/test_event_crypto_adapter.c
@@ -295,7 +295,6 @@ test_op_forward_mode(uint8_t session_less)
 #endif
 	/* Setup Cipher Parameters */
 	cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
-	cipher_xform.next = NULL;
 	cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
 	cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
 
@@ -474,7 +473,6 @@ test_asym_op_forward_mode(uint8_t session_less)
 		return TEST_SKIPPED;
 	}
 	/* Setup Cipher Parameters */
-	xform_tc.next = NULL;
 	xform_tc.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
 	cap_idx.type = xform_tc.xform_type;
 	capability = rte_cryptodev_asym_capability_get(TEST_CDEV_ID, &cap_idx);
@@ -672,7 +670,6 @@ test_op_new_mode(uint8_t session_less)
 #endif
 	/* Setup Cipher Parameters */
 	cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
-	cipher_xform.next = NULL;
 	cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
 	cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
 
@@ -807,7 +804,6 @@ test_asym_op_new_mode(uint8_t session_less)
 		return TEST_SKIPPED;
 	}
 	/* Setup Cipher Parameters */
-	xform_tc.next = NULL;
 	xform_tc.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
 	cap_idx.type = xform_tc.xform_type;
 	capability = rte_cryptodev_asym_capability_get(TEST_CDEV_ID, &cap_idx);
-- 
2.13.6

[PATCH 14/40] app/test-crypto-perf: remove asym crypto next xform

[Arek Kusztal]

- removed asymnetric crypto xform next field.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test-crypto-perf/cperf_ops.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index cbefce8d6c..8371af301a 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -786,7 +786,6 @@ cperf_create_session(struct rte_mempool *sess_mp,
 	int ret;
 
 	if (options->op_type == CPERF_ASYM_MODEX) {
-		xform.next = NULL;
 		xform.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
 		xform.modex.modulus.data = options->modex_data->modulus.data;
 		xform.modex.modulus.length = options->modex_data->modulus.len;
-- 
2.13.6

[PATCH 15/40] app/test-eventdev: remove asym crypto next xform

[Arek Kusztal]

- removed asymmetric crypto xform next field.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test-eventdev/test_perf_common.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/app/test-eventdev/test_perf_common.c b/app/test-eventdev/test_perf_common.c
index f2da6fd74c..78150533a9 100644
--- a/app/test-eventdev/test_perf_common.c
+++ b/app/test-eventdev/test_perf_common.c
@@ -851,7 +851,6 @@ cryptodev_asym_sess_create(struct prod_data *p, struct test_perf *t)
 	struct rte_crypto_asym_xform xform;
 	void *sess;
 
-	xform.next = NULL;
 	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
 	cap_idx.type = xform.xform_type;
 	capability = rte_cryptodev_asym_capability_get(p->ca.cdev_id, &cap_idx);
-- 
2.13.6

[PATCH 16/40] 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.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index b355cbe5fa..728a98f02e 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -250,8 +250,6 @@ struct rte_crypto_modinv_xform {
  *
  */
 struct rte_crypto_dh_xform {
-	enum rte_crypto_asym_ke_type type;
-	/**< Setup xform for key generate or shared secret compute */
 	rte_crypto_uint p;
 	/**< Prime modulus data */
 	rte_crypto_uint g;
@@ -379,27 +377,29 @@ struct rte_crypto_rsa_op_param {
  * @note:
  */
 struct rte_crypto_dh_op_param {
+	enum rte_crypto_asym_ke_type op_type;
+	/**< Key exchange operation type */
 	rte_crypto_uint pub_key;
 	/**<
-	 * Output generated public key when xform type is
+	 * Output generated public key when op_type is
 	 * DH PUB_KEY_GENERATION.
-	 * Input peer public key when xform type is DH
+	 * Input peer public key when op_type is DH
 	 * SHARED_SECRET_COMPUTATION
 	 *
 	 */
 
 	rte_crypto_uint priv_key;
 	/**<
-	 * Output generated private key if xform type is
+	 * Output generated private key when op_type is
 	 * DH PRIVATE_KEY_GENERATION
-	 * Input when xform type is DH SHARED_SECRET_COMPUTATION.
+	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
 	 *
 	 */
 
 	rte_crypto_uint shared_secret;
 	/**<
 	 * Output with calculated shared secret
-	 * when dh xform set up with op type = SHARED_SECRET_COMPUTATION.
+	 * when op type is SHARED_SECRET_COMPUTATION.
 	 *
 	 */
 };
-- 
2.13.6

[PATCH 17/40] crypto/openssl: move dh type from xform to dh op

[Arek Kusztal]

- Moved dh operation type to dh operation struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/openssl/rte_openssl_pmd.c     | 15 ++++++---------
 drivers/crypto/openssl/rte_openssl_pmd_ops.c |  1 -
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index 2a3930df0a..c4ac767052 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.op_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_PUBLIC_KEY_GENERATE)) &&
-			!(sess->u.dh.key_op &
-			(1 << RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE))) {
+	if (asym_op->dh.op_type == RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE &&
+			op->priv_key.data) {
 		/* 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_PUBLIC_KEY_GENERATE)) {
+	if (asym_op->dh.op_type == RTE_CRYPTO_ASYM_KE_PUBLIC_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_PRIVATE_KEY_GENERATE)) {
+	if (asym_op->dh.op_type == RTE_CRYPTO_ASYM_KE_PRIVATE_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 a1be96bf1d..737ec5de80 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -999,7 +999,6 @@ 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.dh_key = dh;
 		asym_session->xfrm_type = RTE_CRYPTO_ASYM_XFORM_DH;
 		break;
-- 
2.13.6

[PATCH 18/40] test/crypto: move dh type from xform to dh op

[Arek Kusztal]

- Moved dh operation type to dh operation struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 9e5d5e4f27..892b5553f8 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1061,8 +1061,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.type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
 	asym_op->dh.priv_key.data = dh_test_params.priv_key.data;
+	asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE;
 	asym_op->dh.priv_key.length = dh_test_params.priv_key.length;
 	asym_op->dh.pub_key.data = (uint8_t *)peer;
 	asym_op->dh.pub_key.length = sizeof(peer);
@@ -1142,8 +1142,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.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
 	asym_op->dh.priv_key.data = output;
+	asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
 	asym_op->dh.priv_key.length = sizeof(output);
 
 	ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, &sess);
@@ -1224,9 +1224,9 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
 	 * using test private key
 	 *
 	 */
-	xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
 
 	asym_op->dh.pub_key.data = output;
+	asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
 	asym_op->dh.pub_key.length = sizeof(output);
 	/* load pre-defined private key */
 	asym_op->dh.priv_key.data = rte_malloc(NULL,
-- 
2.13.6

[PATCH 19/40] cryptodev: changed order of dh fields

[Arek Kusztal]

- changed order of Diffie-Hellman struct fields.
Now order of Diffie-Hellman struct members corresponds
to order of operation in Diffie-Hellman key exchange.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 728a98f02e..52cb1c5c80 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -379,6 +379,13 @@ struct rte_crypto_rsa_op_param {
 struct rte_crypto_dh_op_param {
 	enum rte_crypto_asym_ke_type op_type;
 	/**< Key exchange operation type */
+	rte_crypto_uint priv_key;
+	/**<
+	 * Output generated private key when op_type is
+	 * DH PRIVATE_KEY_GENERATION
+	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
+	 *
+	 */
 	rte_crypto_uint pub_key;
 	/**<
 	 * Output generated public key when op_type is
@@ -387,15 +394,6 @@ struct rte_crypto_dh_op_param {
 	 * SHARED_SECRET_COMPUTATION
 	 *
 	 */
-
-	rte_crypto_uint priv_key;
-	/**<
-	 * Output generated private key when op_type is
-	 * DH PRIVATE_KEY_GENERATION
-	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
-	 *
-	 */
-
 	rte_crypto_uint shared_secret;
 	/**<
 	 * Output with calculated shared secret
-- 
2.13.6

[PATCH 20/40] 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.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 52cb1c5c80..09edf2ac3d 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -82,8 +82,10 @@ enum rte_crypto_asym_xform_type {
 	/**< Modular Exponentiation */
 	RTE_CRYPTO_ASYM_XFORM_ECDSA,
 	/**< Elliptic Curve Digital Signature Algorithm */
-	RTE_CRYPTO_ASYM_XFORM_ECPM
+	RTE_CRYPTO_ASYM_XFORM_ECPM,
 	/**< Elliptic Curve Point Multiplication */
+	RTE_CRYPTO_ASYM_XFORM_ECDH
+	/**< Elliptic Curve Diffie Hellman */
 };
 
 /**
@@ -383,22 +385,28 @@ struct rte_crypto_dh_op_param {
 	/**<
 	 * Output generated private key when op_type is
 	 * DH PRIVATE_KEY_GENERATION
-	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
-	 *
+	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
 	 */
-	rte_crypto_uint pub_key;
+	union {
+		rte_crypto_uint pub_key;
+		struct rte_crypto_ec_point pub_point;
+	};
 	/**<
-	 * Output generated public key when op_type is
-	 * DH PUB_KEY_GENERATION.
-	 * Input peer public key when op_type is DH
-	 * SHARED_SECRET_COMPUTATION
-	 *
+	 * Diffie-Hellman public part
+	 * For DH it is big-endian unsigned integer.
+	 * For ECDH it is a point on the curve.
+	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
+	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
 	 */
-	rte_crypto_uint shared_secret;
+	union {
+		rte_crypto_uint shared_secret;
+		struct rte_crypto_ec_point shared_point;
+	};
 	/**<
-	 * Output with calculated shared secret
-	 * when op type is SHARED_SECRET_COMPUTATION.
-	 *
+	 * Diffie-Hellman shared secret
+	 * For DH it is big-endian unsigned integer.
+	 * For ECDH it is a point on the curve.
+	 * Output for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
 	 */
 };
 
-- 
2.13.6

[PATCH 21/40] 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 | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 09edf2ac3d..73ff9ff815 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -110,8 +110,10 @@ enum rte_crypto_asym_ke_type {
 	/**< Private Key generation operation */
 	RTE_CRYPTO_ASYM_KE_PUBLIC_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_OP_DH_KEY_VERIFY
+	/**< Public Key Verification */
 };
 
 /**
@@ -397,6 +399,10 @@ struct rte_crypto_dh_op_param {
 	 * For ECDH it is a point on the curve.
 	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
 	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
+	 *
+	 * VERIFY option can be used only for elliptic curve
+	 * point validation, for FFDH (DH) it is user's reponsibility
+	 * to check the public key accordingly.
 	 */
 	union {
 		rte_crypto_uint shared_secret;
-- 
2.13.6

[PATCH 22/40] 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>
---
 lib/cryptodev/rte_crypto_asym.h | 42 +++++++++++++++++++++++------------------
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 73ff9ff815..97c3fbee38 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -201,6 +201,28 @@ 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;
+	/**< Hash algorithm to be used for data hash if padding
+	 * scheme is either OAEP or PSS. Valid hash algorithms
+	 * are:
+	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+	 */
+	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
+	 */
+};
+
+/**
  * Asymmetric RSA transform data
  *
  * Structure describing RSA xform params
@@ -355,25 +377,9 @@ struct rte_crypto_rsa_op_param {
 	 *
 	 * All data is in Octet-string network byte order format.
 	 */
+	struct rte_crypto_rsa_padding padding;
+	/**< RSA padding information */
 
-	enum rte_crypto_rsa_padding_type pad;
-	/**< 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:
-	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
-	 */
-
-	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
-	 */
 };
 
 /**
-- 
2.13.6

[PATCH 23/40] crypto/qat: move RSA padding into separate struct

[Arek Kusztal]

- move RSA padding into separate struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/qat/qat_asym.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

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],
-- 
2.13.6

[PATCH 24/40] crypto/openssl: move RSA padding into separate struct

[Arek Kusztal]

- move RSA padding into separate struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/openssl/rte_openssl_pmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index c4ac767052..6b3cf7a6aa 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;
-- 
2.13.6

[PATCH 25/40] crypto/octeontx: move RSA padding into separate struct

[Arek Kusztal]

- move RSA padding into separate struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/octeontx/otx_cryptodev_ops.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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 */
-- 
2.13.6

[PATCH 26/40] crypto/cnxk: move RSA padding into separate struct

[Arek Kusztal]

- move RSA padding into separate struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/cnxk/cnxk_ae.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

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 {
-- 
2.13.6

[PATCH 27/40] common/cpt: move RSA padding into separate struct

[Arek Kusztal]

- move RSA padding into separate struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/common/cpt/cpt_ucode_asym.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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 {
-- 
2.13.6

[PATCH 28/40] test/crypto: move RSA padding into separate struct

[Arek Kusztal]

- move RSA padding into separate struct.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 892b5553f8..eca0612815 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) {
@@ -412,7 +412,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;
-- 
2.13.6

[PATCH 29/40] cryptodev: add salt length and optional label

[Arek Kusztal]

- added salt length and optional label.
Common parameters to PSS and OAEP padding for RSA.
- Fixed hash API in RSA padding.
Now it is specified how hash should be used with
particular RSA padding modes.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 97c3fbee38..c864b8a115 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -205,12 +205,29 @@ 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;
-	/**< Hash algorithm to be used for data hash if padding
-	 * scheme is either OAEP or PSS. Valid hash algorithms
-	 * are:
-	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
+	/**< Type of RSA padding */
+	enum rte_crypto_auth_algorithm hash;
+	/**<
+	 * RSA padding hash function
+	 *
+	 * 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:
+	 * When signing 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;
 	/**<
@@ -220,6 +237,21 @@ struct rte_crypto_rsa_padding {
 	 * for mask generation. Valid hash algorithms are:
 	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
 	 */
+	uint16_t saltlen;
+	/**<
+	 * RSA PSS padding salt length
+	 *
+	 * Used only when RTE_CRYPTO_RSA_PADDING_PSS padding is selected,
+	 * otherwise ignored.
+	 */
+	rte_crypto_param 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

[PATCH 30/40] cryptodev: reduce rsa struct to only necessary fields

[Arek Kusztal]

- reduced rsa struct to only necessary fields.
RSA operation is generally used with one input and one output.
One exception for this is signature verification, when RSA verify
called, both message and signature are inputs, but there is no rsa
output except for op status.

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

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index c864b8a115..37dd3b9d86 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -362,53 +362,66 @@ struct rte_crypto_rsa_op_param {
 	enum rte_crypto_asym_op_type op_type;
 	/**< Type of RSA operation for transform */
 
-	rte_crypto_param message;
+	rte_crypto_param input;
 	/**<
-	 * Pointer to input data
-	 * - to be encrypted for RSA public encrypt.
-	 * - to be signed for RSA sign generation.
-	 * - to be authenticated for RSA sign verification.
+	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
+	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
+	 * input should only be used along with cryptographically
+	 * secure padding scheme.
+	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5
+	 * input shall be no longer than public modulus minus 11.
+	 * If padding.type = RTE_CRYPTO_RSA_PADDING_OAEP
+	 * input shall be no longer than public modulus -
+	 * 2 * len(hash) - 2.
+	 * When op_type == RTE_CRYPTO_ASYM_OP_SIGN:
 	 *
-	 * Pointer to output data
-	 * - for RSA private decrypt.
-	 * In this case the underlying array should have been
-	 * allocated with enough memory to hold plaintext output
-	 * (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.
+	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
+	 * input should only be used along with cryptographically
+	 * secure padding scheme.	 *
+	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5 or
+	 * RTE_CRYPTO_RSA_PADDING_PSS
+	 * if the RTE_CRYPTO_RSA_FLAG_PT flag is set, input shall contain
+	 * the message to be signed, if this flag is not set,
+	 * input shall contain the digest of the message to be signed.
 	 *
-	 * All data is in Octet-string network byte order format.
-	 */
-
-	rte_crypto_param cipher;
-	/**<
-	 * Pointer to input data
-	 * - to be decrypted for RSA private decrypt.
+	 * When op_type == RTE_CRYPTO_ASYM_OP_DECRYPT:
 	 *
-	 * Pointer to output data
-	 * - for RSA public encrypt.
-	 * In this case the underlying array should have been allocated
-	 * with enough memory to hold ciphertext output (i.e. must be
-	 * at least RSA key size). The cipher.length field should
-	 * be 0 and will be overwritten by the PMD with the encrypted length.
+	 * Input shall contain previously encrypted RSA message.
 	 *
-	 * All data is in Octet-string network byte order format.
+	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
+	 *
+	 * Input shall contain signature to be verified
 	 */
-
-	rte_crypto_param sign;
+	union {
+		rte_crypto_param output;
+		rte_crypto_param message;
+	};
 	/**<
-	 * Pointer to input data
-	 * - to be verified for RSA public decrypt.
+	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
+	 *
+	 * Output shall contain encrypted data, output.length shall
+	 * be set to the length of encrypted data.
+	 *
+	 * When op_type == RTE_CRYPTO_ASYM_OP_DECRYPT/RTE_CRYPTO_ASYM_OP_SIGN:
 	 *
-	 * Pointer to output data
-	 * - for RSA private encrypt.
-	 * In this case the underlying array should have been allocated
-	 * 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.
+	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
+	 * output shall contain decrypted/signed data, but all leading zeros
+	 * shall be preserved. Therefore output.length should be
+	 * equal to the length of the modulus..
+	 * For other types of padding, output should contain
+	 * decrypted data, and output.length shall be set to the length
+	 * of decrypted data.
 	 *
-	 * All data is in Octet-string network byte order format.
+	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
+	 *
+	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
+	 * output shall contain the public key decrypted signature.
+	 * All leading zeroes shall be preserved.
+	 *
+	 * For other padding types, the message should be set with data for the
+	 * signature to be compared with.
 	 */
+
 	struct rte_crypto_rsa_padding padding;
 	/**< RSA padding information */
 
-- 
2.13.6

[PATCH 31/40] crypto/qat: reduce rsa struct to only necessary fields

[Arek Kusztal]

- reduced rsa struct to only necessary fields.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/qat/qat_asym.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 5dd355d007..cb2b47acbb 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -347,7 +347,7 @@ rsa_set_pub_input(struct rte_crypto_asym_op *asym_op,
 	if (asym_op->rsa.op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT) {
 		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
-			SET_PKE_LN(cookie->input_array, asym_op->rsa.message,
+			SET_PKE_LN(cookie->input_array, asym_op->rsa.input,
 					alg_bytesize, 0);
 			break;
 		default:
@@ -360,7 +360,7 @@ rsa_set_pub_input(struct rte_crypto_asym_op *asym_op,
 	} else {
 		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
-			SET_PKE_LN(cookie->input_array, asym_op->rsa.sign,
+			SET_PKE_LN(cookie->input_array, asym_op->rsa.input,
 					alg_bytesize, 0);
 			break;
 		default:
@@ -456,7 +456,7 @@ rsa_set_priv_input(struct rte_crypto_asym_op *asym_op,
 			RTE_CRYPTO_ASYM_OP_DECRYPT) {
 		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
-			SET_PKE_LN(cookie->input_array, asym_op->rsa.cipher,
+			SET_PKE_LN(cookie->input_array, asym_op->rsa.input,
 				alg_bytesize, 0);
 			HEXDUMP("RSA ciphertext", cookie->input_array[0],
 				alg_bytesize);
@@ -471,7 +471,7 @@ rsa_set_priv_input(struct rte_crypto_asym_op *asym_op,
 			RTE_CRYPTO_ASYM_OP_SIGN) {
 		switch (asym_op->rsa.padding.type) {
 		case RTE_CRYPTO_RSA_PADDING_NONE:
-			SET_PKE_LN(cookie->input_array, asym_op->rsa.message,
+			SET_PKE_LN(cookie->input_array, asym_op->rsa.input,
 				alg_bytesize, 0);
 			HEXDUMP("RSA text to be signed", cookie->input_array[0],
 				alg_bytesize);
@@ -519,7 +519,7 @@ rsa_collect(struct rte_crypto_asym_op *asym_op,
 
 		if (asym_op->rsa.op_type ==
 				RTE_CRYPTO_ASYM_OP_ENCRYPT) {
-			uint8_t *rsa_result = asym_op->rsa.cipher.data;
+			uint8_t *rsa_result = asym_op->rsa.output.data;
 
 			rte_memcpy(rsa_result,
 					cookie->output_array[0],
@@ -527,7 +527,7 @@ rsa_collect(struct rte_crypto_asym_op *asym_op,
 			HEXDUMP("RSA Encrypted data", cookie->output_array[0],
 				alg_bytesize);
 		} else {
-			uint8_t *rsa_result = asym_op->rsa.cipher.data;
+			uint8_t *rsa_result = asym_op->rsa.output.data;
 
 			switch (asym_op->rsa.padding.type) {
 			case RTE_CRYPTO_RSA_PADDING_NONE:
@@ -545,7 +545,7 @@ rsa_collect(struct rte_crypto_asym_op *asym_op,
 		}
 	} else {
 		if (asym_op->rsa.op_type == RTE_CRYPTO_ASYM_OP_DECRYPT) {
-			uint8_t *rsa_result = asym_op->rsa.message.data;
+			uint8_t *rsa_result = asym_op->rsa.output.data;
 
 			switch (asym_op->rsa.padding.type) {
 			case RTE_CRYPTO_RSA_PADDING_NONE:
@@ -561,7 +561,7 @@ rsa_collect(struct rte_crypto_asym_op *asym_op,
 				return RTE_CRYPTO_OP_STATUS_ERROR;
 			}
 		} else {
-			uint8_t *rsa_result = asym_op->rsa.sign.data;
+			uint8_t *rsa_result = asym_op->rsa.output.data;
 
 			rte_memcpy(rsa_result,
 					cookie->output_array[0],
-- 
2.13.6

[PATCH 32/40] crypto/openssl: reduce rsa struct to only necessary fields

[Arek Kusztal]

- reduced rsa struct to only necessary fields.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/openssl/rte_openssl_pmd.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index 6b3cf7a6aa..f5eb82ac2a 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1915,47 +1915,47 @@ process_openssl_rsa_op(struct rte_crypto_op *cop,
 
 	switch (op->rsa.op_type) {
 	case RTE_CRYPTO_ASYM_OP_ENCRYPT:
-		ret = RSA_public_encrypt(op->rsa.message.length,
-				op->rsa.message.data,
-				op->rsa.cipher.data,
+		ret = RSA_public_encrypt(op->rsa.input.length,
+				op->rsa.input.data,
+				op->rsa.output.data,
 				rsa,
 				pad);
 
 		if (ret > 0)
-			op->rsa.cipher.length = ret;
+			op->rsa.output.length = ret;
 		OPENSSL_LOG(DEBUG,
 				"length of encrypted text %d\n", ret);
 		break;
 
 	case RTE_CRYPTO_ASYM_OP_DECRYPT:
-		ret = RSA_private_decrypt(op->rsa.cipher.length,
-				op->rsa.cipher.data,
-				op->rsa.message.data,
+		ret = RSA_private_decrypt(op->rsa.input.length,
+				op->rsa.input.data,
+				op->rsa.output.data,
 				rsa,
 				pad);
 		if (ret > 0)
-			op->rsa.message.length = ret;
+			op->rsa.output.length = ret;
 		break;
 
 	case RTE_CRYPTO_ASYM_OP_SIGN:
-		ret = RSA_private_encrypt(op->rsa.message.length,
-				op->rsa.message.data,
-				op->rsa.sign.data,
+		ret = RSA_private_encrypt(op->rsa.input.length,
+				op->rsa.input.data,
+				op->rsa.output.data,
 				rsa,
 				pad);
 		if (ret > 0)
-			op->rsa.sign.length = ret;
+			op->rsa.output.length = ret;
 		break;
 
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
-		tmp = rte_malloc(NULL, op->rsa.sign.length, 0);
+		tmp = rte_malloc(NULL, op->rsa.input.length, 0);
 		if (tmp == NULL) {
 			OPENSSL_LOG(ERR, "Memory allocation failed");
 			cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
 			break;
 		}
-		ret = RSA_public_decrypt(op->rsa.sign.length,
-				op->rsa.sign.data,
+		ret = RSA_public_decrypt(op->rsa.input.length,
+				op->rsa.input.data,
 				tmp,
 				rsa,
 				pad);
-- 
2.13.6

[PATCH 33/40] crypto/octeontx: reduce rsa struct to only necessary fields

[Arek Kusztal]

- reduced rsa struct to only necessary fields.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/octeontx/otx_cryptodev_ops.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index 914b17decf..e2b94240e0 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -732,40 +732,40 @@ otx_cpt_asym_rsa_op(struct rte_crypto_op *cop, struct cpt_request_info *req,
 
 	switch (rsa->op_type) {
 	case RTE_CRYPTO_ASYM_OP_ENCRYPT:
-		rsa->cipher.length = rsa_ctx->n.length;
-		memcpy(rsa->cipher.data, req->rptr, rsa->cipher.length);
+		rsa->output.length = rsa_ctx->n.length;
+		memcpy(rsa->output.data, req->rptr, rsa->output.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_DECRYPT:
 		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE)
-			rsa->message.length = rsa_ctx->n.length;
+			rsa->output.length = rsa_ctx->n.length;
 		else {
 			/* Get length of decrypted output */
-			rsa->message.length = rte_cpu_to_be_16
+			rsa->output.length = rte_cpu_to_be_16
 					(*((uint16_t *)req->rptr));
 
 			/* Offset data pointer by length fields */
 			req->rptr += 2;
 		}
-		memcpy(rsa->message.data, req->rptr, rsa->message.length);
+		memcpy(rsa->output.data, req->rptr, rsa->output.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_SIGN:
-		rsa->sign.length = rsa_ctx->n.length;
-		memcpy(rsa->sign.data, req->rptr, rsa->sign.length);
+		rsa->output.length = rsa_ctx->n.length;
+		memcpy(rsa->output.data, req->rptr, rsa->output.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
 		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE)
-			rsa->sign.length = rsa_ctx->n.length;
+			rsa->output.length = rsa_ctx->n.length;
 		else {
 			/* Get length of decrypted output */
-			rsa->sign.length = rte_cpu_to_be_16
+			rsa->output.length = rte_cpu_to_be_16
 					(*((uint16_t *)req->rptr));
 
 			/* Offset data pointer by length fields */
 			req->rptr += 2;
 		}
-		memcpy(rsa->sign.data, req->rptr, rsa->sign.length);
+		memcpy(rsa->output.data, req->rptr, rsa->output.length);
 
-		if (memcmp(rsa->sign.data, rsa->message.data,
+		if (memcmp(rsa->output.data, rsa->message.data,
 			   rsa->message.length)) {
 			CPT_LOG_DP_ERR("RSA verification failed");
 			cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
-- 
2.13.6

[PATCH 34/40] crypto/cnxk: reduce rsa struct to only necessary fields

[Arek Kusztal]

- reduced rsa struct to only necessary fields.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/cnxk/cnxk_ae.h | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/crypto/cnxk/cnxk_ae.h b/drivers/crypto/cnxk/cnxk_ae.h
index 0562f72270..ea6964dd37 100644
--- a/drivers/crypto/cnxk/cnxk_ae.h
+++ b/drivers/crypto/cnxk/cnxk_ae.h
@@ -380,19 +380,19 @@ cnxk_ae_enqueue_rsa_op(struct rte_crypto_op *op,
 
 	switch (rsa->op_type) {
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
-		cnxk_ae_rsa_prep(op, meta_buf, &sess->rsa_ctx, &rsa->sign,
+		cnxk_ae_rsa_prep(op, meta_buf, &sess->rsa_ctx, &rsa->input,
 				 inst);
 		break;
 	case RTE_CRYPTO_ASYM_OP_ENCRYPT:
-		cnxk_ae_rsa_prep(op, meta_buf, &sess->rsa_ctx, &rsa->message,
+		cnxk_ae_rsa_prep(op, meta_buf, &sess->rsa_ctx, &rsa->input,
 				 inst);
 		break;
 	case RTE_CRYPTO_ASYM_OP_SIGN:
 		cnxk_ae_rsa_crt_prep(op, meta_buf, &sess->rsa_ctx,
-				     &rsa->message, inst);
+				     &rsa->input, inst);
 		break;
 	case RTE_CRYPTO_ASYM_OP_DECRYPT:
-		cnxk_ae_rsa_crt_prep(op, meta_buf, &sess->rsa_ctx, &rsa->cipher,
+		cnxk_ae_rsa_crt_prep(op, meta_buf, &sess->rsa_ctx, &rsa->input,
 				     inst);
 		break;
 	default:
@@ -671,44 +671,44 @@ cnxk_ae_dequeue_rsa_op(struct rte_crypto_op *cop, uint8_t *rptr,
 
 	switch (rsa->op_type) {
 	case RTE_CRYPTO_ASYM_OP_ENCRYPT:
-		rsa->cipher.length = rsa_ctx->n.length;
-		memcpy(rsa->cipher.data, rptr, rsa->cipher.length);
+		rsa->output.length = rsa_ctx->n.length;
+		memcpy(rsa->output.data, rptr, rsa->output.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_DECRYPT:
 		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
-			rsa->message.length = rsa_ctx->n.length;
-			memcpy(rsa->message.data, rptr, rsa->message.length);
+			rsa->output.length = rsa_ctx->n.length;
+			memcpy(rsa->output.data, rptr, rsa->output.length);
 		} else {
 			/* Get length of decrypted output */
-			rsa->message.length =
+			rsa->output.length =
 				rte_cpu_to_be_16(*((uint16_t *)rptr));
 			/*
 			 * Offset output data pointer by length field
 			 * (2 bytes) and copy decrypted data.
 			 */
-			memcpy(rsa->message.data, rptr + 2,
-			       rsa->message.length);
+			memcpy(rsa->output.data, rptr + 2,
+			       rsa->output.length);
 		}
 		break;
 	case RTE_CRYPTO_ASYM_OP_SIGN:
-		rsa->sign.length = rsa_ctx->n.length;
-		memcpy(rsa->sign.data, rptr, rsa->sign.length);
+		rsa->input.length = rsa_ctx->n.length;
+		memcpy(rsa->output.data, rptr, rsa->output.length);
 		break;
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
 		if (rsa->padding.type == RTE_CRYPTO_RSA_PADDING_NONE) {
-			rsa->sign.length = rsa_ctx->n.length;
-			memcpy(rsa->sign.data, rptr, rsa->sign.length);
+			rsa->output.length = rsa_ctx->n.length;
+			memcpy(rsa->output.data, rptr, rsa->output.length);
 		} else {
 			/* Get length of signed output */
-			rsa->sign.length =
+			rsa->output.length =
 				rte_cpu_to_be_16(*((uint16_t *)rptr));
 			/*
 			 * Offset output data pointer by length field
 			 * (2 bytes) and copy signed data.
 			 */
-			memcpy(rsa->sign.data, rptr + 2, rsa->sign.length);
+			memcpy(rsa->output.data, rptr + 2, rsa->output.length);
 		}
-		if (memcmp(rsa->sign.data, rsa->message.data,
+		if (memcmp(rsa->output.data, rsa->message.data,
 			   rsa->message.length)) {
 			cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
 		}
-- 
2.13.6

[PATCH 35/40] common/cpt: reduce rsa struct to only necessary fields

[Arek Kusztal]

- reduced rsa struct to only necessary fields.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/common/cpt/cpt_ucode_asym.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/common/cpt/cpt_ucode_asym.h b/drivers/common/cpt/cpt_ucode_asym.h
index 1105a0c125..dafae61f6f 100644
--- a/drivers/common/cpt/cpt_ucode_asym.h
+++ b/drivers/common/cpt/cpt_ucode_asym.h
@@ -463,16 +463,16 @@ cpt_enqueue_rsa_op(struct rte_crypto_op *op,
 
 	switch (rsa->op_type) {
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
-		cpt_rsa_prep(params, &sess->rsa_ctx, &rsa->sign);
+		cpt_rsa_prep(params, &sess->rsa_ctx, &rsa->input);
 		break;
 	case RTE_CRYPTO_ASYM_OP_ENCRYPT:
-		cpt_rsa_prep(params, &sess->rsa_ctx, &rsa->message);
+		cpt_rsa_prep(params, &sess->rsa_ctx, &rsa->input);
 		break;
 	case RTE_CRYPTO_ASYM_OP_SIGN:
-		cpt_rsa_crt_prep(params, &sess->rsa_ctx, &rsa->message);
+		cpt_rsa_crt_prep(params, &sess->rsa_ctx, &rsa->input);
 		break;
 	case RTE_CRYPTO_ASYM_OP_DECRYPT:
-		cpt_rsa_crt_prep(params, &sess->rsa_ctx, &rsa->cipher);
+		cpt_rsa_crt_prep(params, &sess->rsa_ctx, &rsa->input);
 		break;
 	default:
 		op->status = RTE_CRYPTO_OP_STATUS_INVALID_ARGS;
-- 
2.13.6

[PATCH 36/40] test/crypto: reduce rsa struct to only necessary fields

[Arek Kusztal]

- reduced rsa struct to only necessary fields.
This commit reflects changes to the asymmetric crypto API.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c | 80 +++++++++++++++++++++++-------------------
 1 file changed, 43 insertions(+), 37 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index eca0612815..ed86eaf8ba 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -90,14 +90,14 @@ queue_ops_rsa_sign_verify(void *sess)
 	/* Compute sign on the test vector */
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_SIGN;
 
-	asym_op->rsa.message.data = rsaplaintext.data;
-	asym_op->rsa.message.length = rsaplaintext.len;
-	asym_op->rsa.sign.length = 0;
-	asym_op->rsa.sign.data = output_buf;
+	asym_op->rsa.input.data = rsaplaintext.data;
+	asym_op->rsa.input.length = rsaplaintext.len;
+	asym_op->rsa.output.length = 0;
+	asym_op->rsa.output.data = output_buf;
 	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);
+	debug_hexdump(stdout, "message", asym_op->rsa.input.data,
+		      asym_op->rsa.input.length);
 
 	/* Attach asymmetric crypto session to crypto operations */
 	rte_crypto_op_attach_asym_session(op, sess);
@@ -120,13 +120,17 @@ queue_ops_rsa_sign_verify(void *sess)
 		goto error_exit;
 	}
 
-	debug_hexdump(stdout, "signed message", asym_op->rsa.sign.data,
-		      asym_op->rsa.sign.length);
+	debug_hexdump(stdout, "signed message", asym_op->rsa.output.data,
+		      asym_op->rsa.output.length);
 	asym_op = result_op->asym;
 
 	/* Verify sign */
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_VERIFY;
 	asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+	asym_op->rsa.input.data = output_buf;
+	asym_op->rsa.input.length = asym_op->rsa.output.length;
+	asym_op->rsa.message.data = rsaplaintext.data;
+	asym_op->rsa.message.length = rsaplaintext.len;
 
 	/* Process crypto operation */
 	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -181,14 +185,14 @@ queue_ops_rsa_enc_dec(void *sess)
 	/* Compute encryption on the test vector */
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_ENCRYPT;
 
-	asym_op->rsa.message.data = rsaplaintext.data;
-	asym_op->rsa.cipher.data = cipher_buf;
-	asym_op->rsa.cipher.length = 0;
-	asym_op->rsa.message.length = rsaplaintext.len;
+	asym_op->rsa.input.data = rsaplaintext.data;
+	asym_op->rsa.output.data = cipher_buf;
+	asym_op->rsa.output.length = 0;
+	asym_op->rsa.input.length = rsaplaintext.len;
 	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);
+	debug_hexdump(stdout, "message", asym_op->rsa.input.data,
+		      asym_op->rsa.input.length);
 
 	/* Attach asymmetric crypto session to crypto operations */
 	rte_crypto_op_attach_asym_session(op, sess);
@@ -210,14 +214,16 @@ queue_ops_rsa_enc_dec(void *sess)
 		status = TEST_FAILED;
 		goto error_exit;
 	}
-	debug_hexdump(stdout, "encrypted message", asym_op->rsa.message.data,
-		      asym_op->rsa.message.length);
+	debug_hexdump(stdout, "encrypted message", asym_op->rsa.output.data,
+		      asym_op->rsa.output.length);
 
 	/* Use the resulted output as decryption Input vector*/
 	asym_op = result_op->asym;
-	asym_op->rsa.message.length = 0;
+	asym_op->rsa.output.length = 0;
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_DECRYPT;
 	asym_op->rsa.padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5;
+	rte_memcpy(asym_op->rsa.input.data, asym_op->rsa.output.data,
+		asym_op->rsa.input.length);
 
 	/* Process crypto operation */
 	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -270,20 +276,20 @@ test_cryptodev_asym_ver(struct rte_crypto_op *op,
 	case RTE_CRYPTO_ASYM_XFORM_RSA:
 		if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT) {
 			data_size = xform_tc->rsa.n.length;
-			data_received = result_op->asym->rsa.cipher.data;
+			data_received = result_op->asym->rsa.output.data;
 			data_expected = data_tc->rsa_data.ct.data;
 		} else if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_DECRYPT) {
 			data_size = xform_tc->rsa.n.length;
 			data_expected = data_tc->rsa_data.pt.data;
-			data_received = result_op->asym->rsa.message.data;
+			data_received = result_op->asym->rsa.output.data;
 		} else if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_SIGN) {
 			data_size = xform_tc->rsa.n.length;
 			data_expected = data_tc->rsa_data.sign.data;
-			data_received = result_op->asym->rsa.sign.data;
+			data_received = result_op->asym->rsa.output.data;
 		} else if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_VERIFY) {
 			data_size = xform_tc->rsa.n.length;
 			data_expected = data_tc->rsa_data.pt.data;
-			data_received = result_op->asym->rsa.cipher.data;
+			data_received = result_op->asym->rsa.output.data;
 		}
 		break;
 	case RTE_CRYPTO_ASYM_XFORM_DH:
@@ -415,25 +421,25 @@ test_cryptodev_asym_op(struct crypto_testsuite_params_asym *ts_params,
 		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;
-			asym_op->rsa.message.length = data_tc->rsa_data.pt.len;
-			asym_op->rsa.cipher.data = result;
-			asym_op->rsa.cipher.length = data_tc->rsa_data.n.len;
+			asym_op->rsa.input.data = data_tc->rsa_data.pt.data;
+			asym_op->rsa.input.length = data_tc->rsa_data.pt.len;
+			asym_op->rsa.output.data = result;
+			asym_op->rsa.output.length = data_tc->rsa_data.n.len;
 		} else if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_DECRYPT) {
-			asym_op->rsa.message.data = result;
-			asym_op->rsa.message.length = data_tc->rsa_data.n.len;
-			asym_op->rsa.cipher.data = data_tc->rsa_data.ct.data;
-			asym_op->rsa.cipher.length = data_tc->rsa_data.ct.len;
+			asym_op->rsa.output.data = result;
+			asym_op->rsa.output.length = data_tc->rsa_data.n.len;
+			asym_op->rsa.input.data = data_tc->rsa_data.ct.data;
+			asym_op->rsa.input.length = data_tc->rsa_data.ct.len;
 		} else if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_SIGN) {
-			asym_op->rsa.sign.data = result;
-			asym_op->rsa.sign.length = data_tc->rsa_data.n.len;
-			asym_op->rsa.message.data = data_tc->rsa_data.pt.data;
-			asym_op->rsa.message.length = data_tc->rsa_data.pt.len;
+			asym_op->rsa.output.data = result;
+			asym_op->rsa.output.length = data_tc->rsa_data.n.len;
+			asym_op->rsa.input.data = data_tc->rsa_data.pt.data;
+			asym_op->rsa.input.length = data_tc->rsa_data.pt.len;
 		} else if (op->asym->rsa.op_type == RTE_CRYPTO_ASYM_OP_VERIFY) {
-			asym_op->rsa.cipher.data = result;
-			asym_op->rsa.cipher.length = data_tc->rsa_data.n.len;
-			asym_op->rsa.sign.data = data_tc->rsa_data.sign.data;
-			asym_op->rsa.sign.length = data_tc->rsa_data.sign.len;
+			asym_op->rsa.message.data = result;
+			asym_op->rsa.message.length = data_tc->rsa_data.n.len;
+			asym_op->rsa.input.data = data_tc->rsa_data.sign.data;
+			asym_op->rsa.input.length = data_tc->rsa_data.sign.len;
 		}
 		break;
 	case RTE_CRYPTO_ASYM_XFORM_DH:
-- 
2.13.6

[PATCH 37/40] 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 | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 37dd3b9d86..01b1fdd074 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -41,6 +41,26 @@ rte_crypto_asym_ke_strings[];
 extern const char *
 rte_crypto_asym_op_strings[];
 
+#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_NO_PADDING		0
+/**<
+ * If set to 1 - public key will be returned
+ * without leading zero bytes, otherwise it will be
+ * padded to the left with zero bytes (default)
+ */
+#define RTE_CRYPTO_ASYM_FLAG_SHARED_KEY_NO_PADDING	1
+/**<
+ * If set to 1 - shared key will be returned
+ * without leading zero bytes, otherwise it will be
+ * padded to the left with zero bytes (default)
+ */
+
+#define RTE_CRYPTO_ASYM_FLAG_SET(op, flag) \
+	(op->flags |= (1ULL << flag))
+#define RTE_CRYPTO_ASYM_FLAG_UNSET(op, flag) \
+	(op->flags &= (~(1ULL << flag)))
+#define RTE_CRYPTO_ASYM_FLAG_GET(op, flag) \
+	(!!(op->flags &= (1ULL << flag)))
+
 /**
  * List of elliptic curves. This enum aligns with
  * TLS "Supported Groups" registry (previously known  as
@@ -607,6 +627,11 @@ struct rte_crypto_asym_op {
 		struct rte_crypto_ecdsa_op_param ecdsa;
 		struct rte_crypto_ecpm_op_param ecpm;
 	};
+	uint16_t flags;
+	/**< Asymmetric crypto flags, every flag starts with
+	 * RTE_CRYPTO_ASYM_FLAG_*. Flags are set/unset with
+	 * RTE_CRYPTO_ASYM_SET_FLAGS, RTE_CRYPTO_ASYM_GET_FLAGS
+	 */
 };
 
 #ifdef __cplusplus
-- 
2.13.6

[PATCH 38/40] 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 | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 01b1fdd074..a6bb70ca3f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -459,6 +459,10 @@ struct rte_crypto_dh_op_param {
 	 * Output generated private key when op_type is
 	 * DH PRIVATE_KEY_GENERATION
 	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
+	 * In case priv_key.length is 0 and op_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.
 	 */
 	union {
 		rte_crypto_uint pub_key;
-- 
2.13.6

[PATCH 39/40] crypto/openssl: generate dh private key

[Arek Kusztal]

- added dh private key generation based on length.
PMD will generate private key only if priv_key length is
set to 0.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 drivers/crypto/openssl/rte_openssl_pmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index f5eb82ac2a..1300bc3d82 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1754,7 +1754,7 @@ process_openssl_dh_op(struct rte_crypto_op *cop,
 	 * then first set DH with user provided private key
 	 */
 	if (asym_op->dh.op_type == RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE &&
-			op->priv_key.data) {
+			op->priv_key.length > 0) {
 		/* generate public key using user-provided private key
 		 * pub_key = g ^ priv_key mod p
 		 */
-- 
2.13.6

[PATCH 40/40] test/crypto: added test for dh priv key generation

[Arek Kusztal]

- re-added test for dh private gey generation.
This time zero length of priv key determines if key is
generated.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c | 90 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index ed86eaf8ba..3a562eb443 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -1290,6 +1290,90 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)
 }
 
 static int
+test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)
+{
+	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
+	struct rte_mempool *op_mpool = ts_params->op_mpool;
+	struct rte_mempool *sess_mpool = ts_params->session_mpool;
+	uint8_t dev_id = ts_params->valid_devs[0];
+	struct rte_crypto_asym_op *asym_op = NULL;
+	struct rte_crypto_op *op = NULL, *result_op = NULL;
+	void *sess = NULL;
+	int ret, status = TEST_SUCCESS;
+	uint8_t out_pub_key[TEST_DH_MOD_LEN];
+	uint8_t out_prv_key[TEST_DH_MOD_LEN];
+	struct rte_crypto_asym_xform xform = *xfrm;
+
+	/* set up crypto op data structure */
+	op = rte_crypto_op_alloc(op_mpool, RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
+	if (!op) {
+		RTE_LOG(ERR, USER1,
+			"line %u FAILED: %s",
+			__LINE__, "Failed to allocate asymmetric crypto "
+			"operation struct");
+		status = TEST_FAILED;
+		goto error_exit;
+	}
+	asym_op = op->asym;
+	/* Setup a xform chain to generate
+	 * private key first followed by
+	 * public key
+	 */
+
+	asym_op->dh.op_type = RTE_CRYPTO_ASYM_KE_PUBLIC_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 = 0;
+
+	ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool, &sess);
+	if (ret < 0) {
+		RTE_LOG(ERR, USER1,
+				"line %u FAILED: %s", __LINE__,
+				"Session creation failed");
+		status = (ret == -ENOTSUP) ? TEST_SKIPPED : TEST_FAILED;
+		goto error_exit;
+	}
+
+	/* attach asymmetric crypto session to crypto operations */
+	rte_crypto_op_attach_asym_session(op, sess);
+
+	RTE_LOG(DEBUG, USER1, "Process ASYM operation");
+
+	/* Process crypto operation */
+	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
+		RTE_LOG(ERR, USER1,
+			"line %u FAILED: %s",
+			__LINE__, "Error sending packet for operation");
+		status = TEST_FAILED;
+		goto error_exit;
+	}
+
+	while (rte_cryptodev_dequeue_burst(dev_id, 0, &result_op, 1) == 0)
+		rte_pause();
+
+	if (result_op == NULL) {
+		RTE_LOG(ERR, USER1,
+			"line %u FAILED: %s",
+			__LINE__, "Failed to process asym crypto op");
+		status = TEST_FAILED;
+		goto error_exit;
+	}
+	debug_hexdump(stdout, "priv key:",
+			out_prv_key, asym_op->dh.priv_key.length);
+	debug_hexdump(stdout, "pub key:",
+			out_pub_key, asym_op->dh.pub_key.length);
+
+error_exit:
+	if (sess != NULL)
+		rte_cryptodev_asym_session_free(dev_id, sess);
+	if (op != NULL)
+		rte_crypto_op_free(op);
+
+	return status;
+}
+
+static int
 test_mod_inv(void)
 {
 	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
@@ -1525,6 +1609,12 @@ test_dh_keygenration(void)
 			dh_test_params.priv_key.length);
 
 	RTE_LOG(INFO, USER1,
+		"Test Public and Private key pair generation\n");
+
+	status = test_dh_gen_kp(&dh_xform);
+	TEST_ASSERT_EQUAL(status, 0, "Test failed");
+
+	RTE_LOG(INFO, USER1,
 		"Test Public Key Generation using pre-defined priv key\n");
 
 	status = test_dh_gen_pub_key(&dh_xform);
-- 
2.13.6

RE: [EXT] [PATCH 09/40] cryptodev: remove unnecessary zero assignement

[Akhil Goyal]

> - removed unnecessary zero assignement in rsa padding enum.
> Even it is set correctly it should be made consistent with
> other enums in cryptodev. Therefore assignement to zero was
> removed.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 0fc9f49b87..270619acf2 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -116,11 +116,12 @@ enum rte_crypto_asym_ke_type {
>   * Padding types for RSA signature.
>   */
>  enum rte_crypto_rsa_padding_type {
> -	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> +	RTE_CRYPTO_RSA_PADDING_NONE,
>  	/**< RSA no padding scheme */
>  	RTE_CRYPTO_RSA_PADDING_PKCS1_5,
> -	/**< RSA PKCS#1 PKCS1-v1_5 padding scheme. For signatures block type
> 01,
> -	 * for encryption block type 02 are used.
> +	/**< RSA PKCS#1 PKCS1-v1_5 padding scheme.
> +	 * For signatures block type 01, for encryption
> +	 * block type 02 are used.

This change is not required or make it a separate patch.

>  	 */
>  	RTE_CRYPTO_RSA_PADDING_OAEP,
>  	/**< RSA PKCS#1 OAEP padding scheme */
> --
> 2.13.6

RE: [EXT] [PATCH 08/40] test/crypto: separate key exchange operation enum

[Akhil Goyal]

> - Key exchange is now separate enum.
> This commit reflects changes to the asymmetric crypto API
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---

Individual patches must compile.
There are multiple patches which needs to be combined.
6,7,8 should be a single patch or else compilation will be broken

2,3 should also be combined.


>  app/test/test_cryptodev_asym.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
> index 62d710b0a0..0098b6bf65 100644
> --- a/app/test/test_cryptodev_asym.c
> +++ b/app/test/test_cryptodev_asym.c
> @@ -530,7 +530,7 @@ test_one_case(const void *test_case, int sessionless)
>  		printf("  %u) TestCase %s %s\n", test_index++,
>  			tc.modex.description, test_msg);
>  	} else {
> -		for (i = 0; i <=
> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
> +		for (i = 0; i <=
> RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE; i++) {
>  			if (tc.modex.xform_type ==
> RTE_CRYPTO_ASYM_XFORM_RSA) {
>  				if (tc.rsa_data.op_type_flags & (1 << i)) {
>  					if (tc.rsa_data.key_exp) {
> @@ -972,7 +972,7 @@ static inline void print_asym_capa(
>  			rte_crypto_asym_xform_strings[capa->xform_type]);
>  	printf("operation supported -");
> 
> -	for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE;
> i++) {
> +	for (i = 0; i <= RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE; i++)
> {
>  		/* check supported operations */
>  		if (rte_cryptodev_asym_xform_capability_check_optype(capa,
> i))
>  			printf(" %s",
> @@ -1062,7 +1062,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.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;
> @@ -1144,7 +1144,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.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
>  	xform.next = NULL;
>  	asym_op->dh.priv_key.data = output;
>  	asym_op->dh.priv_key.length = sizeof(output);
> @@ -1227,7 +1227,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.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
>  	xform.next = NULL;
> 
>  	asym_op->dh.pub_key.data = output;
> @@ -1317,9 +1317,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.type = RTE_CRYPTO_ASYM_KE_PRIVATE_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.type =
> RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
>  	xform.next = &pub_key_xform;
> 
>  	asym_op->dh.pub_key.data = out_pub_key;
> --
> 2.13.6

RE: [EXT] [PATCH 02/40] cryptodev: remove list end enumerators

[Akhil Goyal]

> - Removed LIST_END enumerators from asymmetric crypto API.
> Adding new enum entries would require moving
> LIST_END down, therefore changing its assigned number.
> This would cause problems to ABI stability, so these
> enums were removed.
> 
> Cc: mdr@ashroe.eu
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---

There was already a patch in patchworks but it need rework.
Can you look at this and address the comments 
http://patches.dpdk.org/project/dpdk/patch/20211008204516.3497060-1-gakhil@marvell.com/


>  devtools/libabigail.abignore    |  2 ++
>  lib/cryptodev/rte_crypto_asym.h | 10 +++-------
>  2 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> index 79ff15dc4e..f1945ce3b7 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -27,6 +27,8 @@
>  ; Ignore changes to rte_crypto_asym_op, asymmetric crypto API is
> experimental
>  [suppress_type]
>          name = rte_crypto_asym_op
> +[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 7206652458..a474b6acd1 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -95,10 +95,8 @@ enum rte_crypto_asym_xform_type {
>  	/**< Elliptic Curve Digital Signature Algorithm
>  	 * Perform Signature Generation and Verification.
>  	 */
> -	RTE_CRYPTO_ASYM_XFORM_ECPM,
> +	RTE_CRYPTO_ASYM_XFORM_ECPM
>  	/**< Elliptic Curve Point Multiplication */
> -	RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> -	/**< End of list */
>  };
> 
>  /**
> @@ -117,9 +115,8 @@ enum rte_crypto_asym_op_type {
>  	/**< DH Private Key generation operation */
>  	RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
>  	/**< DH Public Key generation operation */
> -	RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> +	RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE
>  	/**< DH Shared Secret compute operation */
> -	RTE_CRYPTO_ASYM_OP_LIST_END
>  };
> 
>  /**
> @@ -134,9 +131,8 @@ enum rte_crypto_rsa_padding_type {
>  	 */
>  	RTE_CRYPTO_RSA_PADDING_OAEP,
>  	/**< RSA PKCS#1 OAEP padding scheme */
> -	RTE_CRYPTO_RSA_PADDING_PSS,
> +	RTE_CRYPTO_RSA_PADDING_PSS
>  	/**< RSA PKCS#1 PSS padding scheme */
> -	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
>  };
> 
>  /**
> --
> 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Akhil Goyal]

> - removed asymnetric crypto xform next field.
> Rationale behind having chaining in symmetric crypto
> was a fact that encryption and authentication are usually
> done on the same set of data independent of algorithm.
> HW usually will be able to handle it in one PCI call.
> In asymmetric there is no such relation between algorithms,
> therefore next field would be useless.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---

Squash 12,13,14 patches or else compilation will be broken

>  lib/cryptodev/rte_crypto_asym.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 1652a434a5..b355cbe5fa 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
>   * Structure describing asym xforms.
>   */
>  struct rte_crypto_asym_xform {
> -	struct rte_crypto_asym_xform *next;
> -	/**< Pointer to next xform to set up xform chain.*/
>  	enum rte_crypto_asym_xform_type xform_type;
>  	/**< Asymmetric crypto transform */
> 
> --
> 2.13.6

RE: [EXT] [PATCH 13/40] test/crypto: remove asym crypto next xform

[Akhil Goyal]

> - removed asymnetric crypto xform next field.
> This commit reflects changes to the asymmetric crypto API.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  app/test/test_cryptodev_asym.c             | 100 -----------------------------
>  app/test/test_cryptodev_dh_test_vectors.h  |   1 -
>  app/test/test_cryptodev_dsa_test_vectors.h |   1 -
>  app/test/test_cryptodev_mod_test_vectors.h |   2 -
>  app/test/test_cryptodev_rsa_test_vectors.h |   2 -
>  app/test/test_event_crypto_adapter.c       |   4 --
>  6 files changed, 110 deletions(-)
> 
> diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
> index 0098b6bf65..9e5d5e4f27 100644
> --- a/app/test/test_cryptodev_asym.c
> +++ b/app/test/test_cryptodev_asym.c
> @@ -318,7 +318,6 @@ test_cryptodev_asym_op(struct
> crypto_testsuite_params_asym *ts_params,
> 
>  	int ret, status = TEST_SUCCESS;
> 
> -	xform_tc.next = NULL;
>  	xform_tc.xform_type = data_tc->modex.xform_type;
> 
>  	cap_idx.type = xform_tc.xform_type;
> @@ -1063,7 +1062,6 @@ test_dh_gen_shared_sec(struct
> rte_crypto_asym_xform *xfrm)
> 
>  	/* Setup a xform and op to generate private key only */
>  	xform.dh.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;
>  	asym_op->dh.pub_key.data = (uint8_t *)peer;
> @@ -1145,7 +1143,6 @@ test_dh_gen_priv_key(struct rte_crypto_asym_xform
> *xfrm)
> 
>  	/* Setup a xform and op to generate private key only */
>  	xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
> -	xform.next = NULL;
>  	asym_op->dh.priv_key.data = output;
>  	asym_op->dh.priv_key.length = sizeof(output);
> 
> @@ -1228,7 +1225,6 @@ test_dh_gen_pub_key(struct rte_crypto_asym_xform
> *xfrm)
>  	 *
>  	 */
>  	xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
> -	xform.next = NULL;
> 
>  	asym_op->dh.pub_key.data = output;
>  	asym_op->dh.pub_key.length = sizeof(output);
> @@ -1288,94 +1284,6 @@ test_dh_gen_pub_key(struct
> rte_crypto_asym_xform *xfrm)
>  }
> 
>  static int
> -test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)


Why is this function removed?

> -{
> -	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
> -	struct rte_mempool *op_mpool = ts_params->op_mpool;
> -	struct rte_mempool *sess_mpool = ts_params->session_mpool;
> -	uint8_t dev_id = ts_params->valid_devs[0];
> -	struct rte_crypto_asym_op *asym_op = NULL;
> -	struct rte_crypto_op *op = NULL, *result_op = NULL;
> -	void *sess = NULL;
> -	int ret, status = TEST_SUCCESS;
> -	uint8_t out_pub_key[TEST_DH_MOD_LEN];
> -	uint8_t out_prv_key[TEST_DH_MOD_LEN];
> -	struct rte_crypto_asym_xform pub_key_xform;
> -	struct rte_crypto_asym_xform xform = *xfrm;
> -
> -	/* set up crypto op data structure */
> -	op = rte_crypto_op_alloc(op_mpool,
> RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
> -	if (!op) {
> -		RTE_LOG(ERR, USER1,
> -			"line %u FAILED: %s",
> -			__LINE__, "Failed to allocate asymmetric crypto "
> -			"operation struct");
> -		status = TEST_FAILED;
> -		goto error_exit;
> -	}
> -	asym_op = op->asym;
> -	/* Setup a xform chain to generate
> -	 * private key first followed by
> -	 * public key
> -	 */
> -	xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
> -	pub_key_xform.xform_type = RTE_CRYPTO_ASYM_XFORM_DH;
> -	pub_key_xform.dh.type =
> RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
> -	xform.next = &pub_key_xform;
> -
> -	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);
> -
> -	ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool,
> &sess);
> -	if (ret < 0) {
> -		RTE_LOG(ERR, USER1,
> -				"line %u FAILED: %s", __LINE__,
> -				"Session creation failed");
> -		status = (ret == -ENOTSUP) ? TEST_SKIPPED : TEST_FAILED;
> -		goto error_exit;
> -	}
> -
> -	/* attach asymmetric crypto session to crypto operations */
> -	rte_crypto_op_attach_asym_session(op, sess);
> -
> -	RTE_LOG(DEBUG, USER1, "Process ASYM operation");
> -
> -	/* Process crypto operation */
> -	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
> -		RTE_LOG(ERR, USER1,
> -			"line %u FAILED: %s",
> -			__LINE__, "Error sending packet for operation");
> -		status = TEST_FAILED;
> -		goto error_exit;
> -	}
> -
> -	while (rte_cryptodev_dequeue_burst(dev_id, 0, &result_op, 1) == 0)
> -		rte_pause();
> -
> -	if (result_op == NULL) {
> -		RTE_LOG(ERR, USER1,
> -			"line %u FAILED: %s",
> -			__LINE__, "Failed to process asym crypto op");
> -		status = TEST_FAILED;
> -		goto error_exit;
> -	}
> -	debug_hexdump(stdout, "priv key:",
> -			out_prv_key, asym_op->dh.priv_key.length);
> -	debug_hexdump(stdout, "pub key:",
> -			out_pub_key, asym_op->dh.pub_key.length);
> -
> -error_exit:
> -	if (sess != NULL)
> -		rte_cryptodev_asym_session_free(dev_id, sess);
> -	if (op != NULL)
> -		rte_crypto_op_free(op);
> -
> -	return status;
> -}
> -
> -static int
>  test_mod_inv(void)
>  {
>  	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
> @@ -1611,12 +1519,6 @@ test_dh_keygenration(void)
>  			dh_test_params.priv_key.length);
> 
>  	RTE_LOG(INFO, USER1,
> -		"Test Public and Private key pair generation\n");
> -
> -	status = test_dh_gen_kp(&dh_xform);
> -	TEST_ASSERT_EQUAL(status, 0, "Test failed");
> -
> -	RTE_LOG(INFO, USER1,
>  		"Test Public Key Generation using pre-defined priv key\n");
> 
>  	status = test_dh_gen_pub_key(&dh_xform);
> @@ -1828,7 +1730,6 @@ test_ecdsa_sign_verify(enum curve curve_id)
>  	asym_op = op->asym;
> 
>  	/* Setup asym xform */
> -	xform.next = NULL;
>  	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECDSA;
>  	xform.ec.curve_id = input_params.curve;
> 
> @@ -2030,7 +1931,6 @@ test_ecpm(enum curve curve_id)
>  	asym_op = op->asym;
> 
>  	/* Setup asym xform */
> -	xform.next = NULL;
>  	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECPM;
>  	xform.ec.curve_id = input_params.curve;
> 
> diff --git a/app/test/test_cryptodev_dh_test_vectors.h
> b/app/test/test_cryptodev_dh_test_vectors.h
> index fe7510dcd3..078719072d 100644
> --- a/app/test/test_cryptodev_dh_test_vectors.h
> +++ b/app/test/test_cryptodev_dh_test_vectors.h
> @@ -63,7 +63,6 @@ struct dh_test_param dh_test_params = {
>  };
> 
>  struct rte_crypto_asym_xform dh_xform = {
> -	.next = NULL,
>  	.xform_type = RTE_CRYPTO_ASYM_XFORM_DH,
>  	.dh = {
>  		.p = {
> diff --git a/app/test/test_cryptodev_dsa_test_vectors.h
> b/app/test/test_cryptodev_dsa_test_vectors.h
> index bbcb0d7297..cc60f50b5c 100644
> --- a/app/test/test_cryptodev_dsa_test_vectors.h
> +++ b/app/test/test_cryptodev_dsa_test_vectors.h
> @@ -91,7 +91,6 @@ struct dsa_test_param dsa_test_params = {
>  };
> 
>  struct rte_crypto_asym_xform dsa_xform = {
> -	.next = NULL,
>  	.xform_type = RTE_CRYPTO_ASYM_XFORM_DSA,
>  	.dsa = {
>  		.p = {
> diff --git a/app/test/test_cryptodev_mod_test_vectors.h
> b/app/test/test_cryptodev_mod_test_vectors.h
> index 807ca7a47e..bcd4d5248b 100644
> --- a/app/test/test_cryptodev_mod_test_vectors.h
> +++ b/app/test/test_cryptodev_mod_test_vectors.h
> @@ -1045,7 +1045,6 @@ uint8_t mod_inv[] = {
> 
>  /* MODEX vector. 8< */
>  struct rte_crypto_asym_xform modex_xform = {
> -	.next = NULL,
>  	.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
>  	.modex = {
>  		.modulus = {
> @@ -1061,7 +1060,6 @@ struct rte_crypto_asym_xform modex_xform = {
>  /* >8 End of MODEX vector. */
> 
>  struct rte_crypto_asym_xform modinv_xform = {
> -	.next = NULL,
>  	.xform_type = RTE_CRYPTO_ASYM_XFORM_MODINV,
>  	.modinv = {
>  		.modulus = {
> diff --git a/app/test/test_cryptodev_rsa_test_vectors.h
> b/app/test/test_cryptodev_rsa_test_vectors.h
> index 04539a1ecf..e769dec1f4 100644
> --- a/app/test/test_cryptodev_rsa_test_vectors.h
> +++ b/app/test/test_cryptodev_rsa_test_vectors.h
> @@ -346,7 +346,6 @@ uint8_t rsa_qInv[] = {
> 
>  /** rsa xform using exponent key */
>  struct rte_crypto_asym_xform rsa_xform = {
> -	.next = NULL,
>  	.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA,
>  	.rsa = {
>  		.n = {
> @@ -367,7 +366,6 @@ struct rte_crypto_asym_xform rsa_xform = {
> 
>  /** rsa xform using quintuple key */
>  struct rte_crypto_asym_xform rsa_xform_crt = {
> -	.next = NULL,
>  	.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA,
>  	.rsa = {
>  		.n = {
> diff --git a/app/test/test_event_crypto_adapter.c
> b/app/test/test_event_crypto_adapter.c
> index 2ecc7e2cea..feb1d86c00 100644
> --- a/app/test/test_event_crypto_adapter.c
> +++ b/app/test/test_event_crypto_adapter.c
> @@ -295,7 +295,6 @@ test_op_forward_mode(uint8_t session_less)
>  #endif
>  	/* Setup Cipher Parameters */
>  	cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
> -	cipher_xform.next = NULL;
>  	cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
>  	cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
> 
> @@ -474,7 +473,6 @@ test_asym_op_forward_mode(uint8_t session_less)
>  		return TEST_SKIPPED;
>  	}
>  	/* Setup Cipher Parameters */
> -	xform_tc.next = NULL;
>  	xform_tc.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
>  	cap_idx.type = xform_tc.xform_type;
>  	capability = rte_cryptodev_asym_capability_get(TEST_CDEV_ID,
> &cap_idx);
> @@ -672,7 +670,6 @@ test_op_new_mode(uint8_t session_less)
>  #endif
>  	/* Setup Cipher Parameters */
>  	cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
> -	cipher_xform.next = NULL;
>  	cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
>  	cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
> 
> @@ -807,7 +804,6 @@ test_asym_op_new_mode(uint8_t session_less)
>  		return TEST_SKIPPED;
>  	}
>  	/* Setup Cipher Parameters */
> -	xform_tc.next = NULL;
>  	xform_tc.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
>  	cap_idx.type = xform_tc.xform_type;
>  	capability = rte_cryptodev_asym_capability_get(TEST_CDEV_ID,
> &cap_idx);
> --
> 2.13.6

RE: [EXT] [PATCH 15/40] app/test-eventdev: remove asym crypto next xform

[Akhil Goyal]

> - removed asymmetric crypto xform next field.
> This commit reflects changes to the asymmetric crypto API.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---

Squash in main commit.

>  app/test-eventdev/test_perf_common.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/app/test-eventdev/test_perf_common.c b/app/test-
> eventdev/test_perf_common.c
> index f2da6fd74c..78150533a9 100644
> --- a/app/test-eventdev/test_perf_common.c
> +++ b/app/test-eventdev/test_perf_common.c
> @@ -851,7 +851,6 @@ cryptodev_asym_sess_create(struct prod_data *p,
> struct test_perf *t)
>  	struct rte_crypto_asym_xform xform;
>  	void *sess;
> 
> -	xform.next = NULL;
>  	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
>  	cap_idx.type = xform.xform_type;
>  	capability = rte_cryptodev_asym_capability_get(p->ca.cdev_id,
> &cap_idx);
> --
> 2.13.6

RE: [EXT] [PATCH 00/40] 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
> - Removes LIST_END enumerators (ABI issue - supressed asym_xform)
> - Adds Eliiptic-Curve point verification (DH verification - but will be used only for
> EC)
> - Adds RSA missing padding fields.
> - Adds asym op flags
> - Fixes many API comments (like EC curves)
> 
> Commits are grouped by functionality, and mostly independent.

Please ensure all commits compile individually.
Also mark previous versions in patchworks as superseded.

> 
> Arek Kusztal (40):
>   cryptodev: redefine ec group enum
>   cryptodev: remove list end enumerators
>   test/crypto: remove list end enumerators
>   cryptodev: reduce number of comments in asym xform
>   test/crypto: removed asym xform none
>   cryptodev: separate key exchange operation enum
>   crypto/openssl: separate key exchange operation enum
>   test/crypto: separate key exchange operation enum
>   cryptodev: remove unnecessary zero assignement
>   cryptodev: remove comment about using ephemeral key in dsa
>   cryptodev: remove asym crypto next xform
>   crypto/openssl: remove asym crypto next xform
>   test/crypto: remove asym crypto next xform
>   app/test-crypto-perf: remove asym crypto next xform
>   app/test-eventdev: remove asym crypto next xform
>   cryptodev: move dh type from xform to dh op
>   crypto/openssl: move dh type from xform to dh op
>   test/crypto: move dh type from xform to dh op
>   cryptodev: changed order of dh fields
>   cryptodev: add elliptic curve diffie hellman
>   cryptodev: add public key verify option
>   cryptodev: move RSA padding into separate struct
>   crypto/qat: move RSA padding into separate struct
>   crypto/openssl: move RSA padding into separate struct
>   crypto/octeontx: move RSA padding into separate struct
>   crypto/cnxk: move RSA padding into separate struct
>   common/cpt: move RSA padding into separate struct
>   test/crypto: move RSA padding into separate struct
>   cryptodev: add salt length and optional label
>   cryptodev: reduce rsa struct to only necessary fields
>   crypto/qat: reduce rsa struct to only necessary fields
>   crypto/openssl: reduce rsa struct to only necessary fields
>   crypto/octeontx: reduce rsa struct to only necessary fields
>   crypto/cnxk: reduce rsa struct to only necessary fields
>   common/cpt: reduce rsa struct to only necessary fields
>   test/crypto: reduce rsa struct to only necessary fields
>   cryptodev: add asym op flags
>   cryptodev: clarify usage of private key in dh
>   crypto/openssl: generate dh private key
>   test/crypto: added test for dh priv key generation
> 
>  app/test-crypto-perf/cperf_ops.c             |   1 -
>  app/test-eventdev/test_perf_common.c         |   1 -
>  app/test/test_cryptodev_asym.c               | 117 +++++----
>  app/test/test_cryptodev_dh_test_vectors.h    |   1 -
>  app/test/test_cryptodev_dsa_test_vectors.h   |   1 -
>  app/test/test_cryptodev_mod_test_vectors.h   |   2 -
>  app/test/test_cryptodev_rsa_test_vectors.h   |   2 -
>  app/test/test_event_crypto_adapter.c         |   4 -
>  devtools/libabigail.abignore                 |   2 +
>  drivers/common/cpt/cpt_ucode_asym.h          |  12 +-
>  drivers/crypto/cnxk/cnxk_ae.h                |  44 ++--
>  drivers/crypto/octeontx/otx_cryptodev_ops.c  |  26 +-
>  drivers/crypto/openssl/rte_openssl_pmd.c     |  47 ++--
>  drivers/crypto/openssl/rte_openssl_pmd_ops.c |  33 +--
>  drivers/crypto/qat/qat_asym.c                |  28 +--
>  lib/cryptodev/rte_crypto_asym.h              | 342 ++++++++++++++++-----------
>  lib/cryptodev/rte_cryptodev.c                |  15 +-
>  17 files changed, 358 insertions(+), 320 deletions(-)
> 
> --
> 2.13.6

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

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Friday, May 20, 2022 9:30 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 00/40] 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
> > - Removes LIST_END enumerators (ABI issue - supressed asym_xform)
> > - Adds Eliiptic-Curve point verification (DH verification - but will
> > be used only for
> > EC)
> > - Adds RSA missing padding fields.
> > - Adds asym op flags
> > - Fixes many API comments (like EC curves)
> >
> > Commits are grouped by functionality, and mostly independent.
> 
> Please ensure all commits compile individually.
> Also mark previous versions in patchworks as superseded.
[Arek] - I will send v2 then, and I will fix all technical issues. Please verify if you are fine with changes proposed,. Most of these changes were already proposed in previous patches and in RFCs with no or minor problems found. Second patchset I would like to send contains capability changes and montgormery/Edwards curvers (would be good to have this in this release).
> 
> >
> > Arek Kusztal (40):
> >   cryptodev: redefine ec group enum
> >   cryptodev: remove list end enumerators
> >   test/crypto: remove list end enumerators
> >   cryptodev: reduce number of comments in asym xform
> >   test/crypto: removed asym xform none
> >   cryptodev: separate key exchange operation enum
> >   crypto/openssl: separate key exchange operation enum
> >   test/crypto: separate key exchange operation enum
> >   cryptodev: remove unnecessary zero assignement
> >   cryptodev: remove comment about using ephemeral key in dsa
> >   cryptodev: remove asym crypto next xform
> >   crypto/openssl: remove asym crypto next xform
> >   test/crypto: remove asym crypto next xform
> >   app/test-crypto-perf: remove asym crypto next xform
> >   app/test-eventdev: remove asym crypto next xform
> >   cryptodev: move dh type from xform to dh op
> >   crypto/openssl: move dh type from xform to dh op
> >   test/crypto: move dh type from xform to dh op
> >   cryptodev: changed order of dh fields
> >   cryptodev: add elliptic curve diffie hellman
> >   cryptodev: add public key verify option
> >   cryptodev: move RSA padding into separate struct
> >   crypto/qat: move RSA padding into separate struct
> >   crypto/openssl: move RSA padding into separate struct
> >   crypto/octeontx: move RSA padding into separate struct
> >   crypto/cnxk: move RSA padding into separate struct
> >   common/cpt: move RSA padding into separate struct
> >   test/crypto: move RSA padding into separate struct
> >   cryptodev: add salt length and optional label
> >   cryptodev: reduce rsa struct to only necessary fields
> >   crypto/qat: reduce rsa struct to only necessary fields
> >   crypto/openssl: reduce rsa struct to only necessary fields
> >   crypto/octeontx: reduce rsa struct to only necessary fields
> >   crypto/cnxk: reduce rsa struct to only necessary fields
> >   common/cpt: reduce rsa struct to only necessary fields
> >   test/crypto: reduce rsa struct to only necessary fields
> >   cryptodev: add asym op flags
> >   cryptodev: clarify usage of private key in dh
> >   crypto/openssl: generate dh private key
> >   test/crypto: added test for dh priv key generation
> >
> >  app/test-crypto-perf/cperf_ops.c             |   1 -
> >  app/test-eventdev/test_perf_common.c         |   1 -
> >  app/test/test_cryptodev_asym.c               | 117 +++++----
> >  app/test/test_cryptodev_dh_test_vectors.h    |   1 -
> >  app/test/test_cryptodev_dsa_test_vectors.h   |   1 -
> >  app/test/test_cryptodev_mod_test_vectors.h   |   2 -
> >  app/test/test_cryptodev_rsa_test_vectors.h   |   2 -
> >  app/test/test_event_crypto_adapter.c         |   4 -
> >  devtools/libabigail.abignore                 |   2 +
> >  drivers/common/cpt/cpt_ucode_asym.h          |  12 +-
> >  drivers/crypto/cnxk/cnxk_ae.h                |  44 ++--
> >  drivers/crypto/octeontx/otx_cryptodev_ops.c  |  26 +-
> >  drivers/crypto/openssl/rte_openssl_pmd.c     |  47 ++--
> >  drivers/crypto/openssl/rte_openssl_pmd_ops.c |  33 +--
> >  drivers/crypto/qat/qat_asym.c                |  28 +--
> >  lib/cryptodev/rte_crypto_asym.h              | 342 ++++++++++++++++-----------
> >  lib/cryptodev/rte_cryptodev.c                |  15 +-
> >  17 files changed, 358 insertions(+), 320 deletions(-)
> >
> > --
> > 2.13.6

RE: [EXT] [PATCH 13/40] test/crypto: remove asym crypto next xform

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Friday, May 20, 2022 9:24 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 13/40] test/crypto: remove asym crypto next xform
> 
> > - removed asymnetric crypto xform next field.
> > This commit reflects changes to the asymmetric crypto API.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  app/test/test_cryptodev_asym.c             | 100 -----------------------------
> >  app/test/test_cryptodev_dh_test_vectors.h  |   1 -
> >  app/test/test_cryptodev_dsa_test_vectors.h |   1 -
> >  app/test/test_cryptodev_mod_test_vectors.h |   2 -
> >  app/test/test_cryptodev_rsa_test_vectors.h |   2 -
> >  app/test/test_event_crypto_adapter.c       |   4 --
> >  6 files changed, 110 deletions(-)
> >
> > diff --git a/app/test/test_cryptodev_asym.c
> > b/app/test/test_cryptodev_asym.c index 0098b6bf65..9e5d5e4f27 100644
> > --- a/app/test/test_cryptodev_asym.c
> > +++ b/app/test/test_cryptodev_asym.c
> > @@ -318,7 +318,6 @@ test_cryptodev_asym_op(struct
> > crypto_testsuite_params_asym *ts_params,
> >
> >  	int ret, status = TEST_SUCCESS;
> >
> > -	xform_tc.next = NULL;
> >  	xform_tc.xform_type = data_tc->modex.xform_type;
> >
> >  	cap_idx.type = xform_tc.xform_type;
> > @@ -1063,7 +1062,6 @@ test_dh_gen_shared_sec(struct
> > rte_crypto_asym_xform *xfrm)
> >
> >  	/* Setup a xform and op to generate private key only */
> >  	xform.dh.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;
> >  	asym_op->dh.pub_key.data = (uint8_t *)peer; @@ -1145,7 +1143,6 @@
> > test_dh_gen_priv_key(struct rte_crypto_asym_xform
> > *xfrm)
> >
> >  	/* Setup a xform and op to generate private key only */
> >  	xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
> > -	xform.next = NULL;
> >  	asym_op->dh.priv_key.data = output;
> >  	asym_op->dh.priv_key.length = sizeof(output);
> >
> > @@ -1228,7 +1225,6 @@ test_dh_gen_pub_key(struct
> rte_crypto_asym_xform
> > *xfrm)
> >  	 *
> >  	 */
> >  	xform.dh.type = RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
> > -	xform.next = NULL;
> >
> >  	asym_op->dh.pub_key.data = output;
> >  	asym_op->dh.pub_key.length = sizeof(output); @@ -1288,94 +1284,6
> @@
> > test_dh_gen_pub_key(struct rte_crypto_asym_xform *xfrm)  }
> >
> >  static int
> > -test_dh_gen_kp(struct rte_crypto_asym_xform *xfrm)
> 
> 
> Why is this function removed?
This function is later added with new way of handling it, but in v2 I will squash this changes into one so it will not be removed.
> 
> > -{
> > -	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
> > -	struct rte_mempool *op_mpool = ts_params->op_mpool;
> > -	struct rte_mempool *sess_mpool = ts_params->session_mpool;
> > -	uint8_t dev_id = ts_params->valid_devs[0];
> > -	struct rte_crypto_asym_op *asym_op = NULL;
> > -	struct rte_crypto_op *op = NULL, *result_op = NULL;
> > -	void *sess = NULL;
> > -	int ret, status = TEST_SUCCESS;
> > -	uint8_t out_pub_key[TEST_DH_MOD_LEN];
> > -	uint8_t out_prv_key[TEST_DH_MOD_LEN];
> > -	struct rte_crypto_asym_xform pub_key_xform;
> > -	struct rte_crypto_asym_xform xform = *xfrm;
> > -
> > -	/* set up crypto op data structure */
> > -	op = rte_crypto_op_alloc(op_mpool,
> > RTE_CRYPTO_OP_TYPE_ASYMMETRIC);
> > -	if (!op) {
> > -		RTE_LOG(ERR, USER1,
> > -			"line %u FAILED: %s",
> > -			__LINE__, "Failed to allocate asymmetric crypto "
> > -			"operation struct");
> > -		status = TEST_FAILED;
> > -		goto error_exit;
> > -	}
> > -	asym_op = op->asym;
> > -	/* Setup a xform chain to generate
> > -	 * private key first followed by
> > -	 * public key
> > -	 */
> > -	xform.dh.type = RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE;
> > -	pub_key_xform.xform_type = RTE_CRYPTO_ASYM_XFORM_DH;
> > -	pub_key_xform.dh.type =
> > RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE;
> > -	xform.next = &pub_key_xform;
> > -
> > -	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);
> > -
> > -	ret = rte_cryptodev_asym_session_create(dev_id, &xform, sess_mpool,
> > &sess);
> > -	if (ret < 0) {
> > -		RTE_LOG(ERR, USER1,
> > -				"line %u FAILED: %s", __LINE__,
> > -				"Session creation failed");
> > -		status = (ret == -ENOTSUP) ? TEST_SKIPPED : TEST_FAILED;
> > -		goto error_exit;
> > -	}
> > -
> > -	/* attach asymmetric crypto session to crypto operations */
> > -	rte_crypto_op_attach_asym_session(op, sess);
> > -
> > -	RTE_LOG(DEBUG, USER1, "Process ASYM operation");
> > -
> > -	/* Process crypto operation */
> > -	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
> > -		RTE_LOG(ERR, USER1,
> > -			"line %u FAILED: %s",
> > -			__LINE__, "Error sending packet for operation");
> > -		status = TEST_FAILED;
> > -		goto error_exit;
> > -	}
> > -
> > -	while (rte_cryptodev_dequeue_burst(dev_id, 0, &result_op, 1) == 0)
> > -		rte_pause();
> > -
> > -	if (result_op == NULL) {
> > -		RTE_LOG(ERR, USER1,
> > -			"line %u FAILED: %s",
> > -			__LINE__, "Failed to process asym crypto op");
> > -		status = TEST_FAILED;
> > -		goto error_exit;
> > -	}
> > -	debug_hexdump(stdout, "priv key:",
> > -			out_prv_key, asym_op->dh.priv_key.length);
> > -	debug_hexdump(stdout, "pub key:",
> > -			out_pub_key, asym_op->dh.pub_key.length);
> > -
> > -error_exit:
> > -	if (sess != NULL)
> > -		rte_cryptodev_asym_session_free(dev_id, sess);
> > -	if (op != NULL)
> > -		rte_crypto_op_free(op);
> > -
> > -	return status;
> > -}
> > -
> > -static int
> >  test_mod_inv(void)
> >  {
> >  	struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
> > @@ -1611,12 +1519,6 @@ test_dh_keygenration(void)
> >  			dh_test_params.priv_key.length);
> >
> >  	RTE_LOG(INFO, USER1,
> > -		"Test Public and Private key pair generation\n");
> > -
> > -	status = test_dh_gen_kp(&dh_xform);
> > -	TEST_ASSERT_EQUAL(status, 0, "Test failed");
> > -
> > -	RTE_LOG(INFO, USER1,
> >  		"Test Public Key Generation using pre-defined priv key\n");
> >
> >  	status = test_dh_gen_pub_key(&dh_xform); @@ -1828,7 +1730,6 @@
> > test_ecdsa_sign_verify(enum curve curve_id)
> >  	asym_op = op->asym;
> >
> >  	/* Setup asym xform */
> > -	xform.next = NULL;
> >  	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECDSA;
> >  	xform.ec.curve_id = input_params.curve;
> >
> > @@ -2030,7 +1931,6 @@ test_ecpm(enum curve curve_id)
> >  	asym_op = op->asym;
> >
> >  	/* Setup asym xform */
> > -	xform.next = NULL;
> >  	xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECPM;
> >  	xform.ec.curve_id = input_params.curve;
> >
> > diff --git a/app/test/test_cryptodev_dh_test_vectors.h
> > b/app/test/test_cryptodev_dh_test_vectors.h
> > index fe7510dcd3..078719072d 100644
> > --- a/app/test/test_cryptodev_dh_test_vectors.h
> > +++ b/app/test/test_cryptodev_dh_test_vectors.h
> > @@ -63,7 +63,6 @@ struct dh_test_param dh_test_params = {  };
> >
> >  struct rte_crypto_asym_xform dh_xform = {
> > -	.next = NULL,
> >  	.xform_type = RTE_CRYPTO_ASYM_XFORM_DH,
> >  	.dh = {
> >  		.p = {
> > diff --git a/app/test/test_cryptodev_dsa_test_vectors.h
> > b/app/test/test_cryptodev_dsa_test_vectors.h
> > index bbcb0d7297..cc60f50b5c 100644
> > --- a/app/test/test_cryptodev_dsa_test_vectors.h
> > +++ b/app/test/test_cryptodev_dsa_test_vectors.h
> > @@ -91,7 +91,6 @@ struct dsa_test_param dsa_test_params = {  };
> >
> >  struct rte_crypto_asym_xform dsa_xform = {
> > -	.next = NULL,
> >  	.xform_type = RTE_CRYPTO_ASYM_XFORM_DSA,
> >  	.dsa = {
> >  		.p = {
> > diff --git a/app/test/test_cryptodev_mod_test_vectors.h
> > b/app/test/test_cryptodev_mod_test_vectors.h
> > index 807ca7a47e..bcd4d5248b 100644
> > --- a/app/test/test_cryptodev_mod_test_vectors.h
> > +++ b/app/test/test_cryptodev_mod_test_vectors.h
> > @@ -1045,7 +1045,6 @@ uint8_t mod_inv[] = {
> >
> >  /* MODEX vector. 8< */
> >  struct rte_crypto_asym_xform modex_xform = {
> > -	.next = NULL,
> >  	.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
> >  	.modex = {
> >  		.modulus = {
> > @@ -1061,7 +1060,6 @@ struct rte_crypto_asym_xform modex_xform = {
> >  /* >8 End of MODEX vector. */
> >
> >  struct rte_crypto_asym_xform modinv_xform = {
> > -	.next = NULL,
> >  	.xform_type = RTE_CRYPTO_ASYM_XFORM_MODINV,
> >  	.modinv = {
> >  		.modulus = {
> > diff --git a/app/test/test_cryptodev_rsa_test_vectors.h
> > b/app/test/test_cryptodev_rsa_test_vectors.h
> > index 04539a1ecf..e769dec1f4 100644
> > --- a/app/test/test_cryptodev_rsa_test_vectors.h
> > +++ b/app/test/test_cryptodev_rsa_test_vectors.h
> > @@ -346,7 +346,6 @@ uint8_t rsa_qInv[] = {
> >
> >  /** rsa xform using exponent key */
> >  struct rte_crypto_asym_xform rsa_xform = {
> > -	.next = NULL,
> >  	.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA,
> >  	.rsa = {
> >  		.n = {
> > @@ -367,7 +366,6 @@ struct rte_crypto_asym_xform rsa_xform = {
> >
> >  /** rsa xform using quintuple key */
> >  struct rte_crypto_asym_xform rsa_xform_crt = {
> > -	.next = NULL,
> >  	.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA,
> >  	.rsa = {
> >  		.n = {
> > diff --git a/app/test/test_event_crypto_adapter.c
> > b/app/test/test_event_crypto_adapter.c
> > index 2ecc7e2cea..feb1d86c00 100644
> > --- a/app/test/test_event_crypto_adapter.c
> > +++ b/app/test/test_event_crypto_adapter.c
> > @@ -295,7 +295,6 @@ test_op_forward_mode(uint8_t session_less)  #endif
> >  	/* Setup Cipher Parameters */
> >  	cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
> > -	cipher_xform.next = NULL;
> >  	cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
> >  	cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
> >
> > @@ -474,7 +473,6 @@ test_asym_op_forward_mode(uint8_t session_less)
> >  		return TEST_SKIPPED;
> >  	}
> >  	/* Setup Cipher Parameters */
> > -	xform_tc.next = NULL;
> >  	xform_tc.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
> >  	cap_idx.type = xform_tc.xform_type;
> >  	capability = rte_cryptodev_asym_capability_get(TEST_CDEV_ID,
> > &cap_idx);
> > @@ -672,7 +670,6 @@ test_op_new_mode(uint8_t session_less)  #endif
> >  	/* Setup Cipher Parameters */
> >  	cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
> > -	cipher_xform.next = NULL;
> >  	cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
> >  	cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
> >
> > @@ -807,7 +804,6 @@ test_asym_op_new_mode(uint8_t session_less)
> >  		return TEST_SKIPPED;
> >  	}
> >  	/* Setup Cipher Parameters */
> > -	xform_tc.next = NULL;
> >  	xform_tc.xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX;
> >  	cap_idx.type = xform_tc.xform_type;
> >  	capability = rte_cryptodev_asym_capability_get(TEST_CDEV_ID,
> > &cap_idx);
> > --
> > 2.13.6

RE: [EXT] [PATCH 37/40] cryptodev: add asym op flags

[Akhil Goyal]

> - 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 | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 37dd3b9d86..01b1fdd074 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -41,6 +41,26 @@ rte_crypto_asym_ke_strings[];
>  extern const char *
>  rte_crypto_asym_op_strings[];
> 
> +#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_NO_PADDING		0
> +/**<
> + * If set to 1 - public key will be returned
> + * without leading zero bytes, otherwise it will be
> + * padded to the left with zero bytes (default)
> + */
> +#define RTE_CRYPTO_ASYM_FLAG_SHARED_KEY_NO_PADDING	1
> +/**<
> + * If set to 1 - shared key will be returned
> + * without leading zero bytes, otherwise it will be
> + * padded to the left with zero bytes (default)
> + */
> +
> +#define RTE_CRYPTO_ASYM_FLAG_SET(op, flag) \
> +	(op->flags |= (1ULL << flag))
> +#define RTE_CRYPTO_ASYM_FLAG_UNSET(op, flag) \
> +	(op->flags &= (~(1ULL << flag)))
> +#define RTE_CRYPTO_ASYM_FLAG_GET(op, flag) \
> +	(!!(op->flags &= (1ULL << flag)))
> +

Why are these SET/GET macros needed?
Is the following not sufficient

#define RTE_CRYPTO_ASYM_FLAG_PUB_KEY_NO_PADDING   RTE_BIT32(0)
#define RTE_CRYPTO_ASYM_FLAG_SHARED_KEY_NO_PADDING  RTE_BIT32(1)

op->flags |= RTE_CRYPTO_ASYM_FLAG_PUB_KEY_NO_PADDING;

>  /**
>   * List of elliptic curves. This enum aligns with
>   * TLS "Supported Groups" registry (previously known  as
> @@ -607,6 +627,11 @@ struct rte_crypto_asym_op {
>  		struct rte_crypto_ecdsa_op_param ecdsa;
>  		struct rte_crypto_ecpm_op_param ecpm;
>  	};
> +	uint16_t flags;
> +	/**< Asymmetric crypto flags, every flag starts with
> +	 * RTE_CRYPTO_ASYM_FLAG_*. Flags are set/unset with
> +	 * RTE_CRYPTO_ASYM_SET_FLAGS, RTE_CRYPTO_ASYM_GET_FLAGS
> +	 */
>  };
> 
>  #ifdef __cplusplus
> --
> 2.13.6

RE: [EXT] [PATCH 04/40] cryptodev: reduce number of comments in asym xform

[Akhil Goyal]

> - Reduced number of comments in asymmetric xform.
> Information describing basic functionality of well known
> algorithms are unnecessary.
> - Added information about data memory lifetime.
> It was specified how user should work with private data,
> and it is user's responsability to clear it.
> - Removed NONE asymetric xform.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 45 +++++++++++++----------------------------
>  lib/cryptodev/rte_cryptodev.c   |  1 -
>  2 files changed, 14 insertions(+), 32 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index a474b6acd1..0251e8caae 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -55,46 +55,29 @@ enum rte_crypto_curve_id {
>  };
> 
>  /**
> - * Asymmetric crypto transformation types.
> - * Each xform type maps to one asymmetric algorithm
> - * performing specific operation
> - *
> + * Asymmetric crypto algorithm static data.
> + * Data that may be used more than once (e.g. RSA private key).
> + * It is the USER responsibility to keep track of private data memory
> + * lifetime and security of the this data in xform. The same way
> + * it is the USER responsibility to call cryptodev session_clear()
> + * function if a session was created. If session-less not used
> + * xform data should be cleared after successful session creation.
>   */
>  enum rte_crypto_asym_xform_type {
> -	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
> +	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED,
>  	/**< Invalid xform. */
> -	RTE_CRYPTO_ASYM_XFORM_NONE,
> -	/**< Xform type None.
> -	 * May be supported by PMD to support
> -	 * passthrough op for debugging purpose.
> -	 * if xform_type none , op_type is disregarded.
> -	 */
I believe removing this is not a good idea. As stated, it will help in
Debugging.

>  	RTE_CRYPTO_ASYM_XFORM_RSA,
> -	/**< RSA. Performs Encrypt, Decrypt, Sign and Verify.
> -	 * Refer to rte_crypto_asym_op_type
> -	 */
> +	/**< RSA */
>  	RTE_CRYPTO_ASYM_XFORM_DH,
> -	/**< Diffie-Hellman.
> -	 * Performs Key Generate and Shared Secret Compute.
> -	 * Refer to rte_crypto_asym_op_type
> -	 */
> +	/**< Diffie-Hellman */
>  	RTE_CRYPTO_ASYM_XFORM_DSA,
> -	/**< Digital Signature Algorithm
> -	 * Performs Signature Generation and Verification.
> -	 * Refer to rte_crypto_asym_op_type
> -	 */
> +	/**< Digital Signature Algorithm */
>  	RTE_CRYPTO_ASYM_XFORM_MODINV,
> -	/**< Modular Multiplicative Inverse
> -	 * Perform Modular Multiplicative Inverse b^(-1) mod n
> -	 */
> +	/**< Modular Multiplicative Inverse */
>  	RTE_CRYPTO_ASYM_XFORM_MODEX,
> -	/**< Modular Exponentiation
> -	 * Perform Modular Exponentiation b^e mod n
> -	 */
> +	/**< Modular Exponentiation */
>  	RTE_CRYPTO_ASYM_XFORM_ECDSA,
> -	/**< Elliptic Curve Digital Signature Algorithm
> -	 * Perform Signature Generation and Verification.
> -	 */
> +	/**< Elliptic Curve Digital Signature Algorithm */
>  	RTE_CRYPTO_ASYM_XFORM_ECPM
>  	/**< Elliptic Curve Point Multiplication */
>  };
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
> index e16e6802aa..691625bd04 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -160,7 +160,6 @@ rte_crypto_aead_operation_strings[] = {
>   * Asymmetric crypto transform operation strings identifiers.
>   */
>  const char *rte_crypto_asym_xform_strings[] = {
> -	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
>  	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
>  	[RTE_CRYPTO_ASYM_XFORM_MODEX]	= "modexp",
>  	[RTE_CRYPTO_ASYM_XFORM_MODINV]	= "modinv",
> --
> 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Akhil Goyal]

> - removed asymnetric crypto xform next field.
> Rationale behind having chaining in symmetric crypto
> was a fact that encryption and authentication are usually
> done on the same set of data independent of algorithm.
> HW usually will be able to handle it in one PCI call.
> In asymmetric there is no such relation between algorithms,
> therefore next field would be useless.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>

Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
asymmetric crypto xforms.

> ---
>  lib/cryptodev/rte_crypto_asym.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 1652a434a5..b355cbe5fa 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
>   * Structure describing asym xforms.
>   */
>  struct rte_crypto_asym_xform {
> -	struct rte_crypto_asym_xform *next;
> -	/**< Pointer to next xform to set up xform chain.*/
>  	enum rte_crypto_asym_xform_type xform_type;
>  	/**< Asymmetric crypto transform */
> 
> --
> 2.13.6

RE: [EXT] [PATCH 06/40] cryptodev: separate key exchange operation enum

[Akhil Goyal]

> - separated key exchange enum.
> 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>

Please check if it need update in Documentation.

> ---
>  lib/cryptodev/rte_crypto_asym.h | 24 +++++++++++++++++-------
>  lib/cryptodev/rte_cryptodev.c   | 14 ++++++++++----
>  2 files changed, 27 insertions(+), 11 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 0251e8caae..0fc9f49b87 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[];
> @@ -94,12 +98,18 @@ 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 */
> +};
> +
> +/**
> + * Asymmetric crypto key exchange operation type
> + */
> +enum rte_crypto_asym_ke_type {
> +	RTE_CRYPTO_ASYM_KE_PRIVATE_KEY_GENERATE,
> +	/**< Private Key generation operation */
> +	RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE,
> +	/**< Public Key generation operation */
> +	RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> +	/**< Shared Secret compute operation */
>  };
> 
>  /**
> @@ -239,7 +249,7 @@ struct rte_crypto_modinv_xform {
>   *
>   */
>  struct rte_crypto_dh_xform {
> -	enum rte_crypto_asym_op_type type;
> +	enum rte_crypto_asym_ke_type type;
>  	/**< Setup xform for key generate or shared secret compute */
>  	rte_crypto_uint p;
>  	/**< Prime modulus data */
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
> index 691625bd04..af58f49d07 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -176,10 +176,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_PRIVATE_KEY_GENERATE] =
> "priv_key_generate",
> +	[RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE] =
> "pub_key_generate",
> +	[RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE] =
> "sharedsecret_compute"
>  };
> 
>  /**
> --
> 2.13.6

RE: [EXT] [PATCH 16/40] cryptodev: move dh type from xform to dh op

[Akhil Goyal]

> - 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.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index b355cbe5fa..728a98f02e 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -250,8 +250,6 @@ struct rte_crypto_modinv_xform {
>   *
>   */
>  struct rte_crypto_dh_xform {
> -	enum rte_crypto_asym_ke_type type;
> -	/**< Setup xform for key generate or shared secret compute */
>  	rte_crypto_uint p;
>  	/**< Prime modulus data */
>  	rte_crypto_uint g;
> @@ -379,27 +377,29 @@ struct rte_crypto_rsa_op_param {
>   * @note:
>   */
>  struct rte_crypto_dh_op_param {
> +	enum rte_crypto_asym_ke_type op_type;
> +	/**< Key exchange operation type */
>  	rte_crypto_uint pub_key;
>  	/**<
> -	 * Output generated public key when xform type is
> +	 * Output generated public key when op_type is
>  	 * DH PUB_KEY_GENERATION.
> -	 * Input peer public key when xform type is DH
> +	 * Input peer public key when op_type is DH
>  	 * SHARED_SECRET_COMPUTATION

Add reference with the actual enum field.

>  	 *
>  	 */
> 
>  	rte_crypto_uint priv_key;
>  	/**<
> -	 * Output generated private key if xform type is
> +	 * Output generated private key when op_type is
>  	 * DH PRIVATE_KEY_GENERATION
> -	 * Input when xform type is DH SHARED_SECRET_COMPUTATION.
> +	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
>  	 *
>  	 */
> 
>  	rte_crypto_uint shared_secret;
>  	/**<
>  	 * Output with calculated shared secret
> -	 * when dh xform set up with op type =
> SHARED_SECRET_COMPUTATION.
> +	 * when op type is SHARED_SECRET_COMPUTATION.
>  	 *
>  	 */
>  };
> --
> 2.13.6

RE: [EXT] [PATCH 20/40] cryptodev: add elliptic curve diffie hellman

[Akhil Goyal]

> - 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.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 34 +++++++++++++++++++++-------------
>  1 file changed, 21 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 52cb1c5c80..09edf2ac3d 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -82,8 +82,10 @@ enum rte_crypto_asym_xform_type {
>  	/**< Modular Exponentiation */
>  	RTE_CRYPTO_ASYM_XFORM_ECDSA,
>  	/**< Elliptic Curve Digital Signature Algorithm */
> -	RTE_CRYPTO_ASYM_XFORM_ECPM
> +	RTE_CRYPTO_ASYM_XFORM_ECPM,
>  	/**< Elliptic Curve Point Multiplication */
> +	RTE_CRYPTO_ASYM_XFORM_ECDH
> +	/**< Elliptic Curve Diffie Hellman */
>  };
Please add relevant information in "doc/guides/prog_guide/cryptodev_lib.rst"

> 
>  /**
> @@ -383,22 +385,28 @@ struct rte_crypto_dh_op_param {
>  	/**<
>  	 * Output generated private key when op_type is
>  	 * DH PRIVATE_KEY_GENERATION

Update with actual enum name for this as well

> -	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
> -	 *
> +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
>  	 */
> -	rte_crypto_uint pub_key;
> +	union {
> +		rte_crypto_uint pub_key;
> +		struct rte_crypto_ec_point pub_point;
> +	};
>  	/**<
> -	 * Output generated public key when op_type is
> -	 * DH PUB_KEY_GENERATION.
> -	 * Input peer public key when op_type is DH
> -	 * SHARED_SECRET_COMPUTATION
> -	 *
> +	 * Diffie-Hellman public part
> +	 * For DH it is big-endian unsigned integer.
> +	 * For ECDH it is a point on the curve.
> +	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
>  	 */
> -	rte_crypto_uint shared_secret;
> +	union {
> +		rte_crypto_uint shared_secret;
> +		struct rte_crypto_ec_point shared_point;
> +	};
>  	/**<
> -	 * Output with calculated shared secret
> -	 * when op type is SHARED_SECRET_COMPUTATION.
> -	 *
> +	 * Diffie-Hellman shared secret
> +	 * For DH it is big-endian unsigned integer.
> +	 * For ECDH it is a point on the curve.
> +	 * Output for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
>  	 */

Is it output for others as well?
Please be consistent in the comments for all params.


>  };
> 
> --
> 2.13.6

RE: [EXT] [PATCH 21/40] cryptodev: add public key verify option

[Akhil Goyal]

> - 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 | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 09edf2ac3d..73ff9ff815 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -110,8 +110,10 @@ enum rte_crypto_asym_ke_type {
>  	/**< Private Key generation operation */
>  	RTE_CRYPTO_ASYM_KE_PUBLIC_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_OP_DH_KEY_VERIFY
> +	/**< Public Key Verification */

Shouldn't this be RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_VERIFY ??

>  };
> 
>  /**
> @@ -397,6 +399,10 @@ struct rte_crypto_dh_op_param {
>  	 * For ECDH it is a point on the curve.
>  	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
>  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> +	 *
> +	 * VERIFY option can be used only for elliptic curve
> +	 * point validation, for FFDH (DH) it is user's reponsibility
> +	 * to check the public key accordingly.

What is expected from the user? Please be specific.
Add reference to the ke_type for which this comment id valid.

>  	 */
>  	union {
>  		rte_crypto_uint shared_secret;
> --
> 2.13.6

RE: [EXT] [PATCH 29/40] cryptodev: add salt length and optional label

[Akhil Goyal]

> - added salt length and optional label.
> Common parameters to PSS and OAEP padding for RSA.

Please add description about how it is expected to be used.

> - Fixed hash API in RSA padding.
> Now it is specified how hash should be used with
> particular RSA padding modes.

I believe this should be a separate patch. Right?
Patch title does not justify this

> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 44
> +++++++++++++++++++++++++++++++++++------
>  1 file changed, 38 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 97c3fbee38..c864b8a115 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -205,12 +205,29 @@ 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;

Any specific reason to change the field name?
I think this matches with the next field mgf1md

> -	/**< Hash algorithm to be used for data hash if padding
> -	 * scheme is either OAEP or PSS. Valid hash algorithms
> -	 * are:
> -	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
> +	/**< Type of RSA padding */
> +	enum rte_crypto_auth_algorithm hash;
> +	/**<
> +	 * RSA padding hash function
> +	 *
> +	 * 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:
> +	 * When signing 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;
>  	/**<
> @@ -220,6 +237,21 @@ struct rte_crypto_rsa_padding {
>  	 * for mask generation. Valid hash algorithms are:
>  	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
>  	 */
> +	uint16_t saltlen;
> +	/**<
> +	 * RSA PSS padding salt length
> +	 *
> +	 * Used only when RTE_CRYPTO_RSA_PADDING_PSS padding is
> selected,

Used only when RTE_CRYPTO_RSA_PADDING_PSS is selected,

> +	 * otherwise ignored.
> +	 */
> +	rte_crypto_param label;
> +	/**<
> +	 * RSA OAEP padding optional label
> +	 *
> +	 * Used only when RTE_CRYPTO_RSA_PADDING_OAEP padding is
> selected,

Drop the word padding.

BTW, can this be a union for label and saltlen?
Also can we name them as pss_saltlen and oaep_label?

> +	 * otherwise ignored. If label.data == NULL, a default
> +	 * label (empty string) is used.
> +	 */
>  };
> 
>  /**
> --
> 2.13.6

RE: [EXT] [PATCH 30/40] cryptodev: reduce rsa struct to only necessary fields

[Akhil Goyal]

> - reduced rsa struct to only necessary fields.
> RSA operation is generally used with one input and one output.
> One exception for this is signature verification, when RSA verify
> called, both message and signature are inputs, but there is no rsa
> output except for op status.

I am not sure if this is the correct renaming of fields.

You are changing the name of message -> input and 
Cipher and sign -> output/message union. Right?

I believe this would impact the existing applications and 
Would create confusion as the message was used for input and now it is 
In union with output.

The logic listed here is looking very complex.
Please simplify it. Can you try adding comments in the description of struct
Instead of individual fields.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 87 +++++++++++++++++++++++----------------
> --
>  1 file changed, 50 insertions(+), 37 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index c864b8a115..37dd3b9d86 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -362,53 +362,66 @@ struct rte_crypto_rsa_op_param {
>  	enum rte_crypto_asym_op_type op_type;
>  	/**< Type of RSA operation for transform */
> 
> -	rte_crypto_param message;
> +	rte_crypto_param input;
>  	/**<
> -	 * Pointer to input data
> -	 * - to be encrypted for RSA public encrypt.
> -	 * - to be signed for RSA sign generation.
> -	 * - to be authenticated for RSA sign verification.
> +	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
> +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> +	 * input should only be used along with cryptographically
> +	 * secure padding scheme.
> +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5
> +	 * input shall be no longer than public modulus minus 11.
> +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_OAEP
> +	 * input shall be no longer than public modulus -
> +	 * 2 * len(hash) - 2.
> +	 * When op_type == RTE_CRYPTO_ASYM_OP_SIGN:
>  	 *
> -	 * Pointer to output data
> -	 * - for RSA private decrypt.
> -	 * In this case the underlying array should have been
> -	 * allocated with enough memory to hold plaintext output
> -	 * (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.
> +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> +	 * input should only be used along with cryptographically
> +	 * secure padding scheme.	 *
> +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5 or
> +	 * RTE_CRYPTO_RSA_PADDING_PSS
> +	 * if the RTE_CRYPTO_RSA_FLAG_PT flag is set, input shall contain
> +	 * the message to be signed, if this flag is not set,
> +	 * input shall contain the digest of the message to be signed.

Does it mean if padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5 or RTE_CRYPTO_RSA_PADDING_PSS  and if RTE_CRYPTO_RSA_FLAG_PT flag is set

>  	 *
> -	 * All data is in Octet-string network byte order format.
> -	 */
> -
> -	rte_crypto_param cipher;
> -	/**<
> -	 * Pointer to input data
> -	 * - to be decrypted for RSA private decrypt.
> +	 * When op_type == RTE_CRYPTO_ASYM_OP_DECRYPT:
>  	 *
> -	 * Pointer to output data
> -	 * - for RSA public encrypt.
> -	 * In this case the underlying array should have been allocated
> -	 * with enough memory to hold ciphertext output (i.e. must be
> -	 * at least RSA key size). The cipher.length field should
> -	 * be 0 and will be overwritten by the PMD with the encrypted length.
> +	 * Input shall contain previously encrypted RSA message.
>  	 *
> -	 * All data is in Octet-string network byte order format.
> +	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
> +	 *
> +	 * Input shall contain signature to be verified
>  	 */
> -
> -	rte_crypto_param sign;
> +	union {
> +		rte_crypto_param output;
> +		rte_crypto_param message;
> +	};
>  	/**<
> -	 * Pointer to input data
> -	 * - to be verified for RSA public decrypt.
> +	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
> +	 *
> +	 * Output shall contain encrypted data, output.length shall
> +	 * be set to the length of encrypted data.
> +	 *
> +	 * When op_type ==
> RTE_CRYPTO_ASYM_OP_DECRYPT/RTE_CRYPTO_ASYM_OP_SIGN:
>  	 *
> -	 * Pointer to output data
> -	 * - for RSA private encrypt.
> -	 * In this case the underlying array should have been allocated
> -	 * 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.
> +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> +	 * output shall contain decrypted/signed data, but all leading zeros
> +	 * shall be preserved. Therefore output.length should be
> +	 * equal to the length of the modulus..
> +	 * For other types of padding, output should contain
> +	 * decrypted data, and output.length shall be set to the length
> +	 * of decrypted data.
>  	 *
> -	 * All data is in Octet-string network byte order format.
> +	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
> +	 *
> +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> +	 * output shall contain the public key decrypted signature.
> +	 * All leading zeroes shall be preserved.
> +	 *
> +	 * For other padding types, the message should be set with data for the
> +	 * signature to be compared with.
>  	 */
> +
>  	struct rte_crypto_rsa_padding padding;
>  	/**< RSA padding information */
> 
> --
> 2.13.6

RE: [EXT] [PATCH 38/40] cryptodev: clarify usage of private key in dh

[Akhil Goyal]

> - 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 | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 01b1fdd074..a6bb70ca3f 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -459,6 +459,10 @@ struct rte_crypto_dh_op_param {
>  	 * Output generated private key when op_type is
>  	 * DH PRIVATE_KEY_GENERATION
>  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> +	 * In case priv_key.length is 0 and op_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.

What is expected for the device which does not support this?
How will the application decide?

>  	 */
>  	union {
>  		rte_crypto_uint pub_key;
> --
> 2.13.6

RE: [EXT] [PATCH 38/40] cryptodev: clarify usage of private key in dh

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 2:56 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 38/40] 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>
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 01b1fdd074..a6bb70ca3f 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -459,6 +459,10 @@ struct rte_crypto_dh_op_param {
> >  	 * Output generated private key when op_type is
> >  	 * DH PRIVATE_KEY_GENERATION
> >  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > +	 * In case priv_key.length is 0 and op_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.
> 
> What is expected for the device which does not support this?
> How will the application decide?
[Arek] - it is similar issue as in DSA/ECDSA 'k'. Or we will add some PMD flag to determine if PMD is CSRNG capable or it will be stated in PMD .rst file. If device does not support random, packet will be rejected (send to response queue with NOT_PROCESSED). This comment should probably be added.
> 
> >  	 */
> >  	union {
> >  		rte_crypto_uint pub_key;
> > --
> > 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 1:13 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> > - removed asymnetric crypto xform next field.
> > Rationale behind having chaining in symmetric crypto was a fact that
> > encryption and authentication are usually done on the same set of data
> > independent of algorithm.
> > HW usually will be able to handle it in one PCI call.
> > In asymmetric there is no such relation between algorithms, therefore
> > next field would be useless.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> 
> Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> Not all asymmetric crypto xforms are supported for chaining. Currently
> supported asymmetric crypto chaining is Diffie-Hellman private key generation
> followed by public generation. 
[Arek] And why do chaining when this can be done even with one bit flag.

Also, currently API does not support chaining of
> symmetric and asymmetric crypto xforms.
[Arek] - This is one unlikely scenario to combine symmetric and asymmetric. One I can think of was once proposed DH + DSA integration for random number. But not much else, although we can keep it around for a while.
> 
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> >   * Structure describing asym xforms.
> >   */
> >  struct rte_crypto_asym_xform {
> > -	struct rte_crypto_asym_xform *next;
> > -	/**< Pointer to next xform to set up xform chain.*/
> >  	enum rte_crypto_asym_xform_type xform_type;
> >  	/**< Asymmetric crypto transform */
> >
> > --
> > 2.13.6

RE: [EXT] [PATCH 20/40] cryptodev: add elliptic curve diffie hellman

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 2:08 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 20/40] 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.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 34
> > +++++++++++++++++++++-------------
> >  1 file changed, 21 insertions(+), 13 deletions(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 52cb1c5c80..09edf2ac3d 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -82,8 +82,10 @@ enum rte_crypto_asym_xform_type {
> >  	/**< Modular Exponentiation */
> >  	RTE_CRYPTO_ASYM_XFORM_ECDSA,
> >  	/**< Elliptic Curve Digital Signature Algorithm */
> > -	RTE_CRYPTO_ASYM_XFORM_ECPM
> > +	RTE_CRYPTO_ASYM_XFORM_ECPM,
> >  	/**< Elliptic Curve Point Multiplication */
> > +	RTE_CRYPTO_ASYM_XFORM_ECDH
> > +	/**< Elliptic Curve Diffie Hellman */
> >  };
> Please add relevant information in "doc/guides/prog_guide/cryptodev_lib.rst"
> 
> >
> >  /**
> > @@ -383,22 +385,28 @@ struct rte_crypto_dh_op_param {
> >  	/**<
> >  	 * Output generated private key when op_type is
> >  	 * DH PRIVATE_KEY_GENERATION
> 
> Update with actual enum name for this as well
> 
> > -	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
> > -	 *
> > +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> >  	 */
> > -	rte_crypto_uint pub_key;
> > +	union {
> > +		rte_crypto_uint pub_key;
> > +		struct rte_crypto_ec_point pub_point;
> > +	};
> >  	/**<
> > -	 * Output generated public key when op_type is
> > -	 * DH PUB_KEY_GENERATION.
> > -	 * Input peer public key when op_type is DH
> > -	 * SHARED_SECRET_COMPUTATION
> > -	 *
> > +	 * Diffie-Hellman public part
> > +	 * For DH it is big-endian unsigned integer.
> > +	 * For ECDH it is a point on the curve.
> > +	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> > +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> >  	 */
> > -	rte_crypto_uint shared_secret;
> > +	union {
> > +		rte_crypto_uint shared_secret;
> > +		struct rte_crypto_ec_point shared_point;
> > +	};
> >  	/**<
> > -	 * Output with calculated shared secret
> > -	 * when op type is SHARED_SECRET_COMPUTATION.
> > -	 *
> > +	 * Diffie-Hellman shared secret
> > +	 * For DH it is big-endian unsigned integer.
> > +	 * For ECDH it is a point on the curve.
> > +	 * Output for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> >  	 */
> 
> Is it output for others as well?
[Arek] - No, it is output for phase2 only.
> Please be consistent in the comments for all params.
> 
> 
> >  };
> >
> > --
> > 2.13.6

RE: [EXT] [PATCH 20/40] cryptodev: add elliptic curve diffie hellman

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Tuesday, May 24, 2022 4:52 PM
> To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 20/40] cryptodev: add elliptic curve diffie hellman
> 
> 
> 
> > -----Original Message-----
> > From: Akhil Goyal <gakhil@marvell.com>
> > Sent: Tuesday, May 24, 2022 2:08 PM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> > Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> > <roy.fan.zhang@intel.com>
> > Subject: RE: [EXT] [PATCH 20/40] 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.
> > >
> > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > ---
> > >  lib/cryptodev/rte_crypto_asym.h | 34
> > > +++++++++++++++++++++-------------
> > >  1 file changed, 21 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index 52cb1c5c80..09edf2ac3d
> > > 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -82,8 +82,10 @@ enum rte_crypto_asym_xform_type {
> > >  	/**< Modular Exponentiation */
> > >  	RTE_CRYPTO_ASYM_XFORM_ECDSA,
> > >  	/**< Elliptic Curve Digital Signature Algorithm */
> > > -	RTE_CRYPTO_ASYM_XFORM_ECPM
> > > +	RTE_CRYPTO_ASYM_XFORM_ECPM,
> > >  	/**< Elliptic Curve Point Multiplication */
> > > +	RTE_CRYPTO_ASYM_XFORM_ECDH
> > > +	/**< Elliptic Curve Diffie Hellman */
> > >  };
> > Please add relevant information in "doc/guides/prog_guide/cryptodev_lib.rst"
> >
> > >
> > >  /**
> > > @@ -383,22 +385,28 @@ struct rte_crypto_dh_op_param {
> > >  	/**<
> > >  	 * Output generated private key when op_type is
> > >  	 * DH PRIVATE_KEY_GENERATION
> >
> > Update with actual enum name for this as well
> >
> > > -	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
> > > -	 *
> > > +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > >  	 */
> > > -	rte_crypto_uint pub_key;
> > > +	union {
> > > +		rte_crypto_uint pub_key;
> > > +		struct rte_crypto_ec_point pub_point;
> > > +	};
> > >  	/**<
> > > -	 * Output generated public key when op_type is
> > > -	 * DH PUB_KEY_GENERATION.
> > > -	 * Input peer public key when op_type is DH
> > > -	 * SHARED_SECRET_COMPUTATION
> > > -	 *
> > > +	 * Diffie-Hellman public part
> > > +	 * For DH it is big-endian unsigned integer.
> > > +	 * For ECDH it is a point on the curve.
> > > +	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> > > +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > >  	 */
> > > -	rte_crypto_uint shared_secret;
> > > +	union {
> > > +		rte_crypto_uint shared_secret;
> > > +		struct rte_crypto_ec_point shared_point;
> > > +	};
> > >  	/**<
> > > -	 * Output with calculated shared secret
> > > -	 * when op type is SHARED_SECRET_COMPUTATION.
> > > -	 *
> > > +	 * Diffie-Hellman shared secret
> > > +	 * For DH it is big-endian unsigned integer.
> > > +	 * For ECDH it is a point on the curve.
> > > +	 * Output for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > >  	 */
> >
> > Is it output for others as well?
> [Arek] - No, it is output for phase2 only.
[Arek] - additionally there is still an option to split it into DH_PARAM, ECDH_PARAM, x25519. For secp and Edwards/Montgomery it should be ok with current approach but for SM2 we may need new struct.
> > Please be consistent in the comments for all params.
> >
> >
> > >  };
> > >
> > > --
> > > 2.13.6

RE: [EXT] [PATCH 21/40] cryptodev: add public key verify option

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 2:12 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 21/40] 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>
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 09edf2ac3d..73ff9ff815 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -110,8 +110,10 @@ enum rte_crypto_asym_ke_type {
> >  	/**< Private Key generation operation */
> >  	RTE_CRYPTO_ASYM_KE_PUBLIC_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_OP_DH_KEY_VERIFY
> > +	/**< Public Key Verification */
> 
> Shouldn't this be RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_VERIFY ??
[Arek] - ah, yes. Sorry for that.
> 
> >  };
> >
> >  /**
> > @@ -397,6 +399,10 @@ struct rte_crypto_dh_op_param {
> >  	 * For ECDH it is a point on the curve.
> >  	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> >  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > +	 *
> > +	 * VERIFY option can be used only for elliptic curve
> > +	 * point validation, for FFDH (DH) it is user's reponsibility
> > +	 * to check the public key accordingly.
> 
> What is expected from the user? Please be specific.
[Arek] - Well, this depends on protocol, usually it is size check for FFDH and zero check for x25519/448. Not sure how much information should be provided here.
> Add reference to the ke_type for which this comment id valid.

> 
> >  	 */
> >  	union {
> >  		rte_crypto_uint shared_secret;
> > --
> > 2.13.6

RE: [EXT] [PATCH 29/40] cryptodev: add salt length and optional label

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 2:30 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 29/40] cryptodev: add salt length and optional label
> 
> > - added salt length and optional label.
> > Common parameters to PSS and OAEP padding for RSA.
> 
> Please add description about how it is expected to be used.
> 
> > - Fixed hash API in RSA padding.
> > Now it is specified how hash should be used with particular RSA
> > padding modes.
> 
> I believe this should be a separate patch. Right?
[Arek] +1
> Patch title does not justify this
> 
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 44
> > +++++++++++++++++++++++++++++++++++------
> >  1 file changed, 38 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 97c3fbee38..c864b8a115 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -205,12 +205,29 @@ 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;
> 
> Any specific reason to change the field name?
> I think this matches with the next field mgf1md
[Arek] - now it aligns with RSA RFC. Both current names comes from the OpenSSL EVP_MD naming, in my rfc initially mgf1md was changed too into:
+enum rte_crypto_mgf {
+	RTE_CRYPTO_MGF_DEFAULT,
+	/**< Default mask generation function */
+	RTE_CRYPTO_MGF_MGF1_SHA1,
+	/**< MGF1 function with SHA1 hash algorithm */
But we do not need to be that conformant with the standard I think, so I have left it out.
As for names it may be 'md' as well, every name is ok if is not excessively long.

> 
> > -	/**< Hash algorithm to be used for data hash if padding
> > -	 * scheme is either OAEP or PSS. Valid hash algorithms
> > -	 * are:
> > -	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
> > +	/**< Type of RSA padding */
> > +	enum rte_crypto_auth_algorithm hash;
> > +	/**<
> > +	 * RSA padding hash function
> > +	 *
> > +	 * 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:
> > +	 * When signing 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;
> >  	/**<
> > @@ -220,6 +237,21 @@ struct rte_crypto_rsa_padding {
> >  	 * for mask generation. Valid hash algorithms are:
> >  	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
> >  	 */
> > +	uint16_t saltlen;
> > +	/**<
> > +	 * RSA PSS padding salt length
> > +	 *
> > +	 * Used only when RTE_CRYPTO_RSA_PADDING_PSS padding is
> > selected,
> 
> Used only when RTE_CRYPTO_RSA_PADDING_PSS is selected,
> 
> > +	 * otherwise ignored.
> > +	 */
> > +	rte_crypto_param label;
> > +	/**<
> > +	 * RSA OAEP padding optional label
> > +	 *
> > +	 * Used only when RTE_CRYPTO_RSA_PADDING_OAEP padding is
> > selected,
> 
> Drop the word padding.
> 
> BTW, can this be a union for label and saltlen?
Yes, will do.
> Also can we name them as pss_saltlen and oaep_label?
Yes, though I am not entirely convinced. These names are unique anyway.
> 
> > +	 * otherwise ignored. If label.data == NULL, a default
> > +	 * label (empty string) is used.
> > +	 */
> >  };
> >
> >  /**
> > --
> > 2.13.6

RE: [EXT] [PATCH 30/40] cryptodev: reduce rsa struct to only necessary fields

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 2:53 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 30/40] cryptodev: reduce rsa struct to only necessary
> fields
> 
> > - reduced rsa struct to only necessary fields.
> > RSA operation is generally used with one input and one output.
> > One exception for this is signature verification, when RSA verify
> > called, both message and signature are inputs, but there is no rsa
> > output except for op status.
> 
> I am not sure if this is the correct renaming of fields.
> 
> You are changing the name of message -> input and Cipher and sign ->
> output/message union. Right?
> 
> I believe this would impact the existing applications and Would create confusion
> as the message was used for input and now it is In union with output.
[Arek] - Yes, this will impact current apps. And yes, message may be confusing.
But main question, is there consensus for the Input - Output approach in RSA? If not I will drop it from v2.
If so, in case SIGNATURE_VERIFY and PADDING_NONE decrypted signature should be placed in message or cipher with no further PMD involvement.

> 
> The logic listed here is looking very complex.
> Please simplify it. Can you try adding comments in the description of struct
> Instead of individual fields.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 87
> > +++++++++++++++++++++++----------------
> > --
> >  1 file changed, 50 insertions(+), 37 deletions(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index c864b8a115..37dd3b9d86 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -362,53 +362,66 @@ struct rte_crypto_rsa_op_param {
> >  	enum rte_crypto_asym_op_type op_type;
> >  	/**< Type of RSA operation for transform */
> >
> > -	rte_crypto_param message;
> > +	rte_crypto_param input;
> >  	/**<
> > -	 * Pointer to input data
> > -	 * - to be encrypted for RSA public encrypt.
> > -	 * - to be signed for RSA sign generation.
> > -	 * - to be authenticated for RSA sign verification.
> > +	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
> > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > +	 * input should only be used along with cryptographically
> > +	 * secure padding scheme.
> > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5
> > +	 * input shall be no longer than public modulus minus 11.
> > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_OAEP
> > +	 * input shall be no longer than public modulus -
> > +	 * 2 * len(hash) - 2.
> > +	 * When op_type == RTE_CRYPTO_ASYM_OP_SIGN:
> >  	 *
> > -	 * Pointer to output data
> > -	 * - for RSA private decrypt.
> > -	 * In this case the underlying array should have been
> > -	 * allocated with enough memory to hold plaintext output
> > -	 * (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.
> > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > +	 * input should only be used along with cryptographically
> > +	 * secure padding scheme.	 *
> > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5 or
> > +	 * RTE_CRYPTO_RSA_PADDING_PSS
> > +	 * if the RTE_CRYPTO_RSA_FLAG_PT flag is set, input shall contain
> > +	 * the message to be signed, if this flag is not set,
> > +	 * input shall contain the digest of the message to be signed.
> 
> Does it mean if padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5 or
> RTE_CRYPTO_RSA_PADDING_PSS  and if RTE_CRYPTO_RSA_FLAG_PT flag is set
[Arek] - this one will be out, no one probably will come asking for this functionality anyway.
> 
> >  	 *
> > -	 * All data is in Octet-string network byte order format.
> > -	 */
> > -
> > -	rte_crypto_param cipher;
> > -	/**<
> > -	 * Pointer to input data
> > -	 * - to be decrypted for RSA private decrypt.
> > +	 * When op_type == RTE_CRYPTO_ASYM_OP_DECRYPT:
> >  	 *
> > -	 * Pointer to output data
> > -	 * - for RSA public encrypt.
> > -	 * In this case the underlying array should have been allocated
> > -	 * with enough memory to hold ciphertext output (i.e. must be
> > -	 * at least RSA key size). The cipher.length field should
> > -	 * be 0 and will be overwritten by the PMD with the encrypted length.
> > +	 * Input shall contain previously encrypted RSA message.
> >  	 *
> > -	 * All data is in Octet-string network byte order format.
> > +	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
> > +	 *
> > +	 * Input shall contain signature to be verified
> >  	 */
> > -
> > -	rte_crypto_param sign;
> > +	union {
> > +		rte_crypto_param output;
> > +		rte_crypto_param message;
> > +	};
> >  	/**<
> > -	 * Pointer to input data
> > -	 * - to be verified for RSA public decrypt.
> > +	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
> > +	 *
> > +	 * Output shall contain encrypted data, output.length shall
> > +	 * be set to the length of encrypted data.
> > +	 *
> > +	 * When op_type ==
> > RTE_CRYPTO_ASYM_OP_DECRYPT/RTE_CRYPTO_ASYM_OP_SIGN:
> >  	 *
> > -	 * Pointer to output data
> > -	 * - for RSA private encrypt.
> > -	 * In this case the underlying array should have been allocated
> > -	 * 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.
> > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > +	 * output shall contain decrypted/signed data, but all leading zeros
> > +	 * shall be preserved. Therefore output.length should be
> > +	 * equal to the length of the modulus..
> > +	 * For other types of padding, output should contain
> > +	 * decrypted data, and output.length shall be set to the length
> > +	 * of decrypted data.
> >  	 *
> > -	 * All data is in Octet-string network byte order format.
> > +	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
> > +	 *
> > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > +	 * output shall contain the public key decrypted signature.
> > +	 * All leading zeroes shall be preserved.
> > +	 *
> > +	 * For other padding types, the message should be set with data for the
> > +	 * signature to be compared with.
> >  	 */
> > +
> >  	struct rte_crypto_rsa_padding padding;
> >  	/**< RSA padding information */
> >
> > --
> > 2.13.6

RE: [EXT] [PATCH 04/40] cryptodev: reduce number of comments in asym xform

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 12:59 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 04/40] cryptodev: reduce number of comments in
> asym xform
> 
> > - Reduced number of comments in asymmetric xform.
> > Information describing basic functionality of well known algorithms
> > are unnecessary.
> > - Added information about data memory lifetime.
> > It was specified how user should work with private data, and it is
> > user's responsability to clear it.
> > - Removed NONE asymetric xform.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 45 +++++++++++++----------------------------
> >  lib/cryptodev/rte_cryptodev.c   |  1 -
> >  2 files changed, 14 insertions(+), 32 deletions(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index a474b6acd1..0251e8caae 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -55,46 +55,29 @@ enum rte_crypto_curve_id {  };
> >
> >  /**
> > - * Asymmetric crypto transformation types.
> > - * Each xform type maps to one asymmetric algorithm
> > - * performing specific operation
> > - *
> > + * Asymmetric crypto algorithm static data.
> > + * Data that may be used more than once (e.g. RSA private key).
> > + * It is the USER responsibility to keep track of private data memory
> > + * lifetime and security of the this data in xform. The same way
> > + * it is the USER responsibility to call cryptodev session_clear()
> > + * function if a session was created. If session-less not used
> > + * xform data should be cleared after successful session creation.
> >   */
> >  enum rte_crypto_asym_xform_type {
> > -	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
> > +	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED,
> >  	/**< Invalid xform. */
> > -	RTE_CRYPTO_ASYM_XFORM_NONE,
> > -	/**< Xform type None.
> > -	 * May be supported by PMD to support
> > -	 * passthrough op for debugging purpose.
> > -	 * if xform_type none , op_type is disregarded.
> > -	 */
> I believe removing this is not a good idea. As stated, it will help in Debugging.
> 
> >  	RTE_CRYPTO_ASYM_XFORM_RSA,
> > -	/**< RSA. Performs Encrypt, Decrypt, Sign and Verify.
> > -	 * Refer to rte_crypto_asym_op_type
> > -	 */
> > +	/**< RSA */
> >  	RTE_CRYPTO_ASYM_XFORM_DH,
> > -	/**< Diffie-Hellman.
> > -	 * Performs Key Generate and Shared Secret Compute.
> > -	 * Refer to rte_crypto_asym_op_type
> > -	 */
> > +	/**< Diffie-Hellman */
> >  	RTE_CRYPTO_ASYM_XFORM_DSA,
> > -	/**< Digital Signature Algorithm
> > -	 * Performs Signature Generation and Verification.
> > -	 * Refer to rte_crypto_asym_op_type
> > -	 */
> > +	/**< Digital Signature Algorithm */
> >  	RTE_CRYPTO_ASYM_XFORM_MODINV,
> > -	/**< Modular Multiplicative Inverse
> > -	 * Perform Modular Multiplicative Inverse b^(-1) mod n
> > -	 */
> > +	/**< Modular Multiplicative Inverse */
> >  	RTE_CRYPTO_ASYM_XFORM_MODEX,
> > -	/**< Modular Exponentiation
> > -	 * Perform Modular Exponentiation b^e mod n
> > -	 */
> > +	/**< Modular Exponentiation */
> >  	RTE_CRYPTO_ASYM_XFORM_ECDSA,
> > -	/**< Elliptic Curve Digital Signature Algorithm
> > -	 * Perform Signature Generation and Verification.
> > -	 */
> > +	/**< Elliptic Curve Digital Signature Algorithm */
> >  	RTE_CRYPTO_ASYM_XFORM_ECPM
[Arek] - maybe this is not that important but could not we have asym_algorithm instead of xform_type? There is not ECDSA/ECPM xform at all.
> >  	/**< Elliptic Curve Point Multiplication */  }; diff --git
> > a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c index
> > e16e6802aa..691625bd04 100644
> > --- a/lib/cryptodev/rte_cryptodev.c
> > +++ b/lib/cryptodev/rte_cryptodev.c
> > @@ -160,7 +160,6 @@ rte_crypto_aead_operation_strings[] = {
> >   * Asymmetric crypto transform operation strings identifiers.
> >   */
> >  const char *rte_crypto_asym_xform_strings[] = {
> > -	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
> >  	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
> >  	[RTE_CRYPTO_ASYM_XFORM_MODEX]	= "modexp",
> >  	[RTE_CRYPTO_ASYM_XFORM_MODINV]	= "modinv",
> > --
> > 2.13.6

RE: [EXT] [PATCH 04/40] cryptodev: reduce number of comments in asym xform

[Akhil Goyal]

> > > - Reduced number of comments in asymmetric xform.
> > > Information describing basic functionality of well known algorithms
> > > are unnecessary.
> > > - Added information about data memory lifetime.
> > > It was specified how user should work with private data, and it is
> > > user's responsability to clear it.
> > > - Removed NONE asymetric xform.
> > >
> > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > ---
> > >  lib/cryptodev/rte_crypto_asym.h | 45 +++++++++++++--------------------------
> --
> > >  lib/cryptodev/rte_cryptodev.c   |  1 -
> > >  2 files changed, 14 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index a474b6acd1..0251e8caae 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -55,46 +55,29 @@ enum rte_crypto_curve_id {  };
> > >
> > >  /**
> > > - * Asymmetric crypto transformation types.
> > > - * Each xform type maps to one asymmetric algorithm
> > > - * performing specific operation
> > > - *
> > > + * Asymmetric crypto algorithm static data.
> > > + * Data that may be used more than once (e.g. RSA private key).
> > > + * It is the USER responsibility to keep track of private data memory
> > > + * lifetime and security of the this data in xform. The same way
> > > + * it is the USER responsibility to call cryptodev session_clear()
> > > + * function if a session was created. If session-less not used
> > > + * xform data should be cleared after successful session creation.
> > >   */
> > >  enum rte_crypto_asym_xform_type {
> > > -	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
> > > +	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED,
> > >  	/**< Invalid xform. */
> > > -	RTE_CRYPTO_ASYM_XFORM_NONE,
> > > -	/**< Xform type None.
> > > -	 * May be supported by PMD to support
> > > -	 * passthrough op for debugging purpose.
> > > -	 * if xform_type none , op_type is disregarded.
> > > -	 */
> > I believe removing this is not a good idea. As stated, it will help in Debugging.
> >
> > >  	RTE_CRYPTO_ASYM_XFORM_RSA,
> > > -	/**< RSA. Performs Encrypt, Decrypt, Sign and Verify.
> > > -	 * Refer to rte_crypto_asym_op_type
> > > -	 */
> > > +	/**< RSA */
> > >  	RTE_CRYPTO_ASYM_XFORM_DH,
> > > -	/**< Diffie-Hellman.
> > > -	 * Performs Key Generate and Shared Secret Compute.
> > > -	 * Refer to rte_crypto_asym_op_type
> > > -	 */
> > > +	/**< Diffie-Hellman */
> > >  	RTE_CRYPTO_ASYM_XFORM_DSA,
> > > -	/**< Digital Signature Algorithm
> > > -	 * Performs Signature Generation and Verification.
> > > -	 * Refer to rte_crypto_asym_op_type
> > > -	 */
> > > +	/**< Digital Signature Algorithm */
> > >  	RTE_CRYPTO_ASYM_XFORM_MODINV,
> > > -	/**< Modular Multiplicative Inverse
> > > -	 * Perform Modular Multiplicative Inverse b^(-1) mod n
> > > -	 */
> > > +	/**< Modular Multiplicative Inverse */
> > >  	RTE_CRYPTO_ASYM_XFORM_MODEX,
> > > -	/**< Modular Exponentiation
> > > -	 * Perform Modular Exponentiation b^e mod n
> > > -	 */
> > > +	/**< Modular Exponentiation */
> > >  	RTE_CRYPTO_ASYM_XFORM_ECDSA,
> > > -	/**< Elliptic Curve Digital Signature Algorithm
> > > -	 * Perform Signature Generation and Verification.
> > > -	 */
> > > +	/**< Elliptic Curve Digital Signature Algorithm */
> > >  	RTE_CRYPTO_ASYM_XFORM_ECPM
> [Arek] - maybe this is not that important but could not we have asym_algorithm
> instead of xform_type? There is not ECDSA/ECPM xform at all.

Converting everything to asym algo may not be good. As they have different xforms
And different type of operations.
May be we could split into xform type and algo similar to symmetric crypto?

> > >  	/**< Elliptic Curve Point Multiplication */  }; diff --git
> > > a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c index
> > > e16e6802aa..691625bd04 100644
> > > --- a/lib/cryptodev/rte_cryptodev.c
> > > +++ b/lib/cryptodev/rte_cryptodev.c
> > > @@ -160,7 +160,6 @@ rte_crypto_aead_operation_strings[] = {
> > >   * Asymmetric crypto transform operation strings identifiers.
> > >   */
> > >  const char *rte_crypto_asym_xform_strings[] = {
> > > -	[RTE_CRYPTO_ASYM_XFORM_NONE]	= "none",
> > >  	[RTE_CRYPTO_ASYM_XFORM_RSA]	= "rsa",
> > >  	[RTE_CRYPTO_ASYM_XFORM_MODEX]	= "modexp",
> > >  	[RTE_CRYPTO_ASYM_XFORM_MODINV]	= "modinv",
> > > --
> > > 2.13.6

RE: [EXT] [PATCH 30/40] cryptodev: reduce rsa struct to only necessary fields

[Akhil Goyal]

> > > - reduced rsa struct to only necessary fields.
> > > RSA operation is generally used with one input and one output.
> > > One exception for this is signature verification, when RSA verify
> > > called, both message and signature are inputs, but there is no rsa
> > > output except for op status.
> >
> > I am not sure if this is the correct renaming of fields.
> >
> > You are changing the name of message -> input and Cipher and sign ->
> > output/message union. Right?
> >
> > I believe this would impact the existing applications and Would create
> confusion
> > as the message was used for input and now it is In union with output.
> [Arek] - Yes, this will impact current apps. And yes, message may be confusing.
> But main question, is there consensus for the Input - Output approach in RSA? If
> not I will drop it from v2.
> If so, in case SIGNATURE_VERIFY and PADDING_NONE decrypted signature
> should be placed in message or cipher with no further PMD involvement.

++Kiran

> 
> >
> > The logic listed here is looking very complex.
> > Please simplify it. Can you try adding comments in the description of struct
> > Instead of individual fields.
> > >
> > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > ---
> > >  lib/cryptodev/rte_crypto_asym.h | 87
> > > +++++++++++++++++++++++----------------
> > > --
> > >  1 file changed, 50 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index c864b8a115..37dd3b9d86 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -362,53 +362,66 @@ struct rte_crypto_rsa_op_param {
> > >  	enum rte_crypto_asym_op_type op_type;
> > >  	/**< Type of RSA operation for transform */
> > >
> > > -	rte_crypto_param message;
> > > +	rte_crypto_param input;
> > >  	/**<
> > > -	 * Pointer to input data
> > > -	 * - to be encrypted for RSA public encrypt.
> > > -	 * - to be signed for RSA sign generation.
> > > -	 * - to be authenticated for RSA sign verification.
> > > +	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
> > > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > > +	 * input should only be used along with cryptographically
> > > +	 * secure padding scheme.
> > > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5
> > > +	 * input shall be no longer than public modulus minus 11.
> > > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_OAEP
> > > +	 * input shall be no longer than public modulus -
> > > +	 * 2 * len(hash) - 2.
> > > +	 * When op_type == RTE_CRYPTO_ASYM_OP_SIGN:
> > >  	 *
> > > -	 * Pointer to output data
> > > -	 * - for RSA private decrypt.
> > > -	 * In this case the underlying array should have been
> > > -	 * allocated with enough memory to hold plaintext output
> > > -	 * (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.
> > > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > > +	 * input should only be used along with cryptographically
> > > +	 * secure padding scheme.	 *
> > > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5 or
> > > +	 * RTE_CRYPTO_RSA_PADDING_PSS
> > > +	 * if the RTE_CRYPTO_RSA_FLAG_PT flag is set, input shall contain
> > > +	 * the message to be signed, if this flag is not set,
> > > +	 * input shall contain the digest of the message to be signed.
> >
> > Does it mean if padding.type = RTE_CRYPTO_RSA_PADDING_PKCS1_5 or
> > RTE_CRYPTO_RSA_PADDING_PSS  and if RTE_CRYPTO_RSA_FLAG_PT flag is
> set
> [Arek] - this one will be out, no one probably will come asking for this
> functionality anyway.
> >
> > >  	 *
> > > -	 * All data is in Octet-string network byte order format.
> > > -	 */
> > > -
> > > -	rte_crypto_param cipher;
> > > -	/**<
> > > -	 * Pointer to input data
> > > -	 * - to be decrypted for RSA private decrypt.
> > > +	 * When op_type == RTE_CRYPTO_ASYM_OP_DECRYPT:
> > >  	 *
> > > -	 * Pointer to output data
> > > -	 * - for RSA public encrypt.
> > > -	 * In this case the underlying array should have been allocated
> > > -	 * with enough memory to hold ciphertext output (i.e. must be
> > > -	 * at least RSA key size). The cipher.length field should
> > > -	 * be 0 and will be overwritten by the PMD with the encrypted length.
> > > +	 * Input shall contain previously encrypted RSA message.
> > >  	 *
> > > -	 * All data is in Octet-string network byte order format.
> > > +	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
> > > +	 *
> > > +	 * Input shall contain signature to be verified
> > >  	 */
> > > -
> > > -	rte_crypto_param sign;
> > > +	union {
> > > +		rte_crypto_param output;
> > > +		rte_crypto_param message;
> > > +	};
> > >  	/**<
> > > -	 * Pointer to input data
> > > -	 * - to be verified for RSA public decrypt.
> > > +	 * When op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT:
> > > +	 *
> > > +	 * Output shall contain encrypted data, output.length shall
> > > +	 * be set to the length of encrypted data.
> > > +	 *
> > > +	 * When op_type ==
> > > RTE_CRYPTO_ASYM_OP_DECRYPT/RTE_CRYPTO_ASYM_OP_SIGN:
> > >  	 *
> > > -	 * Pointer to output data
> > > -	 * - for RSA private encrypt.
> > > -	 * In this case the underlying array should have been allocated
> > > -	 * 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.
> > > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > > +	 * output shall contain decrypted/signed data, but all leading zeros
> > > +	 * shall be preserved. Therefore output.length should be
> > > +	 * equal to the length of the modulus..
> > > +	 * For other types of padding, output should contain
> > > +	 * decrypted data, and output.length shall be set to the length
> > > +	 * of decrypted data.
> > >  	 *
> > > -	 * All data is in Octet-string network byte order format.
> > > +	 * When op_type == RTE_CRYPTO_ASYM_OP_VERIFY:
> > > +	 *
> > > +	 * If padding.type = RTE_CRYPTO_RSA_PADDING_NONE
> > > +	 * output shall contain the public key decrypted signature.
> > > +	 * All leading zeroes shall be preserved.
> > > +	 *
> > > +	 * For other padding types, the message should be set with data for the
> > > +	 * signature to be compared with.
> > >  	 */
> > > +
> > >  	struct rte_crypto_rsa_padding padding;
> > >  	/**< RSA padding information */
> > >
> > > --
> > > 2.13.6

RE: [EXT] [PATCH 29/40] cryptodev: add salt length and optional label

[Akhil Goyal]

> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index 97c3fbee38..c864b8a115 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -205,12 +205,29 @@ 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;
> >
> > Any specific reason to change the field name?
> > I think this matches with the next field mgf1md
> [Arek] - now it aligns with RSA RFC. Both current names comes from the
> OpenSSL EVP_MD naming, in my rfc initially mgf1md was changed too into:
> +enum rte_crypto_mgf {
> +	RTE_CRYPTO_MGF_DEFAULT,
> +	/**< Default mask generation function */
> +	RTE_CRYPTO_MGF_MGF1_SHA1,
> +	/**< MGF1 function with SHA1 hash algorithm */
> But we do not need to be that conformant with the standard I think, so I have
> left it out.
> As for names it may be 'md' as well, every name is ok if is not excessively long.
> 
No strong opinion, you can keep any of them.

> >
> > > -	/**< Hash algorithm to be used for data hash if padding
> > > -	 * scheme is either OAEP or PSS. Valid hash algorithms
> > > -	 * are:
> > > -	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
> > > +	/**< Type of RSA padding */
> > > +	enum rte_crypto_auth_algorithm hash;
> > > +	/**<
> > > +	 * RSA padding hash function
> > > +	 *
> > > +	 * 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:
> > > +	 * When signing 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;
> > >  	/**<
> > > @@ -220,6 +237,21 @@ struct rte_crypto_rsa_padding {
> > >  	 * for mask generation. Valid hash algorithms are:
> > >  	 * MD5, SHA1, SHA224, SHA256, SHA384, SHA512
> > >  	 */
> > > +	uint16_t saltlen;
> > > +	/**<
> > > +	 * RSA PSS padding salt length
> > > +	 *
> > > +	 * Used only when RTE_CRYPTO_RSA_PADDING_PSS padding is
> > > selected,
> >
> > Used only when RTE_CRYPTO_RSA_PADDING_PSS is selected,
> >
> > > +	 * otherwise ignored.
> > > +	 */
> > > +	rte_crypto_param label;
> > > +	/**<
> > > +	 * RSA OAEP padding optional label
> > > +	 *
> > > +	 * Used only when RTE_CRYPTO_RSA_PADDING_OAEP padding is
> > > selected,
> >
> > Drop the word padding.
> >
> > BTW, can this be a union for label and saltlen?
> Yes, will do.
> > Also can we name them as pss_saltlen and oaep_label?
> Yes, though I am not entirely convinced. These names are unique anyway.
I believe it will improve readability.

> >
> > > +	 * otherwise ignored. If label.data == NULL, a default
> > > +	 * label (empty string) is used.
> > > +	 */
> > >  };
> > >
> > >  /**
> > > --
> > > 2.13.6

RE: [EXT] [PATCH 21/40] cryptodev: add public key verify option

[Akhil Goyal]

> > >
> > >  /**
> > > @@ -397,6 +399,10 @@ struct rte_crypto_dh_op_param {
> > >  	 * For ECDH it is a point on the curve.
> > >  	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> > >  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > +	 *
> > > +	 * VERIFY option can be used only for elliptic curve
> > > +	 * point validation, for FFDH (DH) it is user's reponsibility
> > > +	 * to check the public key accordingly.
> >
> > What is expected from the user? Please be specific.
> [Arek] - Well, this depends on protocol, usually it is size check for FFDH and zero
> check for x25519/448. Not sure how much information should be provided here.
I can understand we cannot specify everything here.
How about adding in documentation a section to give details?

> > Add reference to the ke_type for which this comment id valid.
> 
> >
> > >  	 */
> > >  	union {
> > >  		rte_crypto_uint shared_secret;
> > > --
> > > 2.13.6

RE: [EXT] [PATCH 20/40] cryptodev: add elliptic curve diffie hellman

[Akhil Goyal]

> > > >  /**
> > > > @@ -383,22 +385,28 @@ struct rte_crypto_dh_op_param {
> > > >  	/**<
> > > >  	 * Output generated private key when op_type is
> > > >  	 * DH PRIVATE_KEY_GENERATION
> > >
> > > Update with actual enum name for this as well
> > >
> > > > -	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
> > > > -	 *
> > > > +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > >  	 */
> > > > -	rte_crypto_uint pub_key;
> > > > +	union {
> > > > +		rte_crypto_uint pub_key;
> > > > +		struct rte_crypto_ec_point pub_point;
> > > > +	};
> > > >  	/**<
> > > > -	 * Output generated public key when op_type is
> > > > -	 * DH PUB_KEY_GENERATION.
> > > > -	 * Input peer public key when op_type is DH
> > > > -	 * SHARED_SECRET_COMPUTATION
> > > > -	 *
> > > > +	 * Diffie-Hellman public part
> > > > +	 * For DH it is big-endian unsigned integer.
> > > > +	 * For ECDH it is a point on the curve.
> > > > +	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> > > > +	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > >  	 */
> > > > -	rte_crypto_uint shared_secret;
> > > > +	union {
> > > > +		rte_crypto_uint shared_secret;
> > > > +		struct rte_crypto_ec_point shared_point;
> > > > +	};
> > > >  	/**<
> > > > -	 * Output with calculated shared secret
> > > > -	 * when op type is SHARED_SECRET_COMPUTATION.
> > > > -	 *
> > > > +	 * Diffie-Hellman shared secret
> > > > +	 * For DH it is big-endian unsigned integer.
> > > > +	 * For ECDH it is a point on the curve.
> > > > +	 * Output for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > >  	 */
> > >
> > > Is it output for others as well?
> > [Arek] - No, it is output for phase2 only.
> [Arek] - additionally there is still an option to split it into DH_PARAM,
> ECDH_PARAM, x25519. For secp and Edwards/Montgomery it should be ok with
> current approach but for SM2 we may need new struct.

I believe we need better documentation for asymmetric cryptography.

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Akhil Goyal]

> > > - removed asymnetric crypto xform next field.
> > > Rationale behind having chaining in symmetric crypto was a fact that
> > > encryption and authentication are usually done on the same set of data
> > > independent of algorithm.
> > > HW usually will be able to handle it in one PCI call.
> > > In asymmetric there is no such relation between algorithms, therefore
> > > next field would be useless.
> > >
> > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >
> > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > Not all asymmetric crypto xforms are supported for chaining. Currently
> > supported asymmetric crypto chaining is Diffie-Hellman private key generation
> > followed by public generation.
> [Arek] And why do chaining when this can be done even with one bit flag.
> 
I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob please confirm.

If we are removing it, then documentation should be in sync.

> Also, currently API does not support chaining of
> > symmetric and asymmetric crypto xforms.
> [Arek] - This is one unlikely scenario to combine symmetric and asymmetric. One
> I can think of was once proposed DH + DSA integration for random number. But
> not much else, although we can keep it around for a while.

Yes it is highly unlikely to use this combination.

> >
> > > ---
> > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > >   * Structure describing asym xforms.
> > >   */
> > >  struct rte_crypto_asym_xform {
> > > -	struct rte_crypto_asym_xform *next;
> > > -	/**< Pointer to next xform to set up xform chain.*/
> > >  	enum rte_crypto_asym_xform_type xform_type;
> > >  	/**< Asymmetric crypto transform */
> > >
> > > --
> > > 2.13.6

RE: [EXT] [PATCH 38/40] cryptodev: clarify usage of private key in dh

[Akhil Goyal]

> > > - 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 | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index 01b1fdd074..a6bb70ca3f 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -459,6 +459,10 @@ struct rte_crypto_dh_op_param {
> > >  	 * Output generated private key when op_type is
> > >  	 * DH PRIVATE_KEY_GENERATION
> > >  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > +	 * In case priv_key.length is 0 and op_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.
> >
> > What is expected for the device which does not support this?
> > How will the application decide?
> [Arek] - it is similar issue as in DSA/ECDSA 'k'. Or we will add some PMD flag to
> determine if PMD is CSRNG capable or it will be stated in PMD .rst file. If device
> does not support random, packet will be rejected (send to response queue with
> NOT_PROCESSED). This comment should probably be added.

I believe this can be covered in the capability patch that you are working on.

RE: [EXT] [PATCH 21/40] cryptodev: add public key verify option

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Wednesday, May 25, 2022 8:00 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 21/40] cryptodev: add public key verify option
> 
> > > >
> > > >  /**
> > > > @@ -397,6 +399,10 @@ struct rte_crypto_dh_op_param {
> > > >  	 * For ECDH it is a point on the curve.
> > > >  	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> > > >  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > > +	 *
> > > > +	 * VERIFY option can be used only for elliptic curve
> > > > +	 * point validation, for FFDH (DH) it is user's reponsibility
> > > > +	 * to check the public key accordingly.
> > >
> > > What is expected from the user? Please be specific.
> > [Arek] - Well, this depends on protocol, usually it is size check for
> > FFDH and zero check for x25519/448. Not sure how much information should
> be provided here.
> I can understand we cannot specify everything here.
> How about adding in documentation a section to give details?
[Arek] - actually I came with another idea.
I have added ECDH param, VERIFY is valid only for ecdh_op and verify is:
RTE_CRYPTO_ASYM_KE_EC_PUBLIC_KEY_VERIFY, so it is not included in dh_op_param.
I doubt there will be any hw acceleration for anything else than EC point verification + I doubt there will be 4 steps verification (that's why I have not included it in flags). I have spilt DH into DH and ECDH, as it probably will be easier when adding sm2 key exchange (instead of extending union fields)

+ Kai
> 
> > > Add reference to the ke_type for which this comment id valid.
> >
> > >
> > > >  	 */
> > > >  	union {
> > > >  		rte_crypto_uint shared_secret;
> > > > --
> > > > 2.13.6

RE: [EXT] [PATCH 20/40] cryptodev: add elliptic curve diffie hellman

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Wednesday, May 25, 2022 8:03 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 20/40] cryptodev: add elliptic curve diffie hellman
> 
> > > > >  /**
> > > > > @@ -383,22 +385,28 @@ struct rte_crypto_dh_op_param {
> > > > >  	/**<
> > > > >  	 * Output generated private key when op_type is
> > > > >  	 * DH PRIVATE_KEY_GENERATION
> > > >
> > > > Update with actual enum name for this as well
> > > >
> > > > > -	 * Input when op_type is DH SHARED_SECRET_COMPUTATION.
> > > > > -	 *
> > > > > +	 * Input for
> RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > > >  	 */
> > > > > -	rte_crypto_uint pub_key;
> > > > > +	union {
> > > > > +		rte_crypto_uint pub_key;
> > > > > +		struct rte_crypto_ec_point pub_point;
> > > > > +	};
> > > > >  	/**<
> > > > > -	 * Output generated public key when op_type is
> > > > > -	 * DH PUB_KEY_GENERATION.
> > > > > -	 * Input peer public key when op_type is DH
> > > > > -	 * SHARED_SECRET_COMPUTATION
> > > > > -	 *
> > > > > +	 * Diffie-Hellman public part
> > > > > +	 * For DH it is big-endian unsigned integer.
> > > > > +	 * For ECDH it is a point on the curve.
> > > > > +	 * Output for RTE_CRYPTO_ASYM_KE_PUBLIC_KEY_GENERATE
> > > > > +	 * Input for
> RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > > >  	 */
> > > > > -	rte_crypto_uint shared_secret;
> > > > > +	union {
> > > > > +		rte_crypto_uint shared_secret;
> > > > > +		struct rte_crypto_ec_point shared_point;
> > > > > +	};
> > > > >  	/**<
> > > > > -	 * Output with calculated shared secret
> > > > > -	 * when op type is SHARED_SECRET_COMPUTATION.
> > > > > -	 *
> > > > > +	 * Diffie-Hellman shared secret
> > > > > +	 * For DH it is big-endian unsigned integer.
> > > > > +	 * For ECDH it is a point on the curve.
> > > > > +	 * Output for
> RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > > >  	 */
> > > >
> > > > Is it output for others as well?
> > > [Arek] - No, it is output for phase2 only.
> > [Arek] - additionally there is still an option to split it into
> > DH_PARAM, ECDH_PARAM, x25519. For secp and Edwards/Montgomery it
> > should be ok with current approach but for SM2 we may need new struct.
> 
> I believe we need better documentation for asymmetric cryptography.
And we definitely need better tests, I have removed part of dh code from openssl pmd at random some time ago and all DH tests still passed!
I have added key exchange tests some time ago, this could be good start, I have v2 for ECDH too.
https://patchwork.dpdk.org/project/dpdk/list/?series=22401
Please take a look.

> 

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Wednesday, May 25, 2022 8:06 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org; Kiran
> Kumar Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> <anoobj@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> > > > - removed asymnetric crypto xform next field.
> > > > Rationale behind having chaining in symmetric crypto was a fact
> > > > that encryption and authentication are usually done on the same
> > > > set of data independent of algorithm.
> > > > HW usually will be able to handle it in one PCI call.
> > > > In asymmetric there is no such relation between algorithms,
> > > > therefore next field would be useless.
> > > >
> > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > >
> > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > Not all asymmetric crypto xforms are supported for chaining.
> > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > private key generation followed by public generation.
> > [Arek] And why do chaining when this can be done even with one bit flag.
> >
> I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob please
> confirm.
> 
> If we are removing it, then documentation should be in sync.
[Arek] - although, we may keep it for now, I am not dropping it in v2. DH priv + pub can be done with priv_key.len = 0 -> similar as 'k' in ecdsa when k.data = NULL.
But I do not see any situation for now it will be  useful, it may be dropped later if not application found.
> 
> > Also, currently API does not support chaining of
> > > symmetric and asymmetric crypto xforms.
> > [Arek] - This is one unlikely scenario to combine symmetric and
> > asymmetric. One I can think of was once proposed DH + DSA integration
> > for random number. But not much else, although we can keep it around for a
> while.
> 
> Yes it is highly unlikely to use this combination.
> 
> > >
> > > > ---
> > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > 100644
> > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > >   * Structure describing asym xforms.
> > > >   */
> > > >  struct rte_crypto_asym_xform {
> > > > -	struct rte_crypto_asym_xform *next;
> > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > >  	/**< Asymmetric crypto transform */
> > > >
> > > > --
> > > > 2.13.6

RE: [EXT] [PATCH 38/40] cryptodev: clarify usage of private key in dh

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Wednesday, May 25, 2022 8:10 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 38/40] 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>
> > > > ---
> > > >  lib/cryptodev/rte_crypto_asym.h | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > b/lib/cryptodev/rte_crypto_asym.h index 01b1fdd074..a6bb70ca3f
> > > > 100644
> > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > @@ -459,6 +459,10 @@ struct rte_crypto_dh_op_param {
> > > >  	 * Output generated private key when op_type is
> > > >  	 * DH PRIVATE_KEY_GENERATION
> > > >  	 * Input for RTE_CRYPTO_ASYM_KE_SHARED_SECRET_COMPUTE
> > > > +	 * In case priv_key.length is 0 and op_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.
> > >
> > > What is expected for the device which does not support this?
> > > How will the application decide?
> > [Arek] - it is similar issue as in DSA/ECDSA 'k'. Or we will add some
> > PMD flag to determine if PMD is CSRNG capable or it will be stated in
> > PMD .rst file. If device does not support random, packet will be
> > rejected (send to response queue with NOT_PROCESSED). This comment
> should probably be added.
> 
> I believe this can be covered in the capability patch that you are working on.
+ 1

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Anoob Joseph]

Hi Arek, Akhil,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Wednesday, May 25, 2022 12:06 PM
> To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> <anoobj@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> 
> 
> > -----Original Message-----
> > From: Akhil Goyal <gakhil@marvell.com>
> > Sent: Wednesday, May 25, 2022 8:06 AM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org;
> > Kiran Kumar Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > <anoobj@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> > > > > - removed asymnetric crypto xform next field.
> > > > > Rationale behind having chaining in symmetric crypto was a fact
> > > > > that encryption and authentication are usually done on the same
> > > > > set of data independent of algorithm.
> > > > > HW usually will be able to handle it in one PCI call.
> > > > > In asymmetric there is no such relation between algorithms,
> > > > > therefore next field would be useless.
> > > > >
> > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > >
> > > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > > private key generation followed by public generation.
> > > [Arek] And why do chaining when this can be done even with one bit flag.
> > >
> > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > please confirm.
> >
> > If we are removing it, then documentation should be in sync.
> [Arek] - although, we may keep it for now, I am not dropping it in v2. DH priv +
> pub can be done with priv_key.len = 0 -> similar as 'k' in ecdsa when k.data =
> NULL.
> But I do not see any situation for now it will be  useful, it may be dropped later if
> not application found.
> >
> > > Also, currently API does not support chaining of
> > > > symmetric and asymmetric crypto xforms.
> > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > asymmetric. One I can think of was once proposed DH + DSA
> > > integration for random number. But not much else, although we can
> > > keep it around for a
> > while.
> >
> > Yes it is highly unlikely to use this combination.

[Anoob] We may need this support when we add EdDSA support. That would involve a asymmetric operation after hash is generated (symmetric). 
https://en.wikipedia.org/wiki/EdDSA#Ed25519

And, asymmetric chaining may become useful when we have PMDs capable of doing more operations together (like the case with EdDSA). So my preference would be to retain the 'next' field in asym crypto xform.
 
> >
> > > >
> > > > > ---
> > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > >
> > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > > 100644
> > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > >   * Structure describing asym xforms.
> > > > >   */
> > > > >  struct rte_crypto_asym_xform {
> > > > > -	struct rte_crypto_asym_xform *next;
> > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > >  	/**< Asymmetric crypto transform */
> > > > >
> > > > > --
> > > > > 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Kusztal, ArkadiuszX]

Hi Anoob,

Sorry, I don't know how I have missed this email!

> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Wednesday, May 25, 2022 9:06 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> Hi Arek, Akhil,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > Sent: Wednesday, May 25, 2022 12:06 PM
> > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > <anoobj@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Akhil Goyal <gakhil@marvell.com>
> > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>;
> > > Anoob Joseph <anoobj@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > > > > > - removed asymnetric crypto xform next field.
> > > > > > Rationale behind having chaining in symmetric crypto was a
> > > > > > fact that encryption and authentication are usually done on
> > > > > > the same set of data independent of algorithm.
> > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > In asymmetric there is no such relation between algorithms,
> > > > > > therefore next field would be useless.
> > > > > >
> > > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > >
> > > > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > > > private key generation followed by public generation.
> > > > [Arek] And why do chaining when this can be done even with one bit flag.
> > > >
> > > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > > please confirm.
> > >
> > > If we are removing it, then documentation should be in sync.
> > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k' in
> > ecdsa when k.data = NULL.
> > But I do not see any situation for now it will be  useful, it may be
> > dropped later if not application found.
> > >
> > > > Also, currently API does not support chaining of
> > > > > symmetric and asymmetric crypto xforms.
> > > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > > asymmetric. One I can think of was once proposed DH + DSA
> > > > integration for random number. But not much else, although we can
> > > > keep it around for a
> > > while.
> > >
> > > Yes it is highly unlikely to use this combination.
> 
> [Anoob] We may need this support when we add EdDSA support. That would
> involve a asymmetric operation after hash is generated (symmetric).
> https://en.wikipedia.org/wiki/EdDSA#Ed25519
> 
> And, asymmetric chaining may become useful when we have PMDs capable of
> doing more operations together (like the case with EdDSA). So my preference
> would be to retain the 'next' field in asym crypto xform.
[Arek] - that is very good point, however to implement EdDSA as chaining would mean that:
- we need to implement EdDSA internals in DPDK
- and EdDSA (in hash option, where actually picking hash would have sense) is not one hash but multiple hash operation, so we would have to had multiple chaining with operations in between
- and we would have to compute R and S separately.
- If PMD does not support one-pass EdDSA - well this is something that should definitely discuss, but having any crypto internals in DPDK is not probably an option?

> 
> > >
> > > > >
> > > > > > ---
> > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > >  1 file changed, 2 deletions(-)
> > > > > >
> > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > > > 100644
> > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > >   * Structure describing asym xforms.
> > > > > >   */
> > > > > >  struct rte_crypto_asym_xform {
> > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > >  	/**< Asymmetric crypto transform */
> > > > > >
> > > > > > --
> > > > > > 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Friday, May 27, 2022 8:31 AM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> Hi Anoob,
> 
> Sorry, I don't know how I have missed this email!
> 
> > -----Original Message-----
> > From: Anoob Joseph <anoobj@marvell.com>
> > Sent: Wednesday, May 25, 2022 9:06 AM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> > Hi Arek, Akhil,
> >
> > Please see inline.
> >
> > Thanks,
> > Anoob
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > <anoobj@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>;
> > > > Anoob Joseph <anoobj@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > Rationale behind having chaining in symmetric crypto was a
> > > > > > > fact that encryption and authentication are usually done on
> > > > > > > the same set of data independent of algorithm.
> > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > In asymmetric there is no such relation between algorithms,
> > > > > > > therefore next field would be useless.
> > > > > > >
> > > > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > > >
> > > > > > Please check documentation
> "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > Currently supported asymmetric crypto chaining is
> > > > > > Diffie-Hellman private key generation followed by public generation.
> > > > > [Arek] And why do chaining when this can be done even with one bit flag.
> > > > >
> > > > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > > > please confirm.
> > > >
> > > > If we are removing it, then documentation should be in sync.
> > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k' in
> > > ecdsa when k.data = NULL.
> > > But I do not see any situation for now it will be  useful, it may be
> > > dropped later if not application found.
> > > >
> > > > > Also, currently API does not support chaining of
> > > > > > symmetric and asymmetric crypto xforms.
> > > > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > > > asymmetric. One I can think of was once proposed DH + DSA
> > > > > integration for random number. But not much else, although we
> > > > > can keep it around for a
> > > > while.
> > > >
> > > > Yes it is highly unlikely to use this combination.
> >
> > [Anoob] We may need this support when we add EdDSA support. That would
> > involve a asymmetric operation after hash is generated (symmetric).
> > https://en.wikipedia.org/wiki/EdDSA#Ed25519
> >
> > And, asymmetric chaining may become useful when we have PMDs capable
> > of doing more operations together (like the case with EdDSA). So my
> > preference would be to retain the 'next' field in asym crypto xform.
> [Arek] - that is very good point, however to implement EdDSA as chaining would
> mean that:
> - we need to implement EdDSA internals in DPDK
> - and EdDSA (in hash option, where actually picking hash would have sense) is
> not one hash but multiple hash operation, so we would have to had multiple
> chaining with operations in between
> - and we would have to compute R and S separately.
> - If PMD does not support one-pass EdDSA - well this is something that should
> definitely discuss, but having any crypto internals in DPDK is not probably an
> option?
[Arek] - but, I have kept 'next' in later changes.
> 
> >
> > > >
> > > > > >
> > > > > > > ---
> > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > >  1 file changed, 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > 100644
> > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > >   * Structure describing asym xforms.
> > > > > > >   */
> > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > >
> > > > > > > --
> > > > > > > 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Friday, May 27, 2022 8:40 AM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> 
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Friday, May 27, 2022 8:31 AM
> > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> > Hi Anoob,
> >
> > Sorry, I don't know how I have missed this email!
> >
> > > -----Original Message-----
> > > From: Anoob Joseph <anoobj@marvell.com>
> > > Sent: Wednesday, May 25, 2022 9:06 AM
> > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > <kirankumark@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > > Hi Arek, Akhil,
> > >
> > > Please see inline.
> > >
> > > Thanks,
> > > Anoob
> > >
> > > > -----Original Message-----
> > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > > <anoobj@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > > dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > > <kirankumark@marvell.com>; Anoob Joseph <anoobj@marvell.com>
> > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > next xform
> > > > >
> > > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > > Rationale behind having chaining in symmetric crypto was a
> > > > > > > > fact that encryption and authentication are usually done
> > > > > > > > on the same set of data independent of algorithm.
> > > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > > In asymmetric there is no such relation between
> > > > > > > > algorithms, therefore next field would be useless.
> > > > > > > >
> > > > > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > > > >
> > > > > > > Please check documentation
> > "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > > Currently supported asymmetric crypto chaining is
> > > > > > > Diffie-Hellman private key generation followed by public generation.
> > > > > > [Arek] And why do chaining when this can be done even with one bit
> flag.
> > > > > >
> > > > > I believe it is OK to remove next. @Kiran Kumar
> > > > > Kokkilagadda/Anoob please confirm.
> > > > >
> > > > > If we are removing it, then documentation should be in sync.
> > > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k'
> > > > in ecdsa when k.data = NULL.
> > > > But I do not see any situation for now it will be  useful, it may
> > > > be dropped later if not application found.
> > > > >
> > > > > > Also, currently API does not support chaining of
> > > > > > > symmetric and asymmetric crypto xforms.
> > > > > > [Arek] - This is one unlikely scenario to combine symmetric
> > > > > > and asymmetric. One I can think of was once proposed DH + DSA
> > > > > > integration for random number. But not much else, although we
> > > > > > can keep it around for a
> > > > > while.
> > > > >
> > > > > Yes it is highly unlikely to use this combination.
> > >
> > > [Anoob] We may need this support when we add EdDSA support. That
> > > would involve a asymmetric operation after hash is generated (symmetric).
> > > https://en.wikipedia.org/wiki/EdDSA#Ed25519
> > >
> > > And, asymmetric chaining may become useful when we have PMDs capable
> > > of doing more operations together (like the case with EdDSA). So my
> > > preference would be to retain the 'next' field in asym crypto xform.
> > [Arek] - that is very good point, however to implement EdDSA as
> > chaining would mean that:
> > - we need to implement EdDSA internals in DPDK
> > - and EdDSA (in hash option, where actually picking hash would have
> > sense) is not one hash but multiple hash operation, so we would have
> > to had multiple chaining with operations in between
> > - and we would have to compute R and S separately.
> > - If PMD does not support one-pass EdDSA - well this is something that
> > should definitely discuss, but having any crypto internals in DPDK is
> > not probably an option?
> [Arek] - but, I have kept 'next' in later changes.
[Arek] - additionally if EdDSAhash one-pass used it is enough to have field with hash, an that's all - only information needed.
Normally EdDSA hash is fixed to SHA256 or BLAKE but for EdDSAhash option there is one additional hash - so enum in Ed struct should be enough.
> >
> > >
> > > > >
> > > > > > >
> > > > > > > > ---
> > > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > > 100644
> > > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > > >   * Structure describing asym xforms.
> > > > > > > >   */
> > > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Anoob Joseph]

Hi Arek,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Friday, May 27, 2022 12:26 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> 
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Friday, May 27, 2022 8:40 AM
> > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX
> > > Sent: Friday, May 27, 2022 8:31 AM
> > > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > <kirankumark@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > > Hi Anoob,
> > >
> > > Sorry, I don't know how I have missed this email!
> > >
> > > > -----Original Message-----
> > > > From: Anoob Joseph <anoobj@marvell.com>
> > > > Sent: Wednesday, May 25, 2022 9:06 AM
> > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil
> > > > Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > <kirankumark@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > > Hi Arek, Akhil,
> > > >
> > > > Please see inline.
> > > >
> > > > Thanks,
> > > > Anoob
> > > >
> > > > > -----Original Message-----
> > > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > > > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > > > <anoobj@marvell.com>
> > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > next xform
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > > > dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > > > <kirankumark@marvell.com>; Anoob Joseph <anoobj@marvell.com>
> > > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > > next xform
> > > > > >
> > > > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > > > Rationale behind having chaining in symmetric crypto was
> > > > > > > > > a fact that encryption and authentication are usually
> > > > > > > > > done on the same set of data independent of algorithm.
> > > > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > > > In asymmetric there is no such relation between
> > > > > > > > > algorithms, therefore next field would be useless.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Arek Kusztal
> > > > > > > > > <arkadiuszx.kusztal@intel.com>
> > > > > > > >
> > > > > > > > Please check documentation
> > > "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > > > Currently supported asymmetric crypto chaining is
> > > > > > > > Diffie-Hellman private key generation followed by public
> generation.
> > > > > > > [Arek] And why do chaining when this can be done even with
> > > > > > > one bit
> > flag.
> > > > > > >
> > > > > > I believe it is OK to remove next. @Kiran Kumar
> > > > > > Kokkilagadda/Anoob please confirm.
> > > > > >
> > > > > > If we are removing it, then documentation should be in sync.
> > > > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k'
> > > > > in ecdsa when k.data = NULL.
> > > > > But I do not see any situation for now it will be  useful, it
> > > > > may be dropped later if not application found.
> > > > > >
> > > > > > > Also, currently API does not support chaining of
> > > > > > > > symmetric and asymmetric crypto xforms.
> > > > > > > [Arek] - This is one unlikely scenario to combine symmetric
> > > > > > > and asymmetric. One I can think of was once proposed DH +
> > > > > > > DSA integration for random number. But not much else,
> > > > > > > although we can keep it around for a
> > > > > > while.
> > > > > >
> > > > > > Yes it is highly unlikely to use this combination.
> > > >
> > > > [Anoob] We may need this support when we add EdDSA support. That
> > > > would involve a asymmetric operation after hash is generated (symmetric).
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.
> > > > org_wiki_EdDSA-
> 23Ed25519&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> > > > rwwviRSxyLWs2n6B-
> WYLn1v9SyTMrT5EQqh2TU&m=bddkY8ZMMGGHjFFvgGsyhfgWB
> > > > fuX0hpwqTdpgCAo_ngHINhO6zwLB-
> mUxNU8xu6p&s=3vFaBffulofGlfAPsjnaaUZa
> > > > V01o6k8XWzwNFWHQzvY&e=
> > > >
> > > > And, asymmetric chaining may become useful when we have PMDs
> > > > capable of doing more operations together (like the case with
> > > > EdDSA). So my preference would be to retain the 'next' field in asym crypto
> xform.
> > > [Arek] - that is very good point, however to implement EdDSA as
> > > chaining would mean that:
> > > - we need to implement EdDSA internals in DPDK
> > > - and EdDSA (in hash option, where actually picking hash would have
> > > sense) is not one hash but multiple hash operation, so we would have
> > > to had multiple chaining with operations in between
> > > - and we would have to compute R and S separately.
> > > - If PMD does not support one-pass EdDSA - well this is something
> > > that should definitely discuss, but having any crypto internals in
> > > DPDK is not probably an option?
> > [Arek] - but, I have kept 'next' in later changes.
> [Arek] - additionally if EdDSAhash one-pass used it is enough to have field with
> hash, an that's all - only information needed.
> Normally EdDSA hash is fixed to SHA256 or BLAKE but for EdDSAhash option
> there is one additional hash - so enum in Ed struct should be enough.

[Anoob] I'm also not clear about what would be the right abstraction. As you described for EdDSA, it can be just a flag. But we may need to revisit this when we add such kind of algos. So my suggestion was to not remove 'next' field just yet. We can revisit this sometime later.

Thanks for agreeing to the suggestion and keeping the field.
 
> > >
> > > >
> > > > > >
> > > > > > > >
> > > > > > > > > ---
> > > > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > > > 100644
> > > > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > > > >   * Structure describing asym xforms.
> > > > > > > > >   */
> > > > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 2.13.6

RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Friday, May 27, 2022 9:28 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> Hi Arek,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > Sent: Friday, May 27, 2022 12:26 PM
> > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX
> > > Sent: Friday, May 27, 2022 8:40 AM
> > > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > <kirankumark@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kusztal, ArkadiuszX
> > > > Sent: Friday, May 27, 2022 8:31 AM
> > > > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > <kirankumark@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > > Hi Anoob,
> > > >
> > > > Sorry, I don't know how I have missed this email!
> > > >
> > > > > -----Original Message-----
> > > > > From: Anoob Joseph <anoobj@marvell.com>
> > > > > Sent: Wednesday, May 25, 2022 9:06 AM
> > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil
> > > > > Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > > > Kokkilagadda <kirankumark@marvell.com>
> > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > next xform
> > > > >
> > > > > Hi Arek, Akhil,
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Thanks,
> > > > > Anoob
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > > > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran
> > > > > > Kumar Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > > > > <anoobj@marvell.com>
> > > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > > next xform
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > > > > dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > > > > <kirankumark@marvell.com>; Anoob Joseph <anoobj@marvell.com>
> > > > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym
> > > > > > > crypto next xform
> > > > > > >
> > > > > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > > > > Rationale behind having chaining in symmetric crypto
> > > > > > > > > > was a fact that encryption and authentication are
> > > > > > > > > > usually done on the same set of data independent of algorithm.
> > > > > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > > > > In asymmetric there is no such relation between
> > > > > > > > > > algorithms, therefore next field would be useless.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Arek Kusztal
> > > > > > > > > > <arkadiuszx.kusztal@intel.com>
> > > > > > > > >
> > > > > > > > > Please check documentation
> > > > "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > > > > Currently supported asymmetric crypto chaining is
> > > > > > > > > Diffie-Hellman private key generation followed by public
> > generation.
> > > > > > > > [Arek] And why do chaining when this can be done even with
> > > > > > > > one bit
> > > flag.
> > > > > > > >
> > > > > > > I believe it is OK to remove next. @Kiran Kumar
> > > > > > > Kokkilagadda/Anoob please confirm.
> > > > > > >
> > > > > > > If we are removing it, then documentation should be in sync.
> > > > > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > > > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k'
> > > > > > in ecdsa when k.data = NULL.
> > > > > > But I do not see any situation for now it will be  useful, it
> > > > > > may be dropped later if not application found.
> > > > > > >
> > > > > > > > Also, currently API does not support chaining of
> > > > > > > > > symmetric and asymmetric crypto xforms.
> > > > > > > > [Arek] - This is one unlikely scenario to combine
> > > > > > > > symmetric and asymmetric. One I can think of was once
> > > > > > > > proposed DH + DSA integration for random number. But not
> > > > > > > > much else, although we can keep it around for a
> > > > > > > while.
> > > > > > >
> > > > > > > Yes it is highly unlikely to use this combination.
> > > > >
> > > > > [Anoob] We may need this support when we add EdDSA support. That
> > > > > would involve a asymmetric operation after hash is generated
> (symmetric).
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.
> > > > > org_wiki_EdDSA-
> > 23Ed25519&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> > > > > rwwviRSxyLWs2n6B-
> > WYLn1v9SyTMrT5EQqh2TU&m=bddkY8ZMMGGHjFFvgGsyhfgWB
> > > > > fuX0hpwqTdpgCAo_ngHINhO6zwLB-
> > mUxNU8xu6p&s=3vFaBffulofGlfAPsjnaaUZa
> > > > > V01o6k8XWzwNFWHQzvY&e=
> > > > >
> > > > > And, asymmetric chaining may become useful when we have PMDs
> > > > > capable of doing more operations together (like the case with
> > > > > EdDSA). So my preference would be to retain the 'next' field in
> > > > > asym crypto
> > xform.
> > > > [Arek] - that is very good point, however to implement EdDSA as
> > > > chaining would mean that:
> > > > - we need to implement EdDSA internals in DPDK
> > > > - and EdDSA (in hash option, where actually picking hash would
> > > > have
> > > > sense) is not one hash but multiple hash operation, so we would
> > > > have to had multiple chaining with operations in between
> > > > - and we would have to compute R and S separately.
> > > > - If PMD does not support one-pass EdDSA - well this is something
> > > > that should definitely discuss, but having any crypto internals in
> > > > DPDK is not probably an option?
> > > [Arek] - but, I have kept 'next' in later changes.
> > [Arek] - additionally if EdDSAhash one-pass used it is enough to have
> > field with hash, an that's all - only information needed.
> > Normally EdDSA hash is fixed to SHA256 or BLAKE but for EdDSAhash
> > option there is one additional hash - so enum in Ed struct should be enough.
> 
> [Anoob] I'm also not clear about what would be the right abstraction. As you
> described for EdDSA, it can be just a flag. But we may need to revisit this when
> we add such kind of algos. So my suggestion was to not remove 'next' field just
> yet. We can revisit this sometime later.
> 
> Thanks for agreeing to the suggestion and keeping the field.
[Arek] - I considered few Ed options:
- or to have
Ed25519_op, Ed448_op,
- or 
EdDSA with
Curve_is = curve25519 (29) | curve448 (30)

By default hash algorithms are SHA2-56 and BLAKE accordingly.
But for preHash Ed there would be hash field:
Hash = [ rte_crypto_auth ]

/* When preHash (PH(M)) used this field is obligatory etc... */
> 
> > > >
> > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > > > > 100644
> > > > > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > > > > >   * Structure describing asym xforms.
> > > > > > > > > >   */
> > > > > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 2.13.6