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 5BD224CB5 for ; Tue, 18 Dec 2018 16:53:21 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2018 07:53:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,368,1539673200"; d="scan'208";a="99671101" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga007.jf.intel.com with ESMTP; 18 Dec 2018 07:53:18 -0800 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.237]) by IRSMSX106.ger.corp.intel.com ([169.254.8.227]) with mapi id 14.03.0415.000; Tue, 18 Dec 2018 15:53:17 +0000 From: "Trahe, Fiona" 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" Thread-Topic: [RFC] cryptodev/asymm: propose changes to modexp and modinv API Thread-Index: AdSSWDzRIVepFZawTBq8hbmOPY/08AC3UC7wADEOW/AAL/PLoAALwttA Date: Tue, 18 Dec 2018 15:53:17 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B435896A4C8E@IRSMSX101.ger.corp.intel.com> References: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B110B2C@hasmsx109.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmRkZDYyNTYtM2UxYy00YTA2LWJjMjQtYjM4ZDBiMmVlMDkwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiK1Zhd09nRWtjbzR1UFFkKzJzTUVVY1Rhek9hT3ptVDhlWDk1WU1CemNsRGNtcW9FcHBzcUxxbnVkaUhNaGgwSiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.181] 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: Tue, 18 Dec 2018 15:53:22 -0000 Hi Shally, Arek, > -----Original Message----- > From: Verma, Shally [mailto:Shally.Verma@cavium.com] > Sent: Tuesday, December 18, 2018 6:54 AM > To: Kusztal, ArkadiuszX > 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 > HI Arek, Fiona >=20 > >-----Original Message----- > >From: Kusztal, ArkadiuszX > >Sent: 17 December 2018 19:55 > >To: Verma, Shally > >Cc: dev@dpdk.org; Trahe, Fiona ; Doherty, Declan > ; Kanaka Durga Kotamarthy > >; Sunila Sahu ; Kotamarthy, = Kanaka > ; Sahu, > >Sunila ; Cel, TomaszX ; J= ozwiak, TomaszX > > >Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and modinv= API > > > >External Email > > > >Hi Shally, > > > >Thanks for your answers :). > > > >My answers in [AK-v2] > > > >> -----Original Message----- > >> From: Verma, Shally [mailto:Shally.Verma@cavium.com] > >> Sent: Monday, December 17, 2018 6:45 AM > >> To: Kusztal, ArkadiuszX > >> Cc: dev@dpdk.org; Trahe, Fiona ; Doherty, Decla= n > >> ; Kanaka Durga Kotamarthy > >> ; Sunila Sahu ; > >> Kotamarthy, Kanaka ; Sahu, Sunila > >> > >> Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and > >> modinv API > >> > >> HI Arek > >> > >> Sorry for late response. Please see response inline > >> > >> From: Kusztal, ArkadiuszX > >> Sent: 13 December 2018 01:56 > >> To: Verma, Shally > >> Cc: dev@dpdk.org; Trahe, Fiona ; Doherty, Decla= n > >> > >> Subject: [RFC] cryptodev/asymm: propose changes to modexp and modinv > >> API > >> > >> External Email > >> Hi Shally, > >> > >> I'm implementing a crypto asymmetric PMD and have some concerns about > >> the API which I will work through over the next few months. Starting w= ith > >> modexp and modinv I have the following questions / suggestions: > >> > >> rte_crypto_asym.h:233 > >> rte_crypto_param modulus; > >> /**< modulus > >> * Prime modulus of the modexp transform o= peration in > >> octet-string > >> * network byte order format. > >> */ > >> [AK] - Why prime? RSA for example use sem= i-prime or "RSA > >> multi-prime". > >> It should be just any positive integer. > >> [Shally] Hmm.. yes you're right . by the purpose of it , it is a semi-= prime > >> input.. so prime shouldn't be mentioned here. > >[AK-v2] I think it could be any nonzero number even composite, for DH, D= SA it would be prime etc. > >> [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 modulu= s value 0 > >> is passed, it should be considered as INVALID_PARAM. > >[AK-v2] - INVALID_PARAM is perfectly fine for me :). >=20 > [Shally] Just to club Fiona response here to which I agree. If you intend= to check modulus value to 0 in > session_init, then cryptodev lib asym_session_configure API can check fo= r Invalid Param. > For any invalid op during enqueue/dequeue it should be in PMD. >=20 > >> > >> rte_crypto_asym.h:253 > >> rte_crypto_param modulus; > >> /**< > >> * Pointer to the prime modulus data for m= odular > >> * inverse operation in octet-string netwo= rk byte > >> * order format. > >> */ > >> [AK] - Same situation as for mod exp. Jus= t any number. > >> [Shally] Yea. It should be reworded as modulus data instead of *prime* > >> modulus data > >> > >> For example when using with RSA Carmichae= l and Euler > >> Totient function will even > >> have composite factors. > >> > >> 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 invers= e. It should be > >> driver responsability to check if result > >> will not overflow [Shally] so these are i= n-place operation. > >> Output will be written back to base param. It also imply length of all= ocated > >> array should be >=3D modulus length which is passed in session 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 str= ucture 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. >=20 > [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 keep in-place option in Asym. > If so, then we would need to add Feature flag indicating in-place process= ing 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 w= hich field(s) was used for in-place result. I don't see a need for in-place, would use out-of-place for all. > >> [AK] - Any particular reason modulus and = exponent is in > >> session? Not saying > >> it is wrong but is it for DH, RSA use cas= es only? > >> [Shally] no that's not the intent. For RSA and DH respective xforms ha= ve been > >> defined. It is kept in session envisioning modulus and exponent wont c= hange > >> frequently across operation but only base value. > >> So once context is loaded with modulus and exponent , app can call mod= exp > >> on different base values. > >> > >> rte_crypto.h:39 > >> enum rte_crypto_op_status { > >> [AK] - There will be many more status opt= ions in asymmetric, > >> could we probably create new one for asym= metric crypto? > >> Even if asymmetric and symmetric > >> overlap? > >> For mod exp, mod inv potentially it will = 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 sp= ecific > >> 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 a= ctual data, not > >> allocated memory (i mean no leading 0ed bytes), so the most significan= t bit > >> will be in data[0]? > >> [Shally] it should be length of actual data not length of allocated me= mory to > >> an array. > >> However it might create bit confusion on modular exponentiation op par= am > >> as that expect length passed should tell actual data length in base ar= ray but > >> array itself should be allocated upto modulus length. > >[AK-v2] - so it is maybe good idea to have allocated data in bytes and a= ctual len in bits here. >=20 > [Shally] No that will make it complex and breaks compatibility too. I wou= ld 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. >=20 > I would suggest you to send a patch with things that we agree or you prop= ose. 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 implementations, uint16_t should be enoug= h > >> for all algorithms big integer sizes [Sha= lly] no hard choices > >> here though. But size_t would never be less than uint16_t so it guaran= tee 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 > >> > >>