* [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW @ 2023-12-28 16:19 Arkadiusz Kusztal 2024-01-04 13:37 ` [EXT] " Gowrishankar Muthukrishnan 0 siblings, 1 reply; 3+ messages in thread From: Arkadiusz Kusztal @ 2023-12-28 16:19 UTC (permalink / raw) To: dev; +Cc: gakhil, kai.ji, ciara.power, Arkadiusz Kusztal 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? + */ + /* 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. */ -- 2.13.6 ^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [EXT] [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW 2023-12-28 16:19 [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW Arkadiusz Kusztal @ 2024-01-04 13:37 ` Gowrishankar Muthukrishnan 2024-01-24 17:41 ` Kusztal, ArkadiuszX 0 siblings, 1 reply; 3+ messages in thread From: Gowrishankar Muthukrishnan @ 2024-01-04 13:37 UTC (permalink / raw) To: Arkadiusz Kusztal; +Cc: Akhil Goyal, kai.ji, ciara.power, Anoob Joseph, dev 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [EXT] [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW 2024-01-04 13:37 ` [EXT] " Gowrishankar Muthukrishnan @ 2024-01-24 17:41 ` Kusztal, ArkadiuszX 0 siblings, 0 replies; 3+ messages in thread From: Kusztal, ArkadiuszX @ 2024-01-24 17:41 UTC (permalink / raw) To: Gowrishankar Muthukrishnan Cc: Akhil Goyal, Ji, Kai, Power, Ciara, Anoob Joseph, dev > -----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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-01-24 17:41 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-12-28 16:19 [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW Arkadiusz Kusztal 2024-01-04 13:37 ` [EXT] " Gowrishankar Muthukrishnan 2024-01-24 17:41 ` Kusztal, ArkadiuszX
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).