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 01A16A04DD; Thu, 2 Jan 2020 08:55:14 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4830A1BFE0; Thu, 2 Jan 2020 08:55:14 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 932AA1BFD8 for ; Thu, 2 Jan 2020 08:55:12 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0027kSS1031106; Wed, 1 Jan 2020 23:55:11 -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=xhoM4GEs3kX9UVhrYkVbIhCffNE3jS+2iH1ybCK/qUw=; b=bNx3rV5xiV9ybMJ/dAGZmxOTdni6rhd3ghLCD2lOUyu4hlzmQAXqilvsCfjOzfOJp+1Z PkbA0pxFanPVqisqrytfN39fyxV++6yqNrur4ac+E7QJW4xWlThkVKC425TMJt+PU7dT LId61HzpkprIAB6LsAp5dJk1CwJD0e9ZDNpmOxyMupU1FfyzGsY4R6tdg55t6WHnKZDa awur5IjoAjYqsCFZe0q+Ie4FMiBC91Rri0EHzxGHatkOOOBwJumXOY2/qqcGjw6i05qp I6dGP6Yzdg2tFWx1hBQFo/aYx0taczVBvjtfO84Of0eWSJ0u+/eHBi21SjPca8fKjZpW jQ== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2x659vmt5t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Jan 2020 23:55:11 -0800 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Jan 2020 23:55:10 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.105) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Jan 2020 23:55:09 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GrrfK/1Vvu+/coso18s/0rqZ7cv5WufhS/56ekF440tmE8QSj2P9Rc1K7+rr9bywHZtemhNokWfthc41eulvd1QW92/4Bs5wCbem9tfCWBqK/MQ89I7uyo9SU2veUh5lZ/MjdQa0PmYiiX6AOmrh7NMlWF0MaNSwVHYxD6dhRLFhC/jSbzplAtouDGZhOPuf4ooWTNUnFe14UtyCEyP7InKbm94wOZV1SpqTpnRDOzEuh9g/Wz/dST55/7NE5nG5RaAYDhV5EhkB8OAKkd+M8DRVrIW6Lwecq0M/ICFQ/A84CWbjMwWeJziBwwdtzF21a/4CN+TJoh8HoNGD1jRM7g== 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=xhoM4GEs3kX9UVhrYkVbIhCffNE3jS+2iH1ybCK/qUw=; b=QHPtqGYzaEkcJlRsQkC4X3xpXPWHodQuH3ANN/8rY8C5fnEC9AyaqjnEH47BSoHMPNJO1V6lzAGhCPSQoas7Ezb5GrvN8tcXOJ3vAHrBdAfmgYgNN68pov4lcuVqaQl/WyVIxgTAJXD/xFWnlXJbUwiC9MKMD6lNA23rpG+OD1uyENED6s7QLAlabLhwU6XMCAj+o3It0Zp9fdCUyIaTsUPENNbcgbStQRzbCIUd8BTZaHU5SSIpw6TTD9SKxKcpIUPXbo/vWUdmCZmA9hpdc4vcb/n06CtzvaVmlJXaT80i4CiV9I0iqo87oQWvgriROmIbzO6xGGrlKNWRVnW9RA== 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=xhoM4GEs3kX9UVhrYkVbIhCffNE3jS+2iH1ybCK/qUw=; b=BUruQBT+CiGONaYdWYnd40kLlTUxfqPrGgr8MFkaDArxKRAzbrhVrYgtf8BadoXBYOFpsUeZjnNVQicV+Vh0ota9NCZtB6J7d0019NlA/LIVASm2cf6Rj/xQjyT1lr2m9zQAq8oB58VeevYVh3E4Q1LsoQOLMNoXbvI2KWRl1Dk= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3325.namprd18.prod.outlook.com (10.255.86.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Thu, 2 Jan 2020 07:55:08 +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.2602.010; Thu, 2 Jan 2020 07:55:08 +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/CAgBO13NA= Date: Thu, 2 Jan 2020 07:55:08 +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: [14.140.231.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a24187d-1288-48e6-a4d9-08d78f591648 x-ms-traffictypediagnostic: MN2PR18MB3325: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:483; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39850400004)(346002)(396003)(376002)(189003)(199004)(13464003)(53546011)(478600001)(7696005)(8676002)(55236004)(55016002)(33656002)(4326008)(316002)(86362001)(81156014)(81166006)(71200400001)(2906002)(9686003)(6506007)(5660300002)(52536014)(8936002)(186003)(76116006)(54906003)(26005)(64756008)(66476007)(66446008)(66556008)(66946007)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3325; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 53ZeQA20SBnBf5TFuN7qqyWhm6yQDmYH7Cf3oTytjTIa1xWbGKd6PL1/McXDHlOCR+Xb8OajNms0VCRL2/QsNpxnrS0VLFEq7Q2V0bCzCwlxCgXd4IwahtoDOSgtwP9D4fMrY+wQsxOWD6sFdmb+w4Fp38FuPjP0RhS7t5g2T7E/pTjOkRb8F7ydcmpgV0Rta5ecvVLpDI+83Gxuw1K0jSudo6++VCFHodQYWn954Z2ImgmzrLioBas4knFu9AMuUoFHjphYSBue5WvW1UxibLIazNKmsf2bSv+wB4C8+NKN2J2ezcU0o8m4Qvqm8PINZL9mFMk7fvkT/HpAVLb8j2P73jZqAqXZkwPM7X/wHdb6G+k8PoVvxpzXnWjnNI6GQ8kK+HZz6J4vJMuuIghbFMRvz1l2K4/2EBHKJmt8xZpgi8XXCSki59+syfP6hUor98VVmSDgVRDZM6hYFLoP1pgn0VFuJPDvLXEsU4OwSBNmtuMMTRwylwNmV2W7biuSqic789MffZUvvNgU9fjQZROccIsqmbhpe4zwwspMnl8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a24187d-1288-48e6-a4d9-08d78f591648 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2020 07:55:08.2556 (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: a6Qb+jZdMDj+wQ7ExDCz0b30kHzPi3WHVYe+EvSXe20nGYyhzeY7VDKTf0m4bszNKml50zW8Oaoptg6tV/BjXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3325 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-02_01:2019-12-30,2020-01-02 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 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 >=20 > External Email >=20 > ---------------------------------------------------------------------- > Hi Anoob, >=20 > Few suggestions inline. >=20 > > ; > > [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, > > +}; >=20 > [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? > > + > > +/** > > + * 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 per= form with one session. In regular use cases, the number of ops done with on= e key is very minimal. But the number of ops using same EC group is more. S= o if we define the session to one per EC group, then we will have better us= age of session. Otherwise, the session need to be created and destroyed eve= ry few operations. =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 itself= ? [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 descrip= tion.=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 like: > 'if k.data =3D=3D NULL =3D> PMD will generate 'k' internally, k.data rema= ins > untouched.' [Anoob] So that will be exposed as a new capability, right? Do you suggest = any changes here to accommodate that?=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 discusse= d > 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?=20 =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', applica= tion should make sure the buffers are large enough. Do you think we could d= ocument it somewhere common instead of adding per operation? =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 >=20 > Regards, > Arek