From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 6CC991B9A4 for ; Thu, 20 Dec 2018 12:07:37 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 03:07:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,376,1539673200"; d="scan'208";a="260985985" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga004.jf.intel.com with ESMTP; 20 Dec 2018 03:07:36 -0800 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 20 Dec 2018 03:07:35 -0800 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 20 Dec 2018 03:07:35 -0800 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.179]) by LCSMSX154.ger.corp.intel.com ([169.254.7.82]) with mapi id 14.03.0415.000; Thu, 20 Dec 2018 13:07:32 +0200 From: "Kusztal, ArkadiuszX" To: "Verma, Shally" , "Trahe, Fiona" CC: "dev@dpdk.org" , "Doherty, Declan" , Kanaka Durga Kotamarthy , Sunila Sahu , "Kotamarthy, Kanaka" , "Sahu, Sunila" , "Cel, TomaszX" , "Jozwiak, TomaszX" , Akhil Goyal Thread-Topic: [RFC] cryptodev/asymm: propose changes to modexp and modinv API Thread-Index: AdSSWDzRIVepFZawTBq8hbmOPY/08AC3UC7wADEOW/AAL/PLoAALwttAAFmAZSAAAQX2QA== Date: Thu, 20 Dec 2018 11:07:32 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B111658@hasmsx109.ger.corp.intel.com> References: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B110B2C@hasmsx109.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435896A4C8E@IRSMSX101.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.104.14.172] Content-Type: text/plain; charset="us-ascii" 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: Thu, 20 Dec 2018 11:07:38 -0000 Hi Shally, Fiona, > -----Original Message----- > From: Verma, Shally [mailto:Shally.Verma@cavium.com] > Sent: Thursday, December 20, 2018 11:53 AM > To: Trahe, Fiona ; Kusztal, ArkadiuszX > > Cc: dev@dpdk.org; Doherty, Declan ; Kanaka > Durga Kotamarthy ; Sunila Sahu > ; Kotamarthy, Kanaka > ; Sahu, Sunila > ; Cel, TomaszX ; > Jozwiak, TomaszX > Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and > modinv API >=20 >=20 >=20 > >-----Original Message----- > >From: Trahe, Fiona > >Sent: 18 December 2018 21:23 > >To: Verma, Shally ; Kusztal, ArkadiuszX > > > >Cc: dev@dpdk.org; Doherty, Declan ; Kanaka > >Durga Kotamarthy ; Sunila Sahu > >; Kotamarthy, Kanaka > ; > >Sahu, Sunila ; Cel, TomaszX > >; Jozwiak, TomaszX > ; > >Trahe, Fiona > >Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and > >modinv API > > > >External Email > > > >Hi Shally, Arek, > > > ... >=20 > >> >> > >> >> rte_crypto_asym.h:323 > >> >> struct rte_crypto_mod_op_param { > >> >> [AK] - There should be a result > >> >> field. It size should be equal to the size > >> >> of modulus. Same apply to mod mult > >> >> inverse. It should be driver responsability to check if result > >> >> will not overflow [Shally] so these ar= e in-place > operation. > >> >> Output will be written back to base param. It also imply length of > >> >> allocated array should be >=3D modulus length which is passed in se= ssion > param. > >> >[AK-v2] I would abandon in-place/oop approach at all in asymmetric. > >> >For symmetric reason for in- > >> place is that very often structure of > >> >packet is almost intact (macs, ip addresses, ttl etc are changed but > >> >structure remains the same, it > >> may differ for IPSec ESP mode etc). > >> >For asymmetric it is mainly used for handshakes (for example in TLS > >> >RSA use case client will send > >> 48byte of pre master secret which > >> >server will use to generate master secret after decryption). I > >> >generally don't think asymmetric crypto > >> can be used as symmetric > >> >especially that only RSA would be (to some extent) capable of it. > >> > >> [Shally] So you suggest all asym ops should be out of place? Am okay > >> with add that. However would like to ask if anyone has preference to k= eep > in-place option in Asym. > >> If so, then we would need to add Feature flag indicating in-place > processing capability. > >[Fiona] I'm ok with dropping all in-place for asymm. As there are > >multiple inputs and output for various algos it would be quite difficult= to > craft set of capabilities to reflect which field(s) was used for in-place= result. > >I don't see a need for in-place, would use out-of-place for all. > > > [Shally] Am okay with that too. So, Arek will you send patches with these > changes? Yes, I will send patches. Thanks, Arek >=20 > Thanks > Shally >=20 > >> >> [AK] - Any particular reason modulus > >> >> and exponent is in session? Not saying > >> >> it is wrong but is it for DH, RSA use = cases only? > >> >> [Shally] no that's not the intent. For RSA and DH respective > >> >> xforms have been defined. It is kept in session envisioning > >> >> modulus and exponent wont change frequently across operation but > only base value. > >> >> So once context is loaded with modulus and exponent , app can call > >> >> modexp on different base values. > >> >> > >> >> rte_crypto.h:39 > >> >> enum rte_crypto_op_status { > >> >> [AK] - There will be many more status = options in > asymmetric, > >> >> could we probably create new one for a= symmetric > crypto? > >> >> Even if asymmetric and symmetric > >> >> overlap? > >> >> For mod exp, mod inv potentially it wi= ll be: > >> >> DIVIDING_BY_ZERO_ERROR, > INVERSE_NOT_EXISTS_ERROR... > >> >> [Shally] So far RTE_CRYPTO_OP_STATUS_INVALID_PARAM has been > >> >> sufficient for such cases. Do you have any use-cases where you > >> >> need specific error code to indicate asym specific error codes? > >> >There would be many examples, one of which: > >> >[AK-v2] Ok, still to discussion i think though. > >> >> > >> >> rte_crypto_asym.h:33 > >> >> size_t length; > >> >> /**< length of data in bytes */ > >> >> [AK] - Is it guaranteed to be length > >> >> of actual data, not allocated memory (i mean no leading 0ed > >> >> bytes), so the most significant bit will be in data[0]? > >> >> [Shally] it should be length of actual data not length of > >> >> allocated memory to an array. > >> >> However it might create bit confusion on modular exponentiation op > >> >> param as that expect length passed should tell actual data length > >> >> in base array but array itself should be allocated upto modulus len= gth. > >> >[AK-v2] - so it is maybe good idea to have allocated data in bytes an= d > actual len in bits here. > >> > >> [Shally] No that will make it complex and breaks compatibility too. I > >> would propose to keep it in bytes which states length of actual data > present in array. > >> Any confusion around it will be resolved if we add out of place or > >> proper documentation if in-place is retained. > >> > >> I would suggest you to send a patch with things that we agree or you > >> propose. We can discuss on that further. > >[Fiona] yes, agreed, Arek will send a patch. > > > >> Thanks > >> Shally > >> >> > >> >> [AK] - could it be uint16/32_t > >> >> instead as size_t can have different sizes in different implementat= ions, > uint16_t should be enough > >> >> for all algorithms big integer sizes > >> >> [Shally] no hard choices here though. But size_t would never be > >> >> less than uint16_t so it guarantee to be large enough for any > >> >> machines > >> >> > >> >> rte_crypto_asym.h:74, 250, 257, 351 > >> >> /**< Modular Inverse > >> >> [AK] - Modular Multiplicative Inverse > >> >> [Shally] Ack. > >> >> > >> >> Thanks, > >> >> Arek > >> >> > >> >>