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

[Gowrishankar Muthukrishnan <gmuthukrishn@marvell.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