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 86A29425C3; Sun, 17 Sep 2023 17:59:58 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1088140291; Sun, 17 Sep 2023 17:59:58 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 6DCD74025E for ; Sun, 17 Sep 2023 17:59:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694966395; x=1726502395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MrpV27r1T3cnjkc2IIH8K/7jKQO2ILBD+NnXC8jDSlI=; b=SKWu+BVm7YkGB7SePLOPHh35PbvveQdch0xmF84ZJcVjZz7CrCRZKH2V pghVb4yCGuoU63zOQTArgjVKHWtRn0mclCEjaJszq1hH3ficeUc1F9IvV 47R0oY+6IZ+GlX+nCE/4Brrz9e6y8WgpRsDIPrXngW3W1z+iDvhnTxGjy fzK7hQUFXAdBNxCdoecgJTe90wEnaIvGceR7lbYWXcXV9bilpcmrMbkoa S/+jX/541+f2xIUYxGlJliQuZVbObqP9qR8iQo4Q+9XBZMQeJZ92oMuZa aKWcvNuq49QGgzqvDXfrvdAN50db1rctnrGuYziNjOPH+hCuLp1SzOIL2 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10836"; a="364552271" X-IronPort-AV: E=Sophos;i="6.02,154,1688454000"; d="scan'208";a="364552271" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2023 08:59:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10836"; a="869314659" X-IronPort-AV: E=Sophos;i="6.02,154,1688454000"; d="scan'208";a="869314659" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga004.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 17 Sep 2023 08:59:54 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Sun, 17 Sep 2023 08:59:53 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Frontend Transport; Sun, 17 Sep 2023 08:59:53 -0700 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.48) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.32; Sun, 17 Sep 2023 08:59:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Usi8b2CldW2UR0Eyt+JR7Gt4LTvH1lx6aNTQJCRTcybcOuo6H6rdV8pie4xjnt4k5NRtcBTNOkv9gM7v6jJw2zHJttqwNL4FnvxbtGSWG7B8kZMamVHEaWJ1ujRayXXSgL2duHmwVbIOnhEbe5jtZdVWnTmaeA10Kigv2QmrsOmIGE96yKUG4wo+LfsA38NJYsDnQ54rn7NKnRYHZQ/vuyOF6swlfC7U/NGDhltA7zFpmfzzJbwwPxTQicDMAuqtL7vF4YL7Ao49c54KUMbjLrc8R4UCUQzo4L40Qh9x8uCbGFLRRYeXfzjNcZyNiCMoSPTbR+HxCQCHCNSUL8oz9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l8wgVwY/iJXLHf5cRgEbHu8+m4Y7sXF6nWkUEkNIZ+A=; b=WkhWMQQI7yPl/m9xPNwNhz82GUsP/8DM1gdN0R2V+f1C9bHKw/fHrzUJ9LANzrLochIJb7eQ0O2Dtyy1ZHihwR/rIBt7KDbHO57oIzJLth/z0aeCWp1yi8ZFWk3WHu69PrveDSdLm+YxsUQuxAa6Cm4linW+FO02bJetEKgqLz3/5zj3aFzJTWchcQZS+YS1gIPGXP/2WTw/ATbyE7wNeXjFTcMDpLTgBNssvNNfuCpDlnhFw9qegieTRX94OHkbM5HFaxKly2feuANFdduC459h4Xb5j/IgArM6xw2qoxFAEV0M1030pvYtjp1QDXRidozOtKUbuMxH8ZQj0YDBCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from PH0PR11MB5013.namprd11.prod.outlook.com (2603:10b6:510:30::21) by BL1PR11MB5304.namprd11.prod.outlook.com (2603:10b6:208:316::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.24; Sun, 17 Sep 2023 15:59:50 +0000 Received: from PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::66f1:bfcc:6d66:1c6d]) by PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::66f1:bfcc:6d66:1c6d%4]) with mapi id 15.20.6792.026; Sun, 17 Sep 2023 15:59:50 +0000 From: "Kusztal, ArkadiuszX" To: Gowrishankar Muthukrishnan , "dev@dpdk.org" CC: Akhil Goyal , "Ji, Kai" , "Power, Ciara" Subject: RE: [EXT] [RFC] cryptodev: refactor sm2, add plain message flag Thread-Topic: [EXT] [RFC] cryptodev: refactor sm2, add plain message flag Thread-Index: AQHZzHrXEckQhEIm8E2Q48xMvyrjua/pbqqAgDX0j3A= Date: Sun, 17 Sep 2023 15:59:49 +0000 Message-ID: References: <20230811173944.2550303-1-arkadiuszx.kusztal@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR11MB5013:EE_|BL1PR11MB5304:EE_ x-ms-office365-filtering-correlation-id: 5f93406c-b00c-4c50-1ee6-08dbb7971f78 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hN8E73d6jt6f3I9vDvPKRZGCnnGqSX9LGFXru7OAPr9uscRut7EAohCFYano4rKA8h+czZr9JCykZWA3xX9UFNrwj3oiBCrTPirPbYAv6Gm3rDYtnpQOrudN++KuEjZWVYej3+YbSiDGu1U6WquC4QB85SsOW6mZ5dHEpUib6V1aPrw7l70uEUpI7c75Qj2Crq1tq2W4u8LBsWeolFL66FFN0KbdqYd9cENMRfET9mX3OM0b65hiS1r8FJ+8pLyMxyzxa628w/kSboRFgf3gDCcYh5D6DdoATMJ0OJYKVjXRv1Wv38AE9fJjWudDi3L9GtAnFWmc5yB8DvGNS5HHqyw4XrkaVV4m1BBnWsBqZNlYnhJqNMY3r7Uhmsp8vwwpJfhpJGYbH66F5mWPu8YKmkOn5W/EcnkTcNKguJHHwkaxYutMTG5V1UAehqsW8neKiUdmOefcngPzvFTqecA9nkcAdUS/RYY7yqwPqrcjUfZyNSrkXXR8VQxxxpeVr/3UM0Rzv+aPESMeu4l3fd31qYAlBXnq/q5mzUT4bWp/L8QWEMFD95f0ybK8fZYKaoI4ai4s6YIKrjkMT03/wWrq8wbYkys67JZoylaNPme44+zE90cqieZp/o1bF1KJHTNW/2lHB5peDJhWHaqS+gOLGQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5013.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(346002)(136003)(366004)(396003)(39860400002)(186009)(451199024)(1800799009)(55016003)(26005)(107886003)(82960400001)(2906002)(15650500001)(33656002)(5660300002)(38100700002)(38070700005)(86362001)(8676002)(8936002)(4326008)(316002)(122000001)(41300700001)(76116006)(66946007)(66556008)(54906003)(64756008)(66446008)(66476007)(478600001)(966005)(71200400001)(83380400001)(110136005)(52536014)(53546011)(6506007)(9686003)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?UL2rObARmTVBt5rwcycQuti0x9w1z6ZldbFrLOoX4CHCt8rCM/ctnlx3MFZT?= =?us-ascii?Q?7/nlrji3M0mu+kN7m+MIKLz9Ckj2LKJoRgHOGkjD5PGIhTuFjgEVLtH0+BwR?= =?us-ascii?Q?WiShIbZNGnPgTzpfecaKOnriilfM1KFfeVIVX1cZ23BqJ5onD7jl34u5wPxh?= =?us-ascii?Q?oS68b19wAG6BSFMW4vKiswr3JAcE5kuhfdqLDwHkzNbqqVuo1l/9YN4hMpSO?= =?us-ascii?Q?C8tBBL4YlCWjtrGJNH3vRo/Vv4vtH5qDfoocBIlZTOLy+oB3QzhCMvtZt5Z2?= =?us-ascii?Q?Wyk+tBMw4qo8neQQS80SAkXWyf/EIUo71X00Ehhnp/SFLzjjLGIf+1bBlyDZ?= =?us-ascii?Q?zR7cs41OCR4YgDH05eq7BamcMekLCvSJc5WCyqvsBR1bTjRyVY8xtr2xFc32?= =?us-ascii?Q?FXJLpA1pjRRYK2tR/AFzzttsNM0Wx87Ui+3y+Qw0hwnySOJ/UrvXIkSL2h0z?= =?us-ascii?Q?qjOmUTtx8UD5hn2LHtVmsqY3t6qHTL1YPzNOlf/+eAQ0ehOdWZbry//HyCxz?= =?us-ascii?Q?rUsAB0hsp8v+DWZ1YKuOIkPEUiE+y/vwAxiRFFoWbSfNn3PhqJFaYtXHggsK?= =?us-ascii?Q?uiJOMYl+gtW+IxaJ0m3p8qJOpuKJEOEDtM5UtTn2JXHHTvX5qg4WxSUbzS77?= =?us-ascii?Q?2DLyahbnE3QihZ1/0Of70gwZdifyvQDdoD87EGcbf/6DQN8m15qTqifFTm4n?= =?us-ascii?Q?qUZIPjGA4lzIfiPCMzIIGdAOPm7NdxU4of+YMhWL/vH9Qeshdergd2ukcS/C?= =?us-ascii?Q?BZFTCmgTDr0WTKOLjcFIICyLmhdaWJo55MEPlIKlckdbGUHJmqMnHie9HlI4?= =?us-ascii?Q?5rx5TR+pZJBpr90Iy2zKHHEzwwbfcC+9DLCTYAtOaNbBTWm8OSVj8ftq0JJ9?= =?us-ascii?Q?AzWyI7UWXYvPyCIzfDibUkPsPCfi22IBeCu+FkLyTzcobheg6RPlXwH8ZRHz?= =?us-ascii?Q?QE5vOM/QLRLbtIqjHpghYH3+dSnJvzB06PctzlH/8xeAsQbXdh9mpDzYHClf?= =?us-ascii?Q?F1H6NCrdD+URR864KlffW0GjI7NXO2rW4aaPWMGddwiTiRkB3bMwN4qHqav2?= =?us-ascii?Q?mV8tVkvswcwVLRygJVwKbxQEb8j3XsQWxJGcCH3K4214xmBOj3FicFeJqC5o?= =?us-ascii?Q?5fwBASDYdBPiRNu5AnjFbfJ/IKiitGRiMmfp3j7DcSk3IJSanIKp0ez9SZJ8?= =?us-ascii?Q?bPG9VG/LtjKvn9F/etWkcVCa7P2DIw1NnRloUib3QSLGVFyr6ZpBikAGCe5G?= =?us-ascii?Q?/hujaocxjJYnT5gIraa+B6vjFWTCSeJNV3gxiiv3PPLGYfr4Dvm6/l8/QBZO?= =?us-ascii?Q?9xjHPCx/WbuxkqXnlUS8V4hffBNfQbRqk51zCmsf0ZHB5KX89b9l2L6+L+eZ?= =?us-ascii?Q?d5ZZ6Eq5bbc3YDKg63boRsfKbtOmNMtZwFCZ8Ue3GRXnrQl8RGyjHOmzU0ws?= =?us-ascii?Q?zY/SZPL0ku1WKCB2ROYXbd4+cdG20g0sJ970FNquZDtjPQ7/Jtnh64kXcCX4?= =?us-ascii?Q?5n6GVQkNmHi+p+Kg70Pbnml+c5UVpzmeq5mZ8G1n9lDHogYuERFzs33cQqKw?= =?us-ascii?Q?uF+QTxydEPzzLpVZ/zkMEKfgcncovmcF3FMQnZ5F0lvi6ymbXQF17tKHZHtJ?= =?us-ascii?Q?Bg=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5013.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f93406c-b00c-4c50-1ee6-08dbb7971f78 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2023 15:59:49.8575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pj27CBoaT/FiWuiL5kY1RIyfAJ4OmlNqDSLB++0sBRsRH3Xq5MBgrm2dUeaQUoAvloaNGKTFkXVUXOqG7YGIYywIO2+TvayJsxBSsDcxpZw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5304 X-OriginatorOrg: intel.com 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 > -----Original Message----- > From: Gowrishankar Muthukrishnan > Sent: Monday, August 14, 2023 9:49 AM > To: Kusztal, ArkadiuszX ; dev@dpdk.org > Cc: Akhil Goyal ; Ji, Kai ; Power, = Ciara > > Subject: RE: [EXT] [RFC] cryptodev: refactor sm2, add plain message flag >=20 > Hi, > Please find my comments inline. At the same time, may I request you to re= view > my patch series : > https://patches.dpdk.org/project/dpdk/list/?series=3D29149 >=20 > > SM2 asymmetric crypto operation was split into cipher and signature > > operation. Now it corresponds to the other crypto algorithms and > > facilitates addition of other SM2 components like the SM2 key exchange. > > > > Flag to distinguish between a plain message or a hash used for > > signature was added to the DSA, ECDSA and SM2. > > > > Signed-off-by: Arkadiusz Kusztal > > --- > > lib/cryptodev/rte_crypto_asym.h | 116 > > +++++++++++++++++--------------- > > 1 file changed, 63 insertions(+), 53 deletions(-) > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h > > b/lib/cryptodev/rte_crypto_asym.h index 8b5794fb7c..43bdb392c5 100644 > > --- a/lib/cryptodev/rte_crypto_asym.h > > +++ b/lib/cryptodev/rte_crypto_asym.h > > @@ -54,6 +54,7 @@ rte_crypto_asym_op_strings[]; > > * and if the flag is not set, shared secret will be padded to the lef= t with > > * zeros to the size of the underlying algorithm (default) > > */ > > +#define RTE_CRYPTO_ASYM_FLAG_PLAIN_INPUT RTE_BIT32(2) > > > > /** > > * List of elliptic curves. This enum aligns with @@ -379,16 +380,6 > > @@ struct rte_crypto_ec_xform { > > /**< Pre-defined ec groups */ > > }; > > > > -/** > > - * Asymmetric SM2 transform data. > > - * > > - * Structure describing SM2 xform params. > > - */ > > -struct rte_crypto_sm2_xform { > > - enum rte_crypto_auth_algorithm hash; > > - /**< Hash algorithm used in SM2 op. */ > > -}; > > - > > /** > > * Operations params for modular operations: > > * exponentiation and multiplicative inverse @@ -540,7 +531,12 @@ > > struct rte_crypto_dsa_op_param { > > enum rte_crypto_asym_op_type op_type; > > /**< Signature Generation or Verification */ > > rte_crypto_param message; > > - /**< input message to be signed or verified */ > > + /**< > > + * Pointer to the input data > > + * In case RTE_CRYPTO_ASYM_FLAG_PLAIN_INPUT flag is set in the > > op flags field, > > + * it is a message to be signed by the PMD. > > + * Otherwise, it is a message hash. > > + */ >=20 > If a PMD does not support plain message but only hash digest, then this n= ew flag > cannot help, as it is set by application without checking PMD capabilitie= s. > Instead, I had proposed adding hash capability for any EC xform in genera= l (as > other EC curves too can benefit out of it). > https://patches.dpdk.org/project/dpdk/patch/086351e84370ce65dcf947dba12a > 46f9c62ae79b.1691658879.git.gmuthukrishn@marvell.com/ Actually hash should be moved outside of xform, we do not want to have a se= ssion per hash I think. Session should be per key, eventually per private key only. >=20 > To note, more than one hash algorithm needs to be supported as in ECDSA f= or > eg. so I made it bitmask of hash algorithms supported by PMD. > For SM2, today we set only SM3. >=20 > With this, the application can check the xform capability and set op para= ms as > shown in : > https://patches.dpdk.org/project/dpdk/patch/f3be0a425170ee26a1396d34f52a > 8e07941f7ce5.1691658879.git.gmuthukrishn@marvell.com/ >=20 > > rte_crypto_uint k; > > /**< Per-message secret number, which is an integer > > * in the interval (1, q-1). > > @@ -579,7 +575,12 @@ struct rte_crypto_ecdsa_op_param { > > /**< Public key of the signer for verification */ > > > > rte_crypto_param message; > > - /**< Input message digest to be signed or verified */ > > + /**< > > + * Pointer to the input data > > + * In case RTE_CRYPTO_ASYM_FLAG_PLAIN_INPUT flag is set in the > > op flags field, > > + * it is a message to be signed by the PMD. > > + * Otherwise, it is a message hash. > > + */ > > > Please find above my comments for this flag. >=20 > > rte_crypto_uint k; > > /**< The ECDSA per-message secret number, which is an integer @@ > > -652,52 +653,20 @@ struct rte_crypto_asym_xform { > > }; > > }; > > > > -/** > > - * SM2 operation params. > > - */ > > -struct rte_crypto_sm2_op_param { > > +struct rte_crypto_sm2_signature { >=20 > Yeah, it will help picking params for the application easily. > Just a suggestion: could we retain _param suffix. Say > rte_crypto_sm2_sign_param. >=20 > > enum rte_crypto_asym_op_type op_type; > > /**< Signature generation or verification. */ >=20 > Now op_type can either be sign/verify here. > > - > > - rte_crypto_uint pkey; > > - /**< Private key for encryption or sign generation. */ > > - > > - struct rte_crypto_ec_point q; > > - /**< Public key for decryption or verification. */ > > - > > rte_crypto_param message; > > /**< > > - * Pointer to input data > > - * - to be encrypted for SM2 public encrypt. > > - * - to be signed for SM2 sign generation. > > - * - to be authenticated for SM2 sign verification. > > - * > > - * Pointer to output data > > - * - for SM2 private decrypt. > > - * In this case the underlying array should have been > > - * allocated with enough memory to hold plaintext output > > - * (at least encrypted text length). The message.length field > > - * will be overwritten by the PMD with the decrypted length. > > - */ > > - > > - rte_crypto_param cipher; > > - /**< > > - * Pointer to input data > > - * - to be decrypted for SM2 private decrypt. > > - * > > - * Pointer to output data > > - * - for SM2 public encrypt. > > - * In this case the underlying array should have been allocated > > - * with enough memory to hold ciphertext output (at least X bytes > > - * for prime field curve of N bytes and for message M bytes, > > - * where X =3D (C1 || C2 || C3) and computed based on SM2 RFC as > > - * C1 (1 + N + N), C2 =3D M, C3 =3D N. The cipher.length field will > > - * be overwritten by the PMD with the encrypted length. > > + * Pointer to the input data > > + * In case RTE_CRYPTO_ASYM_FLAG_PLAIN_INPUT flag is set in the > > op flags field, > > + * it is a message to be signed by the PMD. > > + * Otherwise, it is a message hash. > > */ > Please find above my comments for this flag. >=20 > > - > > rte_crypto_uint id; > > - /**< The SM2 id used by signer and verifier. */ > > - > > + /**< The SM2 id used by signer and verifier. > > + * In case RTE_CRYPTO_ASYM_FLAG_PLAIN_INPUT flag is set this > > field is unused. > > + */ > > rte_crypto_uint k; > > /**< The SM2 per-message secret number, which is an integer > > * in the interval (1, n-1). > > @@ -719,6 +688,46 @@ struct rte_crypto_sm2_op_param { > > */ > > }; > > > > +struct rte_crypto_sm2_cipher { > > + enum rte_crypto_asym_op_type op_type; > > + /**< Ecryption or decryption. */ > > + rte_crypto_param message; > > + /**< > > + * Pointer to input data > > + * - to be encrypted for SM2 public encrypt. * > > + * Pointer to output data > > + * - for SM2 private decrypt. > > + */ > > + rte_crypto_param cipher; > > + /**< > > + * Pointer to input data > > + * - to be decrypted for SM2 private decrypt. > > + * > > + * Pointer to output data > > + * - for SM2 public encrypt. > > + */ > > + rte_crypto_uint k; > > + /**< The SM2 per-message secret number, which is an integer > > + * in the interval (1, n-1). > > + * If the random number is generated by the PMD, > > + * the 'rte_crypto_param.data' parameter should be set to NULL. > > + */ > > +}; > > + > > +/* > > + * Asymmetric SM2 transform data. > > + * > > + * Structure describing SM2 xform params. > > + */ > > +struct rte_crypto_sm2_xform { > > + enum rte_crypto_auth_algorithm hash; > > + /**< Hash algorithm used in SM2 op. */ > > + rte_crypto_uint dA; > > + /**< Private key. */ > > + struct rte_crypto_ec_point PA; > > + /**< Public key. */ > > +}; > > + >=20 > sm2_xform is no more required, but ec_xform can be reused as I had propos= ed > in: > [v1,4/6] cryptodev: use generic EC xform params for SM2 >=20 > So, to summarize, may I request below of this patch to go above my patch = series > If you agree. >=20 > (1). Splitting sm2 op params into sign and cipher ops. > (2). Move private and public keys from op param into EC xform. > For DSA , should we move public key into xform as a session param = ? Regardless which way we would go, it should be consistent across the API. I= would say that private key should always be in session, public key eventua= lly. Except for the key exchange, of course. >=20 > Thanks, > Gowrishankar >=20 > > /** > > * Asymmetric Cryptographic Operation. > > * > > @@ -743,7 +752,8 @@ struct rte_crypto_asym_op { > > struct rte_crypto_dsa_op_param dsa; > > struct rte_crypto_ecdsa_op_param ecdsa; > > struct rte_crypto_ecpm_op_param ecpm; > > - struct rte_crypto_sm2_op_param sm2; > > + struct rte_crypto_sm2_signature sm2_signature; > > + struct rte_crypto_sm2_cipher sm2_cipher; > > }; > > uint16_t flags; > > /**< > > -- > > 2.34.1