[dpdk-dev] [PATCH v2 0/3]Rework API for RSA algorithm in asymmetric crypto

[dpdk-dev] [PATCH v2 0/3]Rework API for RSA algorithm in asymmetric crypto

[Arek Kusztal]

Most things from v1 were simplified according to Shally adn Fiona comments.
No more rfc details in comments and some things were shortened.
There is no more struct for padding too, but only union for
PSS and OAEP.
Added test case for padding none with encryption (pkcs padding is done in test)
ps. I will send signature padding none signature case soon.

Major changes comparing to current version:
- Cipher field was introduced
- Added guide to use none padding
- Field for singature verification when padding none selected was added
	(as there is no Public-Decrypt)
- Padding union was created
- PKCS1-v1_5 Block type 0 was removed
- Fixed all wrong comments (prime numbers etc.)

v2:
- Field for singature verification when padding none selected was added
- Removed details from RFC
- Simplified padding struct
- Added padding none test case

Arek Kusztal (3):
  cryptodev: rework api of rsa algorithm
  crypto/openssl: rework openssl rsa implementation
  test: rework rsa test implementation

 app/test/test_cryptodev_asym.c           |  44 +++++++--
 app/test/test_cryptodev_asym_util.h      |  52 +++++++++++
 drivers/crypto/openssl/rte_openssl_pmd.c |  67 ++++++++------
 lib/librte_cryptodev/rte_crypto_asym.h   | 150 ++++++++++++++++++++++++-------
 4 files changed, 243 insertions(+), 70 deletions(-)

-- 
2.1.0

[dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Arek Kusztal]

This patch reworks API of RSA algorithm.
Major changes:
- Cipher field was introduced
- Field for singature verification when padding none selected was added
- Padding union was created
- PKCS1-v1_5 Block type 0 was removed
- Fixed comments about prime numbers
- Added guide to use none padding

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

diff --git a/lib/librte_cryptodev/rte_crypto_asym.h b/lib/librte_cryptodev/rte_crypto_asym.h
index 8672f21..486399c 100644
--- a/lib/librte_cryptodev/rte_crypto_asym.h
+++ b/lib/librte_cryptodev/rte_crypto_asym.h
@@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
  */
 enum rte_crypto_rsa_padding_type {
 	RTE_CRYPTO_RSA_PADDING_NONE = 0,
-	/**< RSA no padding scheme */
-	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
-	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
-	 * as described in rfc2313
+	/**< RSA no padding scheme.
+	 * In this case user is responsible for provision and verification
+	 * of padding.
 	 */
-	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
-	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
-	 * as described in rfc2313
-	 */
-	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
-	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
-	 * as described in rfc2313
+	RTE_CRYPTO_RSA_PADDING_PKCS1,
+	/**< 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 */
+	/**< RSA PKCS#1 OAEP padding scheme, can be used only for encryption/
+	 * decryption.
+	 */
 	RTE_CRYPTO_RSA_PADDING_PSS,
-	/**< RSA PKCS#1 PSS padding scheme */
+	/**< RSA PKCS#1 PSS padding scheme, can be used only for signatures.
+	 */
 	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
 };
 
@@ -199,8 +197,8 @@ struct rte_crypto_rsa_priv_key_qt {
  */
 struct rte_crypto_rsa_xform {
 	rte_crypto_param n;
-	/**< n - Prime modulus
-	 * Prime modulus data of RSA operation in Octet-string network
+	/**< n - Modulus
+	 * Modulus data of RSA operation in Octet-string network
 	 * byte order format.
 	 */
 
@@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
 	/**<
 	 * Pointer to data
 	 * - to be encrypted for RSA public encrypt.
-	 * - to be decrypted for RSA private decrypt.
 	 * - to be signed for RSA sign generation.
 	 * - to be authenticated for RSA sign verification.
+	 *
+	 * Octet-string network byte order format.
+	 *
+	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
+	 * operation, and output to RTE_CRYPTO_ASYM_OP_DECRYPT operation.
+	 *
+	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used length in bytes
+	 * of this field needs to be greater or equal to the length of
+	 * corresponding RSA key in bytes.
+	 *
+	 * When padding field is set to RTE_CRYPTO_RSA_PADDING_NONE
+	 * returned data size will be equal to the size of RSA key
+	 * in bytes. All leading zeroes will be preserved.
+	 */
+
+	rte_crypto_param cipher;
+	/**<
+	 * Pointer to data
+	 * - to be decrypted for RSA private decrypt.
+	 *
+	 * Octet-string network byte order format.
+	 *
+	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
+	 * operation, and output to RTE_CRYPTO_ASYM_OP_ENCRYPT operation.
+	 *
+	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used length in bytes
+	 * of this field needs to be greater or equal to the length of
+	 * corresponding RSA key in bytes.
 	 */
 
 	rte_crypto_param sign;
@@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
 	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
 	 * over-written with generated signature.
 	 *
-	 * Length of the signature data will be equal to the
-	 * RSA prime modulus length.
+	 * Octet-string network byte order format.
+	 *
+	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length in bytes
+	 * of this field needs to be greater or equal to the length of
+	 * corresponding RSA key in bytes.
 	 */
 
-	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
+	rte_crypto_param message_to_verify;
+	/**<
+	 * Pointer to the message 'm' that was signed with
+	 * RSASP1 in RFC8017. It is the result of operation RSAVP1
+	 * defined in RFC8017, where field `sign` is the input
+	 * parameter `s`.
+	 *
+	 * Used only when padding type is set to RTE_CRYPTO_RSA_PADDING_NONE
+	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
+	 *
+	 * Returned data size will be equal to the size of RSA key
+	 * in bytes. All leading zeroes will be preserved.
+	 *
+	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used length in bytes
+	 * of this field needs to be greater or equal to the length of
+	 * corresponding RSA key in bytes.
 	 */
 
-	enum rte_crypto_auth_algorithm mgf1md;
+	enum rte_crypto_rsa_padding_type padding;
+	/**<
+	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
+	 * driver will distinguish between block type basing
+	 * on rte_crypto_asym_op_type of the operation.
+	 *
+	 * Which padding type is supported by the driver can be
+	 * found in in specific driver guide.
+	 */
+	enum rte_crypto_auth_algorithm padding_hash;
+	/**<
+	 * -	For PKCS1-v1_5 signature (Block type 01) this field
+	 * represents hash function that will be used to create
+	 * message hash.
+	 *
+	 * -	For OAEP this field represents hash function that will
+	 * be used to produce hash of the optional label.
+	 *
+	 * -	For PSS this field represents hash function that will be used
+	 * to produce hash (mHash) of message M and of M' (padding1 | mHash | salt)
+	 *
+	 * If not set driver will use default value.
+	 */
+	union {
+		struct {
+			enum rte_crypto_auth_algorithm mgf;
+			/**<
+			 * Mask genereation function hash algorithm.
+			 *
+			 * If not set driver will use default value.
+			 */
+			rte_crypto_param label;
+			/**<
+			 * Optional label, if driver does not support
+			 * this option, optional label is just an empty string.
+			 */
+		} OAEP;
+		struct {
+			enum rte_crypto_auth_algorithm mgf;
+			/**<
+			 * Mask genereation function hash algorithm.
+			 *
+			 * If not set driver will use default value.
+			 */
+			int seed_len;
+			/**<
+			 * Intended seed length. Nagative number has special
+			 * value as follows:
+			 * -1 : seed len = length of output ot used hash function
+			 * -2 : seed len is maximized
+			 */
+		} PSS;
+	};
 	/**<
-	 * 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
+	 * Padding type of RSA crypto operation.
+	 * What are random number generator requirements and prequisites
+	 * can be found specific driver guide.
 	 */
 };
 
-- 
2.1.0

Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Kusztal, ArkadiuszX]

+ Shally's Marvell address.
Shally, Fiona can you take a look?

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, July 3, 2019 5:38 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> shally.verma@caviumnetworks.com; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> 
> This patch reworks API of RSA algorithm.
> Major changes:
> - Cipher field was introduced
> - Field for singature verification when padding none selected was added
> - Padding union was created
> - PKCS1-v1_5 Block type 0 was removed
> - Fixed comments about prime numbers
> - Added guide to use none padding
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/librte_cryptodev/rte_crypto_asym.h | 150
> ++++++++++++++++++++++++++-------
>  1 file changed, 118 insertions(+), 32 deletions(-)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> b/lib/librte_cryptodev/rte_crypto_asym.h
> index 8672f21..486399c 100644
> --- a/lib/librte_cryptodev/rte_crypto_asym.h
> +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> @@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
>   */
>  enum rte_crypto_rsa_padding_type {
>  	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> -	/**< RSA no padding scheme */
> -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
> -	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
> -	 * as described in rfc2313
> +	/**< RSA no padding scheme.
> +	 * In this case user is responsible for provision and verification
> +	 * of padding.
>  	 */
> -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
> -	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
> -	 * as described in rfc2313
> -	 */
> -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
> -	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
> -	 * as described in rfc2313
> +	RTE_CRYPTO_RSA_PADDING_PKCS1,
> +	/**< 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 */
> +	/**< RSA PKCS#1 OAEP padding scheme, can be used only for
> encryption/
> +	 * decryption.
> +	 */
>  	RTE_CRYPTO_RSA_PADDING_PSS,
> -	/**< RSA PKCS#1 PSS padding scheme */
> +	/**< RSA PKCS#1 PSS padding scheme, can be used only for
> signatures.
> +	 */
>  	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
>  };
> 
> @@ -199,8 +197,8 @@ struct rte_crypto_rsa_priv_key_qt {
>   */
>  struct rte_crypto_rsa_xform {
>  	rte_crypto_param n;
> -	/**< n - Prime modulus
> -	 * Prime modulus data of RSA operation in Octet-string network
> +	/**< n - Modulus
> +	 * Modulus data of RSA operation in Octet-string network
>  	 * byte order format.
>  	 */
> 
> @@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
>  	/**<
>  	 * Pointer to data
>  	 * - to be encrypted for RSA public encrypt.
> -	 * - to be decrypted for RSA private decrypt.
>  	 * - to be signed for RSA sign generation.
>  	 * - to be authenticated for RSA sign verification.
> +	 *
> +	 * Octet-string network byte order format.
> +	 *
> +	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
> +	 * operation, and output to RTE_CRYPTO_ASYM_OP_DECRYPT
> operation.
> +	 *
> +	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used length in
> bytes
> +	 * of this field needs to be greater or equal to the length of
> +	 * corresponding RSA key in bytes.
> +	 *
> +	 * When padding field is set to RTE_CRYPTO_RSA_PADDING_NONE
> +	 * returned data size will be equal to the size of RSA key
> +	 * in bytes. All leading zeroes will be preserved.
> +	 */
> +
> +	rte_crypto_param cipher;
> +	/**<
> +	 * Pointer to data
> +	 * - to be decrypted for RSA private decrypt.
> +	 *
> +	 * Octet-string network byte order format.
> +	 *
> +	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
> +	 * operation, and output to RTE_CRYPTO_ASYM_OP_ENCRYPT
> operation.
> +	 *
> +	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used length in
> bytes
> +	 * of this field needs to be greater or equal to the length of
> +	 * corresponding RSA key in bytes.
>  	 */
> 
>  	rte_crypto_param sign;
> @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
>  	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
>  	 * over-written with generated signature.
>  	 *
> -	 * Length of the signature data will be equal to the
> -	 * RSA prime modulus length.
> +	 * Octet-string network byte order format.
> +	 *
> +	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length in bytes
> +	 * of this field needs to be greater or equal to the length of
> +	 * corresponding RSA key in bytes.
>  	 */
> 
> -	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
> +	rte_crypto_param message_to_verify;
> +	/**<
> +	 * Pointer to the message 'm' that was signed with
> +	 * RSASP1 in RFC8017. It is the result of operation RSAVP1
> +	 * defined in RFC8017, where field `sign` is the input
> +	 * parameter `s`.
> +	 *
> +	 * Used only when padding type is set to
> RTE_CRYPTO_RSA_PADDING_NONE
> +	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
> +	 *
> +	 * Returned data size will be equal to the size of RSA key
> +	 * in bytes. All leading zeroes will be preserved.
> +	 *
> +	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used length in
> bytes
> +	 * of this field needs to be greater or equal to the length of
> +	 * corresponding RSA key in bytes.
>  	 */
> 
> -	enum rte_crypto_auth_algorithm mgf1md;
> +	enum rte_crypto_rsa_padding_type padding;
> +	/**<
> +	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
> +	 * driver will distinguish between block type basing
> +	 * on rte_crypto_asym_op_type of the operation.
> +	 *
> +	 * Which padding type is supported by the driver can be
> +	 * found in in specific driver guide.
> +	 */
> +	enum rte_crypto_auth_algorithm padding_hash;
> +	/**<
> +	 * -	For PKCS1-v1_5 signature (Block type 01) this field
> +	 * represents hash function that will be used to create
> +	 * message hash.
> +	 *
> +	 * -	For OAEP this field represents hash function that will
> +	 * be used to produce hash of the optional label.
> +	 *
> +	 * -	For PSS this field represents hash function that will be used
> +	 * to produce hash (mHash) of message M and of M' (padding1 |
> mHash | salt)
> +	 *
> +	 * If not set driver will use default value.
> +	 */
> +	union {
> +		struct {
> +			enum rte_crypto_auth_algorithm mgf;
> +			/**<
> +			 * Mask genereation function hash algorithm.
> +			 *
> +			 * If not set driver will use default value.
> +			 */
> +			rte_crypto_param label;
> +			/**<
> +			 * Optional label, if driver does not support
> +			 * this option, optional label is just an empty string.
> +			 */
> +		} OAEP;
> +		struct {
> +			enum rte_crypto_auth_algorithm mgf;
> +			/**<
> +			 * Mask genereation function hash algorithm.
> +			 *
> +			 * If not set driver will use default value.
> +			 */
> +			int seed_len;
> +			/**<
> +			 * Intended seed length. Nagative number has special
> +			 * value as follows:
> +			 * -1 : seed len = length of output ot used hash
> function
> +			 * -2 : seed len is maximized
> +			 */
> +		} PSS;
> +	};
>  	/**<
> -	 * 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
> +	 * Padding type of RSA crypto operation.
> +	 * What are random number generator requirements and prequisites
> +	 * can be found specific driver guide.
>  	 */
>  };
> 
> --
> 2.1.0

Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Shally Verma]

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Thursday, July 4, 2019 6:10 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> shally.verma@caviumnetworks.com; Shally Verma <shallyv@marvell.com>
> Subject: [EXT] RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> 
> External Email
> 
..

> > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > b/lib/librte_cryptodev/rte_crypto_asym.h
> > index 8672f21..486399c 100644
> > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > @@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
> >   */
> >  enum rte_crypto_rsa_padding_type {
> >  	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> > -	/**< RSA no padding scheme */
> > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
> > -	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
> > -	 * as described in rfc2313
> > +	/**< RSA no padding scheme.
> > +	 * In this case user is responsible for provision and verification
> > +	 * of padding.
> >  	 */
> > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
> > -	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
> > -	 * as described in rfc2313
> > -	 */
> > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
> > -	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
> > -	 * as described in rfc2313
> > +	RTE_CRYPTO_RSA_PADDING_PKCS1,
[Shally] My preference would still be to rename as PKCS1_V1.5 to align more to standard

> > +	/**< 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 */
> > +	/**< RSA PKCS#1 OAEP padding scheme, can be used only for
> > encryption/
> > +	 * decryption.
> > +	 */
> >  	RTE_CRYPTO_RSA_PADDING_PSS,
> > -	/**< RSA PKCS#1 PSS padding scheme */
> > +	/**< RSA PKCS#1 PSS padding scheme, can be used only for
> > signatures.
> > +	 */
> >  	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> >  };
> >
...

> >  struct rte_crypto_rsa_xform {
> >  	rte_crypto_param n;
> > -	/**< n - Prime modulus
> > -	 * Prime modulus data of RSA operation in Octet-string network
> > +	/**< n - Modulus
> > +	 * Modulus data of RSA operation in Octet-string network
> >  	 * byte order format.
> >  	 */
> >
> > @@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
> >  	/**<
> >  	 * Pointer to data
> >  	 * - to be encrypted for RSA public encrypt.
> > -	 * - to be decrypted for RSA private decrypt.
> >  	 * - to be signed for RSA sign generation.
> >  	 * - to be authenticated for RSA sign verification.
> > +	 *
> > +	 * Octet-string network byte order format.
> > +	 *
> > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_DECRYPT
> > operation.
> > +	 *
> > +	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used length in
> > bytes
> > +	 * of this field needs to be greater or equal to the length of
> > +	 * corresponding RSA key in bytes.
[Shally] better rephrased " When an op_type ASYM_OP_DECRYPT used, length of output buffer should be greater than  or equal to RSA key modulus length 

> > +	 *
> > +	 * When padding field is set to RTE_CRYPTO_RSA_PADDING_NONE
> > +	 * returned data size will be equal to the size of RSA key
> > +	 * in bytes. All leading zeroes will be preserved.
> > +	 */
[Shally] Is it in context of OP_TYPE_DECRYPT? Even if it is PADDING_NONE,  whether it is encrypted/decrypted, o/p length can vary between 0 .. RSA modulus length - 1 as perf rfc8017

> > +
> > +	rte_crypto_param cipher;
> > +	/**<
> > +	 * Pointer to data
> > +	 * - to be decrypted for RSA private decrypt.
> > +	 *
> > +	 * Octet-string network byte order format.
> > +	 *
> > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
> > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > operation.
> > +	 *
> > +	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used length in
> > bytes
> > +	 * of this field needs to be greater or equal to the length of
> > +	 * corresponding RSA key in bytes.
> >  	 */
[Shally] recommend rephrasing as above

> >
> >  	rte_crypto_param sign;
> > @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
> >  	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
> >  	 * over-written with generated signature.
> >  	 *
> > -	 * Length of the signature data will be equal to the
> > -	 * RSA prime modulus length.
> > +	 * Octet-string network byte order format.
> > +	 *
> > +	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length in bytes
> > +	 * of this field needs to be greater or equal to the length of
> > +	 * corresponding RSA key in bytes.
[Shally] field ---> buffer

> >  	 */
> >
> > -	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
> > +	rte_crypto_param message_to_verify;
> > +	/**<
> > +	 * Pointer to the message 'm' that was signed with
> > +	 * RSASP1 in RFC8017.
>> It is the result of operation RSAVP1
> > +	 * defined in RFC8017, where field `sign` is the input
> > +	 * parameter `s`.
> > +	 *
[Shally] This is confusing. Are you trying to say "this is output to VERIFY_OP ? where output should be same as message buffer provided above? 
If yes, then why not just use that message buffer as an output of VERIFY_OP than adding a new one?

> > +	 * Used only when padding type is set to
> > RTE_CRYPTO_RSA_PADDING_NONE
[Shally] I think regardless of padding, we can provide it as output to sign operation 

> > +	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
> > +	 *
> > +	 * Returned data size will be equal to the size of RSA key
> > +	 * in bytes. All leading zeroes will be preserved.
> > +	 *
[Shally] Again, I think it should instead be mentioned as return size can be 0 ... modulus_len - 1

> > +	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used length in
> > bytes
> > +	 * of this field needs to be greater or equal to the length of
> > +	 * corresponding RSA key in bytes.
> >  	 */
[Shally] There're multiple statements starting with when op_type = VERIFY, can we club them and make description shorter?

> >
> > -	enum rte_crypto_auth_algorithm mgf1md;
> > +	enum rte_crypto_rsa_padding_type padding;
> > +	/**<
> > +	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
> > +	 * driver will distinguish between block type basing
> > +	 * on rte_crypto_asym_op_type of the operation.
> > +	 *
> > +	 * Which padding type is supported by the driver can be
> > +	 * found in in specific driver guide.
[Shally] better rephrase " PMD expose padding type support in its capability. Refer to <struct / API definition>

> > +	 */
> > +	enum rte_crypto_auth_algorithm padding_hash;
> > +	/**<
> > +	 * -	For PKCS1-v1_5 signature (Block type 01) this field
> > +	 * represents hash function that will be used to create
> > +	 * message hash.
[Shally] Currently PMD input pre-computed hash atleast for PKCSV_1.5 .. does your hw support this offload for RSA?
So far , in our testing we observe openssl does it already before calling private/public_key_enc so we should not be mentioning it 
in spec unless any hw provide that combined offload hash + rsa

> > +	 *
> > +	 * -	For OAEP this field represents hash function that will
> > +	 * be used to produce hash of the optional label.
> > +	 *
> > +	 * -	For PSS this field represents hash function that will be used
> > +	 * to produce hash (mHash) of message M and of M' (padding1 |
> > mHash | salt)
> > +	 *
> > +	 * If not set driver will use default value.
> > +	 */
> > +	union {
> > +		struct {
> > +			enum rte_crypto_auth_algorithm mgf;
> > +			/**<
> > +			 * Mask genereation function hash algorithm.
> > +			 *
> > +			 * If not set driver will use default value.
> > +			 */
> > +			rte_crypto_param label;
> > +			/**<
> > +			 * Optional label, if driver does not support
> > +			 * this option, optional label is just an empty string.
> > +			 */
> > +		} OAEP;
> > +		struct {
> > +			enum rte_crypto_auth_algorithm mgf;
[Shally] Though  it is mentioned in current spec, but I have similar doubt here do we need to provide this offload in spec? I will use terms from rfc8017 for further discussion.
  if we have any PMD whose HW provide full RSAES-OAEP offload i.e. doing EME-OAEP followed by RSAEP, 
then it make sense to have it in spec. But if we don't have any PMD example which support that full offload, then we can redefine spec only to support RSAEP and omit md and mgf from spec.



> > +			/**<
> > +			 * Mask genereation function hash algorithm.
> > +			 *
> > +			 * If not set driver will use default value.
> > +			 */
> > +			int seed_len;
> > +			/**<
> > +			 * Intended seed length. Nagative number has
> special
> > +			 * value as follows:
> > +			 * -1 : seed len = length of output ot used hash
> > function
> > +			 * -2 : seed len is maximized
> > +			 */
> > +		} PSS;
> > +	};
> >  	/**<
> > -	 * 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
> > +	 * Padding type of RSA crypto operation.
> > +	 * What are random number generator requirements and prequisites
> > +	 * can be found specific driver guide.
[Shally] I would suggest it to rephrase again " app should refer to PMD guide to check for RNG requirement and other pre-requisites used in hash generation.
However , this feedback is relevant if we are retaining full OAEP offload.

> >  	 */
> >  };
> >
> > --
> > 2.1.0

Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Kusztal, ArkadiuszX]

Hi Shally,

With [AK]

> -----Original Message-----
> From: Shally Verma [mailto:shallyv@marvell.com]
> Sent: Saturday, July 6, 2019 3:14 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> shally.verma@caviumnetworks.com
> Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> 
> 
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > Sent: Thursday, July 4, 2019 6:10 PM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > shally.verma@caviumnetworks.com; Shally Verma <shallyv@marvell.com>
> > Subject: [EXT] RE: [PATCH v2 1/3] cryptodev: rework api of rsa
> > algorithm
> >
> > External Email
> >
> ..
> 
> > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > > b/lib/librte_cryptodev/rte_crypto_asym.h
> > > index 8672f21..486399c 100644
> > > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > > @@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
> > >   */
> > >  enum rte_crypto_rsa_padding_type {
> > >  	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> > > -	/**< RSA no padding scheme */
> > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
> > > -	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
> > > -	 * as described in rfc2313
> > > +	/**< RSA no padding scheme.
> > > +	 * In this case user is responsible for provision and verification
> > > +	 * of padding.
> > >  	 */
> > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
> > > -	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
> > > -	 * as described in rfc2313
> > > -	 */
> > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
> > > -	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
> > > -	 * as described in rfc2313
> > > +	RTE_CRYPTO_RSA_PADDING_PKCS1,
> [Shally] My preference would still be to rename as PKCS1_V1.5 to align more
> to standard
[AK] - Agree.

> 
> > > +	/**< 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 */
> > > +	/**< RSA PKCS#1 OAEP padding scheme, can be used only for
> > > encryption/
> > > +	 * decryption.
> > > +	 */
> > >  	RTE_CRYPTO_RSA_PADDING_PSS,
> > > -	/**< RSA PKCS#1 PSS padding scheme */
> > > +	/**< RSA PKCS#1 PSS padding scheme, can be used only for
> > > signatures.
> > > +	 */
> > >  	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > >  };
> > >
> ...
> 
> > >  struct rte_crypto_rsa_xform {
> > >  	rte_crypto_param n;
> > > -	/**< n - Prime modulus
> > > -	 * Prime modulus data of RSA operation in Octet-string network
> > > +	/**< n - Modulus
> > > +	 * Modulus data of RSA operation in Octet-string network
> > >  	 * byte order format.
> > >  	 */
> > >
> > > @@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
> > >  	/**<
> > >  	 * Pointer to data
> > >  	 * - to be encrypted for RSA public encrypt.
> > > -	 * - to be decrypted for RSA private decrypt.
> > >  	 * - to be signed for RSA sign generation.
> > >  	 * - to be authenticated for RSA sign verification.
> > > +	 *
> > > +	 * Octet-string network byte order format.
> > > +	 *
> > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > operation.
> > > +	 *
> > > +	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used length in
> > > bytes
> > > +	 * of this field needs to be greater or equal to the length of
> > > +	 * corresponding RSA key in bytes.
> [Shally] better rephrased " When an op_type ASYM_OP_DECRYPT used,
> length of output buffer should be greater than  or equal to RSA key modulus
> length
[AK] - RSA key size is a RSA modulus size, but can be changed.
> 
> > > +	 *
> > > +	 * When padding field is set to RTE_CRYPTO_RSA_PADDING_NONE
> > > +	 * returned data size will be equal to the size of RSA key
> > > +	 * in bytes. All leading zeroes will be preserved.
> > > +	 */
> [Shally] Is it in context of OP_TYPE_DECRYPT? Even if it is PADDING_NONE,
> whether it is encrypted/decrypted, o/p length can vary between 0 .. RSA
> modulus length - 1 as perf rfc8017
[AK] 
example. 20 bytes was encrypted with 2048bit key PKCS_1.5
1. Padding PKCS_1.5 set - Upon decryption we return 20 bytes of recovered message.
2. Padding NONE set (padding done by user) - we return 236 bytes of padding (one leading zero) | 20 bytes of message = 256 bytes. 
(like in example test case I have added)
3. Padding NONE set (textbook rsa) - we return 236 bytes of zeroes | 20 bytes of message = 256 bytes.
> 
> > > +
> > > +	rte_crypto_param cipher;
> > > +	/**<
> > > +	 * Pointer to data
> > > +	 * - to be decrypted for RSA private decrypt.
> > > +	 *
> > > +	 * Octet-string network byte order format.
> > > +	 *
> > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > operation.
> > > +	 *
> > > +	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used length in
> > > bytes
> > > +	 * of this field needs to be greater or equal to the length of
> > > +	 * corresponding RSA key in bytes.
> > >  	 */
> [Shally] recommend rephrasing as above
> 
> > >
> > >  	rte_crypto_param sign;
> > > @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
> > >  	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
> > >  	 * over-written with generated signature.
> > >  	 *
> > > -	 * Length of the signature data will be equal to the
> > > -	 * RSA prime modulus length.
> > > +	 * Octet-string network byte order format.
> > > +	 *
> > > +	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length in bytes
> > > +	 * of this field needs to be greater or equal to the length of
> > > +	 * corresponding RSA key in bytes.
> [Shally] field ---> buffer
[AK] - Agreed
> 
> > >  	 */
> > >
> > > -	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
> > > +	rte_crypto_param message_to_verify;
> > > +	/**<
> > > +	 * Pointer to the message 'm' that was signed with
> > > +	 * RSASP1 in RFC8017.
> >> It is the result of operation RSAVP1
> > > +	 * defined in RFC8017, where field `sign` is the input
> > > +	 * parameter `s`.
> > > +	 *
> [Shally] This is confusing. Are you trying to say "this is output to VERIFY_OP ?
> where output should be same as message buffer provided above?
> If yes, then why not just use that message buffer as an output of VERIFY_OP
> than adding a new one?
[AK] - it is output of signature verify (in openssl Public_Decrypt) for PADDING_NONE case. It will be used to check if signature is correct.
In `message` then there could be original message.
But yes, we can use message as an output buffer, I just though it would be more transparent. 
Since user need to verify it by himself it is not that important to keep original message in `message` field, both ways will do.
Waiting for opinions.
> 
> > > +	 * Used only when padding type is set to
> > > RTE_CRYPTO_RSA_PADDING_NONE
> [Shally] I think regardless of padding, we can provide it as output to sign
> operation
[AK] - `Sign` is the place to put signature into.
> 
> > > +	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
> > > +	 *
> > > +	 * Returned data size will be equal to the size of RSA key
> > > +	 * in bytes. All leading zeroes will be preserved.
> > > +	 *
> [Shally] Again, I think it should instead be mentioned as return size can be 0
> ... modulus_len - 1
> 
> > > +	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used length in
> > > bytes
> > > +	 * of this field needs to be greater or equal to the length of
> > > +	 * corresponding RSA key in bytes.
> > >  	 */
> [Shally] There're multiple statements starting with when op_type = VERIFY,
> can we club them and make description shorter?
> 
> > >
> > > -	enum rte_crypto_auth_algorithm mgf1md;
> > > +	enum rte_crypto_rsa_padding_type padding;
> > > +	/**<
> > > +	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
> > > +	 * driver will distinguish between block type basing
> > > +	 * on rte_crypto_asym_op_type of the operation.
> > > +	 *
> > > +	 * Which padding type is supported by the driver can be
> > > +	 * found in in specific driver guide.
> [Shally] better rephrase " PMD expose padding type support in its capability.
> Refer to <struct / API definition>
> 
> > > +	 */
> > > +	enum rte_crypto_auth_algorithm padding_hash;
> > > +	/**<
> > > +	 * -	For PKCS1-v1_5 signature (Block type 01) this field
> > > +	 * represents hash function that will be used to create
> > > +	 * message hash.
> [Shally] Currently PMD input pre-computed hash atleast for PKCSV_1.5 ..
> does your hw support this offload for RSA?
> So far , in our testing we observe openssl does it already before calling
> private/public_key_enc so we should not be mentioning it in spec unless any
> hw provide that combined offload hash + rsa

[AK] - Openssl for PKCS1_5 signature use RSA_private_encrypt which does not handle algorithmIdentifier.
https://www.openssl.org/docs/man1.0.2/man3/RSA_private_encrypt.html
And it is not said what data should be provided for signing. To be properly signed input buffer should be DER encoded concatenation of algorithmIdentifier and message digest.
There would be much work to be done by user then: adding OID, computing Hash of message, ASN.1 call. Waiting for comments on that.

> 
> > > +	 *
> > > +	 * -	For OAEP this field represents hash function that will
> > > +	 * be used to produce hash of the optional label.
> > > +	 *
> > > +	 * -	For PSS this field represents hash function that will be used
> > > +	 * to produce hash (mHash) of message M and of M' (padding1 |
> > > mHash | salt)
> > > +	 *
> > > +	 * If not set driver will use default value.
> > > +	 */
> > > +	union {
> > > +		struct {
> > > +			enum rte_crypto_auth_algorithm mgf;
> > > +			/**<
> > > +			 * Mask genereation function hash algorithm.
> > > +			 *
> > > +			 * If not set driver will use default value.
> > > +			 */
> > > +			rte_crypto_param label;
> > > +			/**<
> > > +			 * Optional label, if driver does not support
> > > +			 * this option, optional label is just an empty string.
> > > +			 */
> > > +		} OAEP;
> > > +		struct {
> > > +			enum rte_crypto_auth_algorithm mgf;
> [Shally] Though  it is mentioned in current spec, but I have similar doubt here
> do we need to provide this offload in spec? I will use terms from rfc8017 for
> further discussion.
>   if we have any PMD whose HW provide full RSAES-OAEP offload i.e. doing
> EME-OAEP followed by RSAEP, then it make sense to have it in spec. But if we
> don't have any PMD example which support that full offload, then we can
> redefine spec only to support RSAEP and omit md and mgf from spec.
> 
[AK] - I thought to add PSS/OAEP to Openssl. Though OAEP and PSS for sure will be implemented 
having custom MGF is not that necessary. Waiting for opinions.

> 
> 
> > > +			/**<
> > > +			 * Mask genereation function hash algorithm.
> > > +			 *
> > > +			 * If not set driver will use default value.
> > > +			 */
> > > +			int seed_len;
> > > +			/**<
> > > +			 * Intended seed length. Nagative number has
> > special
> > > +			 * value as follows:
> > > +			 * -1 : seed len = length of output ot used hash
> > > function
> > > +			 * -2 : seed len is maximized
> > > +			 */
> > > +		} PSS;
> > > +	};
> > >  	/**<
> > > -	 * 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
> > > +	 * Padding type of RSA crypto operation.
> > > +	 * What are random number generator requirements and prequisites
> > > +	 * can be found specific driver guide.
> [Shally] I would suggest it to rephrase again " app should refer to PMD guide
> to check for RNG requirement and other pre-requisites used in hash
> generation.
> However , this feedback is relevant if we are retaining full OAEP offload.
> 
> > >  	 */
> > >  };
> > >
> > > --
> > > 2.1.0

Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Kusztal, ArkadiuszX]

To clarify bit more
With [AK2]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Kusztal, ArkadiuszX
> Sent: Monday, July 8, 2019 7:44 PM
> To: Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> shally.verma@caviumnetworks.com
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa
> algorithm
> 
> Hi Shally,
> 
> With [AK]
> 
> > -----Original Message-----
> > From: Shally Verma [mailto:shallyv@marvell.com]
> > Sent: Saturday, July 6, 2019 3:14 PM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > shally.verma@caviumnetworks.com
> > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> >
> >
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > Sent: Thursday, July 4, 2019 6:10 PM
> > > To: dev@dpdk.org
> > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > shally.verma@caviumnetworks.com; Shally Verma
> <shallyv@marvell.com>
> > > Subject: [EXT] RE: [PATCH v2 1/3] cryptodev: rework api of rsa
> > > algorithm
> > >
> > > External Email
> > >
> > ..
> >
> > > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > index 8672f21..486399c 100644
> > > > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > @@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
> > > >   */
> > > >  enum rte_crypto_rsa_padding_type {
> > > >  	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> > > > -	/**< RSA no padding scheme */
> > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
> > > > -	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
> > > > -	 * as described in rfc2313
> > > > +	/**< RSA no padding scheme.
> > > > +	 * In this case user is responsible for provision and verification
> > > > +	 * of padding.
> > > >  	 */
> > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
> > > > -	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
> > > > -	 * as described in rfc2313
> > > > -	 */
> > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
> > > > -	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
> > > > -	 * as described in rfc2313
> > > > +	RTE_CRYPTO_RSA_PADDING_PKCS1,
> > [Shally] My preference would still be to rename as PKCS1_V1.5 to align
> > more to standard
> [AK] - Agree.
> 
> >
> > > > +	/**< 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 */
> > > > +	/**< RSA PKCS#1 OAEP padding scheme, can be used only for
> > > > encryption/
> > > > +	 * decryption.
> > > > +	 */
> > > >  	RTE_CRYPTO_RSA_PADDING_PSS,
> > > > -	/**< RSA PKCS#1 PSS padding scheme */
> > > > +	/**< RSA PKCS#1 PSS padding scheme, can be used only for
> > > > signatures.
> > > > +	 */
> > > >  	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > > >  };
> > > >
> > ...
> >
> > > >  struct rte_crypto_rsa_xform {
> > > >  	rte_crypto_param n;
> > > > -	/**< n - Prime modulus
> > > > -	 * Prime modulus data of RSA operation in Octet-string network
> > > > +	/**< n - Modulus
> > > > +	 * Modulus data of RSA operation in Octet-string network
> > > >  	 * byte order format.
> > > >  	 */
> > > >
> > > > @@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
> > > >  	/**<
> > > >  	 * Pointer to data
> > > >  	 * - to be encrypted for RSA public encrypt.
> > > > -	 * - to be decrypted for RSA private decrypt.
> > > >  	 * - to be signed for RSA sign generation.
> > > >  	 * - to be authenticated for RSA sign verification.
> > > > +	 *
> > > > +	 * Octet-string network byte order format.
> > > > +	 *
> > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > operation.
> > > > +	 *
> > > > +	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used length in
> > > > bytes
> > > > +	 * of this field needs to be greater or equal to the length of
> > > > +	 * corresponding RSA key in bytes.
> > [Shally] better rephrased " When an op_type ASYM_OP_DECRYPT used,
> > length of output buffer should be greater than  or equal to RSA key
> > modulus length
> [AK] - RSA key size is a RSA modulus size, but can be changed.
> >
> > > > +	 *
> > > > +	 * When padding field is set to RTE_CRYPTO_RSA_PADDING_NONE
> > > > +	 * returned data size will be equal to the size of RSA key
> > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > +	 */
> > [Shally] Is it in context of OP_TYPE_DECRYPT? Even if it is
> > PADDING_NONE, whether it is encrypted/decrypted, o/p length can vary
> > between 0 .. RSA modulus length - 1 as perf rfc8017
> [AK]
> example. 20 bytes was encrypted with 2048bit key PKCS_1.5 1. Padding
> PKCS_1.5 set - Upon decryption we return 20 bytes of recovered message.
> 2. Padding NONE set (padding done by user) - we return 236 bytes of padding
> (one leading zero) | 20 bytes of message = 256 bytes.
> (like in example test case I have added) 3. Padding NONE set (textbook rsa) -
> we return 236 bytes of zeroes | 20 bytes of message = 256 bytes.
> >
> > > > +
> > > > +	rte_crypto_param cipher;
> > > > +	/**<
> > > > +	 * Pointer to data
> > > > +	 * - to be decrypted for RSA private decrypt.
> > > > +	 *
> > > > +	 * Octet-string network byte order format.
> > > > +	 *
> > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > operation.
> > > > +	 *
> > > > +	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used length in
> > > > bytes
> > > > +	 * of this field needs to be greater or equal to the length of
> > > > +	 * corresponding RSA key in bytes.
> > > >  	 */
> > [Shally] recommend rephrasing as above
> >
> > > >
> > > >  	rte_crypto_param sign;
> > > > @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
> > > >  	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
> > > >  	 * over-written with generated signature.
> > > >  	 *
> > > > -	 * Length of the signature data will be equal to the
> > > > -	 * RSA prime modulus length.
> > > > +	 * Octet-string network byte order format.
> > > > +	 *
> > > > +	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length in bytes
> > > > +	 * of this field needs to be greater or equal to the length of
> > > > +	 * corresponding RSA key in bytes.
> > [Shally] field ---> buffer
> [AK] - Agreed
> >
> > > >  	 */
> > > >
> > > > -	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
> > > > +	rte_crypto_param message_to_verify;
> > > > +	/**<
> > > > +	 * Pointer to the message 'm' that was signed with
> > > > +	 * RSASP1 in RFC8017.
> > >> It is the result of operation RSAVP1
> > > > +	 * defined in RFC8017, where field `sign` is the input
> > > > +	 * parameter `s`.
> > > > +	 *
> > [Shally] This is confusing. Are you trying to say "this is output to VERIFY_OP
> ?
> > where output should be same as message buffer provided above?
> > If yes, then why not just use that message buffer as an output of
> > VERIFY_OP than adding a new one?
> [AK] - it is output of signature verify (in openssl Public_Decrypt) for
> PADDING_NONE case. It will be used to check if signature is correct.
> In `message` then there could be original message.
> But yes, we can use message as an output buffer, I just though it would be
> more transparent.
> Since user need to verify it by himself it is not that important to keep original
> message in `message` field, both ways will do.
> Waiting for opinions.
> >
> > > > +	 * Used only when padding type is set to
> > > > RTE_CRYPTO_RSA_PADDING_NONE
> > [Shally] I think regardless of padding, we can provide it as output to
> > sign operation
> [AK] - `Sign` is the place to put signature into.
> >
> > > > +	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
> > > > +	 *
> > > > +	 * Returned data size will be equal to the size of RSA key
> > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > +	 *
> > [Shally] Again, I think it should instead be mentioned as return size
> > can be 0 ... modulus_len - 1
> >
> > > > +	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used length in
> > > > bytes
> > > > +	 * of this field needs to be greater or equal to the length of
> > > > +	 * corresponding RSA key in bytes.
> > > >  	 */
> > [Shally] There're multiple statements starting with when op_type =
> > VERIFY, can we club them and make description shorter?
> >
> > > >
> > > > -	enum rte_crypto_auth_algorithm mgf1md;
> > > > +	enum rte_crypto_rsa_padding_type padding;
> > > > +	/**<
> > > > +	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
> > > > +	 * driver will distinguish between block type basing
> > > > +	 * on rte_crypto_asym_op_type of the operation.
> > > > +	 *
> > > > +	 * Which padding type is supported by the driver can be
> > > > +	 * found in in specific driver guide.
> > [Shally] better rephrase " PMD expose padding type support in its
> capability.
> > Refer to <struct / API definition>
> >
> > > > +	 */
> > > > +	enum rte_crypto_auth_algorithm padding_hash;
> > > > +	/**<
> > > > +	 * -	For PKCS1-v1_5 signature (Block type 01) this field
> > > > +	 * represents hash function that will be used to create
> > > > +	 * message hash.
> > [Shally] Currently PMD input pre-computed hash atleast for PKCSV_1.5 ..
> > does your hw support this offload for RSA?
> > So far , in our testing we observe openssl does it already before
> > calling private/public_key_enc so we should not be mentioning it in
> > spec unless any hw provide that combined offload hash + rsa
> 
> [AK] - Openssl for PKCS1_5 signature use RSA_private_encrypt which does
> not handle algorithmIdentifier.
> https://www.openssl.org/docs/man1.0.2/man3/RSA_private_encrypt.html
> And it is not said what data should be provided for signing. To be properly
> signed input buffer should be DER encoded concatenation of
> algorithmIdentifier and message digest.
> There would be much work to be done by user then: adding OID, computing
> Hash of message, ASN.1 call. Waiting for comments on that.

[AK2] - we do not specify what data should user provide to be signed.

> 
> >
> > > > +	 *
> > > > +	 * -	For OAEP this field represents hash function that will
> > > > +	 * be used to produce hash of the optional label.
> > > > +	 *
> > > > +	 * -	For PSS this field represents hash function that will be used
> > > > +	 * to produce hash (mHash) of message M and of M' (padding1 |
> > > > mHash | salt)
> > > > +	 *
> > > > +	 * If not set driver will use default value.
> > > > +	 */
> > > > +	union {
> > > > +		struct {
> > > > +			enum rte_crypto_auth_algorithm mgf;
> > > > +			/**<
> > > > +			 * Mask genereation function hash algorithm.
> > > > +			 *
> > > > +			 * If not set driver will use default value.
> > > > +			 */
> > > > +			rte_crypto_param label;
> > > > +			/**<
> > > > +			 * Optional label, if driver does not support
> > > > +			 * this option, optional label is just an empty string.
> > > > +			 */
> > > > +		} OAEP;
> > > > +		struct {
> > > > +			enum rte_crypto_auth_algorithm mgf;
> > [Shally] Though  it is mentioned in current spec, but I have similar
> > doubt here do we need to provide this offload in spec? I will use
> > terms from rfc8017 for further discussion.
> >   if we have any PMD whose HW provide full RSAES-OAEP offload i.e.
> > doing EME-OAEP followed by RSAEP, then it make sense to have it in
> > spec. But if we don't have any PMD example which support that full
> > offload, then we can redefine spec only to support RSAEP and omit md and
> mgf from spec.
> >
> [AK] - I thought to add PSS/OAEP to Openssl. Though OAEP and PSS for sure
> will be implemented having custom MGF is not that necessary. Waiting for
> opinions.

> 
> >
> >
> > > > +			/**<
> > > > +			 * Mask genereation function hash algorithm.
> > > > +			 *
> > > > +			 * If not set driver will use default value.
> > > > +			 */
> > > > +			int seed_len;
> > > > +			/**<
> > > > +			 * Intended seed length. Nagative number has
> > > special
> > > > +			 * value as follows:
> > > > +			 * -1 : seed len = length of output ot used hash
> > > > function
> > > > +			 * -2 : seed len is maximized
> > > > +			 */
> > > > +		} PSS;
> > > > +	};
> > > >  	/**<
> > > > -	 * 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
> > > > +	 * Padding type of RSA crypto operation.
> > > > +	 * What are random number generator requirements and prequisites
> > > > +	 * can be found specific driver guide.
> > [Shally] I would suggest it to rephrase again " app should refer to
> > PMD guide to check for RNG requirement and other pre-requisites used
> > in hash generation.
> > However , this feedback is relevant if we are retaining full OAEP offload.
> >
> > > >  	 */
> > > >  };
> > > >
> > > > --
> > > > 2.1.0

Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Akhil Goyal]

Hi Shally,

Do you have further comments on this series?

If yes, we may need to defer this to next release. As cryptodev change should not be there beyond RC2. In fact all of them should be closed by RC1.

Regards,
Akhil

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Tuesday, July 9, 2019 3:33 PM
> To: Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> 
> To clarify bit more
> With [AK2]
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Kusztal, ArkadiuszX
> > Sent: Monday, July 8, 2019 7:44 PM
> > To: Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > shally.verma@caviumnetworks.com
> > Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa
> > algorithm
> >
> > Hi Shally,
> >
> > With [AK]
> >
> > > -----Original Message-----
> > > From: Shally Verma [mailto:shallyv@marvell.com]
> > > Sent: Saturday, July 6, 2019 3:14 PM
> > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > shally.verma@caviumnetworks.com
> > > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > Sent: Thursday, July 4, 2019 6:10 PM
> > > > To: dev@dpdk.org
> > > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > > shally.verma@caviumnetworks.com; Shally Verma
> > <shallyv@marvell.com>
> > > > Subject: [EXT] RE: [PATCH v2 1/3] cryptodev: rework api of rsa
> > > > algorithm
> > > >
> > > > External Email
> > > >
> > > ..
> > >
> > > > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > index 8672f21..486399c 100644
> > > > > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > @@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
> > > > >   */
> > > > >  enum rte_crypto_rsa_padding_type {
> > > > >  	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> > > > > -	/**< RSA no padding scheme */
> > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
> > > > > -	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
> > > > > -	 * as described in rfc2313
> > > > > +	/**< RSA no padding scheme.
> > > > > +	 * In this case user is responsible for provision and verification
> > > > > +	 * of padding.
> > > > >  	 */
> > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
> > > > > -	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
> > > > > -	 * as described in rfc2313
> > > > > -	 */
> > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
> > > > > -	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
> > > > > -	 * as described in rfc2313
> > > > > +	RTE_CRYPTO_RSA_PADDING_PKCS1,
> > > [Shally] My preference would still be to rename as PKCS1_V1.5 to align
> > > more to standard
> > [AK] - Agree.
> >
> > >
> > > > > +	/**< 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 */
> > > > > +	/**< RSA PKCS#1 OAEP padding scheme, can be used only for
> > > > > encryption/
> > > > > +	 * decryption.
> > > > > +	 */
> > > > >  	RTE_CRYPTO_RSA_PADDING_PSS,
> > > > > -	/**< RSA PKCS#1 PSS padding scheme */
> > > > > +	/**< RSA PKCS#1 PSS padding scheme, can be used only for
> > > > > signatures.
> > > > > +	 */
> > > > >  	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > > > >  };
> > > > >
> > > ...
> > >
> > > > >  struct rte_crypto_rsa_xform {
> > > > >  	rte_crypto_param n;
> > > > > -	/**< n - Prime modulus
> > > > > -	 * Prime modulus data of RSA operation in Octet-string network
> > > > > +	/**< n - Modulus
> > > > > +	 * Modulus data of RSA operation in Octet-string network
> > > > >  	 * byte order format.
> > > > >  	 */
> > > > >
> > > > > @@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
> > > > >  	/**<
> > > > >  	 * Pointer to data
> > > > >  	 * - to be encrypted for RSA public encrypt.
> > > > > -	 * - to be decrypted for RSA private decrypt.
> > > > >  	 * - to be signed for RSA sign generation.
> > > > >  	 * - to be authenticated for RSA sign verification.
> > > > > +	 *
> > > > > +	 * Octet-string network byte order format.
> > > > > +	 *
> > > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > > operation.
> > > > > +	 *
> > > > > +	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used
> length in
> > > > > bytes
> > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > +	 * corresponding RSA key in bytes.
> > > [Shally] better rephrased " When an op_type ASYM_OP_DECRYPT used,
> > > length of output buffer should be greater than  or equal to RSA key
> > > modulus length
> > [AK] - RSA key size is a RSA modulus size, but can be changed.
> > >
> > > > > +	 *
> > > > > +	 * When padding field is set to
> RTE_CRYPTO_RSA_PADDING_NONE
> > > > > +	 * returned data size will be equal to the size of RSA key
> > > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > > +	 */
> > > [Shally] Is it in context of OP_TYPE_DECRYPT? Even if it is
> > > PADDING_NONE, whether it is encrypted/decrypted, o/p length can vary
> > > between 0 .. RSA modulus length - 1 as perf rfc8017
> > [AK]
> > example. 20 bytes was encrypted with 2048bit key PKCS_1.5 1. Padding
> > PKCS_1.5 set - Upon decryption we return 20 bytes of recovered message.
> > 2. Padding NONE set (padding done by user) - we return 236 bytes of padding
> > (one leading zero) | 20 bytes of message = 256 bytes.
> > (like in example test case I have added) 3. Padding NONE set (textbook rsa) -
> > we return 236 bytes of zeroes | 20 bytes of message = 256 bytes.
> > >
> > > > > +
> > > > > +	rte_crypto_param cipher;
> > > > > +	/**<
> > > > > +	 * Pointer to data
> > > > > +	 * - to be decrypted for RSA private decrypt.
> > > > > +	 *
> > > > > +	 * Octet-string network byte order format.
> > > > > +	 *
> > > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > > +	 * operation, and output to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > > operation.
> > > > > +	 *
> > > > > +	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used
> length in
> > > > > bytes
> > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > +	 * corresponding RSA key in bytes.
> > > > >  	 */
> > > [Shally] recommend rephrasing as above
> > >
> > > > >
> > > > >  	rte_crypto_param sign;
> > > > > @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
> > > > >  	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
> > > > >  	 * over-written with generated signature.
> > > > >  	 *
> > > > > -	 * Length of the signature data will be equal to the
> > > > > -	 * RSA prime modulus length.
> > > > > +	 * Octet-string network byte order format.
> > > > > +	 *
> > > > > +	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length in
> bytes
> > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > +	 * corresponding RSA key in bytes.
> > > [Shally] field ---> buffer
> > [AK] - Agreed
> > >
> > > > >  	 */
> > > > >
> > > > > -	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
> > > > > +	rte_crypto_param message_to_verify;
> > > > > +	/**<
> > > > > +	 * Pointer to the message 'm' that was signed with
> > > > > +	 * RSASP1 in RFC8017.
> > > >> It is the result of operation RSAVP1
> > > > > +	 * defined in RFC8017, where field `sign` is the input
> > > > > +	 * parameter `s`.
> > > > > +	 *
> > > [Shally] This is confusing. Are you trying to say "this is output to VERIFY_OP
> > ?
> > > where output should be same as message buffer provided above?
> > > If yes, then why not just use that message buffer as an output of
> > > VERIFY_OP than adding a new one?
> > [AK] - it is output of signature verify (in openssl Public_Decrypt) for
> > PADDING_NONE case. It will be used to check if signature is correct.
> > In `message` then there could be original message.
> > But yes, we can use message as an output buffer, I just though it would be
> > more transparent.
> > Since user need to verify it by himself it is not that important to keep original
> > message in `message` field, both ways will do.
> > Waiting for opinions.
> > >
> > > > > +	 * Used only when padding type is set to
> > > > > RTE_CRYPTO_RSA_PADDING_NONE
> > > [Shally] I think regardless of padding, we can provide it as output to
> > > sign operation
> > [AK] - `Sign` is the place to put signature into.
> > >
> > > > > +	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
> > > > > +	 *
> > > > > +	 * Returned data size will be equal to the size of RSA key
> > > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > > +	 *
> > > [Shally] Again, I think it should instead be mentioned as return size
> > > can be 0 ... modulus_len - 1
> > >
> > > > > +	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used length
> in
> > > > > bytes
> > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > +	 * corresponding RSA key in bytes.
> > > > >  	 */
> > > [Shally] There're multiple statements starting with when op_type =
> > > VERIFY, can we club them and make description shorter?
> > >
> > > > >
> > > > > -	enum rte_crypto_auth_algorithm mgf1md;
> > > > > +	enum rte_crypto_rsa_padding_type padding;
> > > > > +	/**<
> > > > > +	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
> > > > > +	 * driver will distinguish between block type basing
> > > > > +	 * on rte_crypto_asym_op_type of the operation.
> > > > > +	 *
> > > > > +	 * Which padding type is supported by the driver can be
> > > > > +	 * found in in specific driver guide.
> > > [Shally] better rephrase " PMD expose padding type support in its
> > capability.
> > > Refer to <struct / API definition>
> > >
> > > > > +	 */
> > > > > +	enum rte_crypto_auth_algorithm padding_hash;
> > > > > +	/**<
> > > > > +	 * -	For PKCS1-v1_5 signature (Block type 01) this field
> > > > > +	 * represents hash function that will be used to create
> > > > > +	 * message hash.
> > > [Shally] Currently PMD input pre-computed hash atleast for PKCSV_1.5 ..
> > > does your hw support this offload for RSA?
> > > So far , in our testing we observe openssl does it already before
> > > calling private/public_key_enc so we should not be mentioning it in
> > > spec unless any hw provide that combined offload hash + rsa
> >
> > [AK] - Openssl for PKCS1_5 signature use RSA_private_encrypt which does
> > not handle algorithmIdentifier.
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.op
> enssl.org%2Fdocs%2Fman1.0.2%2Fman3%2FRSA_private_encrypt.html&amp;da
> ta=02%7C01%7Cakhil.goyal%40nxp.com%7Cdb7fd9c8893144df755808d704549
> 746%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636982633668853
> 558&amp;sdata=FGOMjneOQsB7DRg8fKYHWhn5TKH3eO8QKA1bGbbt25w%3D&
> amp;reserved=0
> > And it is not said what data should be provided for signing. To be properly
> > signed input buffer should be DER encoded concatenation of
> > algorithmIdentifier and message digest.
> > There would be much work to be done by user then: adding OID, computing
> > Hash of message, ASN.1 call. Waiting for comments on that.
> 
> [AK2] - we do not specify what data should user provide to be signed.
> 
> >
> > >
> > > > > +	 *
> > > > > +	 * -	For OAEP this field represents hash function that will
> > > > > +	 * be used to produce hash of the optional label.
> > > > > +	 *
> > > > > +	 * -	For PSS this field represents hash function that will be
> used
> > > > > +	 * to produce hash (mHash) of message M and of M' (padding1 |
> > > > > mHash | salt)
> > > > > +	 *
> > > > > +	 * If not set driver will use default value.
> > > > > +	 */
> > > > > +	union {
> > > > > +		struct {
> > > > > +			enum rte_crypto_auth_algorithm mgf;
> > > > > +			/**<
> > > > > +			 * Mask genereation function hash algorithm.
> > > > > +			 *
> > > > > +			 * If not set driver will use default value.
> > > > > +			 */
> > > > > +			rte_crypto_param label;
> > > > > +			/**<
> > > > > +			 * Optional label, if driver does not support
> > > > > +			 * this option, optional label is just an empty
> string.
> > > > > +			 */
> > > > > +		} OAEP;
> > > > > +		struct {
> > > > > +			enum rte_crypto_auth_algorithm mgf;
> > > [Shally] Though  it is mentioned in current spec, but I have similar
> > > doubt here do we need to provide this offload in spec? I will use
> > > terms from rfc8017 for further discussion.
> > >   if we have any PMD whose HW provide full RSAES-OAEP offload i.e.
> > > doing EME-OAEP followed by RSAEP, then it make sense to have it in
> > > spec. But if we don't have any PMD example which support that full
> > > offload, then we can redefine spec only to support RSAEP and omit md and
> > mgf from spec.
> > >
> > [AK] - I thought to add PSS/OAEP to Openssl. Though OAEP and PSS for sure
> > will be implemented having custom MGF is not that necessary. Waiting for
> > opinions.
> 
> >
> > >
> > >
> > > > > +			/**<
> > > > > +			 * Mask genereation function hash algorithm.
> > > > > +			 *
> > > > > +			 * If not set driver will use default value.
> > > > > +			 */
> > > > > +			int seed_len;
> > > > > +			/**<
> > > > > +			 * Intended seed length. Nagative number has
> > > > special
> > > > > +			 * value as follows:
> > > > > +			 * -1 : seed len = length of output ot used hash
> > > > > function
> > > > > +			 * -2 : seed len is maximized
> > > > > +			 */
> > > > > +		} PSS;
> > > > > +	};
> > > > >  	/**<
> > > > > -	 * 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
> > > > > +	 * Padding type of RSA crypto operation.
> > > > > +	 * What are random number generator requirements and
> prequisites
> > > > > +	 * can be found specific driver guide.
> > > [Shally] I would suggest it to rephrase again " app should refer to
> > > PMD guide to check for RNG requirement and other pre-requisites used
> > > in hash generation.
> > > However , this feedback is relevant if we are retaining full OAEP offload.
> > >
> > > > >  	 */
> > > > >  };
> > > > >
> > > > > --
> > > > > 2.1.0

Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Kusztal, ArkadiuszX]

Hi Akhil, Shally, Fiona

I thought to split it in smaller patches, which from some could be applied in this release.
And I can send these patches today.

- 4 important enough to put in this release are:

1. Remove RSA prime modulus nonsense.
2. Add cipher field.
3. Specify what data should be provided for signing (in current only working case - openssl with pkcs1 user would need to append ASN.1 DER encoded algorithmIdentifier and concat it with message digest. You can easily verify it with functions RSA_sign, RSA_verify from openssl).
4. Remove BT0 padding.
5. Padding NONE behavior
6. Fix grammar and bad increment  in simulate pkcs_1 function in test for block type 1.

- Others and opens are:
1. Creating padding struct
2. Padding parameters (seedlen, optional label etc)
3. Leading zeroes questions.
4. Random number requirements.
5. Capabilities.

> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Tuesday, July 16, 2019 3:51 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Shally Verma
> <shallyv@marvell.com>; dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> 
> Hi Shally,
> 
> Do you have further comments on this series?
> 
> If yes, we may need to defer this to next release. As cryptodev change should
> not be there beyond RC2. In fact all of them should be closed by RC1.
> 
> Regards,
> Akhil
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > Sent: Tuesday, July 9, 2019 3:33 PM
> > To: Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> > Cc: Akhil Goyal <akhil.goyal@nxp.com>; Trahe, Fiona
> > <fiona.trahe@intel.com>
> > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> >
> > To clarify bit more
> > With [AK2]
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Kusztal,
> > > ArkadiuszX
> > > Sent: Monday, July 8, 2019 7:44 PM
> > > To: Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > shally.verma@caviumnetworks.com
> > > Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa
> > > algorithm
> > >
> > > Hi Shally,
> > >
> > > With [AK]
> > >
> > > > -----Original Message-----
> > > > From: Shally Verma [mailto:shallyv@marvell.com]
> > > > Sent: Saturday, July 6, 2019 3:14 PM
> > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > dev@dpdk.org
> > > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > > shally.verma@caviumnetworks.com
> > > > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > > Sent: Thursday, July 4, 2019 6:10 PM
> > > > > To: dev@dpdk.org
> > > > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > > > shally.verma@caviumnetworks.com; Shally Verma
> > > <shallyv@marvell.com>
> > > > > Subject: [EXT] RE: [PATCH v2 1/3] cryptodev: rework api of rsa
> > > > > algorithm
> > > > >
> > > > > External Email
> > > > >
> > > > ..
> > > >
> > > > > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > index 8672f21..486399c 100644
> > > > > > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > @@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
> > > > > >   */
> > > > > >  enum rte_crypto_rsa_padding_type {
> > > > > >  	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> > > > > > -	/**< RSA no padding scheme */
> > > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
> > > > > > -	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
> > > > > > -	 * as described in rfc2313
> > > > > > +	/**< RSA no padding scheme.
> > > > > > +	 * In this case user is responsible for provision and
> verification
> > > > > > +	 * of padding.
> > > > > >  	 */
> > > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
> > > > > > -	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
> > > > > > -	 * as described in rfc2313
> > > > > > -	 */
> > > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
> > > > > > -	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
> > > > > > -	 * as described in rfc2313
> > > > > > +	RTE_CRYPTO_RSA_PADDING_PKCS1,
> > > > [Shally] My preference would still be to rename as PKCS1_V1.5 to
> > > > align more to standard
> > > [AK] - Agree.
> > >
> > > >
> > > > > > +	/**< 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 */
> > > > > > +	/**< RSA PKCS#1 OAEP padding scheme, can be used only for
> > > > > > encryption/
> > > > > > +	 * decryption.
> > > > > > +	 */
> > > > > >  	RTE_CRYPTO_RSA_PADDING_PSS,
> > > > > > -	/**< RSA PKCS#1 PSS padding scheme */
> > > > > > +	/**< RSA PKCS#1 PSS padding scheme, can be used only for
> > > > > > signatures.
> > > > > > +	 */
> > > > > >  	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > > > > >  };
> > > > > >
> > > > ...
> > > >
> > > > > >  struct rte_crypto_rsa_xform {
> > > > > >  	rte_crypto_param n;
> > > > > > -	/**< n - Prime modulus
> > > > > > -	 * Prime modulus data of RSA operation in Octet-string
> network
> > > > > > +	/**< n - Modulus
> > > > > > +	 * Modulus data of RSA operation in Octet-string network
> > > > > >  	 * byte order format.
> > > > > >  	 */
> > > > > >
> > > > > > @@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
> > > > > >  	/**<
> > > > > >  	 * Pointer to data
> > > > > >  	 * - to be encrypted for RSA public encrypt.
> > > > > > -	 * - to be decrypted for RSA private decrypt.
> > > > > >  	 * - to be signed for RSA sign generation.
> > > > > >  	 * - to be authenticated for RSA sign verification.
> > > > > > +	 *
> > > > > > +	 * Octet-string network byte order format.
> > > > > > +	 *
> > > > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > > > +	 * operation, and output to
> RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > > > operation.
> > > > > > +	 *
> > > > > > +	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used
> > length in
> > > > > > bytes
> > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > +	 * corresponding RSA key in bytes.
> > > > [Shally] better rephrased " When an op_type ASYM_OP_DECRYPT used,
> > > > length of output buffer should be greater than  or equal to RSA
> > > > key modulus length
> > > [AK] - RSA key size is a RSA modulus size, but can be changed.
> > > >
> > > > > > +	 *
> > > > > > +	 * When padding field is set to
> > RTE_CRYPTO_RSA_PADDING_NONE
> > > > > > +	 * returned data size will be equal to the size of RSA key
> > > > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > > > +	 */
> > > > [Shally] Is it in context of OP_TYPE_DECRYPT? Even if it is
> > > > PADDING_NONE, whether it is encrypted/decrypted, o/p length can
> > > > vary between 0 .. RSA modulus length - 1 as perf rfc8017
> > > [AK]
> > > example. 20 bytes was encrypted with 2048bit key PKCS_1.5 1. Padding
> > > PKCS_1.5 set - Upon decryption we return 20 bytes of recovered message.
> > > 2. Padding NONE set (padding done by user) - we return 236 bytes of
> > > padding (one leading zero) | 20 bytes of message = 256 bytes.
> > > (like in example test case I have added) 3. Padding NONE set
> > > (textbook rsa) - we return 236 bytes of zeroes | 20 bytes of message =
> 256 bytes.
> > > >
> > > > > > +
> > > > > > +	rte_crypto_param cipher;
> > > > > > +	/**<
> > > > > > +	 * Pointer to data
> > > > > > +	 * - to be decrypted for RSA private decrypt.
> > > > > > +	 *
> > > > > > +	 * Octet-string network byte order format.
> > > > > > +	 *
> > > > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > > > +	 * operation, and output to
> RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > > > operation.
> > > > > > +	 *
> > > > > > +	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used
> > length in
> > > > > > bytes
> > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > +	 * corresponding RSA key in bytes.
> > > > > >  	 */
> > > > [Shally] recommend rephrasing as above
> > > >
> > > > > >
> > > > > >  	rte_crypto_param sign;
> > > > > > @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
> > > > > >  	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
> > > > > >  	 * over-written with generated signature.
> > > > > >  	 *
> > > > > > -	 * Length of the signature data will be equal to the
> > > > > > -	 * RSA prime modulus length.
> > > > > > +	 * Octet-string network byte order format.
> > > > > > +	 *
> > > > > > +	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length
> in
> > bytes
> > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > +	 * corresponding RSA key in bytes.
> > > > [Shally] field ---> buffer
> > > [AK] - Agreed
> > > >
> > > > > >  	 */
> > > > > >
> > > > > > -	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
> > > > > > +	rte_crypto_param message_to_verify;
> > > > > > +	/**<
> > > > > > +	 * Pointer to the message 'm' that was signed with
> > > > > > +	 * RSASP1 in RFC8017.
> > > > >> It is the result of operation RSAVP1
> > > > > > +	 * defined in RFC8017, where field `sign` is the input
> > > > > > +	 * parameter `s`.
> > > > > > +	 *
> > > > [Shally] This is confusing. Are you trying to say "this is output
> > > > to VERIFY_OP
> > > ?
> > > > where output should be same as message buffer provided above?
> > > > If yes, then why not just use that message buffer as an output of
> > > > VERIFY_OP than adding a new one?
> > > [AK] - it is output of signature verify (in openssl Public_Decrypt)
> > > for PADDING_NONE case. It will be used to check if signature is correct.
> > > In `message` then there could be original message.
> > > But yes, we can use message as an output buffer, I just though it
> > > would be more transparent.
> > > Since user need to verify it by himself it is not that important to
> > > keep original message in `message` field, both ways will do.
> > > Waiting for opinions.
> > > >
> > > > > > +	 * Used only when padding type is set to
> > > > > > RTE_CRYPTO_RSA_PADDING_NONE
> > > > [Shally] I think regardless of padding, we can provide it as
> > > > output to sign operation
> > > [AK] - `Sign` is the place to put signature into.
> > > >
> > > > > > +	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
> > > > > > +	 *
> > > > > > +	 * Returned data size will be equal to the size of RSA key
> > > > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > > > +	 *
> > > > [Shally] Again, I think it should instead be mentioned as return
> > > > size can be 0 ... modulus_len - 1
> > > >
> > > > > > +	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used
> length
> > in
> > > > > > bytes
> > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > +	 * corresponding RSA key in bytes.
> > > > > >  	 */
> > > > [Shally] There're multiple statements starting with when op_type =
> > > > VERIFY, can we club them and make description shorter?
> > > >
> > > > > >
> > > > > > -	enum rte_crypto_auth_algorithm mgf1md;
> > > > > > +	enum rte_crypto_rsa_padding_type padding;
> > > > > > +	/**<
> > > > > > +	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
> > > > > > +	 * driver will distinguish between block type basing
> > > > > > +	 * on rte_crypto_asym_op_type of the operation.
> > > > > > +	 *
> > > > > > +	 * Which padding type is supported by the driver can be
> > > > > > +	 * found in in specific driver guide.
> > > > [Shally] better rephrase " PMD expose padding type support in its
> > > capability.
> > > > Refer to <struct / API definition>
> > > >
> > > > > > +	 */
> > > > > > +	enum rte_crypto_auth_algorithm padding_hash;
> > > > > > +	/**<
> > > > > > +	 * -	For PKCS1-v1_5 signature (Block type 01) this field
> > > > > > +	 * represents hash function that will be used to create
> > > > > > +	 * message hash.
> > > > [Shally] Currently PMD input pre-computed hash atleast for PKCSV_1.5
> ..
> > > > does your hw support this offload for RSA?
> > > > So far , in our testing we observe openssl does it already before
> > > > calling private/public_key_enc so we should not be mentioning it
> > > > in spec unless any hw provide that combined offload hash + rsa
> > >
> > > [AK] - Openssl for PKCS1_5 signature use RSA_private_encrypt which
> > > does not handle algorithmIdentifier.
> > >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > op
> >
> enssl.org%2Fdocs%2Fman1.0.2%2Fman3%2FRSA_private_encrypt.html&amp
> ;da
> >
> ta=02%7C01%7Cakhil.goyal%40nxp.com%7Cdb7fd9c8893144df755808d7045
> 49
> >
> 746%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369826336688
> 53
> >
> 558&amp;sdata=FGOMjneOQsB7DRg8fKYHWhn5TKH3eO8QKA1bGbbt25w%3
> D&
> > amp;reserved=0
> > > And it is not said what data should be provided for signing. To be
> > > properly signed input buffer should be DER encoded concatenation of
> > > algorithmIdentifier and message digest.
> > > There would be much work to be done by user then: adding OID,
> > > computing Hash of message, ASN.1 call. Waiting for comments on that.
> >
> > [AK2] - we do not specify what data should user provide to be signed.
> >
> > >
> > > >
> > > > > > +	 *
> > > > > > +	 * -	For OAEP this field represents hash function that will
> > > > > > +	 * be used to produce hash of the optional label.
> > > > > > +	 *
> > > > > > +	 * -	For PSS this field represents hash function that will be
> > used
> > > > > > +	 * to produce hash (mHash) of message M and of M'
> (padding1
> > > > > > +|
> > > > > > mHash | salt)
> > > > > > +	 *
> > > > > > +	 * If not set driver will use default value.
> > > > > > +	 */
> > > > > > +	union {
> > > > > > +		struct {
> > > > > > +			enum rte_crypto_auth_algorithm mgf;
> > > > > > +			/**<
> > > > > > +			 * Mask genereation function hash algorithm.
> > > > > > +			 *
> > > > > > +			 * If not set driver will use default value.
> > > > > > +			 */
> > > > > > +			rte_crypto_param label;
> > > > > > +			/**<
> > > > > > +			 * Optional label, if driver does not support
> > > > > > +			 * this option, optional label is just an empty
> > string.
> > > > > > +			 */
> > > > > > +		} OAEP;
> > > > > > +		struct {
> > > > > > +			enum rte_crypto_auth_algorithm mgf;
> > > > [Shally] Though  it is mentioned in current spec, but I have
> > > > similar doubt here do we need to provide this offload in spec? I
> > > > will use terms from rfc8017 for further discussion.
> > > >   if we have any PMD whose HW provide full RSAES-OAEP offload i.e.
> > > > doing EME-OAEP followed by RSAEP, then it make sense to have it in
> > > > spec. But if we don't have any PMD example which support that full
> > > > offload, then we can redefine spec only to support RSAEP and omit
> > > > md and
> > > mgf from spec.
> > > >
> > > [AK] - I thought to add PSS/OAEP to Openssl. Though OAEP and PSS for
> > > sure will be implemented having custom MGF is not that necessary.
> > > Waiting for opinions.
> >
> > >
> > > >
> > > >
> > > > > > +			/**<
> > > > > > +			 * Mask genereation function hash algorithm.
> > > > > > +			 *
> > > > > > +			 * If not set driver will use default value.
> > > > > > +			 */
> > > > > > +			int seed_len;
> > > > > > +			/**<
> > > > > > +			 * Intended seed length. Nagative number
> has
> > > > > special
> > > > > > +			 * value as follows:
> > > > > > +			 * -1 : seed len = length of output ot used
> hash
> > > > > > function
> > > > > > +			 * -2 : seed len is maximized
> > > > > > +			 */
> > > > > > +		} PSS;
> > > > > > +	};
> > > > > >  	/**<
> > > > > > -	 * 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
> > > > > > +	 * Padding type of RSA crypto operation.
> > > > > > +	 * What are random number generator requirements and
> > prequisites
> > > > > > +	 * can be found specific driver guide.
> > > > [Shally] I would suggest it to rephrase again " app should refer
> > > > to PMD guide to check for RNG requirement and other pre-requisites
> > > > used in hash generation.
> > > > However , this feedback is relevant if we are retaining full OAEP offload.
> > > >
> > > > > >  	 */
> > > > > >  };
> > > > > >
> > > > > > --
> > > > > > 2.1.0

Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa algorithm

[Trahe, Fiona]

Hi Arek, Shally, Akhil,

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Tuesday, July 16, 2019 3:16 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> 
> Hi Akhil, Shally, Fiona
> 
> I thought to split it in smaller patches, which from some could be applied in this release.
> And I can send these patches today.
> 
> - 4 important enough to put in this release are:
[Fiona] and 4 became 6 :)
I agree with those if they can be sent for RC2. Better to get some improvement into 19.08 and continue work on the opens in a future release.  


> 1. Remove RSA prime modulus nonsense.
> 2. Add cipher field.
> 3. Specify what data should be provided for signing (in current only working case - openssl with pkcs1
> user would need to append ASN.1 DER encoded algorithmIdentifier and concat it with message digest.
> You can easily verify it with functions RSA_sign, RSA_verify from openssl).
> 4. Remove BT0 padding.
> 5. Padding NONE behavior
> 6. Fix grammar and bad increment  in simulate pkcs_1 function in test for block type 1.
> 
> - Others and opens are:
> 1. Creating padding struct
> 2. Padding parameters (seedlen, optional label etc)
> 3. Leading zeroes questions.
> 4. Random number requirements.
> 5. Capabilities.
> 
> > -----Original Message-----
> > From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> > Sent: Tuesday, July 16, 2019 3:51 PM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Shally Verma
> > <shallyv@marvell.com>; dev@dpdk.org
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>
> > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> >
> > Hi Shally,
> >
> > Do you have further comments on this series?
> >
> > If yes, we may need to defer this to next release. As cryptodev change should
> > not be there beyond RC2. In fact all of them should be closed by RC1.
> >
> > Regards,
> > Akhil
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > Sent: Tuesday, July 9, 2019 3:33 PM
> > > To: Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> > > Cc: Akhil Goyal <akhil.goyal@nxp.com>; Trahe, Fiona
> > > <fiona.trahe@intel.com>
> > > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> > >
> > > To clarify bit more
> > > With [AK2]
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Kusztal,
> > > > ArkadiuszX
> > > > Sent: Monday, July 8, 2019 7:44 PM
> > > > To: Shally Verma <shallyv@marvell.com>; dev@dpdk.org
> > > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > > shally.verma@caviumnetworks.com
> > > > Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa
> > > > algorithm
> > > >
> > > > Hi Shally,
> > > >
> > > > With [AK]
> > > >
> > > > > -----Original Message-----
> > > > > From: Shally Verma [mailto:shallyv@marvell.com]
> > > > > Sent: Saturday, July 6, 2019 3:14 PM
> > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > > dev@dpdk.org
> > > > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > > > shally.verma@caviumnetworks.com
> > > > > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > > > Sent: Thursday, July 4, 2019 6:10 PM
> > > > > > To: dev@dpdk.org
> > > > > > Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> > > > > > shally.verma@caviumnetworks.com; Shally Verma
> > > > <shallyv@marvell.com>
> > > > > > Subject: [EXT] RE: [PATCH v2 1/3] cryptodev: rework api of rsa
> > > > > > algorithm
> > > > > >
> > > > > > External Email
> > > > > >
> > > > > ..
> > > > >
> > > > > > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > > b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > > index 8672f21..486399c 100644
> > > > > > > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > > > > > > @@ -111,23 +111,21 @@ enum rte_crypto_asym_op_type {
> > > > > > >   */
> > > > > > >  enum rte_crypto_rsa_padding_type {
> > > > > > >  	RTE_CRYPTO_RSA_PADDING_NONE = 0,
> > > > > > > -	/**< RSA no padding scheme */
> > > > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT0,
> > > > > > > -	/**< RSA PKCS#1 V1.5 Block Type 0 padding scheme
> > > > > > > -	 * as described in rfc2313
> > > > > > > +	/**< RSA no padding scheme.
> > > > > > > +	 * In this case user is responsible for provision and
> > verification
> > > > > > > +	 * of padding.
> > > > > > >  	 */
> > > > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT1,
> > > > > > > -	/**< RSA PKCS#1 V1.5 Block Type 01 padding scheme
> > > > > > > -	 * as described in rfc2313
> > > > > > > -	 */
> > > > > > > -	RTE_CRYPTO_RSA_PKCS1_V1_5_BT2,
> > > > > > > -	/**< RSA PKCS#1 V1.5 Block Type 02 padding scheme
> > > > > > > -	 * as described in rfc2313
> > > > > > > +	RTE_CRYPTO_RSA_PADDING_PKCS1,
> > > > > [Shally] My preference would still be to rename as PKCS1_V1.5 to
> > > > > align more to standard
> > > > [AK] - Agree.
> > > >
> > > > >
> > > > > > > +	/**< 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 */
> > > > > > > +	/**< RSA PKCS#1 OAEP padding scheme, can be used only for
> > > > > > > encryption/
> > > > > > > +	 * decryption.
> > > > > > > +	 */
> > > > > > >  	RTE_CRYPTO_RSA_PADDING_PSS,
> > > > > > > -	/**< RSA PKCS#1 PSS padding scheme */
> > > > > > > +	/**< RSA PKCS#1 PSS padding scheme, can be used only for
> > > > > > > signatures.
> > > > > > > +	 */
> > > > > > >  	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > > > > > >  };
> > > > > > >
> > > > > ...
> > > > >
> > > > > > >  struct rte_crypto_rsa_xform {
> > > > > > >  	rte_crypto_param n;
> > > > > > > -	/**< n - Prime modulus
> > > > > > > -	 * Prime modulus data of RSA operation in Octet-string
> > network
> > > > > > > +	/**< n - Modulus
> > > > > > > +	 * Modulus data of RSA operation in Octet-string network
> > > > > > >  	 * byte order format.
> > > > > > >  	 */
> > > > > > >
> > > > > > > @@ -397,9 +395,36 @@ struct rte_crypto_rsa_op_param {
> > > > > > >  	/**<
> > > > > > >  	 * Pointer to data
> > > > > > >  	 * - to be encrypted for RSA public encrypt.
> > > > > > > -	 * - to be decrypted for RSA private decrypt.
> > > > > > >  	 * - to be signed for RSA sign generation.
> > > > > > >  	 * - to be authenticated for RSA sign verification.
> > > > > > > +	 *
> > > > > > > +	 * Octet-string network byte order format.
> > > > > > > +	 *
> > > > > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > > > > +	 * operation, and output to
> > RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > > > > operation.
> > > > > > > +	 *
> > > > > > > +	 * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used
> > > length in
> > > > > > > bytes
> > > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > > +	 * corresponding RSA key in bytes.
> > > > > [Shally] better rephrased " When an op_type ASYM_OP_DECRYPT used,
> > > > > length of output buffer should be greater than  or equal to RSA
> > > > > key modulus length
> > > > [AK] - RSA key size is a RSA modulus size, but can be changed.
> > > > >
> > > > > > > +	 *
> > > > > > > +	 * When padding field is set to
> > > RTE_CRYPTO_RSA_PADDING_NONE
> > > > > > > +	 * returned data size will be equal to the size of RSA key
> > > > > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > > > > +	 */
> > > > > [Shally] Is it in context of OP_TYPE_DECRYPT? Even if it is
> > > > > PADDING_NONE, whether it is encrypted/decrypted, o/p length can
> > > > > vary between 0 .. RSA modulus length - 1 as perf rfc8017
> > > > [AK]
> > > > example. 20 bytes was encrypted with 2048bit key PKCS_1.5 1. Padding
> > > > PKCS_1.5 set - Upon decryption we return 20 bytes of recovered message.
> > > > 2. Padding NONE set (padding done by user) - we return 236 bytes of
> > > > padding (one leading zero) | 20 bytes of message = 256 bytes.
> > > > (like in example test case I have added) 3. Padding NONE set
> > > > (textbook rsa) - we return 236 bytes of zeroes | 20 bytes of message =
> > 256 bytes.
> > > > >
> > > > > > > +
> > > > > > > +	rte_crypto_param cipher;
> > > > > > > +	/**<
> > > > > > > +	 * Pointer to data
> > > > > > > +	 * - to be decrypted for RSA private decrypt.
> > > > > > > +	 *
> > > > > > > +	 * Octet-string network byte order format.
> > > > > > > +	 *
> > > > > > > +	 * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT
> > > > > > > +	 * operation, and output to
> > RTE_CRYPTO_ASYM_OP_ENCRYPT
> > > > > > > operation.
> > > > > > > +	 *
> > > > > > > +	 * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used
> > > length in
> > > > > > > bytes
> > > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > > +	 * corresponding RSA key in bytes.
> > > > > > >  	 */
> > > > > [Shally] recommend rephrasing as above
> > > > >
> > > > > > >
> > > > > > >  	rte_crypto_param sign;
> > > > > > > @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param {
> > > > > > >  	 * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
> > > > > > >  	 * over-written with generated signature.
> > > > > > >  	 *
> > > > > > > -	 * Length of the signature data will be equal to the
> > > > > > > -	 * RSA prime modulus length.
> > > > > > > +	 * Octet-string network byte order format.
> > > > > > > +	 *
> > > > > > > +	 * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length
> > in
> > > bytes
> > > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > > +	 * corresponding RSA key in bytes.
> > > > > [Shally] field ---> buffer
> > > > [AK] - Agreed
> > > > >
> > > > > > >  	 */
> > > > > > >
> > > > > > > -	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
> > > > > > > +	rte_crypto_param message_to_verify;
> > > > > > > +	/**<
> > > > > > > +	 * Pointer to the message 'm' that was signed with
> > > > > > > +	 * RSASP1 in RFC8017.
> > > > > >> It is the result of operation RSAVP1
> > > > > > > +	 * defined in RFC8017, where field `sign` is the input
> > > > > > > +	 * parameter `s`.
> > > > > > > +	 *
> > > > > [Shally] This is confusing. Are you trying to say "this is output
> > > > > to VERIFY_OP
> > > > ?
> > > > > where output should be same as message buffer provided above?
> > > > > If yes, then why not just use that message buffer as an output of
> > > > > VERIFY_OP than adding a new one?
> > > > [AK] - it is output of signature verify (in openssl Public_Decrypt)
> > > > for PADDING_NONE case. It will be used to check if signature is correct.
> > > > In `message` then there could be original message.
> > > > But yes, we can use message as an output buffer, I just though it
> > > > would be more transparent.
> > > > Since user need to verify it by himself it is not that important to
> > > > keep original message in `message` field, both ways will do.
> > > > Waiting for opinions.
> > > > >
> > > > > > > +	 * Used only when padding type is set to
> > > > > > > RTE_CRYPTO_RSA_PADDING_NONE
> > > > > [Shally] I think regardless of padding, we can provide it as
> > > > > output to sign operation
> > > > [AK] - `Sign` is the place to put signature into.
> > > > >
> > > > > > > +	 * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY.
> > > > > > > +	 *
> > > > > > > +	 * Returned data size will be equal to the size of RSA key
> > > > > > > +	 * in bytes. All leading zeroes will be preserved.
> > > > > > > +	 *
> > > > > [Shally] Again, I think it should instead be mentioned as return
> > > > > size can be 0 ... modulus_len - 1
> > > > >
> > > > > > > +	 * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used
> > length
> > > in
> > > > > > > bytes
> > > > > > > +	 * of this field needs to be greater or equal to the length of
> > > > > > > +	 * corresponding RSA key in bytes.
> > > > > > >  	 */
> > > > > [Shally] There're multiple statements starting with when op_type =
> > > > > VERIFY, can we club them and make description shorter?
> > > > >
> > > > > > >
> > > > > > > -	enum rte_crypto_auth_algorithm mgf1md;
> > > > > > > +	enum rte_crypto_rsa_padding_type padding;
> > > > > > > +	/**<
> > > > > > > +	 * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected,
> > > > > > > +	 * driver will distinguish between block type basing
> > > > > > > +	 * on rte_crypto_asym_op_type of the operation.
> > > > > > > +	 *
> > > > > > > +	 * Which padding type is supported by the driver can be
> > > > > > > +	 * found in in specific driver guide.
> > > > > [Shally] better rephrase " PMD expose padding type support in its
> > > > capability.
> > > > > Refer to <struct / API definition>
> > > > >
> > > > > > > +	 */
> > > > > > > +	enum rte_crypto_auth_algorithm padding_hash;
> > > > > > > +	/**<
> > > > > > > +	 * -	For PKCS1-v1_5 signature (Block type 01) this field
> > > > > > > +	 * represents hash function that will be used to create
> > > > > > > +	 * message hash.
> > > > > [Shally] Currently PMD input pre-computed hash atleast for PKCSV_1.5
> > ..
> > > > > does your hw support this offload for RSA?
> > > > > So far , in our testing we observe openssl does it already before
> > > > > calling private/public_key_enc so we should not be mentioning it
> > > > > in spec unless any hw provide that combined offload hash + rsa
> > > >
> > > > [AK] - Openssl for PKCS1_5 signature use RSA_private_encrypt which
> > > > does not handle algorithmIdentifier.
> > > >
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > op
> > >
> > enssl.org%2Fdocs%2Fman1.0.2%2Fman3%2FRSA_private_encrypt.html&amp
> > ;da
> > >
> > ta=02%7C01%7Cakhil.goyal%40nxp.com%7Cdb7fd9c8893144df755808d7045
> > 49
> > >
> > 746%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369826336688
> > 53
> > >
> > 558&amp;sdata=FGOMjneOQsB7DRg8fKYHWhn5TKH3eO8QKA1bGbbt25w%3
> > D&
> > > amp;reserved=0
> > > > And it is not said what data should be provided for signing. To be
> > > > properly signed input buffer should be DER encoded concatenation of
> > > > algorithmIdentifier and message digest.
> > > > There would be much work to be done by user then: adding OID,
> > > > computing Hash of message, ASN.1 call. Waiting for comments on that.
> > >
> > > [AK2] - we do not specify what data should user provide to be signed.
> > >
> > > >
> > > > >
> > > > > > > +	 *
> > > > > > > +	 * -	For OAEP this field represents hash function that will
> > > > > > > +	 * be used to produce hash of the optional label.
> > > > > > > +	 *
> > > > > > > +	 * -	For PSS this field represents hash function that will be
> > > used
> > > > > > > +	 * to produce hash (mHash) of message M and of M'
> > (padding1
> > > > > > > +|
> > > > > > > mHash | salt)
> > > > > > > +	 *
> > > > > > > +	 * If not set driver will use default value.
> > > > > > > +	 */
> > > > > > > +	union {
> > > > > > > +		struct {
> > > > > > > +			enum rte_crypto_auth_algorithm mgf;
> > > > > > > +			/**<
> > > > > > > +			 * Mask genereation function hash algorithm.
> > > > > > > +			 *
> > > > > > > +			 * If not set driver will use default value.
> > > > > > > +			 */
> > > > > > > +			rte_crypto_param label;
> > > > > > > +			/**<
> > > > > > > +			 * Optional label, if driver does not support
> > > > > > > +			 * this option, optional label is just an empty
> > > string.
> > > > > > > +			 */
> > > > > > > +		} OAEP;
> > > > > > > +		struct {
> > > > > > > +			enum rte_crypto_auth_algorithm mgf;
> > > > > [Shally] Though  it is mentioned in current spec, but I have
> > > > > similar doubt here do we need to provide this offload in spec? I
> > > > > will use terms from rfc8017 for further discussion.
> > > > >   if we have any PMD whose HW provide full RSAES-OAEP offload i.e.
> > > > > doing EME-OAEP followed by RSAEP, then it make sense to have it in
> > > > > spec. But if we don't have any PMD example which support that full
> > > > > offload, then we can redefine spec only to support RSAEP and omit
> > > > > md and
> > > > mgf from spec.
> > > > >
> > > > [AK] - I thought to add PSS/OAEP to Openssl. Though OAEP and PSS for
> > > > sure will be implemented having custom MGF is not that necessary.
> > > > Waiting for opinions.
> > >
> > > >
> > > > >
> > > > >
> > > > > > > +			/**<
> > > > > > > +			 * Mask genereation function hash algorithm.
> > > > > > > +			 *
> > > > > > > +			 * If not set driver will use default value.
> > > > > > > +			 */
> > > > > > > +			int seed_len;
> > > > > > > +			/**<
> > > > > > > +			 * Intended seed length. Nagative number
> > has
> > > > > > special
> > > > > > > +			 * value as follows:
> > > > > > > +			 * -1 : seed len = length of output ot used
> > hash
> > > > > > > function
> > > > > > > +			 * -2 : seed len is maximized
> > > > > > > +			 */
> > > > > > > +		} PSS;
> > > > > > > +	};
> > > > > > >  	/**<
> > > > > > > -	 * 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
> > > > > > > +	 * Padding type of RSA crypto operation.
> > > > > > > +	 * What are random number generator requirements and
> > > prequisites
> > > > > > > +	 * can be found specific driver guide.
> > > > > [Shally] I would suggest it to rephrase again " app should refer
> > > > > to PMD guide to check for RNG requirement and other pre-requisites
> > > > > used in hash generation.
> > > > > However , this feedback is relevant if we are retaining full OAEP offload.
> > > > >
> > > > > > >  	 */
> > > > > > >  };
> > > > > > >
> > > > > > > --
> > > > > > > 2.1.0

[dpdk-dev] [PATCH v2 2/3] crypto/openssl: rework openssl rsa implementation

[Arek Kusztal]

This commit reworks implementation of RSA algorithm
in OPENSSL PMD to be conformant to API changes.

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

diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index 7c8bf0d..642580b 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -1842,15 +1842,13 @@ 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);
 	uint8_t *tmp;
 
 	cop->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
 
 	switch (pad) {
-	case RTE_CRYPTO_RSA_PKCS1_V1_5_BT0:
-	case RTE_CRYPTO_RSA_PKCS1_V1_5_BT1:
-	case RTE_CRYPTO_RSA_PKCS1_V1_5_BT2:
+	case RTE_CRYPTO_RSA_PADDING_PKCS1:
 		pad = RSA_PKCS1_PADDING;
 		break;
 	case RTE_CRYPTO_RSA_PADDING_NONE:
@@ -1867,19 +1865,19 @@ process_openssl_rsa_op(struct rte_crypto_op *cop,
 	case RTE_CRYPTO_ASYM_OP_ENCRYPT:
 		ret = RSA_public_encrypt(op->rsa.message.length,
 				op->rsa.message.data,
-				op->rsa.message.data,
+				op->rsa.cipher.data,
 				rsa,
 				pad);
 
 		if (ret > 0)
-			op->rsa.message.length = ret;
+			op->rsa.cipher.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.message.length,
-				op->rsa.message.data,
+		ret = RSA_private_decrypt(op->rsa.cipher.length,
+				op->rsa.cipher.data,
 				op->rsa.message.data,
 				rsa,
 				pad);
@@ -1898,28 +1896,39 @@ process_openssl_rsa_op(struct rte_crypto_op *cop,
 		break;
 
 	case RTE_CRYPTO_ASYM_OP_VERIFY:
-		tmp = rte_malloc(NULL, op->rsa.sign.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,
-				tmp,
-				rsa,
-				pad);
-
-		OPENSSL_LOG(DEBUG,
-				"Length of public_decrypt %d "
-				"length of message %zd\n",
-				ret, op->rsa.message.length);
-		if ((ret <= 0) || (CRYPTO_memcmp(tmp, op->rsa.message.data,
-				op->rsa.message.length))) {
-			OPENSSL_LOG(ERR, "RSA sign Verification failed");
-			cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
+		if (pad == RSA_NO_PADDING) {
+			ret = RSA_public_decrypt(op->rsa.sign.length,
+					op->rsa.sign.data,
+					op->rsa.message_to_verify.data,
+					rsa,
+					pad);
+
+			if (ret > 0)
+				op->rsa.message_to_verify.length = ret;
+		} else {
+			tmp = rte_malloc(NULL, op->rsa.sign.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,
+					tmp,
+					rsa,
+					pad);
+
+			OPENSSL_LOG(DEBUG,
+					"Length of public_decrypt %d "
+					"length of message %zd\n",
+					ret, op->rsa.message.length);
+			if ((ret <= 0) || (CRYPTO_memcmp(tmp, op->rsa.message.data,
+					op->rsa.message.length))) {
+				OPENSSL_LOG(ERR, "RSA sign Verification failed");
+				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
+			}
+			rte_free(tmp);
 		}
-		rte_free(tmp);
 		break;
 
 	default:
-- 
2.1.0

Re: [dpdk-dev] [PATCH v2 2/3] crypto/openssl: rework openssl rsa implementation

[Kusztal, ArkadiuszX]

+ Shally's Marvell address.
Shally, Fiona can you take a look?

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, July 3, 2019 5:38 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>;
> shally.verma@caviumnetworks.com; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v2 2/3] crypto/openssl: rework openssl rsa implementation
> 
> This commit reworks implementation of RSA algorithm in OPENSSL PMD to
> be conformant to API changes.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  drivers/crypto/openssl/rte_openssl_pmd.c | 67 ++++++++++++++++++--------
> ------
>  1 file changed, 38 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c
> b/drivers/crypto/openssl/rte_openssl_pmd.c
> index 7c8bf0d..642580b 100644
> --- a/drivers/crypto/openssl/rte_openssl_pmd.c
> +++ b/drivers/crypto/openssl/rte_openssl_pmd.c
> @@ -1842,15 +1842,13 @@ 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);
>  	uint8_t *tmp;
> 
>  	cop->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
> 
>  	switch (pad) {
> -	case RTE_CRYPTO_RSA_PKCS1_V1_5_BT0:
> -	case RTE_CRYPTO_RSA_PKCS1_V1_5_BT1:
> -	case RTE_CRYPTO_RSA_PKCS1_V1_5_BT2:
> +	case RTE_CRYPTO_RSA_PADDING_PKCS1:
>  		pad = RSA_PKCS1_PADDING;
>  		break;
>  	case RTE_CRYPTO_RSA_PADDING_NONE:
> @@ -1867,19 +1865,19 @@ process_openssl_rsa_op(struct rte_crypto_op
> *cop,
>  	case RTE_CRYPTO_ASYM_OP_ENCRYPT:
>  		ret = RSA_public_encrypt(op->rsa.message.length,
>  				op->rsa.message.data,
> -				op->rsa.message.data,
> +				op->rsa.cipher.data,
>  				rsa,
>  				pad);
> 
>  		if (ret > 0)
> -			op->rsa.message.length = ret;
> +			op->rsa.cipher.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.message.length,
> -				op->rsa.message.data,
> +		ret = RSA_private_decrypt(op->rsa.cipher.length,
> +				op->rsa.cipher.data,
>  				op->rsa.message.data,
>  				rsa,
>  				pad);
> @@ -1898,28 +1896,39 @@ process_openssl_rsa_op(struct rte_crypto_op
> *cop,
>  		break;
> 
>  	case RTE_CRYPTO_ASYM_OP_VERIFY:
> -		tmp = rte_malloc(NULL, op->rsa.sign.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,
> -				tmp,
> -				rsa,
> -				pad);
> -
> -		OPENSSL_LOG(DEBUG,
> -				"Length of public_decrypt %d "
> -				"length of message %zd\n",
> -				ret, op->rsa.message.length);
> -		if ((ret <= 0) || (CRYPTO_memcmp(tmp, op-
> >rsa.message.data,
> -				op->rsa.message.length))) {
> -			OPENSSL_LOG(ERR, "RSA sign Verification failed");
> -			cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
> +		if (pad == RSA_NO_PADDING) {
> +			ret = RSA_public_decrypt(op->rsa.sign.length,
> +					op->rsa.sign.data,
> +					op->rsa.message_to_verify.data,
> +					rsa,
> +					pad);
> +
> +			if (ret > 0)
> +				op->rsa.message_to_verify.length = ret;
> +		} else {
> +			tmp = rte_malloc(NULL, op->rsa.sign.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,
> +					tmp,
> +					rsa,
> +					pad);
> +
> +			OPENSSL_LOG(DEBUG,
> +					"Length of public_decrypt %d "
> +					"length of message %zd\n",
> +					ret, op->rsa.message.length);
> +			if ((ret <= 0) || (CRYPTO_memcmp(tmp, op-
> >rsa.message.data,
> +					op->rsa.message.length))) {
> +				OPENSSL_LOG(ERR, "RSA sign Verification
> failed");
> +				cop->status =
> RTE_CRYPTO_OP_STATUS_ERROR;
> +			}
> +			rte_free(tmp);
>  		}
> -		rte_free(tmp);
>  		break;
> 
>  	default:
> --
> 2.1.0

[dpdk-dev] [PATCH v2 3/3] test: rework rsa test implementation

[Arek Kusztal]

This commit reworks rsa test implementation to be conformant
to the RSA API.
Simulation of PKCS1_5 padding was added to be used with PADDING_NONE
option.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 app/test/test_cryptodev_asym.c      | 44 ++++++++++++++++++++++++-------
 app/test/test_cryptodev_asym_util.h | 52 +++++++++++++++++++++++++++++++++++++
 2 files changed, 87 insertions(+), 9 deletions(-)

diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index fc92d3d..ae43861 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -402,7 +402,7 @@ test_rsa_sign_verify(void)
 	asym_op->rsa.message.data = input_buf;
 	asym_op->rsa.message.length = rsaplaintext.len;
 	asym_op->rsa.sign.data = output_buf;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PKCS1_V1_5_BT1;
+	asym_op->rsa.padding = RTE_CRYPTO_RSA_PADDING_PKCS1;
 
 	debug_hexdump(stdout, "message", asym_op->rsa.message.data,
 			asym_op->rsa.message.length);
@@ -437,7 +437,7 @@ test_rsa_sign_verify(void)
 
 	/* Verify sign */
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_VERIFY;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PKCS1_V1_5_BT2;
+	asym_op->rsa.padding = RTE_CRYPTO_RSA_PADDING_PKCS1;
 
 	/* Process crypto operation */
 	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -483,7 +483,7 @@ test_rsa_sign_verify(void)
 }
 
 static int
-test_rsa_enc_dec(void)
+test_rsa_enc_dec(enum rte_crypto_rsa_padding_type padding)
 {
 	struct crypto_testsuite_params *ts_params = &testsuite_params;
 	struct rte_mempool *op_mpool = ts_params->op_mpool;
@@ -495,6 +495,7 @@ test_rsa_enc_dec(void)
 	struct rte_cryptodev_asym_session *sess = NULL;
 	int status = TEST_SUCCESS;
 	uint8_t input_buf[TEST_DATA_SIZE] = {0};
+	uint8_t cipher_buf[TEST_DATA_SIZE] = {0};
 
 	/* test case supports op with exponent key only,
 	 * Check in PMD feature flag for RSA exponent key type support.
@@ -542,12 +543,18 @@ test_rsa_enc_dec(void)
 	asym_op = op->asym;
 	/*Compute encryption on the test vector */
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_ENCRYPT;
-
-	memcpy(input_buf, rsaplaintext.data,
-			rsaplaintext.len);
 	asym_op->rsa.message.data = input_buf;
 	asym_op->rsa.message.length = rsaplaintext.len;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PKCS1_V1_5_BT2;
+	asym_op->rsa.cipher.data = cipher_buf;
+	asym_op->rsa.cipher.length = 0;
+	asym_op->rsa.padding = padding;
+	if (padding == RTE_CRYPTO_RSA_PADDING_NONE) {
+		rsa_simulate_pkcs1_5_padding(0, input_buf, rsa_xform.rsa.n.length,
+				rsaplaintext.data, rsaplaintext.len);
+		asym_op->rsa.message.length = rsa_xform.rsa.n.length;
+	} else
+		memcpy(input_buf, rsaplaintext.data,
+				rsaplaintext.len);
 
 	debug_hexdump(stdout, "message", asym_op->rsa.message.data,
 			asym_op->rsa.message.length);
@@ -581,7 +588,7 @@ test_rsa_enc_dec(void)
 	/* Use the resulted output as decryption Input vector*/
 	asym_op = result_op->asym;
 	asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_DECRYPT;
-	asym_op->rsa.pad = RTE_CRYPTO_RSA_PKCS1_V1_5_BT1;
+	asym_op->rsa.padding = padding;
 
 	/* Process crypto operation */
 	if (rte_cryptodev_enqueue_burst(dev_id, 0, &op, 1) != 1) {
@@ -604,7 +611,15 @@ test_rsa_enc_dec(void)
 	}
 	status = TEST_SUCCESS;
 	int ret = 0;
+
+	if (padding == RTE_CRYPTO_RSA_PADDING_NONE) {
+		result_op->asym->rsa.message.length =
+				rsa_simulate_strip_pkcs1_5_padding(result_op->asym->rsa.message.data,
+				rsa_xform.rsa.n.length);
+	}
+
 	ret = rsa_verify(&rsaplaintext, result_op);
+
 	if (ret)
 		status = TEST_FAILED;
 
@@ -624,6 +639,16 @@ test_rsa_enc_dec(void)
 }
 
 static int
+test_rsa_enc_dec_pkcs_1(void){
+	return test_rsa_enc_dec(RTE_CRYPTO_RSA_PADDING_PKCS1);
+}
+
+static int
+test_rsa_enc_dec_pkcs_1_none(void){
+	return test_rsa_enc_dec(RTE_CRYPTO_RSA_PADDING_NONE);
+}
+
+static int
 testsuite_setup(void)
 {
 	struct crypto_testsuite_params *ts_params = &testsuite_params;
@@ -1684,7 +1709,8 @@ static struct unit_test_suite cryptodev_openssl_asym_testsuite  = {
 		TEST_CASE_ST(ut_setup, ut_teardown, test_capability),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_dsa),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_dh_keygenration),
-		TEST_CASE_ST(ut_setup, ut_teardown, test_rsa_enc_dec),
+		TEST_CASE_ST(ut_setup, ut_teardown, test_rsa_enc_dec_pkcs_1),
+		TEST_CASE_ST(ut_setup, ut_teardown, test_rsa_enc_dec_pkcs_1_none),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_rsa_sign_verify),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_mod_inv),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_mod_exp),
diff --git a/app/test/test_cryptodev_asym_util.h b/app/test/test_cryptodev_asym_util.h
index b3d9fb4..484b967 100644
--- a/app/test/test_cryptodev_asym_util.h
+++ b/app/test/test_cryptodev_asym_util.h
@@ -7,6 +7,58 @@
 
 /* Below Apis compare resulted buffer to original test vector */
 
+/*
+ * Two functions below simulate pkcs 1.5 padding and serves only as an example,
+ * both offer no security.
+ */
+static inline int rsa_simulate_pkcs1_5_padding(int op, uint8_t *p,
+		int key_size, const uint8_t *src, int len) {
+
+	int ps_len;
+
+	if (len > key_size - 11)
+		return -1;
+	ps_len = key_size - len - 3;
+
+	*(p++) = 0;
+	*(p++) = op ? 1 : 2;
+	if (op) {
+		while (ps_len--)
+			*p = 0xFF;
+	} else {
+		while (ps_len--) {
+			*p = (uint8_t)rand();
+			*p ^= !(*p);
+			p++;
+		}
+	}
+
+	*(p++) = 0;
+	memcpy(p, src, len);
+
+	return 0;
+}
+
+static inline int rsa_simulate_strip_pkcs1_5_padding(uint8_t *src,
+		int key_size) {
+	uint8_t tmp[key_size], *orig_src = src;
+	int i = 1;
+	++src;
+	while (*(src) && i < key_size) {
+		++i;
+		++src;
+	}
+	if (i == key_size)
+		return -1;
+
+	++i;
+	++src;
+
+	memcpy(tmp, src, key_size - i);
+	memcpy(orig_src, tmp, key_size - i);
+	return key_size - i;
+}
+
 static inline int rsa_verify(struct rsa_test_data *rsa_param,
 		struct rte_crypto_op *result_op)
 {
-- 
2.1.0

Re: [dpdk-dev] [PATCH v2 0/3]Rework API for RSA algorithm in asymmetric crypto

[Trahe, Fiona]

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, July 3, 2019 4:38 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>; shally.verma@caviumnetworks.com;
> Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v2 0/3]Rework API for RSA algorithm in asymmetric crypto
> 
> Most things from v1 were simplified according to Shally adn Fiona comments.
> No more rfc details in comments and some things were shortened.
> There is no more struct for padding too, but only union for
> PSS and OAEP.
> Added test case for padding none with encryption (pkcs padding is done in test)
> ps. I will send signature padding none signature case soon.
> 
> Major changes comparing to current version:
> - Cipher field was introduced
> - Added guide to use none padding
> - Field for singature verification when padding none selected was added
> 	(as there is no Public-Decrypt)
> - Padding union was created
> - PKCS1-v1_5 Block type 0 was removed
> - Fixed all wrong comments (prime numbers etc.)
> 
> v2:
> - Field for singature verification when padding none selected was added
> - Removed details from RFC
> - Simplified padding struct
> - Added padding none test case
> 
> Arek Kusztal (3):
>   cryptodev: rework api of rsa algorithm
>   crypto/openssl: rework openssl rsa implementation
>   test: rework rsa test implementation
> 
>  app/test/test_cryptodev_asym.c           |  44 +++++++--
>  app/test/test_cryptodev_asym_util.h      |  52 +++++++++++
>  drivers/crypto/openssl/rte_openssl_pmd.c |  67 ++++++++------
>  lib/librte_cryptodev/rte_crypto_asym.h   | 150 ++++++++++++++++++++++++-------
>  4 files changed, 243 insertions(+), 70 deletions(-)
> 
> --
> 2.1.0
[Fiona] There are a few spelling mistakes still, but as this API is still experimental and will
have further changes in 19.11 which can address those, I would not like to block this patchset now, so
Series-acked-by: Fiona Trahe <fiona.trahe@intel.com>