From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 02583A04F0; Mon, 13 Jan 2020 17:36:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2D2D1C133; Mon, 13 Jan 2020 17:36:46 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 86AA41C12C for ; Mon, 13 Jan 2020 17:36:45 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00DGUUgr007547; Mon, 13 Jan 2020 08:36:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=G1D6C+zkrAQj4gPaLiOl66YkQC0827QQSGlKXiW6174=; b=D2FOx11y4DF6JfbLcmluknJauGuqd2Pb7pznPjDn8BBDl8SU7uWF8Z11N296Ih97ClnN VQkLb9zt2IWECKd/8HizQNmbPTyREEb5wmrTxKQnjrgoV5g28q+4MH+2KiWIOcYHIVP6 0qIgtWK1OzAZ8fMC6BIgEjWN1zuFSA3+JxE6RkSr4VKlXQtONeJZYP5wJNulUhfpa+wd +Nd/vKdAYNvsXhaEDd0kpcEYiwKn8ZZAV+VxVqAKvTyfbUsJ1P3EYx/KmjuwYttD5Inz BAKEEaPVwmjwzW/QQx1z4FgeUa2TmDIlkvIEANrWWYe4Dzq9jdXbYuVE61MuvMxZxI4Y tA== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2xgng4s8mv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 08:36:44 -0800 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Jan 2020 08:36:42 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.168) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 13 Jan 2020 08:36:42 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B+64RGMaYnRj7tB8gBzdTTrb8eCheWff+ULTCTWubFDrdRh4+jHQcHv1a+MzvcrLp39T05BWUcBnbpzdJHHwPbTA1EG5YpdKSZgTegXvL//vAwA7+TtbN4lZFenSvvn841w+C9UaeXWoDcc87J15IPyqrjEyMl+j0dudn+oTHfZei2DFpQD5OtKEyFx3cbWmECQAzXfPTfdTn8KLoyE/+bK5Ek71Pl3P+b1OnKjdCPu5SKYABaFamdaH84DU6rpDIiq2FvRb+gkms3IJCLhc26iLOrA3l3N17mEVAw30gSjinODunmVyJ4ECYRKhIUjOK7U6u8roR54VhCc90irlQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G1D6C+zkrAQj4gPaLiOl66YkQC0827QQSGlKXiW6174=; b=aH3WtNlqXC8k+lhfjLg9b3b7Lr+Q/gDIZ+Bebs7sBsZ+a7AkFGmmkC4mcRMcB14YOkYU20Ja42NdiB8krJN9zOTZ7UNB12Bva1YAlWCQ3D0yQhXuGGPmA3WihhmvBEzzgSYD/IqxtblFhaF9IVpb59bQ1o6TcJVcNna45iOFrmpar1YLicdWkqw+eYE+3jDyqGV8/QxETvkbaOAxcofk5nsnptl71p7RavQHBTd9iaP+dvl5kfH4iwt3AKVntD2l6OB+y3CXd6UeydSt5x0i85G6t0HUGOXjUbWQ4fMfecv2t1AxEXwg01JZLIaMxIFqrT4hcX4yRQG/Q9cu4Pjtkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G1D6C+zkrAQj4gPaLiOl66YkQC0827QQSGlKXiW6174=; b=d2+ScCU17zn+VawHgGhoAhGYkRa53yDj0/eWu7ACMNYrGsVx83PNsTKfhM8zUqgmSdlZNZQC+ubkhT041U4W1Cettc94iQoNw284aznlF/kiC3qn5o/R2MXId0jAwygtIvn37SGwtIo3uawMlh8S6vdEaS9L63JeY/Z3ERhrwcE= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3149.namprd18.prod.outlook.com (10.255.236.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.16; Mon, 13 Jan 2020 16:36:41 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::5db5:d179:8a01:4636]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::5db5:d179:8a01:4636%7]) with mapi id 15.20.2623.015; Mon, 13 Jan 2020 16:36:41 +0000 From: Anoob Joseph To: "Kusztal, ArkadiuszX" , Akhil Goyal , "Doherty, Declan" , "De Lara Guarch, Pablo" CC: Ayuj Verma , "Trahe, Fiona" , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Shally Verma , Ankur Dwivedi , Sunila Sahu , "dev@dpdk.org" Thread-Topic: [PATCH 1/4] lib/crypto: add support for ECDSA Thread-Index: AQHVq2FkRKxzlEXGS0WGYbWP1DI5UKfDR/CAgBO13NCAC4XgAIAGdoeg Date: Mon, 13 Jan 2020 16:36:40 +0000 Message-ID: References: <1575546206-2478-1-git-send-email-anoobj@marvell.com> <1575546206-2478-2-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [111.125.206.208] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58f2c399-a1da-4717-e7a6-08d79846c49f x-ms-traffictypediagnostic: MN2PR18MB3149: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:285; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(396003)(39850400004)(366004)(136003)(199004)(189003)(5660300002)(76116006)(64756008)(66446008)(66946007)(7696005)(55236004)(86362001)(26005)(110136005)(6506007)(9686003)(53546011)(54906003)(55016002)(71200400001)(66476007)(478600001)(66556008)(316002)(8936002)(33656002)(81156014)(8676002)(81166006)(2906002)(186003)(30864003)(52536014)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3149; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U15nDlwP/VqhRiEIrqQIvJfbFqbsp+YQu9TxQUR2S6p6XsBGu9SzVlX/4ZCdt6i6TQTXUoQfc8JE0H9k1mrcQddgDeHgFG1cdYO2rX0coQNBUilUsGZEdWVNsDqhxuna9MKWrTN8v5OHTWGOGw3VevweQSX8DH4SFd33ddU7p+3ebl62PxHJnoSZ9C3E03qZIMkJqAZz/WLiciPOsFhuESvF69tA9S7utzM+OipyUznInQgpAv6zsXBNpeUOqCKdDvG2dvKrWLKP8Y20X9m2grUGfLNltmsrlYb79AdYvbBPk2rE84o9ZlwpkYo+GTX7aooyMsaglfeKWDgop4ZIGw5TENJuSIRJMKciVyDa8gqxntY2pw6j9wgUxOfOQURhzxvkfyPIZr+i/5LxmVUl4781eQ0IX3HqaLJBoCp0CxfeT9couuW1IaJX9vZlPqromoqQq2/53stULwULVC2xP4703J82HY5pjtHThJwXdWE7EzCTJkzxOWqdhQlwjyCdbVXYl6aL1nSegVsTckDMYQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 58f2c399-a1da-4717-e7a6-08d79846c49f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2020 16:36:40.8482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vg5F9DCjTYrM4RQWkSQcr9Lj03cTDk+h1pMbQTfgRfCb2X3RrTYc3waNESrT2wOzv1C7geJZw5OXB8ZEkEO19A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3149 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-13_05:2020-01-13, 2020-01-13 signatures=0 Subject: Re: [dpdk-dev] [PATCH 1/4] lib/crypto: add support for ECDSA 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Akhil, Do you suggest any change for the title here? As in, should I make it, cryptodev: support ECDSA @Arek, please see inline for responses. Thanks, Anoob > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Thursday, January 9, 2020 6:34 PM > To: Anoob Joseph ; Akhil Goyal ; > Doherty, Declan ; De Lara Guarch, Pablo > > Cc: Ayuj Verma ; Trahe, Fiona > ; Jerin Jacob Kollanukkaran ; > Narayana Prasad Raju Athreya ; Shally Verma > ; Ankur Dwivedi ; Sunila Sahu > ; dev@dpdk.org > Subject: [EXT] RE: [PATCH 1/4] lib/crypto: add support for ECDSA >=20 > External Email >=20 > ---------------------------------------------------------------------- > Hi Anoob, >=20 > > -----Original Message----- > > From: Anoob Joseph > > Sent: Thursday, January 2, 2020 8:55 AM > > To: Kusztal, ArkadiuszX ; Akhil Goyal > > ; Doherty, Declan ; De > > Lara Guarch, Pablo > > Cc: Ayuj Verma ; Trahe, Fiona > > ; Jerin Jacob Kollanukkaran > > ; Narayana Prasad Raju Athreya > > ; Shally Verma ; Ankur > > Dwivedi ; Sunila Sahu ; > > dev@dpdk.org > > Subject: RE: [PATCH 1/4] lib/crypto: add support for ECDSA > > > > Hi Arek, > > > > Please see inline. > > > > Thanks, > > Anoob > > > > > -----Original Message----- > > > From: Kusztal, ArkadiuszX > > > Sent: Friday, December 20, 2019 9:36 PM > > > To: Anoob Joseph ; Akhil Goyal > > > ; Doherty, Declan ; > > > De Lara Guarch, Pablo > > > Cc: Ayuj Verma ; Trahe, Fiona > > > ; Jerin Jacob Kollanukkaran > > > ; Narayana Prasad Raju Athreya > > > ; Shally Verma ; Ankur > > > Dwivedi ; Sunila Sahu ; > > > dev@dpdk.org > > > Subject: [EXT] RE: [PATCH 1/4] lib/crypto: add support for ECDSA > > > > > > External Email > > > > > > -------------------------------------------------------------------- > > > -- > > > Hi Anoob, > > > > > > Few suggestions inline. > > > > > > > ; > > > > [Asymmetric] > > > > -RSA =3D > > > > -DSA =3D > > > > -Modular Exponentiation =3D > > > > -Modular Inversion =3D > > > > -Diffie-hellman =3D > > > > \ No newline at end of file > > > > +RSA =3D > > > > +DSA =3D > > > > +Modular Exponentiation =3D > > > > +Modular Inversion =3D > > > > +Diffie-hellman =3D > > > > +ECDSA =3D > > > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h > > > > b/lib/librte_cryptodev/rte_crypto_asym.h > > > > index 0d34ce8..dd5e6e3 100644 > > > > --- a/lib/librte_cryptodev/rte_crypto_asym.h > > > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h > > > > @@ -81,6 +81,10 @@ enum rte_crypto_asym_xform_type { > > > > /**< Modular Exponentiation > > > > * Perform Modular Exponentiation b^e mod n > > > > */ > > > > + RTE_CRYPTO_ASYM_XFORM_ECDSA, > > > > + /**< Elliptic Curve Digital Signature Algorithm > > > > + * Perform Signature Generation and Verification. > > > > + */ > > > > RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > > > > /**< End of list */ > > > > }; > > > > @@ -319,6 +323,46 @@ struct rte_crypto_dsa_xform { }; > > > > > > > > /** > > > > + * TLS named curves > > > > + * > > > > +https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > 3A__www.iana.org_ass > > > > +ignments_tls- > > > 2Dparameters_&d=3DDwIFAg&c=3DnKjWec2b6R0mOyPaz7xtfQ&r=3DjPfB8r > > > > +wwviRSxyLWs2n6B-WYLn1v9SyTMrT5EQqh2TU&m=3DnYBsHHO1NEdu- > > > JmNULDH0kx7auwQd > > > > > > > > > +SbI0VYNVNxmm1w&s=3DRKZgomFiHpm9Yp8AYEn4FjlPpzbdavkMv5cRUggVid > > > A&e=3D > > > > + * tls-parameters.xhtml#tls-parameters-8 > > > > + * secp192r1 =3D 19, > > > > + * secp224r1 =3D 21, > > > > + * secp256r1 =3D 23, > > > > + * secp384r1 =3D 24, > > > > + * secp521r1 =3D 25, > > > > + */ > > > > +enum rte_crypto_ec_group { > > > > + RTE_CRYPTO_EC_GROUP_UNKNOWN =3D 0, > > > > + RTE_CRYPTO_EC_GROUP_NISTP192 =3D 19, > > > > + RTE_CRYPTO_EC_GROUP_NISTP224 =3D 21, > > > > + RTE_CRYPTO_EC_GROUP_NISTP256 =3D 23, > > > > + RTE_CRYPTO_EC_GROUP_NISTP384 =3D 24, > > > > + RTE_CRYPTO_EC_GROUP_NISTP521 =3D 25, }; > > > > > > [Arek] Since in comment we use SECG naming maybe enum should follow > > to > > > avoid confusion? > > > > [Anoob] How about RTE_CRYPTO_EC_GROUP_SECP521R1 and so on? > [Arek] Iam ok with that. [Anoob] Will update in v2. =20 > > > > > > + > > > > +/** > > > > + * Structure for elliptic curve point */ struct > > > > +rte_crypto_ec_point { > > > > + rte_crypto_param x; > > > > + /**< X coordinate */ > > > > + rte_crypto_param y; > > > > + /**< Y coordinate */ > > > > +}; > > > > + > > > > +/** > > > > + * Asymmetric elliptic curve transform data > > > > + * > > > > + * Structure describing all EC based xform params > > > > + * > > > > + */ > > > > +struct rte_crypto_ec_xform { > > > > + enum rte_crypto_ec_group curve_id; > > > > + /**< Pre-defined ec groups */ > > > > +}; > > > > + > > > > +/** > > > > * Operations params for modular operations: > > > > * exponentiation and multiplicative inverse > > > > * > > > > @@ -372,6 +416,11 @@ struct rte_crypto_asym_xform { > > > > > > > > struct rte_crypto_dsa_xform dsa; > > > > /**< DSA xform parameters */ > > > > + > > > > + struct rte_crypto_ec_xform ec; > > > > + /**< EC xform parameters, used by elliptic curve based > > > > + * operations. > > > > + */ > > > > }; > > > > }; > > > > > > > > @@ -516,6 +565,39 @@ struct rte_crypto_dsa_op_param { }; > > > > > > > > /** > > > > + * ECDSA operation params > > > > + */ > > > > +struct rte_crypto_ecdsa_op_param { > > > > + enum rte_crypto_asym_op_type op_type; > > > > + /**< Signature generation or verification */ > > > > + > > > > + rte_crypto_param pkey; > > > > + /**< Private key of the signer for signature generation */ > > > [Arek] - for DSA we have private key in xform, why this inconsistency= ? > > > > [Anoob] Putting key in the session would limit the number of ops we > > can perform with one session. In regular use cases, the number of ops > > done with one key is very minimal. But the number of ops using same EC = group > is more. > > So if we define the session to one per EC group, then we will have > > better usage of session. Otherwise, the session need to be created and > > destroyed every few operations. > [Arek] I agree with that, so maybe we could change DSA similar way (leave= only > group params?) [Anoob] I'm okay with that. But that will have to be taken up separately, I= guess. Shall I take that you are in agreement with the proposed change her= e? =20 > > > > > > + > > > > + struct rte_crypto_ec_point q; > > > > + /**< Public key of the signer for verification */ > > > > + > > > > + rte_crypto_param message; > > > > + /**< Input message to be signed or verified */ > > > [Arek] - This I expect should be message digest instead of message it= self? > > > > [Anoob] Yes. Message digest is what is expected. This is following > > what is done with DSA & RSA. Do you recommend any changes? Variable > > name or description. > [Arek] Some information would be good I think. [Anoob] I'll update the comment to state the same /**< Input message digest to be signed or verified */ Is this fine? =20 > > > > > > + > > > > + rte_crypto_param k; > > > > + /**< The ECDSA per-message secret number, which is an integer > > > > + * in the interval (1, n-1) > > > > + */ > > > [Arek] - If pmd can generate 'k' internally we could do something lik= e: > > > 'if k.data =3D=3D NULL =3D> PMD will generate 'k' internally, k.data > > > remains untouched.' > > > > [Anoob] So that will be exposed as a new capability, right? Do you > > suggest any changes here to accommodate that? > [Arek] Or maybe feature flag, it would apply to DSA as well. [Anoob] I meant feature flag only! Capability is for net devs etc. =20 > > > > > Another option is to provide user with some callback function to > > > generate CSRN which could be useful for RSA PSS, OAEP as well (we > > > already discussed that internally in Intel, I will elaborate on this > > > bit more in > > different thread). > > > > [Anoob] Do you intend to keep the generated CSRN hidden in the PMD? > [Arek] Openssl PMD does that with DSA but iam not a fan of that. But if s= ome hw > can do DSA/ECDSA by generating 'k' by itself it would have to be added an= yway. > Other option is to add aforementioned callbacks (for HW that not generate= 'k' > by itself) [Anoob] I think we can support either case. Our h/w also can generate CSRN = and so are open to ideas. Can you explain the proposed callback function? A= lso, we can defer that discussion to a separate thread, if we have an agree= ment on the approach here.=20 =20 > > > > > > > > > + > > > > + rte_crypto_param r; > > > > + /**< r component of elliptic curve signature > > > > + * output : for signature generation > > > > + * input : for signature verification > > > > + */ > > > > + rte_crypto_param s; > > > > + /**< s component of elliptic curve signature > > > > + * output : for signature generation > > > > + * input : for signature verification > > > > + */ > > > [Arek] - Do we want to add any constraints like 'this field should > > > be big enough to hold...' > > > > [Anoob] For every case where rte_crypto_param is used for 'output', > > application should make sure the buffers are large enough. Do you > > think we could document it somewhere common instead of adding per > operation? > [Arek] > Both options look good to me. [Anoob] How about updating the description of 'rte_crypto_param' to reflect= the same? I can update it in v2, if you can confirm. =20 > > > > > > +}; > > > > + > > > > +/** > > > > * Asymmetric Cryptographic Operation. > > > > * > > > > * Structure describing asymmetric crypto operation params. > > > > @@ -537,6 +619,7 @@ struct rte_crypto_asym_op { > > > > struct rte_crypto_mod_op_param modinv; > > > > struct rte_crypto_dh_op_param dh; > > > > struct rte_crypto_dsa_op_param dsa; > > > > + struct rte_crypto_ecdsa_op_param ecdsa; > > > > }; > > > > }; > > > > > > > > diff --git a/lib/librte_cryptodev/rte_cryptodev.c > > > > b/lib/librte_cryptodev/rte_cryptodev.c > > > > index 89aa2ed..0d6babb 100644 > > > > --- a/lib/librte_cryptodev/rte_cryptodev.c > > > > +++ b/lib/librte_cryptodev/rte_cryptodev.c > > > > @@ -173,6 +173,7 @@ const char *rte_crypto_asym_xform_strings[] =3D= { > > > > [RTE_CRYPTO_ASYM_XFORM_MODINV] =3D "modinv", > > > > [RTE_CRYPTO_ASYM_XFORM_DH] =3D "dh", > > > > [RTE_CRYPTO_ASYM_XFORM_DSA] =3D "dsa", > > > > + [RTE_CRYPTO_ASYM_XFORM_ECDSA] =3D "ecdsa", > > > > }; > > > > > > > > /** > > > > -- > > > > 2.7.4 > > > > > > Regards, > > > Arek