diff mbox series

[v2,11/14] cryptodev: move RSA padding into separate struct

Message ID 20220525155324.9288-12-arkadiuszx.kusztal@intel.com (mailing list archive)
State Superseded, archived
Delegated to: akhil goyal
Headers
Series cryptodev: rsa, dh, ecdh changes |

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Arkadiusz Kusztal May 25, 2022, 3:53 p.m. UTC 
  - move RSA padding into separate struct.
More padding members should be added into padding,
therefore having separate struct for padding parameters will
make this more readable.

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

Comments

Akhil Goyal May 26, 2022, 12:04 p.m. UTC | #1 
>  /**
> + * RSA padding type
> + */
> +struct rte_crypto_rsa_padding {
> +	enum rte_crypto_rsa_padding_type type;
> +	/**< RSA padding scheme to be used for transform */
> +	enum rte_crypto_auth_algorithm md;
> +	/**<
> +	 * RSA padding hash function
> +	 *
> +	 * When a specific padding type is selected, the following rule apply:
> +	 * - RTE_CRYPTO_RSA_PADDING_NONE:
> +	 * This field is ignored by the PMD
> +	 *
> +	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
> +	 * When signing operation this field is used to determine value
> +	 * of the DigestInfo structure, therefore specifying which algorithm
> +	 * was used to create the message digest.
> +	 * When doing encryption/decryption this field is ignored for this
> +	 * padding type.
> +	 *
> +	 * - RTE_CRYPTO_RSA_PADDING_OAEP
> +	 * This field shall be set with the hash algorithm used
> +	 * in the padding scheme
> +	 *
> +	 * - RTE_CRYPTO_RSA_PADDING_PSS
> +	 * This field shall be set with the hash algorithm used
> +	 * in the padding scheme (and to create the input message digest)
> +	 */
Forgot to comment on previous patch about the valid algos for this.
They are removed in previous patch, but it should not be removed. Right?
Arkadiusz Kusztal May 26, 2022, 12:14 p.m. UTC | #2 
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, May 26, 2022 2:05 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH v2 11/14] cryptodev: move RSA padding into separate
> struct
> 
> >  /**
> > + * RSA padding type
> > + */
> > +struct rte_crypto_rsa_padding {
> > +	enum rte_crypto_rsa_padding_type type;
> > +	/**< RSA padding scheme to be used for transform */
> > +	enum rte_crypto_auth_algorithm md;
> > +	/**<
> > +	 * RSA padding hash function
> > +	 *
> > +	 * When a specific padding type is selected, the following rule apply:
> > +	 * - RTE_CRYPTO_RSA_PADDING_NONE:
> > +	 * This field is ignored by the PMD
> > +	 *
> > +	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
> > +	 * When signing operation this field is used to determine value
> > +	 * of the DigestInfo structure, therefore specifying which algorithm
> > +	 * was used to create the message digest.
> > +	 * When doing encryption/decryption this field is ignored for this
> > +	 * padding type.
> > +	 *
> > +	 * - RTE_CRYPTO_RSA_PADDING_OAEP
> > +	 * This field shall be set with the hash algorithm used
> > +	 * in the padding scheme
> > +	 *
> > +	 * - RTE_CRYPTO_RSA_PADDING_PSS
> > +	 * This field shall be set with the hash algorithm used
> > +	 * in the padding scheme (and to create the input message digest)
> > +	 */
> Forgot to comment on previous patch about the valid algos for this.
> They are removed in previous patch, but it should not be removed. Right?
Which hash functions are supported by RSA can be found in RSA standard, additionally our list was incomplete.
There is no Hash functions enum in Cryptodev -> we keep Hash functions together with mac aglorithms, so that's why it was probably included in the first place. But I would say we should not specify valid algs here.
>
Akhil Goyal May 26, 2022, 12:19 p.m. UTC | #3 
> > >  /**
> > > + * RSA padding type
> > > + */
> > > +struct rte_crypto_rsa_padding {
> > > +	enum rte_crypto_rsa_padding_type type;
> > > +	/**< RSA padding scheme to be used for transform */
> > > +	enum rte_crypto_auth_algorithm md;
> > > +	/**<
> > > +	 * RSA padding hash function
> > > +	 *
> > > +	 * When a specific padding type is selected, the following rule apply:
> > > +	 * - RTE_CRYPTO_RSA_PADDING_NONE:
> > > +	 * This field is ignored by the PMD
> > > +	 *
> > > +	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
> > > +	 * When signing operation this field is used to determine value
> > > +	 * of the DigestInfo structure, therefore specifying which algorithm
> > > +	 * was used to create the message digest.
> > > +	 * When doing encryption/decryption this field is ignored for this
> > > +	 * padding type.
> > > +	 *
> > > +	 * - RTE_CRYPTO_RSA_PADDING_OAEP
> > > +	 * This field shall be set with the hash algorithm used
> > > +	 * in the padding scheme
> > > +	 *
> > > +	 * - RTE_CRYPTO_RSA_PADDING_PSS
> > > +	 * This field shall be set with the hash algorithm used
> > > +	 * in the padding scheme (and to create the input message digest)
> > > +	 */
> > Forgot to comment on previous patch about the valid algos for this.
> > They are removed in previous patch, but it should not be removed. Right?
> Which hash functions are supported by RSA can be found in RSA standard,
> additionally our list was incomplete.
> There is no Hash functions enum in Cryptodev -> we keep Hash functions
> together with mac aglorithms, so that's why it was probably included in the first
> place. But I would say we should not specify valid algs here.

In that case, mgf1md comment should also be updated.
But again, if we are combining with mac algos, we should specify it. Right? This is not
RFC, it is our implementation of the RFC. If we are combining with mac algos, it makes
more sense to specify the valid algos.
Arkadiusz Kusztal May 26, 2022, 12:35 p.m. UTC | #4 
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Thursday, May 26, 2022 2:20 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH v2 11/14] cryptodev: move RSA padding into separate
> struct
> 
> > > >  /**
> > > > + * RSA padding type
> > > > + */
> > > > +struct rte_crypto_rsa_padding {
> > > > +	enum rte_crypto_rsa_padding_type type;
> > > > +	/**< RSA padding scheme to be used for transform */
> > > > +	enum rte_crypto_auth_algorithm md;
> > > > +	/**<
> > > > +	 * RSA padding hash function
> > > > +	 *
> > > > +	 * When a specific padding type is selected, the following rule apply:
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_NONE:
> > > > +	 * This field is ignored by the PMD
> > > > +	 *
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
> > > > +	 * When signing operation this field is used to determine value
> > > > +	 * of the DigestInfo structure, therefore specifying which algorithm
> > > > +	 * was used to create the message digest.
> > > > +	 * When doing encryption/decryption this field is ignored for this
> > > > +	 * padding type.
> > > > +	 *
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_OAEP
> > > > +	 * This field shall be set with the hash algorithm used
> > > > +	 * in the padding scheme
> > > > +	 *
> > > > +	 * - RTE_CRYPTO_RSA_PADDING_PSS
> > > > +	 * This field shall be set with the hash algorithm used
> > > > +	 * in the padding scheme (and to create the input message digest)
> > > > +	 */
> > > Forgot to comment on previous patch about the valid algos for this.
> > > They are removed in previous patch, but it should not be removed. Right?
> > Which hash functions are supported by RSA can be found in RSA
> > standard, additionally our list was incomplete.
> > There is no Hash functions enum in Cryptodev -> we keep Hash functions
> > together with mac aglorithms, so that's why it was probably included
> > in the first place. But I would say we should not specify valid algs here.
> 
> In that case, mgf1md comment should also be updated.
> But again, if we are combining with mac algos, we should specify it. Right? This
> is not RFC, it is our implementation of the RFC. If we are combining with mac
> algos, it makes more sense to specify the valid algos.
Its actually not that big problem, though I thought it is stating the obvious.
So we can add it back again but with full RSA hash list (including 512/224 256), or we will add it when this will be added to rte_crypto_auth_algorithm?
Akhil Goyal May 26, 2022, 12:41 p.m. UTC | #5 
> > > > >  /**
> > > > > + * RSA padding type
> > > > > + */
> > > > > +struct rte_crypto_rsa_padding {
> > > > > +	enum rte_crypto_rsa_padding_type type;
> > > > > +	/**< RSA padding scheme to be used for transform */
> > > > > +	enum rte_crypto_auth_algorithm md;
> > > > > +	/**<
> > > > > +	 * RSA padding hash function
> > > > > +	 *
> > > > > +	 * When a specific padding type is selected, the following rule
> apply:
> > > > > +	 * - RTE_CRYPTO_RSA_PADDING_NONE:
> > > > > +	 * This field is ignored by the PMD
> > > > > +	 *
> > > > > +	 * - RTE_CRYPTO_RSA_PADDING_PKCS1_5:
> > > > > +	 * When signing operation this field is used to determine value
> > > > > +	 * of the DigestInfo structure, therefore specifying which
> algorithm
> > > > > +	 * was used to create the message digest.
> > > > > +	 * When doing encryption/decryption this field is ignored for
> this
> > > > > +	 * padding type.
> > > > > +	 *
> > > > > +	 * - RTE_CRYPTO_RSA_PADDING_OAEP
> > > > > +	 * This field shall be set with the hash algorithm used
> > > > > +	 * in the padding scheme
> > > > > +	 *
> > > > > +	 * - RTE_CRYPTO_RSA_PADDING_PSS
> > > > > +	 * This field shall be set with the hash algorithm used
> > > > > +	 * in the padding scheme (and to create the input message
> digest)
> > > > > +	 */
> > > > Forgot to comment on previous patch about the valid algos for this.
> > > > They are removed in previous patch, but it should not be removed. Right?
> > > Which hash functions are supported by RSA can be found in RSA
> > > standard, additionally our list was incomplete.
> > > There is no Hash functions enum in Cryptodev -> we keep Hash functions
> > > together with mac aglorithms, so that's why it was probably included
> > > in the first place. But I would say we should not specify valid algs here.
> >
> > In that case, mgf1md comment should also be updated.
> > But again, if we are combining with mac algos, we should specify it. Right?
> This
> > is not RFC, it is our implementation of the RFC. If we are combining with mac
> > algos, it makes more sense to specify the valid algos.
> Its actually not that big problem, though I thought it is stating the obvious.
> So we can add it back again but with full RSA hash list (including 512/224 256), or
> we will add it when this will be added to rte_crypto_auth_algorithm?

Whatever current support is there, it should be added to specify which all can be
Used from the rte_crypto_auth_algorithm enum. As not all can be blindly used.
diff mbox series

Patch

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