From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680083.outbound.protection.outlook.com [40.107.68.83]) by dpdk.org (Postfix) with ESMTP id 53AF41B5D5 for ; Tue, 18 Dec 2018 14:53: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=/90FVbOAR1dXNeH3MYvcUNib7H4o3BwgMbyBHLPoJW8=; b=l8gMfbLZAaWvpxuUtolVbMyFAy+hAydpJQo5HSOaTqlQGBoLA3V5nWTEdMS2YmvtOiVTe6FJjYKwCsWJWapGeSQkZDYwT/yr/BoIOAYbZT79FUWqDZozSCcKQzbYl44NCL1B0MyYgvzxzlgz+Zhq8acG0kL0Ws1RG98PB1d8rKQ= Received: from SN6PR07MB5152.namprd07.prod.outlook.com (52.135.101.33) by SN6PR07MB5582.namprd07.prod.outlook.com (20.177.252.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.22; Tue, 18 Dec 2018 13:53:40 +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.023; Tue, 18 Dec 2018 13:53:40 +0000 From: "Verma, Shally" To: "Kusztal, ArkadiuszX" 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/AAL/PLoA== Date: Tue, 18 Dec 2018 13:53:40 +0000 Message-ID: References: <06EE24DD0B19E248B53F6DC8657831551B10FD2B@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B110B2C@hasmsx109.ger.corp.intel.com> In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B110B2C@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; SN6PR07MB5582; 6:duXRD83cF4ArA1tvmIhs3vu/916azK0Cr3zNd11yzeeo5uUvoXoRGUg8OELUR/E9CJMGhI71phumAGu5+eTjWJI5pRVip9l6zcWp93F+wQ/Qvrq5x6vakaon8y3PE3bldDcGv/k+036YBBI+0Icd7KJZERSMQ9cPIJveSCm4ZI0rm2aNQHI+K+ooB6Rzk6A+aGxOPh+41mSzu/jDptMSXpC9QgoDP7WNfl+kjKSdcWRb0w5sBgKXLkWa5E9sUcQQrV9h7NDkqvIiuuYghtpgS0+QovO5XLfEMc/0iucIhY6UXDVVC8SBGQyZ+qKk7v0Jfn+iWAwW/loBgmaqnKsbMOSkZroQPpjImsljsin+/vCFvi8RGId1Jdn7BH1MhmUNU+5smf/SjCBSIKWVCpNq2JxjWE4hXuoVactEFfgl6dgsnRELxt2n1Vb2fIrd/BaMT/actKHC23FaDZ5tteaCEg==; 5:oHbC4OBTSR8Q56+Qa9igaxNSRFJjSNf3yqQy3sViKT7XDVnKyY/8+vPBInCKlw0VjjgP3UBfU1SHFU0+NuhOZ89tkzcmS9CjIanD8KUenQAVDSciX4WP+ws6F1IsDqIgXoNhRqW99dAgIZ7jZHs7q8fLGQ16CS/8G7UiIfxSKgw=; 7:WXNv0zRehC5zgp8CWD6YPHYcPw8BBmDPmaJ7xkriTu5wCAuEU1ZTOrNNwECVQNyEKRp0e/utPYBNKYxRgpmTW3Tl/18V1oIbMn51lvIT/Fq4FvjmxfBQIiL1kAuELyR2OmxQqbStXw0L1lxEmrs2Kg== x-ms-office365-filtering-correlation-id: cdf8cf3b-700c-490a-801a-08d664f037be x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB5582; x-ms-traffictypediagnostic: SN6PR07MB5582: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005020)(6040522)(2401047)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231475)(944501520)(52105112)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:SN6PR07MB5582; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB5582; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(346002)(376002)(136003)(13464003)(189003)(199004)(8936002)(7736002)(6116002)(55016002)(53936002)(9686003)(97736004)(81156014)(54906003)(8676002)(81166006)(6246003)(316002)(14454004)(71190400001)(71200400001)(25786009)(68736007)(305945005)(4326008)(72206003)(105586002)(478600001)(66066001)(2906002)(76176011)(106356001)(186003)(256004)(33656002)(5660300001)(6436002)(7696005)(229853002)(74316002)(26005)(99286004)(486006)(53546011)(6506007)(55236004)(3846002)(86362001)(102836004)(446003)(11346002)(14444005)(476003)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB5582; H:SN6PR07MB5152.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: J8oJn9DB26/jSxw37dvVbMWv375+TcjcfqSOv7mih3r7lI4amAAK7VUEJAwrsLxuKkDiVpSrBNuMw3sf8pndydTYIaDi/7Qvej+QVh0Fg1s6CA02HPYQd5gequcfU0HL6SCR7VIQSlqHdiXET1Ro4OqiE2dwBZ6R/2Hv8vAWOAlKCddCsTI0YEzA54r5YwFTmf+KSJyI+5/Ok+VaD/us3Ft5yDTi84f3/wUrlB8/orxm2FRS8qFZWRjF8H35H8n+f/L0tF5i7rvTl/3w0N+niiBqp/3ntpuYOjHIRNhHyPOu0EYK13TfRRrmkwucuOon 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: cdf8cf3b-700c-490a-801a-08d664f037be X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 13:53:40.7822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB5582 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 13:53:43 -0000 HI Arek, Fiona >-----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, Ka= naka ; Sahu, >Sunila ; Cel, TomaszX ; Joz= wiak, TomaszX >Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and modinv A= PI > >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, Declan >> ; 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, 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 API which I will work through over the next few months. Starting wit= h >> 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 ope= ration in >> octet-string >> * network byte order format. >> */ >> [AK] - Why prime? RSA for example use semi-= 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-pr= ime >> 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. >> [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 = value 0 >> is passed, it should be considered as INVALID_PARAM. >[AK-v2] - INVALID_PARAM is perfectly fine for me :). [Shally] Just to club Fiona response here to which I agree. If you intend t= o check modulus value to 0 in session_init, then cryptodev lib asym_session= _configure API can check for 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 mod= ular >> * inverse operation in octet-string network= byte >> * order format. >> */ >> [AK] - Same situation as for mod exp. Just = any number. >> [Shally] Yea. It should be reworded as modulus data instead of *prime* >> modulus data >> >> 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 s= ize 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 [Shally] so these are in-= place operation. >> Output will be written back to base param. It also imply length of alloc= ated >> 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 sy= mmetric reason for in-place is that very often structure of >packet is almost intact (macs, ip addresses, ttl etc are changed but struc= ture remains the same, it may differ for IPSec ESP mode etc). >For asymmetric it is mainly used for handshakes (for example in TLS RSA us= e case client will send 48byte of pre master secret which >server will use to generate master secret after decryption). I generally d= on'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 with a= dd that. However would like to ask if anyone has preference to keep in-plac= e option in Asym. If so, then we would need to add Feature flag indicating in-place processin= g capability. >> >> [AK] - Any particular reason modulus and ex= ponent is in >> session? Not saying >> 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 cha= nge >> frequently across operation but only base value. >> So once context is loaded with modulus and exponent , app can call modex= p >> on different base values. >> >> rte_crypto.h:39 >> enum rte_crypto_op_status { >> [AK] - There will be many more status optio= ns in asymmetric, >> could we probably create new one for asymme= tric crypto? >> Even if asymmetric and symmetric >> overlap? >> For mod exp, mod inv potentially it will be= : >> DIVIDING_BY_ZERO_ERROR, INVERSE_NOT_EXISTS_E= RROR... >> [Shally] So far RTE_CRYPTO_OP_STATUS_INVALID_PARAM has been >> sufficient for such cases. Do you have any use-cases where you need spec= ific >> 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 act= ual data, not >> allocated 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 memo= ry 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 arra= y but >> array itself should be allocated upto modulus length. >[AK-v2] - so it is maybe good idea to have allocated data in bytes and act= ual len in bits here. [Shally] No that will make it complex and breaks compatibility too. I would= 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 d= ocumentation if in-place is retained. I would suggest you to send a patch with things that we agree or you propos= e. We can discuss on that further. Thanks Shally >> >> [AK] - could it be uint16/32_t instead as s= ize_t can have >> different sizes in different implementations, uint16_t should be enough >> for all algorithms big integer sizes [Shall= y] no hard choices >> here though. But size_t would never be less than uint16_t so it guarante= e 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 >> >>