From: Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>
To: Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
Cc: Akhil Goyal <gakhil@marvell.com>,
"kai.ji@intel.com" <kai.ji@intel.com>,
"ciara.power@intel.com" <ciara.power@intel.com>,
Anoob Joseph <anoobj@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [EXT] [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW
Date: Thu, 4 Jan 2024 13:37:36 +0000 [thread overview]
Message-ID: <CO1PR18MB47145781F446D59AE17FE18FCB672@CO1PR18MB4714.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20231228161932.54253-1-arkadiuszx.kusztal@intel.com>
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
next prev parent reply other threads:[~2024-01-04 13:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-28 16:19 Arkadiusz Kusztal
2024-01-04 13:37 ` Gowrishankar Muthukrishnan [this message]
2024-01-24 17:41 ` [EXT] " Kusztal, ArkadiuszX
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=CO1PR18MB47145781F446D59AE17FE18FCB672@CO1PR18MB4714.namprd18.prod.outlook.com \
--to=gmuthukrishn@marvell.com \
--cc=anoobj@marvell.com \
--cc=arkadiuszx.kusztal@intel.com \
--cc=ciara.power@intel.com \
--cc=dev@dpdk.org \
--cc=gakhil@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).