From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 29597437B4; Thu, 28 Dec 2023 18:31:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9CAA940295; Thu, 28 Dec 2023 18:31:31 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id DB80E40041 for ; Thu, 28 Dec 2023 18:31:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1703784690; x=1735320690; h=from:to:cc:subject:date:message-id; bh=4VMXUWjqGffV/xvm+86YCWXIunLbTVSaOv0OygJKYmw=; b=RXnLFKpxsAUr/c5u/ROV2At7ZawzDGHOI8B/engyO+Fu/xWh5PK9DnS3 KEEUZ5y10r8pKhq4T8iX8hsJFtxxqUbAAIz2G480enLMljDnjhk36PeVf NFaKo9gU1/WeqyVUFbdvDnXdkPGR352qFkXDydaDTRlXgXu49bMKhxJZW KjAlCSXtcMXgsp1E9e0HzeTupaIgDKpr/DQNA/XPfxPwBKHmFffBVdRD/ QlQB9181IfYEZgBW3jm/a8GA5yW9/AMCGvdk8Z8Y+tcE50VBFc0/WB0jK ByXxmy2TtzurX1fmu43XwKk5osjBMxUC+xoG8Svyl3hKbPXPL7iUt0PXb A==; X-IronPort-AV: E=McAfee;i="6600,9927,10937"; a="460892042" X-IronPort-AV: E=Sophos;i="6.04,312,1695711600"; d="scan'208";a="460892042" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Dec 2023 09:31:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,312,1695711600"; d="scan'208";a="20623948" Received: from silpixa00399302.ir.intel.com ([10.237.214.136]) by fmviesa001.fm.intel.com with ESMTP; 28 Dec 2023 09:31:11 -0800 From: Arkadiusz Kusztal To: dev@dpdk.org Cc: gakhil@marvell.com, kai.ji@intel.com, ciara.power@intel.com, Arkadiusz Kusztal Subject: [RFC PATCH] cryptodev: add sm2 key exchange and encryption for HW Date: Thu, 28 Dec 2023 16:19:32 +0000 Message-Id: <20231228161932.54253-1-arkadiuszx.kusztal@intel.com> X-Mailer: git-send-email 2.13.6 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org This commit adds comments for the proposal of addition of SM2 algorithm key exchange and encryption/decryption operation. Signed-off-by: Arkadiusz Kusztal --- 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