From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680067.outbound.protection.outlook.com [40.107.68.67]) by dpdk.org (Postfix) with ESMTP id 153051B7D4 for ; Mon, 17 Dec 2018 06:44:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XJZJ4IYFvfOznTt9rCHKCKcx4TBqIn2pczs77OsRAAo=; b=DPqNlvbGAx476FDS1qNUPYXOeGBy7rL71RRBiMCGzSL7aw6GswGZ0Ip4vnLFb/8+/moA3EJeBQqU3BPfaykKepkSakjbf4WzJY5Ws5DGUEKaubPFUAXti4dIEIJatOldJUYvpj8aJ8TEe0Ao8q0Ns+pPgaDisvgkRd5TIteG7Uw= Received: from SN6PR07MB5152.namprd07.prod.outlook.com (52.135.101.33) by SN6PR07MB5165.namprd07.prod.outlook.com (52.135.101.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Mon, 17 Dec 2018 05:44:41 +0000 Received: from SN6PR07MB5152.namprd07.prod.outlook.com ([fe80::14c5:1013:408f:49c1]) by SN6PR07MB5152.namprd07.prod.outlook.com ([fe80::14c5:1013:408f:49c1%5]) with mapi id 15.20.1425.021; Mon, 17 Dec 2018 05:44:41 +0000 From: "Verma, Shally" To: "Kusztal, ArkadiuszX" CC: "dev@dpdk.org" , "Trahe, Fiona" , "Doherty, Declan" , Kanaka Durga Kotamarthy , Sunila Sahu , "Kotamarthy, Kanaka" , "Sahu, Sunila" Thread-Topic: [RFC] cryptodev/asymm: propose changes to modexp and modinv API Thread-Index: AdSSWDzRIVepFZawTBq8hbmOPY/08AC3UC7w Date: Mon, 17 Dec 2018 05:44:41 +0000 Message-ID: References: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shally.Verma@cavium.com; x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR07MB5165; 6:2jHJ5mCOfWjKOoDj3GgGdNIx4wMFOFJJq2kCOfW58pDKKnhexCbHOelzmgY38vmX9vewXRn3gwY7I7zNF31mcLbhnwQNAGAwiRKXX92KZHfIokmIkT2mkAbUe6SsPjirjqakVWb7yNRhaXqD6kcyg7jRNOI6QPriMGdR3wQ+NeWh05fvgbe2ZNX05IZLd6wCKy1JD1eEWf4iDGAs5OO6xKpo2l2MvLz/ZqT6dDdGWHc7ZSrVpWjnEM75NS5eKPI82cTXd+tL77VTq/ivbnrfg91bSUJs68urHIe7OcFCFO2CytxvrZ7YoCc0P6w3X4FR2r1Ceeb3zi9uZqqaJ43ra5rzn2ZcqZ05i0g5NLEbon8VoknKkY8670AK5cBu2P0xevNAWybG5eWGob/mV/lcYT2WEYx4WZjGrIMLo6TI1rkRqYmoe7NWHSflubhsDM9aO7iTTiNx22rztp+IEgWY5w==; 5:ubcVSuEGPGvIdowKWRIJg1FQCv/hqz11hM9O6BqAPLjEAL25fz/YkFj2otjk0esSSHiaXmqARUQHe9l9fqFND7hZUaGcikTmxXCuI/RJo/xLnpOu8s5nRl7SEiu2vfcr4MP/ps+7cj6Q8pMhwqYDVGbNC+TrMdI+KayT3ZTwfRs=; 7:t8tcKJgGTvbcMT4rI/38PGLVxOKrgl43d/rdtAUTxdbsPMfxXIVvHdtQ0MEG0ZxjmSpNFL6WaEaRHasuJs7RJ/adKbV716fMgLAbO3rABWVWlltGbTnAW12SzDuDR+VS2TaW9uaoWVQWEiwTABWnNw== x-ms-office365-filtering-correlation-id: 8eae55c0-2727-46bc-f74b-08d663e2bdcc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB5165; x-ms-traffictypediagnostic: SN6PR07MB5165: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:SN6PR07MB5165; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB5165; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(136003)(366004)(39860400002)(199004)(189003)(2906002)(55236004)(446003)(102836004)(53546011)(8676002)(316002)(186003)(5660300001)(26005)(3846002)(6506007)(229853002)(106356001)(105586002)(6116002)(54906003)(6916009)(7696005)(7736002)(305945005)(33656002)(99286004)(74316002)(76176011)(25786009)(81156014)(71200400001)(71190400001)(72206003)(14454004)(486006)(478600001)(6436002)(14444005)(256004)(97736004)(68736007)(6246003)(9686003)(81166006)(8936002)(4326008)(476003)(86362001)(107886003)(11346002)(66066001)(53936002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB5165; H:SN6PR07MB5152.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3x8bmYBnmCTpUnzJgreEhrtpYQYyWK2W4V9H054K9bbbGQOyXuaYRHnsMX7+46hlbfPWnoKegorv7JJhZsjzopeOiTwBDGUUQogb/2DKqpJlz3fQIPzYVqthPBKqFcbojCgMsblYn4pxU1GtqfFSRv9WuMm9gwiDPbEc3vFdT/HEet981YnY5p+OJQTV1ySO/arw+KASeA/i+kcL64E2XNjthzrKj+t5cEXPuTuKvlBlNfrC8Hc2nTvZ/PrJvfg33IEhVROj4ogstBuEOLepa/pRfTNX6oNMTRyc3GsZyIGPvOlvex0vrIqbNajuRuR/ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8eae55c0-2727-46bc-f74b-08d663e2bdcc X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 05:44:41.6788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB5165 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 05:44:43 -0000 HI Arek Sorry for late response. Please see response inline From: Kusztal, ArkadiuszX =20 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 External Email Hi Shally, I'm implementing a crypto asymmetric PMD and have some concerns about the A= PI which I=20 will work through over the next few months. Starting with modexp and modinv= I have the following questions / suggestions: =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-pr= ime". =A0=A0=A0=A0=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-prime= input.. so prime shouldn't be mentioned here. =A0=A0=A0=A0=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 se= t flag accordingly. [Shally] Sorry I didn't get this.. which flag you mean here? if modulus val= ue 0 is passed, it should be considered as INVALID_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=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* modu= lus data =A0=A0=A0=A0=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 func= tion 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=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 r= esponsability 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 ba= se param. It also imply length of allocated array should be >=3D modulus le= ngth which is passed in session 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] - 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 be= en defined. It is kept in session envisioning modulus and exponent wont cha= nge frequently across operation but only base value.=20 So once context is loaded with modulus and exponent , app can call modexp o= n different base values. =A0=A0=A0=A0=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 a= symmetric 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...=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 [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? =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 allocate= d 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.=20 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. =A0=A0=A0=A0=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 differe= nt 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=20 [Shally] no hard choices here though. But size_t would never be less than u= int16_t so it guarantee to be large enough for any machines =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 rte_crypto_asym.h:74, 250, 257, 351 =A0=A0=A0=A0=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.=A0=A0=A0=20 Thanks, Arek =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20