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

[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 at 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