This commit adds comments for the proposal of addition of SM2
algorithm key exchange and encryption/decryption operation.
Signed-off-by: Arkadiusz Kusztal <arkadiuszx.kusz...@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
