[v3,1/3] cryptodev: add SM2 asymmetric crypto algorithm
Checks
Commit Message
ShangMi 2 (SM2) is set of public-key cryptography algorithms
based on elliptic curves.
Added support for asymmetric SM2 in cryptodev along with prime
field curve, as referenced in RFC:
https://datatracker.ietf.org/doc/html/draft-shen-sm2-ecdsa-02
Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
---
doc/guides/cryptodevs/features/default.ini | 1 +
doc/guides/rel_notes/release_23_07.rst | 5 ++
lib/cryptodev/rte_crypto_asym.h | 87 ++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 1 +
4 files changed, 94 insertions(+)
Comments
Acked-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Some things will need to be changed before the next release (few of them I described below), but I will ack it. Especially that other algorithms have similar issues.
> -----Original Message-----
> From: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> Sent: Sunday, June 4, 2023 11:43 AM
> To: dev@dpdk.org
> Cc: anoobj@marvell.com; Akhil Goyal <gakhil@marvell.com>; Kusztal,
> ArkadiuszX <arkadiuszx.kusztal@intel.com>; Fan Zhang
> <fanzhang.oss@gmail.com>; Ji, Kai <kai.ji@intel.com>; Gowrishankar
> Muthukrishnan <gmuthukrishn@marvell.com>
> Subject: [PATCH v3 1/3] cryptodev: add SM2 asymmetric crypto algorithm
>
> ShangMi 2 (SM2) is set of public-key cryptography algorithms based on elliptic
> curves.
>
> Added support for asymmetric SM2 in cryptodev along with prime field curve, as
> referenced in RFC:
> https://datatracker.ietf.org/doc/html/draft-shen-sm2-ecdsa-02
>
> Signed-off-by: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
> ---
> doc/guides/cryptodevs/features/default.ini | 1 +
> doc/guides/rel_notes/release_23_07.rst | 5 ++
> lib/cryptodev/rte_crypto_asym.h | 87 ++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.c | 1 +
> 4 files changed, 94 insertions(+)
>
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 523da0cfa8..a69967bb9e 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -125,6 +125,7 @@ Diffie-hellman =
> ECDSA =
> ECPM =
> ECDH =
> +SM2 =
>
> ;
> ; Supported Operating systems of a default crypto driver.
> diff --git a/doc/guides/rel_notes/release_23_07.rst
> b/doc/guides/rel_notes/release_23_07.rst
> index a9b1293689..8b8e69d619 100644
> --- a/doc/guides/rel_notes/release_23_07.rst
> +++ b/doc/guides/rel_notes/release_23_07.rst
> @@ -55,6 +55,11 @@ New Features
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* **Added SM2 asymmetric algorithm in cryptodev.**
> +
> + Added support for ShamMi 2 (SM2) asymmetric crypto algorithm along
> + with prime field curve support.
> +
>
> Removed Items
> -------------
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 989f38323f..ab0b4abea7 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -119,6 +119,11 @@ enum rte_crypto_asym_xform_type {
> /**< Elliptic Curve Point Multiplication */
> RTE_CRYPTO_ASYM_XFORM_ECFPM,
> /**< Elliptic Curve Fixed Point Multiplication */
> + RTE_CRYPTO_ASYM_XFORM_SM2,
> + /**< ShangMi 2
> + * Performs Encrypt, Decrypt, Sign and Verify.
> + * Refer to rte_crypto_asym_op_type.
> + */
> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> /**< End of list */
> };
> @@ -382,6 +387,17 @@ struct rte_crypto_ec_xform {
> /**< Pre-defined ec groups */
> };
>
> +/**
> + * Asymmetric SM2 transform data
> + *
> + * Structure describing SM2 xform params
> + *
> + */
> +struct rte_crypto_sm2_xform {
> + enum rte_crypto_auth_algorithm hash;
> + /**< Hash algorithm used in SM2 op. */ };
> +
> /**
> * Operations params for modular operations:
> * exponentiation and multiplicative inverse @@ -637,9 +653,79 @@ struct
> rte_crypto_asym_xform {
> /**< EC xform parameters, used by elliptic curve based
> * operations.
> */
> +
> + struct rte_crypto_sm2_xform sm2;
> + /**< SM2 xform parameters */
> };
> };
>
> +/**
> + * SM2 operation params
> + */
> +struct rte_crypto_sm2_op_param {
> + enum rte_crypto_asym_op_type op_type;
> + /**< Signature generation or verification */
> +
> + rte_crypto_uint pkey;
> + /**< Private key for encryption or sign generation */
> +
> + struct rte_crypto_ec_point q;
> + /**< Public key for decryption or verification */
> +
> + rte_crypto_param message;
> + /**<
> + * Pointer to input data
> + * - to be encrypted for SM2 public encrypt.
> + * - to be signed for SM2 sign generation.
> + * - to be authenticated for SM2 sign verification.
> + *
This repeats problems known to dsa/ecdsa. What will work on OpenSSL PMD will not work on the HW. Ironically, test will pass for both...
We can extend this before the next release.
> + * Pointer to output data
> + * - for SM2 private decrypt.
> + * In this case the underlying array should have been
> + * allocated with enough memory to hold plaintext output
> + * (at least encrypted text length). The message.length field
> + * will be overwritten by the PMD with the decrypted length.
> + */
> +
> + rte_crypto_param cipher;
> + /**<
> + * Pointer to input data
> + * - to be decrypted for SM2 private decrypt.
> + *
> + * Pointer to output data
> + * - for SM2 public encrypt.
> + * In this case the underlying array should have been allocated
> + * with enough memory to hold ciphertext output (at least X bytes
> + * for prime field curve of N bytes and for message M bytes,
> + * where X = (C1 + C2 + C3) and computed based on SM2 RFC as
> + * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
> + * be overwritten by the PMD with the encrypted length.
> + */
I thought it was concatenation, not addition.
> +
> + rte_crypto_uint id;
> + /**< The SM2 id used by signer and verifier and is in interval (1,
> +n-1). */
Where does the (1,n-1) limitation comes from? As it is a hashed prefix, should it have any mathematical interpretation at all?
> +
> + rte_crypto_uint k;
> + /**< The SM2 per-message secret number, which is an integer
> + * in the interval (1, n-1).
> + * If the random number is generated by the PMD,
> + * the 'rte_crypto_param.data' parameter should be set to NULL.
> + */
> +
> + rte_crypto_uint r;
> + /**< r component of elliptic curve signature
> + * output : for signature generation (of at least N bytes
> + * where prime field length is N bytes)
> + * input : for signature verification
> + */
> + rte_crypto_uint s;
> + /**< s component of elliptic curve signature
> + * output : for signature generation (of at least N bytes
> + * where prime field length is N bytes)
> + * input : for signature verification
> + */
> +};
> +
> /**
> * Asymmetric Cryptographic Operation.
> *
> @@ -665,6 +751,7 @@ struct rte_crypto_asym_op {
> struct rte_crypto_dsa_op_param dsa;
> struct rte_crypto_ecdsa_op_param ecdsa;
> struct rte_crypto_ecpm_op_param ecpm;
> + struct rte_crypto_sm2_op_param sm2;
> };
> uint16_t flags;
> /**<
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c index
> a96114b2da..21cabc3ffd 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -299,6 +299,7 @@ crypto_asym_xform_strings[] = {
> [RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
> [RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
> [RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
> + [RTE_CRYPTO_ASYM_XFORM_SM2] = "sm2",
> };
>
> /**
> --
> 2.25.1
> Acked-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>
> Some things will need to be changed before the next release (few of them I
> described below), but I will ack it. Especially that other algorithms have similar
> issues.
>
Sure. I also thought any improvements can collectively addressed as it is another EC.
> > +/**
> > + * Asymmetric SM2 transform data
> > + *
> > + * Structure describing SM2 xform params
> > + *
> > + */
> > +struct rte_crypto_sm2_xform {
> > + enum rte_crypto_auth_algorithm hash;
> > + /**< Hash algorithm used in SM2 op. */ };
> > +
> > /**
> > * Operations params for modular operations:
> > * exponentiation and multiplicative inverse @@ -637,9 +653,79 @@
> > struct rte_crypto_asym_xform {
> > /**< EC xform parameters, used by elliptic curve based
> > * operations.
> > */
> > +
> > + struct rte_crypto_sm2_xform sm2;
> > + /**< SM2 xform parameters */
> > };
> > };
> >
> > +/**
> > + * SM2 operation params
> > + */
> > +struct rte_crypto_sm2_op_param {
> > + enum rte_crypto_asym_op_type op_type;
> > + /**< Signature generation or verification */
> > +
> > + rte_crypto_uint pkey;
> > + /**< Private key for encryption or sign generation */
> > +
> > + struct rte_crypto_ec_point q;
> > + /**< Public key for decryption or verification */
> > +
> > + rte_crypto_param message;
> > + /**<
> > + * Pointer to input data
> > + * - to be encrypted for SM2 public encrypt.
> > + * - to be signed for SM2 sign generation.
> > + * - to be authenticated for SM2 sign verification.
> > + *
>
> This repeats problems known to dsa/ecdsa. What will work on OpenSSL PMD will
> not work on the HW. Ironically, test will pass for both...
> We can extend this before the next release.
Ack
>
> > + * Pointer to output data
> > + * - for SM2 private decrypt.
> > + * In this case the underlying array should have been
> > + * allocated with enough memory to hold plaintext output
> > + * (at least encrypted text length). The message.length field
> > + * will be overwritten by the PMD with the decrypted length.
> > + */
> > +
> > + rte_crypto_param cipher;
> > + /**<
> > + * Pointer to input data
> > + * - to be decrypted for SM2 private decrypt.
> > + *
> > + * Pointer to output data
> > + * - for SM2 public encrypt.
> > + * In this case the underlying array should have been allocated
> > + * with enough memory to hold ciphertext output (at least X bytes
> > + * for prime field curve of N bytes and for message M bytes,
> > + * where X = (C1 + C2 + C3) and computed based on SM2 RFC as
> > + * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
> > + * be overwritten by the PMD with the encrypted length.
> > + */
> I thought it was concatenation, not addition.
Typo I did. Yes it should have been ||.
> > +
> > + rte_crypto_uint id;
> > + /**< The SM2 id used by signer and verifier and is in interval (1,
> > +n-1). */
> Where does the (1,n-1) limitation comes from? As it is a hashed prefix, should it
> have any mathematical interpretation at all?
Yeah it is not necessarily limited wrt n. we can just phrase it:
/**< The SM2 id used by signer and verifier */
In fact, here could be another improvement (applicable to EC as well) to
keep the params specific to op. Sign/verify only would need this param
(and r , s below).
> > +
> > + rte_crypto_uint k;
> > + /**< The SM2 per-message secret number, which is an integer
> > + * in the interval (1, n-1).
> > + * If the random number is generated by the PMD,
> > + * the 'rte_crypto_param.data' parameter should be set to NULL.
> > + */
> > +
> > + rte_crypto_uint r;
> > + /**< r component of elliptic curve signature
> > + * output : for signature generation (of at least N bytes
> > + * where prime field length is N bytes)
> > + * input : for signature verification
> > + */
> > + rte_crypto_uint s;
> > + /**< s component of elliptic curve signature
> > + * output : for signature generation (of at least N bytes
> > + * where prime field length is N bytes)
> > + * input : for signature verification
> > + */
> > +};
> > +
@@ -125,6 +125,7 @@ Diffie-hellman =
ECDSA =
ECPM =
ECDH =
+SM2 =
;
; Supported Operating systems of a default crypto driver.
@@ -55,6 +55,11 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added SM2 asymmetric algorithm in cryptodev.**
+
+ Added support for ShamMi 2 (SM2) asymmetric crypto algorithm
+ along with prime field curve support.
+
Removed Items
-------------
@@ -119,6 +119,11 @@ enum rte_crypto_asym_xform_type {
/**< Elliptic Curve Point Multiplication */
RTE_CRYPTO_ASYM_XFORM_ECFPM,
/**< Elliptic Curve Fixed Point Multiplication */
+ RTE_CRYPTO_ASYM_XFORM_SM2,
+ /**< ShangMi 2
+ * Performs Encrypt, Decrypt, Sign and Verify.
+ * Refer to rte_crypto_asym_op_type.
+ */
RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
/**< End of list */
};
@@ -382,6 +387,17 @@ struct rte_crypto_ec_xform {
/**< Pre-defined ec groups */
};
+/**
+ * Asymmetric SM2 transform data
+ *
+ * Structure describing SM2 xform params
+ *
+ */
+struct rte_crypto_sm2_xform {
+ enum rte_crypto_auth_algorithm hash;
+ /**< Hash algorithm used in SM2 op. */
+};
+
/**
* Operations params for modular operations:
* exponentiation and multiplicative inverse
@@ -637,9 +653,79 @@ struct rte_crypto_asym_xform {
/**< EC xform parameters, used by elliptic curve based
* operations.
*/
+
+ struct rte_crypto_sm2_xform sm2;
+ /**< SM2 xform parameters */
};
};
+/**
+ * SM2 operation params
+ */
+struct rte_crypto_sm2_op_param {
+ enum rte_crypto_asym_op_type op_type;
+ /**< Signature generation or verification */
+
+ rte_crypto_uint pkey;
+ /**< Private key for encryption or sign generation */
+
+ struct rte_crypto_ec_point q;
+ /**< Public key for decryption or verification */
+
+ rte_crypto_param message;
+ /**<
+ * Pointer to input data
+ * - to be encrypted for SM2 public encrypt.
+ * - to be signed for SM2 sign generation.
+ * - to be authenticated for SM2 sign verification.
+ *
+ * Pointer to output data
+ * - for SM2 private decrypt.
+ * In this case the underlying array should have been
+ * allocated with enough memory to hold plaintext output
+ * (at least encrypted text length). The message.length field
+ * will be overwritten by the PMD with the decrypted length.
+ */
+
+ rte_crypto_param cipher;
+ /**<
+ * Pointer to input data
+ * - to be decrypted for SM2 private decrypt.
+ *
+ * Pointer to output data
+ * - for SM2 public encrypt.
+ * In this case the underlying array should have been allocated
+ * with enough memory to hold ciphertext output (at least X bytes
+ * for prime field curve of N bytes and for message M bytes,
+ * where X = (C1 + C2 + C3) and computed based on SM2 RFC as
+ * C1 (1 + N + N), C2 = M, C3 = N. The cipher.length field will
+ * be overwritten by the PMD with the encrypted length.
+ */
+
+ rte_crypto_uint id;
+ /**< The SM2 id used by signer and verifier and is in interval (1, n-1). */
+
+ rte_crypto_uint k;
+ /**< The SM2 per-message secret number, which is an integer
+ * in the interval (1, n-1).
+ * If the random number is generated by the PMD,
+ * the 'rte_crypto_param.data' parameter should be set to NULL.
+ */
+
+ rte_crypto_uint r;
+ /**< r component of elliptic curve signature
+ * output : for signature generation (of at least N bytes
+ * where prime field length is N bytes)
+ * input : for signature verification
+ */
+ rte_crypto_uint s;
+ /**< s component of elliptic curve signature
+ * output : for signature generation (of at least N bytes
+ * where prime field length is N bytes)
+ * input : for signature verification
+ */
+};
+
/**
* Asymmetric Cryptographic Operation.
*
@@ -665,6 +751,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_dsa_op_param dsa;
struct rte_crypto_ecdsa_op_param ecdsa;
struct rte_crypto_ecpm_op_param ecpm;
+ struct rte_crypto_sm2_op_param sm2;
};
uint16_t flags;
/**<
@@ -299,6 +299,7 @@ crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
[RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
[RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
+ [RTE_CRYPTO_ASYM_XFORM_SM2] = "sm2",
};
/**