From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 670321B440 for ; Wed, 12 Dec 2018 21:25:46 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 12:25:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,346,1539673200"; d="scan'208,217";a="106967849" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga007.fm.intel.com with ESMTP; 12 Dec 2018 12:25:41 -0800 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 12 Dec 2018 12:25:41 -0800 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 12 Dec 2018 12:25:40 -0800 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.179]) by HASMSX110.ger.corp.intel.com ([169.254.6.76]) with mapi id 14.03.0415.000; Wed, 12 Dec 2018 22:25:38 +0200 From: "Kusztal, ArkadiuszX" To: "sverma@caviumnetworks.com" CC: "dev@dpdk.org" , "Trahe, Fiona" , "Doherty, Declan" Thread-Topic: [RFC] cryptodev/asymm: propose changes to modexp and modinv API Thread-Index: AdSSWDzRIVepFZawTBq8hbmOPY/08A== Date: Wed, 12 Dec 2018 20:25:37 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> 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.12.171] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [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: Wed, 12 Dec 2018 20:25:47 -0000 Hi Shally, I'm implementing a crypto asymmetric PMD and have some concerns about the A= PI which I will work through over the next few months. Starting with 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 operat= ion in octet-string * network byte order format. */ [AK] - Why prime? RSA for example use semi-pri= me or "RSA multi-prime". It should be just any positive integer. [AK] - If session API layer should check if it= is non-zero and set flag accordingly. rte_crypto_asym.h:253 rte_crypto_param modulus; /**< * Pointer to the prime modulus data for modula= r * inverse operation in octet-string network by= te * order format. */ [AK] - Same situation as for mod exp. Just any= number. For example when using with RSA Carmichael 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 inverse. It= should be driver responsability to check if result will not overflow [AK] - Any particular reason modulus and expon= ent is in session? Not saying it is wrong but is it for DH, RSA use cases on= ly? 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 asymmetri= c crypto? Even if asymmetric and symmetric overlap? For mod exp, mod inv potentially it will be: DIVIDING_BY_ZERO_ERROR, INVERSE_NOT_EXISTS_ERRO= R... 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 sign= ificant bit will be in data[0]? [AK] - could it be uint16/32_t instead as size= _t can have different sizes in different implementations, uint16_t should b= e enough for all algorithms big integer sizes rte_crypto_asym.h:74, 250, 257, 351 /**< Modular Inverse [AK] - Modular Multiplicative Inverse Thanks, Arek