From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820083.outbound.protection.outlook.com [40.107.82.83]) by dpdk.org (Postfix) with ESMTP id 1C0081B138 for ; Thu, 20 Dec 2018 11:52:48 +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=u+07CstyCjMWbVFbe5Fp6LMjQssfMXbvu/AVDjzA9qY=; b=eOaIqhgttJFUnYO3XTkEibxEHcBXhqBDQp9zmtgvb8kqgtO/CanPaalMyrgnmb0Kc9q1Oqhc9sXFn3aq/Q6eCdIC7UIepVnl6pSwnwEVO8rxgLjDI3Mxpkbfdw5ZEQqhnEfQMYcReH6ZZKX/Gfe7DWCVvZeRFMBNgLPOG3b36K4= Received: from SN6PR07MB5152.namprd07.prod.outlook.com (52.135.101.33) by SN6PR07MB5277.namprd07.prod.outlook.com (52.135.105.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.19; Thu, 20 Dec 2018 10:52:45 +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.024; Thu, 20 Dec 2018 10:52:45 +0000 From: "Verma, Shally" To: "Trahe, Fiona" , "Kusztal, ArkadiuszX" CC: "dev@dpdk.org" , "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/AAL/PLoAALwttAAFmAZSA= Date: Thu, 20 Dec 2018 10:52:45 +0000 Message-ID: References: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B110B2C@hasmsx109.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435896A4C8E@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B435896A4C8E@IRSMSX101.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; SN6PR07MB5277; 6:kGL8cO6WhiKZfeax+tJI5mxTaAIV4MjTZ0wfAOWWCUwpucdgqHiDs9Rc5/pET/ORrAsUaazrAXoiGY8buBFLq21H8oLskyeQeIA+mYHtp+U1YGk/7qXFZOkFnxs8zN/sBeF0dkYa4Uxn4BoqF7dfBZYmDuHXC8AfXCWC0oH3eC/kkbGZJ374cMVzIV6g+mhx9Z39frMXTlmn6JTAlF3nRPQ5YJYkcftYmjGuR8QhI4ZOrgcD5aoPjbVxg+2aUrMisNNqgIfgIAgDuSpOuJt2Q/3Eu49lt2xZN+1CuFevaMsyR4GDIEvoLqQANIHZ07OWmQe1dHmN99xQDUSveUq/Aqa6nz6Agd9gNseTmhoT5ntSbZ7ODkP1AANcud+lajxmFMml5fsxeOjRn6pehEbUw4JP7foTZFjOyfUguWoRDE24bwhyjY6c36pT9WjsT2mYX1yN7GRaynEEyDaMmPIKAQ==; 5:x0tBxsolpKMbQstUSd8Ki6ZIUGEsdTSjSYeHLz8aAZMSPLLGtLaEIiSkyeO1hHyptHH0OLlfamgxKgwGkxWno6nW3dg/sCzBrfuhEVRm3+5HUmA1VuaesQQh13W3TC/m/W0Dm+Q3ysThOdp/Hp7s0RAvlV8+dr6Fbn5tg1zPPDk=; 7:8T4bt8EgYHj+UuA90lzFuJ6+WCW4vaRmeRDpZ3fJ2ieDh5ZXLk1RcU3RW2AINbkxY1E/+4QEwrB98A1eo1xLP3htVRtVW9DbHo4KitvpFlop3kQ9w26lQ46WDg/sS1arxbMdAJLOPCgqq63FLzNvFA== x-ms-office365-filtering-correlation-id: a3e1105b-730f-47c4-721c-08d666694667 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB5277; x-ms-traffictypediagnostic: SN6PR07MB5277: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005026)(6040522)(2401047)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231475)(944501520)(52105112)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:SN6PR07MB5277; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB5277; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(366004)(346002)(136003)(199004)(189003)(13464003)(72206003)(186003)(2906002)(508600001)(68736007)(25786009)(14454004)(26005)(74316002)(6116002)(3846002)(81156014)(446003)(81166006)(8936002)(305945005)(7736002)(8676002)(55236004)(6436002)(486006)(102836004)(86362001)(71190400001)(71200400001)(5660300001)(66066001)(476003)(93886005)(9686003)(316002)(6506007)(55016002)(53936002)(106356001)(11346002)(6246003)(76176011)(97736004)(105586002)(229853002)(7696005)(110136005)(33656002)(54906003)(99286004)(4326008)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB5277; 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: w7/VyWx78xoE2f4QmKQegd0nrX9v+UlI+x8+iTkQydovqxoPmuk0FT7wHDQoe4fKr52N3gSfoCM30s7d8Xb4EgqWaZmyt//ye/hXpf+ZLiwOA4SE1BL+/EQZTvVrJU+EtCqY/p8Lqpe/WTgScxCiIssrIyMjqz+m+lzQuWMVW/9BlA71IsuJI2oi+KS7NsyuS+m5qtwnC/W+pJUh1MvoNz9qZ/Erb/zmKKY+d6FYeOYSm1a38cmZnHbnGm3m10SGwXZwa622WPzxw9OF1PJ6fBnLnxhIEjiJ63tZr4tQqW1TVjkqB7VgvhXdX8l4Zgwh spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3e1105b-730f-47c4-721c-08d666694667 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2018 10:52:45.7487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB5277 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 10:52:48 -0000 >-----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 A= PI > >External Email > >Hi Shally, Arek, > ... >> >> >> >> rte_crypto_asym.h:323 >> >> struct rte_crypto_mod_op_param { >> >> [AK] - There should be a result field. I= t size should be equal to >> >> the size >> >> of modulus. Same apply to mod mult inver= se. It should be >> >> driver responsability to check if result >> >> will not overflow [Shally] so these are = in-place operation. >> >> Output will be written back to base param. It also imply length of al= located >> >> 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 st= ructure 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 generall= y 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 wit= h 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 proces= sing 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 c= hanges? Thanks Shally >> >> [AK] - Any particular reason modulus and= exponent is in >> >> session? Not saying >> >> it is wrong but is it for DH, RSA use ca= ses only? >> >> [Shally] no that's not the intent. For RSA and DH respective xforms h= ave 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 mo= dexp >> >> on different base values. >> >> >> >> rte_crypto.h:39 >> >> enum rte_crypto_op_status { >> >> [AK] - There will be many more status op= tions in asymmetric, >> >> could we probably create new one for asy= mmetric crypto? >> >> Even if asymmetric and symmetric >> >> overlap? >> >> For mod exp, mod inv potentially it will= be: >> >> DIVIDING_BY_ZERO_ERROR, INVERSE_NOT_EXIST= S_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 s= pecific >> >> 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 significa= nt bit >> >> will be in data[0]? >> >> [Shally] it should be length of actual data not length of allocated m= emory to >> >> an array. >> >> However it might create bit confusion on modular exponentiation op pa= ram >> >> as that expect length passed should tell actual data length in base a= rray but >> >> array itself should be allocated upto modulus length. >> >[AK-v2] - so it is maybe good idea to have allocated data in bytes and = actual len in bits here. >> >> [Shally] No that will make it complex and breaks compatibility too. I wo= uld 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 prope= r documentation if in-place is >> retained. >> >> I would suggest you to send a patch with things that we agree or you pro= pose. We can discuss on that >> further. >[Fiona] yes, agreed, Arek will send a patch. > >> Thanks >> Shally >> >> >> >> [AK] - could it be uint16/32_t instead a= s size_t can have >> >> different sizes in different implementations, uint16_t should be enou= gh >> >> for all algorithms big integer sizes [Sh= ally] no hard choices >> >> here though. But size_t would never be less than uint16_t so it guara= ntee 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 >> >> >> >>