diff mbox series

[RFC] cryptodev: add sm2 key exchange and encryption for HW

Message ID 20231228161932.54253-1-arkadiuszx.kusztal@intel.com (mailing list archive)
State New
Delegated to: akhil goyal
Headers
Series [RFC] cryptodev: add sm2 key exchange and encryption for HW |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/intel-Functional success Functional PASS

Commit Message

Arkadiusz Kusztal Dec. 28, 2023, 4:19 p.m. UTC 
  This commit adds comments for the proposal of addition of SM2
algorithm key exchange and encryption/decryption operation.

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

Comments

Gowrishankar Muthukrishnan Jan. 4, 2024, 1:37 p.m. UTC | #1 
Hi,

> This commit adds comments for the proposal of addition of SM2 algorithm key
> exchange and encryption/decryption operation.
> 
> Signed-off-by: Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
> ---
>  lib/cryptodev/rte_crypto_asym.h | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 39d3da3952..6911a14dbd 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -639,6 +639,10 @@ struct rte_crypto_asym_xform {  struct
> rte_crypto_sm2_op_param {
>  	enum rte_crypto_asym_op_type op_type;
>  	/**< Signature generation or verification. */
> +	/*
> +	 * For key exchange operation, new struct should be created.
> +	 * Doing that, the current struct could be split into signature and
> encryption.
> +	 */
> 
>  	enum rte_crypto_auth_algorithm hash;
>  	/**< Hash algorithm used in EC op. */
> @@ -672,6 +676,18 @@ struct rte_crypto_sm2_op_param {
>  	 * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
>  	 * be overwritten by the PMD with the encrypted length.
>  	 */
> +	/* SM2 encryption algorithm relies on certain cryptographic functions,
> +	 * that HW devices not necesseraly need to implement.
> +	 * When C1 is a elliptic curve point, C2 and C3 need additional
> +	 * operation like KDF and Hash. The question here is: should only
> +	 * elliptic curve output parameters (namely C1 and PB) be returned to
> the user,
> +	 * or should encryption be, in this case, computed within the PMD using
> +	 * software methods, or should both option be available?
> +	 */

I second on splitting this struct for PKE (may be _pke and _dsa).

At the same time, handling these structs should be followed by some capability check
and that was what I have been thinking on to propose as asym OP capability in this release.
Right now, asymmetric capability is defined only by xform (not also by op).
But we could add op capab also as below.

struct rte_cryptodev_capabilities caps_sm2[] = {
	.op = RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
	{
		.asym = {
			.xform_capa = {
				.xform_type = RTE_CRYPTO_ASYM_XFORM_SM2,
				.op_types = ...
			},
			.op_capa = [
				{
					.op_type = RTE_CRYPTO_ASYM_OP_ENC,
					.capa = (1 << RTE_CRYPTO_ASYM_SM2_PKE_KDF | 1 << RTE_CRYPTO_ASYM_SM2_PKE_HASH)  <<<< NEW ENUM >>>>
				}
			]
		}
	}
}

Doing this, hash_algos member in asym xform capability today can eventually be removed
And it sounds better for an op. Also, this op capability check could be done once for the session.
If you are also aligned, I can send an RFC for capab check.

> +	/* Similar applies to the key exchange in the HW. The second phase of
> KE, most likely,
> +	 * will go as far as to obtain xU,yU(xV,xV), where SW can easily
> calculate SA.

What does SA mean here ? Signature algorithm ??.

Thanks,
Gowrishankar

> +	 * Should then both options be available?
> +	 */
> 
>  	rte_crypto_uint id;
>  	/**< The SM2 id used by signer and verifier. */
> --
> 2.13.6
Arkadiusz Kusztal Jan. 24, 2024, 5:41 p.m. UTC | #2 
> -----Original Message-----
> From: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> Sent: Thursday, January 4, 2024 2:38 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Cc: Akhil Goyal <gakhil@marvell.com>; Ji, Kai <kai.ji@intel.com>; Power, Ciara
> <ciara.power@intel.com>; Anoob Joseph <anoobj@marvell.com>;
> dev@dpdk.org
> Subject: RE: [EXT] [RFC PATCH] cryptodev: add sm2 key exchange and
> encryption for HW
> 
> Hi,
> 
> > This commit adds comments for the proposal of addition of SM2
> > algorithm key exchange and encryption/decryption operation.
> >
> > Signed-off-by: Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 39d3da3952..6911a14dbd 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -639,6 +639,10 @@ struct rte_crypto_asym_xform {  struct
> > rte_crypto_sm2_op_param {
> >  	enum rte_crypto_asym_op_type op_type;
> >  	/**< Signature generation or verification. */
> > +	/*
> > +	 * For key exchange operation, new struct should be created.
> > +	 * Doing that, the current struct could be split into signature and
> > encryption.
> > +	 */
> >
> >  	enum rte_crypto_auth_algorithm hash;
> >  	/**< Hash algorithm used in EC op. */ @@ -672,6 +676,18 @@ struct
> > rte_crypto_sm2_op_param {
> >  	 * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
> >  	 * be overwritten by the PMD with the encrypted length.
> >  	 */
> > +	/* SM2 encryption algorithm relies on certain cryptographic functions,
> > +	 * that HW devices not necesseraly need to implement.
> > +	 * When C1 is a elliptic curve point, C2 and C3 need additional
> > +	 * operation like KDF and Hash. The question here is: should only
> > +	 * elliptic curve output parameters (namely C1 and PB) be returned
> > +to
> > the user,
> > +	 * or should encryption be, in this case, computed within the PMD using
> > +	 * software methods, or should both option be available?
> > +	 */
> 
> I second on splitting this struct for PKE (may be _pke and _dsa).
> 
> At the same time, handling these structs should be followed by some capability
> check and that was what I have been thinking on to propose as asym OP
> capability in this release.
> Right now, asymmetric capability is defined only by xform (not also by op).
> But we could add op capab also as below.
> 
> struct rte_cryptodev_capabilities caps_sm2[] = {
> 	.op = RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
> 	{
> 		.asym = {
> 			.xform_capa = {
> 				.xform_type =
> RTE_CRYPTO_ASYM_XFORM_SM2,
> 				.op_types = ...
> 			},
> 			.op_capa = [
> 				{
> 					.op_type =
> RTE_CRYPTO_ASYM_OP_ENC,
> 					.capa = (1 <<
> RTE_CRYPTO_ASYM_SM2_PKE_KDF | 1 <<
> RTE_CRYPTO_ASYM_SM2_PKE_HASH)  <<<< NEW ENUM >>>>
> 				}
> 			]
> 		}
> 	}
> }
> 
> Doing this, hash_algos member in asym xform capability today can eventually be
> removed And it sounds better for an op. Also, this op capability check could be
> done once for the session.
> If you are also aligned, I can send an RFC for capab check.

Yes, please send.
Additionally, on top of it, we need to add several fields to the sm2.
We have never had this problem, as most of the algorithms are self-sufficient, which is not a case for smX, as well as EdDSA for example. 
So for certain HW cases:
For encryption and decryption, there should be C1 as an input or output.
For key exchange, there should be (xU/V,yU/V) as an output.

> 
> > +	/* Similar applies to the key exchange in the HW. The second phase
> > +of
> > KE, most likely,
> > +	 * will go as far as to obtain xU,yU(xV,xV), where SW can easily
> > calculate SA.
> 
> What does SA mean here ? Signature algorithm ??.
> 
> Thanks,
> Gowrishankar
> 
> > +	 * Should then both options be available?
> > +	 */
> >
> >  	rte_crypto_uint id;
> >  	/**< The SM2 id used by signer and verifier. */
> > --
> > 2.13.6
diff mbox series

Patch

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 39d3da3952..6911a14dbd 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -639,6 +639,10 @@  struct rte_crypto_asym_xform {
 struct rte_crypto_sm2_op_param {
 	enum rte_crypto_asym_op_type op_type;
 	/**< Signature generation or verification. */
+	/*
+	 * For key exchange operation, new struct should be created.
+	 * Doing that, the current struct could be split into signature and encryption.
+	 */
 
 	enum rte_crypto_auth_algorithm hash;
 	/**< Hash algorithm used in EC op. */
@@ -672,6 +676,18 @@  struct rte_crypto_sm2_op_param {
 	 * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
 	 * be overwritten by the PMD with the encrypted length.
 	 */
+	/* SM2 encryption algorithm relies on certain cryptographic functions,
+	 * that HW devices not necesseraly need to implement.
+	 * When C1 is a elliptic curve point, C2 and C3 need additional
+	 * operation like KDF and Hash. The question here is: should only
+	 * elliptic curve output parameters (namely C1 and PB) be returned to the user,
+	 * or should encryption be, in this case, computed within the PMD using
+	 * software methods, or should both option be available?
+	 */
+	/* Similar applies to the key exchange in the HW. The second phase of KE, most likely,
+	 * will go as far as to obtain xU,yU(xV,xV), where SW can easily calculate SA.
+	 * Should then both options be available?
+	 */
 
 	rte_crypto_uint id;
 	/**< The SM2 id used by signer and verifier. */