From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 2AD691B59F for ; Mon, 17 Dec 2018 15:24:54 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2018 06:24:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,365,1539673200"; d="scan'208";a="126656514" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 17 Dec 2018 06:24:53 -0800 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Dec 2018 06:24:53 -0800 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Dec 2018 06:24:53 -0800 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.179]) by HASMSX110.ger.corp.intel.com ([169.254.6.30]) with mapi id 14.03.0415.000; Mon, 17 Dec 2018 16:24:51 +0200 From: "Kusztal, ArkadiuszX" To: "Verma, Shally" CC: "dev@dpdk.org" , "Trahe, Fiona" , "Doherty, Declan" , Kanaka Durga Kotamarthy , Sunila Sahu , "Kotamarthy, Kanaka" , "Sahu, Sunila" , "Cel, TomaszX" , "Jozwiak, TomaszX" Thread-Topic: [RFC] cryptodev/asymm: propose changes to modexp and modinv API Thread-Index: AdSSWDzRIVepFZawTBq8hbmOPY/08AC3UC7wADEOW/A= Date: Mon, 17 Dec 2018 14:24:50 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B110B2C@hasmsx109.ger.corp.intel.com> References: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.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.103.104.48] 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 14:24:55 -0000 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, Declan > ; Kanaka Durga Kotamarthy > ; Sunila Sahu ; > Kotamarthy, Kanaka ; Sahu, Sunila > > Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and > modinv API >=20 > HI Arek >=20 > Sorry for late response. Please see response inline >=20 > From: Kusztal, ArkadiuszX > Sent: 13 December 2018 01:56 > To: Verma, Shally > Cc: dev@dpdk.org; Trahe, Fiona ; Doherty, Declan > > Subject: [RFC] cryptodev/asymm: propose changes to modexp and modinv > API >=20 > External Email > Hi Shally, >=20 > 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 with > modexp and modinv I have the following questions / suggestions: >=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-pri= me > input.. so prime shouldn't be mentioned here. [AK-v2] I think it could be any nonzero number even composite, for DH, DSA = 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 v= alue 0 > is passed, it should be considered as INVALID_PARAM. [AK-v2] - INVALID_PARAM is perfectly fine for me :). >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rte_crypto_asym.h:253 > =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 /**< > =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 * Pointer to the prime modulus data for modular > =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 * inverse operation in octet-string network byte > =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 * 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] - Same situation as for mod exp. Just any number. > [Shally] Yea. It should be reworded as modulus data instead of *prime* > modulus data >=20 > =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 For example when using with RSA Carmichael and Euler > Totient function will even > =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 have composite factors. >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rte_crypto_asym.h:323 > =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 struct rte_crypto_mod_op_param { > =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] - There should be a result field. It size should be equal= to > the size > =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 of modulus. Same apply to mod mult inverse. It should be > driver responsability to check if result > =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 will not overflow [Shally] so these are in-place operation. > Output will be written back to base param. It also imply length of alloca= ted > 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 sym= metric 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 us= ed 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 symme= tric especially that only RSA would be (to some extent) capable of it. >=20 > =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] - Any particular reason modulus and exponent is in > session? Not saying > =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 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 chan= ge > frequently across operation but only base value. > So once context is loaded with modulus and exponent , app can call modexp > on different base values. >=20 > =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.h:39 > =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 enum rte_crypto_op_status { > =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] - There will be many more status options in asymmetric, > =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 could we probably create new one for asymmetric crypto? > Even if asymmetric and symmetric > =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 overlap? > =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 For mod exp, mod inv potentially it will be: > =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 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 speci= fic > 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. >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rte_crypto_asym.h:33 > =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 size_t length; > =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 /**< length of data in bytes */ > =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] - Is it guaranteed to be length of actual data, not > allocated memory (i mean no leading 0ed bytes), so the most significant b= it > will be in data[0]? > [Shally] it should be length of actual data not length of allocated memor= y 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 length. [AK-v2] - so it is maybe good idea to have allocated data in bytes and actu= al len in bits here. >=20 > =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] - could it be uint16/32_t instead as size_t can have > different sizes in different implementations, uint16_t should be enough > =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 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 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rte_crypto_asym.h:74, 250, 257, 3= 51 > =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 /**< Modular Inverse > =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] - Modular Multiplicative Inverse > =A0=A0=A0=A0[Shally] Ack. >=20 > Thanks, > Arek >=20 >=20