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 824CCA0C41; Tue, 7 Sep 2021 13:42:22 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41D99410ED; Tue, 7 Sep 2021 13:42:22 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 06151410EC for ; Tue, 7 Sep 2021 13:42:19 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10099"; a="283885909" X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="283885909" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2021 04:42:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,274,1624345200"; d="scan'208";a="523790850" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmsmga004.fm.intel.com with ESMTP; 07 Sep 2021 04:42:18 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 7 Sep 2021 04:42:18 -0700 Received: from orsmsx609.amr.corp.intel.com (10.22.229.22) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 7 Sep 2021 04:42:17 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx609.amr.corp.intel.com (10.22.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 7 Sep 2021 04:42:17 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.177) 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.2242.10; Tue, 7 Sep 2021 04:42:17 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G0lAj2BfVFVFhMvAC8AkEMaoPs5mmLSt1qr1tHRtyE15XrATdMpSpbrSBZ1ZUfOVAeUr4qsj4r+9Irlru/khoUf93mV8B3lUhBt0wz/nxzuByWu2Ja6OTgKbqjY8Us/QB5TCh+6EUZFcBkTIwXp7ocucDCRkWzGN1aup0gUgy4cr9jzX3zhNhPCjNd5MQDLGce9HLQQWFbnmJensN3cIVaqmCx/qiwfMEsFVenN/RS8RatlAKMxvAw4Zoi19Uu1n/vQ6OBXNEO14dpbsuTK1NR3DGs37kIAUDShEuRJ2XNHevFgJXmNmHMpFV3wZAkgvTTQ6I+X8RLq2xtV5ilCtLA== 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; bh=DPpPpNC1kTzEfZWbvBoHBjDwUDBBjzllMAxBLbMTpfQ=; b=ODivBhOR3f8fb4tfJ3qsbtPuU/H5wWAinow94T8fCxfWCn5CHbNVpiIF9slynKbHizREhepCd3w6t+UAHhSydoOSLAqGmo4k7JPHCuG8RpHovgCiQNwNrybKdas8vJYM4q5bynOh9oZZXfm80HYr75dJJJo42Bggoepjg48v/RtmKX7JnvAbFfFtOUqb024IJLlJq59gHZii66pvLXUhUVwQ2AzEUGgikBxfDiUl7852D2QCD4N1jENdrpX9XtsY5csiZQ8jqXwYgKoGazJYw+L73n3xIzNvqXyojxcqSEoNfklPiRnj/quO4//rLjggnbXX1hx6Qdebx/wi6nnCWQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DPpPpNC1kTzEfZWbvBoHBjDwUDBBjzllMAxBLbMTpfQ=; b=l7HvOzpx/fITh7WaN+xtTNTh4Qw1lPo/oegvvKekjwyqT1hlIkGfY7fz0mwQBWS9BWu6U8c35HpgMMHw9BtrKaGngRa3304w0fqFaRMZPVcGXNEHYHqmDx3gTEDS4Lij1oy2snVm4BFFMpwi+ox43JwDmqW5IRNIAS6rf9EnVbU= Received: from PH0PR11MB5013.namprd11.prod.outlook.com (2603:10b6:510:30::21) by PH0PR11MB5143.namprd11.prod.outlook.com (2603:10b6:510:3f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.22; Tue, 7 Sep 2021 11:42:16 +0000 Received: from PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::8d5f:18da:7d0f:d274]) by PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::8d5f:18da:7d0f:d274%8]) with mapi id 15.20.4457.024; Tue, 7 Sep 2021 11:42:16 +0000 From: "Kusztal, ArkadiuszX" To: Akhil Goyal , "dev@dpdk.org" CC: "thomas@monjalon.net" , "david.marchand@redhat.com" , "hemant.agrawal@nxp.com" , Anoob Joseph , "De Lara Guarch, Pablo" , "Trahe, Fiona" , "Doherty, Declan" , "matan@nvidia.com" , "g.singh@nxp.com" , "Zhang, Roy Fan" , "jianjay.zhou@huawei.com" , "asomalap@amd.com" , "ruifeng.wang@arm.com" Thread-Topic: [dpdk-dev] [PATCH 2/4] cryptodev: promote asym APIs to stable Thread-Index: AQHXhjfz7920p1fab0SEpL/smLnv86uMXyxggAZCAICABfIB0A== Date: Tue, 7 Sep 2021 11:42:16 +0000 Message-ID: References: <20210731181327.660296-1-gakhil@marvell.com> <20210731181327.660296-3-gakhil@marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49c25ee5-961d-4537-68f8-08d971f48ad4 x-ms-traffictypediagnostic: PH0PR11MB5143: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GahemS+YAJeHSX8BjmX6tmd5SGd98/atTHWCJbTqAB65w+FrYe8wKE1ZO00JrmzPTFKDoCStbe5RRf1VqP2ohKtgOBiHpSFjdSQ5rf+aIrtkh21X8uZ0RN+Kkh/bwP1JefW0BLZSQO7TY+rswbuhHeViBtyaHdIOpDjPP9giPdx7bhwYZgfI8tkdCXGT6ur4LCg8Bo1+mT5rCM8LmI/RU30a5haqYBsfL/1Cb3DtiaQRhclAfZBt9kciBxRo8AUn+eQYvZ/gDZrZVQ1yJ9WZJ75XTvxFWVwkUMkLjJnkAXAIHu4HGrS6s2iLgCZfSMkSxbEtMlcpryp+70THcKYr2f+R5Fh/g1Mq9hnXhIhFYSvH39KwpNj9asmB/eheHzGZBHQIA6vQcWxWBhwE57GIWi5054b14LJBycgUlb6tBRvDtoD0Mqh7WazXztkOgpodVeW8l3uaqQItFV7XZOart+tK9ijGoeNboWOe/cQ2NBOhfa2/H+wBsHBTqMzdrnNA646loNzEKK295AdlzGi7YAfSUDWpzMiWHdm/rNynGmsUVM9xdxf7M3zrcntbey21puC+fQ02fcxZ6KSou2kHCFL0sL57l+ZALFxUcudfIOHjxjtMNdUiTMgbNekbuI8MkrS0KrqB0NQbIbPvBb+u7rKaSr8ylyCPhot9mJzzyOucXxUgFFWiaslexzaY7Tt1fYuIpM1h+Ndcu7s9P68wyg/v31PajO7em6oV1CnOPv5/pWrJvC8L2+9Qg0ufj0GqJsy1L2ZZaD0YdgxXJXUqe21gJbN+C2mrq4f0o9GSuww= 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:(4636009)(366004)(2906002)(66446008)(64756008)(66556008)(55016002)(71200400001)(66946007)(186003)(4326008)(122000001)(9686003)(38100700002)(7696005)(52536014)(508600001)(6506007)(86362001)(83380400001)(7416002)(5660300002)(26005)(33656002)(8676002)(316002)(38070700005)(110136005)(54906003)(66476007)(8936002)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?f6g8F2s1PrWZfCL/lvSvYNY9arj7+DFvlWhg3bE5lTNUXVnnp1WSnIOMDMGO?= =?us-ascii?Q?LxlODTugBBBYLrxRRH+k2EBweHOxT9knmTg0H8kU09ahz2f7ek1olg/SP/ru?= =?us-ascii?Q?jiSNPj4yiE9oexOYPFxBAbHIroCPRHb6AEIsOneK/vNvbWJYFqWf3r0UbXk/?= =?us-ascii?Q?ZZkTv6uyCWZ5AG/xMTXWRqLp/mf9seV4a5s5d12PQTZfxnUIq6nUISjJ+ROd?= =?us-ascii?Q?HNcuNQ0EnVo+g1eJ4OEa0A+oio2l/YzrSR85H2T+QPL3Yb4vcWdUYX01pVXa?= =?us-ascii?Q?A/fwPh2U+Khirq43JkYpcMAHmOaOZzZdBpsOLdcgSUgDwhUTV5+riKKX6TKK?= =?us-ascii?Q?YVXqHffb8TnqoD9/3G2+VsQcllUuRTmCl966s1NlJkqXCh+4OTSNBDe8H8tZ?= =?us-ascii?Q?XySGM31Uf3O+tn2D6XmIEliacty95LYnhEPWgBhPvJpdZJwkgrmHCVfb6N2F?= =?us-ascii?Q?x8u93hxePzqkLMFmuYu+nDPBmd411824QyegtkplO9VWPSDyNYDj6VAnJsej?= =?us-ascii?Q?/2rLSGkaazxgpQV5K245M3L31mRDTHOCDuzf4vlQIKl9b6MVxPBAYaG07Q9w?= =?us-ascii?Q?qY9iRW9cDQGqfoWkLTsv0RuFBXIjBY+EVtK6l0JndRPku/yOxu+3AjCnnRF0?= =?us-ascii?Q?aG2n6oleCU9jYfB4Qzjlpx8Vjqc3Gdo89m7pkkufG20t0WDkjlDAide2Ysq4?= =?us-ascii?Q?1P8l3ERgC4tydsNIK0LHN0EsUChBHv+kHOJMflsrqp/jw0OS1PTr3fXJf3JJ?= =?us-ascii?Q?m2t9OoOEm2xRXma7Vy5ngjTFH4cgzIuPYVujXGcmPbTnaURhn/a6p2QCu7mJ?= =?us-ascii?Q?2+A2QW3TphGxv+ReiYuNlnYFakzQWlkAFF2ve65CRouN6rnnbEQFszLt5cIX?= =?us-ascii?Q?52Ne67R6K3UahJf5MySCnEQqtNRq0F45Nh+itaPVndEAUidXMMQLlfrJsv4/?= =?us-ascii?Q?E6P1I55x6oK2iKsDYVnXefW7ER6G5Gh5T2b8+t9ps312eydTrT+pe31oJdK8?= =?us-ascii?Q?v2e0+5XSJ6p53dw+WPX0GUtjEI0j36IY7Zwtdvdb4OZxlok/ZndDKB3UdEZe?= =?us-ascii?Q?tX1kDNLG6adXJjS/kqxcSVeIHG2DivTjf+RlldEU0rPGXjCtop7IXvQuePPT?= =?us-ascii?Q?5DN2y9TIhr07xbuErKi+A1oibxY98Obx79haPJ52g4Xp9CpSeTxuH8+xXZqr?= =?us-ascii?Q?VFV99UxLNiAGKKdl7vBgvhX1m3FWA+xadJC1AziiCQXPBOcy8NrqK7QP67eB?= =?us-ascii?Q?W5dwInHxi+PqWkfttxOrXZtxWUSHPMAqLKtxV8OZcJR1T77oy5bwhjfkkPQ6?= =?us-ascii?Q?y26YlKFI6/bNr3GH5nARx8PA?= 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: 49c25ee5-961d-4537-68f8-08d971f48ad4 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2021 11:42:16.3845 (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: Y6ll6ihEQv3zzXqz6tuXU2RsQucj6J0ypoWySaYS+cPdeZfRg4aO/ASQn5NQjqZRUBP/1DU8PTOQs/8zod5j5cl1W+4rHrNAr8xpe/J6F7Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5143 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 2/4] cryptodev: promote asym APIs to stable 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 Sender: "dev" > Do you think all the asym APIs are not eligible for promoting it to stabl= e APIs? > I haven't seen any changes for quite some time and we cannot have it > experimental Forever. > The APIs which you think are expected to change, we can leave them as > experimental And mark the others as stable. We could potentially make capability related functions stable but for other= s there are still some many uncertainties, another example: Ecdsa op expects 'k' in "in the interval (1, n-1)", openssl pmd will not ev= en have function that accepts 'k' (although optionally inverse of k yes), w= hat should user put then here? This API needs more attention I believe, I can send patches for it after 21= .11 release.=20 My opinion is that we should push all this by another year. >=20 > Can you post a patch for it? I will drop it from my series. >=20 > Also, could you review the other patches in the series as well. >=20 > Regards, > Akhil >=20 > > Hi Akhil, > > > > I am not sure if this API is ready to be stable so I will add few comme= nts here: > > > > RSA: > > rte_crypto_param message; > > ... > > * - to be signed for RSA sign generation. > > > > If this message is plaintext, then in case of: > > 1) PKCS1_1.5 padding: > > Standard defines data to be signed as DER encoded struct of > > digestAlgorithm > > + digest > > (few exceptions I am aware of were TLS prior to 1.2 or IKE version 1) > > - There is no field to specify that, even if PMD would be correctly > > implemented it still would lack information about hash aglorithm. > > - Currently what openssl pmd for example is doing is > > RSA_private_encrypt which omits this step > (https://www.openssl.org/docs/man1.1.1/man3/RSA_private_encrypt.html - > mentions this). > > 2) PADDING_NONE: > > I cannot find what user is supposed to do in this case, and I think it > > may be quite common option for hw due to reliance on strong CSPRNG for > > PSS or OAEP. > > > > DSA: > > struct rte_crypto_dsa_op_param { > > ... > > There is no 'k' parameter? I though I have added it, how hw with no > > CSRNG should work with DSA? > > > > For ECDSA private key is in Op, for DSA is in xform. Where this > > inconsistency comes from? > > > > /**< x: Private key of the signer in octet-string network > > * byte order format. > > * Used when app has pre-defined private key. > > * Valid only when xform chain is DSA ONLY. > > * if xform chain is DH private key generate + DSA, then DSA sign > > * compute will use internally generated key. > > > > And this one I cannot understand, there is DH and DSA in one line plus > > seems that private dsa key would be generated and used in the same > operation. > > We want to create self-signed certificate here on the fly or something? > > > > RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE, > > /**< DH Private Key generation operation */ > > > > This is another interesting part (similar to 'k' in (EC)DSA, PSS, QAEO > > in RSA), there was no any type of hw random number generation concept > > for symmetric crypto (i.e. salt, IV, nonce) and here we have > > standalone Diffie Hellman private key generator. > > And since it is no crypto computation but random number generation, > > maybe there should be another module to handle CSRNG or we could > > register randomness source into cryptodev, like callback? Another > > option would be to predefine randomness source per device like (i.e. > > x86 RDRAND, /dev/random) for user to decide. > > > > Additionally there is DH op but there is no ECDH (I know there is > > ECPM, but the same way there is MODEXP which creates another > inconsistency). > > Optionally we can extend DH API to work with EC? > > EDDSA, EDDH needs to be implemented soon too. > > > > Regards, > > Arek