From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
To: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "anoobj@marvell.com" <anoobj@marvell.com>,
Akhil Goyal <gakhil@marvell.com>,
Fan Zhang <fanzhang.oss@gmail.com>, "Ji, Kai" <kai.ji@intel.com>
Subject: RE: [PATCH v3 1/3] cryptodev: add SM2 asymmetric crypto algorithm
Date: Tue, 6 Jun 2023 20:01:11 +0000 [thread overview]
Message-ID: <PH0PR11MB5013FD002F0D5E881AD8C2519F52A@PH0PR11MB5013.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87bbd8b9642bf20513448c3747f9e6f28eef0561.1685870993.git.gmuthukrishn@marvell.com>
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
next prev parent reply other threads:[~2023-06-06 20:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-04 9:42 [PATCH v3 0/3] SM2 crypto algorithm support Gowrishankar Muthukrishnan
2023-06-04 9:42 ` [PATCH v3 1/3] cryptodev: add SM2 asymmetric crypto algorithm Gowrishankar Muthukrishnan
2023-06-06 20:01 ` Kusztal, ArkadiuszX [this message]
2023-06-07 3:39 ` Gowrishankar Muthukrishnan
2023-06-04 9:42 ` [PATCH v3 2/3] test/crypto: add asymmetric SM2 test cases Gowrishankar Muthukrishnan
2023-06-04 9:42 ` [PATCH v3 3/3] crypto/openssl: add SM2 asymmetric crypto support Gowrishankar Muthukrishnan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PH0PR11MB5013FD002F0D5E881AD8C2519F52A@PH0PR11MB5013.namprd11.prod.outlook.com \
--to=arkadiuszx.kusztal@intel.com \
--cc=anoobj@marvell.com \
--cc=dev@dpdk.org \
--cc=fanzhang.oss@gmail.com \
--cc=gakhil@marvell.com \
--cc=gmuthukrishn@marvell.com \
--cc=kai.ji@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).