From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 952AA1B8C9 for ; Mon, 17 Dec 2018 19:34:26 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2018 10:34:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,366,1539673200"; d="scan'208";a="119043033" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga002.jf.intel.com with ESMTP; 17 Dec 2018 10:34:23 -0800 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.237]) by IRSMSX108.ger.corp.intel.com ([169.254.11.26]) with mapi id 14.03.0415.000; Mon, 17 Dec 2018 18:34:22 +0000 From: "Trahe, Fiona" To: "Kusztal, ArkadiuszX" , "Verma, Shally" CC: "dev@dpdk.org" , "Doherty, Declan" , Kanaka Durga Kotamarthy , Sunila Sahu , "Kotamarthy, Kanaka" , "Sahu, Sunila" , "Cel, TomaszX" , "Jozwiak, TomaszX" , "Trahe, Fiona" Thread-Topic: [RFC] cryptodev/asymm: propose changes to modexp and modinv API Thread-Index: AdSSWDzRIVepFZawTBq8hbmOPY/08AC3UC7wADEOW/AADvl2sA== Date: Mon, 17 Dec 2018 18:34:22 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B435896A3F62@IRSMSX101.ger.corp.intel.com> References: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B110B2C@hasmsx109.ger.corp.intel.com> In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B110B2C@hasmsx109.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDFiMmI5YTctMzE0Ni00NTFhLTg4NDgtODVmNmY2MmIyZjdmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiXC91RU9kTjJBT0dlRExwVUhCREw0WDlSdmJFWUtPbmJIblVCNDJJcmx2YzhyMW1MU1FVYkxxb0VNakZvKzF2OUUifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] cryptodev/asymm: propose changes to modexp and modinv API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 18:34:27 -0000 Hi Shally, Arek, > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Monday, December 17, 2018 7:25 AM > To: Verma, Shally > Cc: dev@dpdk.org; Trahe, Fiona ; Doherty, Declan > ; Kanaka Durga Kotamarthy ; Sunila Sahu > ; Kotamarthy, Kanaka ; S= ahu, Sunila > ; Cel, TomaszX ; Jozwiak, = TomaszX > > Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and modinv = API >=20 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rte_crypto_asym.h:233 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 rte_crypto_param modulus; > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 /**< modulus > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 * Prime modulus of the modexp transform operation in > > octet-string > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 * network byte order format. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 */ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 [AK] - Why prime? RSA for example use semi-prime or "RSA > > multi-prime". > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 It should be just any positive integer. > > [Shally] Hmm.. yes you're right . by the purpose of it , it is a semi-p= rime > > input.. so prime shouldn't be mentioned here. > [AK-v2] I think it could be any nonzero number even composite, for DH, DS= A it would be prime etc. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 [AK] - If session API layer should check if it is non-zero = and > > set flag accordingly. > > [Shally] Sorry I didn't get this.. which flag you mean here? if modulus= value 0 > > is passed, it should be considered as INVALID_PARAM. > [AK-v2] - INVALID_PARAM is perfectly fine for me :). [Fiona] About where the error checking should be done.=20 In symmetric crypto the API layer doesn't do param checking it's up to the = PMD. But it seems, for asymm at least, like a good idea that the API layer check= s for valid session params, that way all PMDs benefit, rather than having multiple implementati= ons do the same checks. @Arek, I think that's what you're suggesting? For op params I'm not so sure, the API layer probably shouldn't open up the= op and should just pass to the=20 PMD, to enable performance optimisation. The PMD generally does very little= checking on the data-path - but I think for asymm at least divide-by-zero cases should be checked by= the PMDs.=20