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 34408A046B; Thu, 9 Jan 2020 14:03:48 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6327C1DD59; Thu, 9 Jan 2020 14:03:47 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 96BAA1DD57 for ; Thu, 9 Jan 2020 14:03:45 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2020 05:03:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,413,1571727600"; d="scan'208";a="421774420" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga005.fm.intel.com with ESMTP; 09 Jan 2020 05:03:44 -0800 Received: from orsmsx114.amr.corp.intel.com (10.22.240.10) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 05:03:43 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX114.amr.corp.intel.com (10.22.240.10) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 05:03:43 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.170) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 9 Jan 2020 05:03:43 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nP9UVDwOsb5jmkLW7glEZvqkgi4hWVDD3vcJIML7Rjxad5SCu1/OidpmX3pUqXhn19fa+0j5Tea/FZyNjszRl41Z5CfDV8REtCzPlWlbi7mNdJAKEuwr00Gq9qzTl7+unU6uqvUQYj8h6K7ZpysU7ObuqSx5EZp8NwLIbpD8Zm5XtTTVvveRhH8vdR0DpsDDlX8VKvyr6ubHo6cQ/5RGjL77dTniyaBkV1WiBzCoqax5Df8z+a05OJAUmImt4mGj+96mgj0Tx7a/NKn4z+7SPl5ZzLbqb0vRTJ9uq2OEiljuLhDl9y4p/OaU6anlUXF1qPP8XJ47DfISPBaempPqKA== 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=i4ZOl4bc6lGXPgVPZsfckHqBO3mW8kJilx4kBkO3Hbg=; b=GBgRVlLjOQfHJLIQ6kAUiDnrTIg1oiU96eATv42lMKtVFropGP0QynkW0oH/d7p+GnjCNgiZ/ZTN+ERz1jeoFW3bBnonSLFGPgXjEHNEUkayNgz8oV90HZSKNIfwApfQXVM4jZ6P9jbgZRLAY7EUwphaGVlHjf3WKsXmS4Rn8oDoJ/Dmaejhdtnq3kiUSx/M3E8pJSX/kHVCBcF9xcTGBK23uMSUtEvGL9tpvArHmS00k5qM/x+jrJ9DaeB2Eol7Rs3yN3zIr34PNTP/NbXug0wAs1YoZcTUjrYGqGmwPvGVY30dx52nH+4wuqqBod4DBMWZg3if8k2hL5GVMgvEMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i4ZOl4bc6lGXPgVPZsfckHqBO3mW8kJilx4kBkO3Hbg=; b=LJVx3p1AJMP87YEOVw/TNfWtUvllMbk1Vf4LUun/xHPtJ4UvvKax9N2Pd/6OWY3DYFfHupiWy0wqryhkljBg1QjGzSJ9dNN1IBPEL3XfETP0lFNpkc0dAWfHUxkcQ35uOtdjWZ3oeewRXPgBgmaBSQTWfyJ0lWZbrqkK5THPFn4= Received: from BYAPR11MB3831.namprd11.prod.outlook.com (20.178.239.150) by BYAPR11MB3349.namprd11.prod.outlook.com (20.177.186.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 13:03:42 +0000 Received: from BYAPR11MB3831.namprd11.prod.outlook.com ([fe80::2410:3fa:b1a1:9a3a]) by BYAPR11MB3831.namprd11.prod.outlook.com ([fe80::2410:3fa:b1a1:9a3a%6]) with mapi id 15.20.2602.018; Thu, 9 Jan 2020 13:03:42 +0000 From: "Kusztal, ArkadiuszX" 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" Thread-Topic: [PATCH 1/4] lib/crypto: add support for ECDSA Thread-Index: AQHVq2F/ClDDEhFhTkSJKuDq6QguHqfDOErwgBP02gCACyI9IA== Date: Thu, 9 Jan 2020 13:03:42 +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-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.2.0.6 dlp-product: dlpe-windows x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTgzNzY5YTYtYzNiOC00ODc2LTg0ODgtZjNlYjZlYzFiZjQ0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiOU14NndoRm1QMVhJYTg4bEZaWE1HSWR3UFwvajlNekQzY3cwOExHMUpUVjM1WGFTM3dnZjJNS20yc05pNDQzdUIifQ== authentication-results: spf=none (sender IP is ) smtp.mailfrom=arkadiuszx.kusztal@intel.com; x-originating-ip: [192.198.151.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 99465bff-6b5d-4f1d-8ff6-08d795045a3c x-ms-traffictypediagnostic: BYAPR11MB3349: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:260; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(39860400002)(376002)(346002)(13464003)(199004)(189003)(186003)(55016002)(26005)(81156014)(6506007)(86362001)(53546011)(6636002)(81166006)(8676002)(9686003)(8936002)(2906002)(110136005)(71200400001)(54906003)(7696005)(5660300002)(66556008)(52536014)(76116006)(66476007)(66946007)(64756008)(66446008)(316002)(4326008)(33656002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR11MB3349; H:BYAPR11MB3831.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B6XI+0xRpvVdGAY8pf9TsRKw9Hzv/A8RStC2M5gDTzorrM0guX6Xk1st9+779q0wQU8MpGz2Sh42+f6WMdo8KrDrPo5MEeaTE0gNx4bJynTxS7Sqi+0Kpzryjx80DDhIf/BJiAZzROMQw3UHyvvLT8k2HwrrzEDoBqmRKPqCWxAvJM6/Mhgn31CGXiSA63jUW3BKA32U0GdPu11s456O1w+bUDWvyxcu/UJyHHLd66r8PR55tmaK+J4AuosHFO/OZhywf938PdyhVAf4N2TSqiWlIJG1tIRpU2zoWp2PsrTeLpGQcSxt62l1NywZMek5K+4qAA5n8UJI8mS+bDIdDTBm+XO6eYL3AvaWmaG9XA/6U59j1PP6dKP8yMReXzh3J+cGSMkClr7pptHuYzUMhEJrnwVoksrvlYEZsz7Rqj3/dN94aoZgoOtCn11XHcjaC5VtYJ4FRIoYVY/MMXUqBX4uwa1o9DqQIP/ug3jcw8l552DgkRfVeirKBTupSDn6dofelPJXIHyFU562d3dqpAxDjYxIP81HJV9dzy9RzLPYWGnmvDuiZKveYSzeV6H4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 99465bff-6b5d-4f1d-8ff6-08d795045a3c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 13:03:42.0701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jfc5UghP6u7kd0NlMKeAiX36RXrsLfSCCEife4Uctb/frcLcXSty5Ve9dyD8jVN6pMt7W00e0vBK0WoyBnHlje8+Cmequ1BI391vziE9ZDg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3349 X-OriginatorOrg: intel.com 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 Anoob, > -----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 >=20 > Hi Arek, >=20 > Please see inline. >=20 > Thanks, > Anoob >=20 > > -----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? >=20 > [Anoob] How about RTE_CRYPTO_EC_GROUP_SECP521R1 and so on? [Arek] Iam ok with that. >=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? >=20 > [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 wi= th > one key is very minimal. But the number of ops using same EC group is mor= e. > 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 o= nly group params?) >=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 itse= lf? >=20 > [Anoob] Yes. Message digest is what is expected. This is following what i= s > done with DSA & RSA. Do you recommend any changes? Variable name or > description. [Arek] Some information would be good I think. >=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 re= mains > > untouched.' >=20 > [Anoob] So that will be exposed as a new capability, right? Do you sugges= t > any changes here to accommodate that? [Arek] Or maybe feature flag, it would apply to DSA as well. >=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 bi= t more in > different thread). >=20 > [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 som= e hw can do DSA/ECDSA by generating 'k' by itself it would have to be added= anyway. Other option is to add aforementioned callbacks (for HW that not g= enerate 'k' by itself) >=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...' >=20 > [Anoob] For every case where rte_crypto_param is used for 'output', > application should make sure the buffers are large enough. Do you think w= e > could document it somewhere common instead of adding per operation? [Arek] Both options look good to me. >=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