From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id A32CDA04FD;
Tue, 14 Jan 2020 12:05:36 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 2779D1C201;
Tue, 14 Jan 2020 12:05:36 +0100 (CET)
Received: from mga18.intel.com (mga18.intel.com [134.134.136.126])
by dpdk.org (Postfix) with ESMTP id 98A501C1AA
for <dev@dpdk.org>; Tue, 14 Jan 2020 12:05:34 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga008.fm.intel.com ([10.253.24.58])
by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
14 Jan 2020 03:05:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,432,1571727600"; d="scan'208";a="219573015"
Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202])
by fmsmga008.fm.intel.com with ESMTP; 14 Jan 2020 03:05:31 -0800
Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by
fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS)
id 14.3.439.0; Tue, 14 Jan 2020 03:05:33 -0800
Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by
FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS)
id 14.3.439.0; Tue, 14 Jan 2020 03:05:32 -0800
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.103)
by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id
14.3.439.0; Tue, 14 Jan 2020 03:01:57 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=P8OeCJW1tLCwElEhFvIisxP/3rmHUO8w6NJ7b8PnJYzaKIQUYr9KumYdn3X0V+ozbnEEGkyIeF1uVdNRGNyOSRD4fb7i0uie3ZVd3PQLa5T0tNLgK0Iz/ezaHJWl6FspiTCfrbkt+W3e9qJlM81TF/3wuZEha3CYp9R69juUoyqFddGsV+GLKfDLcHAI3CCVYcCLUHd8w8KAoOE7tttTds3mELRacHxmBsWxN9QTT+uWAxv7YIpZIqcxYIinLSaynRRIEGzIgwXjWERSgirqfXTKcfiCO6afIG7Tb7kem1wr79OvAiiNb/jqdD7AViVNicrFp+CcsUKjm/ZdKattsQ==
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=kSxo/hiZ8UsapqxobWJt/oXnNHZSj0Yrvm+mkFoP+2U=;
b=MjIvoBl2DS6SekqVwefrMGCD5T0OLtdFH9D8bTMQXXtpLEbNM8iAFjfdGNL5+JQkUe525rXQenEkkQwOvBmyX/0Zlj+iHUpJC0HKrhSb1fvGuQLC61psXZ75cQuUwDbJcD6PEQd1g8KLgnVYISPZcDbgFts4OZf6MXp4o34oLW8FSKdVIgMOb3ttW1IK5NpAzSvkD82Uh9MeZBS9vatekXIFkkumElQprUe8MmF2hkGpBzHeJG+vvGvAMt9Rdk2mlqBF2PuyriMWdS6GTuQjXYapiixKh0WksZTAsrAF1A47TRFxfGL+LtHhm72AwGypevaIAtnYNnvnRWMAUw4RJw==
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=kSxo/hiZ8UsapqxobWJt/oXnNHZSj0Yrvm+mkFoP+2U=;
b=sUY2UHlRCLj8xw9QU6/MC44LpFj5uKaw6y/YplJRUlLtFEBqdz+S8K6fN3/tDzwJG8eCBNBoaZfgcZCgafK25c5foB9XMCfGNXbwLp8L7/sUihN1IfUnli7Mr2tTbAIFeKEti7b8LQfr1EZdeqB26Ez3R2UNCnXX5hzb9hZB7wo=
Received: from BYAPR11MB3831.namprd11.prod.outlook.com (20.178.239.150) by
BYAPR11MB3366.namprd11.prod.outlook.com (20.177.185.84) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2623.13; Tue, 14 Jan 2020 11:01:55 +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.2623.017; Tue, 14 Jan 2020
11:01:55 +0000
From: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>
To: Shally Verma <shallyv@marvell.com>, Anoob Joseph <anoobj@marvell.com>,
Akhil Goyal <akhil.goyal@nxp.com>, "Doherty, Declan"
<declan.doherty@intel.com>, "De Lara Guarch, Pablo"
<pablo.de.lara.guarch@intel.com>
CC: Ayuj Verma <ayverma@marvell.com>, "Trahe, Fiona" <fiona.trahe@intel.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Narayana Prasad Raju Athreya
<pathreya@marvell.com>, Ankur Dwivedi <adwivedi@marvell.com>, Sunila Sahu
<ssahu@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH 1/4] lib/crypto: add support for ECDSA
Thread-Index: AQHVq2F/ClDDEhFhTkSJKuDq6QguHqfDOErwgBP02gCACyI9IIAGuR8AgADTMgCAAF9skA==
Date: Tue, 14 Jan 2020 11:01:54 +0000
Message-ID: <BYAPR11MB38310B33F4BD6B1DEE3199F09F340@BYAPR11MB3831.namprd11.prod.outlook.com>
References: <1575546206-2478-1-git-send-email-anoobj@marvell.com>
<1575546206-2478-2-git-send-email-anoobj@marvell.com>
<BYAPR11MB38310C19E20E2B5C053D53319F2D0@BYAPR11MB3831.namprd11.prod.outlook.com>
<MN2PR18MB28778E340EA10115FAC5C107DF200@MN2PR18MB2877.namprd18.prod.outlook.com>
<BYAPR11MB383168E327501263454C7DC79F390@BYAPR11MB3831.namprd11.prod.outlook.com>
<MN2PR18MB2877D4AEBB1A8314B117CBD2DF350@MN2PR18MB2877.namprd18.prod.outlook.com>
<BN8PR18MB2867F8671C3A080B091576C9AD340@BN8PR18MB2867.namprd18.prod.outlook.com>
In-Reply-To: <BN8PR18MB2867F8671C3A080B091576C9AD340@BN8PR18MB2867.namprd18.prod.outlook.com>
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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTVhNWJmMTAtMjdlNC00ZWFmLTk0MTQtZGJlZTgzYjY4NGE0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVFNZVWVcL1BJeXRVbzJSYytzelBubklhMm5GMGNtSHlhR0ozcjJveXo3Ynd0bjZ6aWhDcnZkMGNtSzV6ZW5CU2cifQ==
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: 68bdf51f-6042-440a-b3fc-08d798e12b15
x-ms-traffictypediagnostic: BYAPR11MB3366:
x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3366955FB6161EF426AF67029F340@BYAPR11MB3366.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 028256169F
x-forefront-antispam-report: SFV:NSPM;
SFS:(10019020)(346002)(39860400002)(136003)(396003)(376002)(366004)(199004)(189003)(33656002)(4326008)(6636002)(76116006)(2906002)(478600001)(81156014)(81166006)(8676002)(316002)(55016002)(9686003)(54906003)(66476007)(110136005)(71200400001)(8936002)(66556008)(186003)(66946007)(64756008)(86362001)(52536014)(7696005)(5660300002)(6506007)(26005)(66446008);
DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR11MB3366;
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: nwTWWhPfqodn7nmV696ZaEm9/A2zD4EuHrqiL67W2K5EbNwSc+ugsPma48Rj7s4/0KJzQB/vS4gE8Q++vA29kqIdS2BTvVVmiIgDAs7p2Eo6z5eEj8s4c7wSsJhzj2SCD/2yOx9Vr5iMWE9cd0ZDutYBR1wRPP09E8GW8YWVNfV0ztJSmveeSQgq3LWUKy/rMFRAcsPq4h0aHxo5Yw96BdEBn6hK9RJNqcJa+eGfah9d8IeRKBP+ic/ynOErMdSKA/0Pfs7gqBqMMOrpHcH1sNgeQlJk1dzHIIBO/ExooyR6ovBELFTSoNYKwldYm99Oik4vMqnENKXMoSQKkt8YCrkS8qZABe/0sg56Nv872ia4oyj+iyX2/goxrIZXX1dChTwSGEz1eIOb2HrswtPlHXThhipKhrumyB56R84UF5zx+/ddCe7A9sW33dDfFQEx
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 68bdf51f-6042-440a-b3fc-08d798e12b15
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 11:01:54.6395 (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: wFdha0q1VjaoJx9eeNKURW5foQ6WHTNIrk6tdr58dZlDJJC6W/gC1T19CruLM/z1gfNGjNBwR0TXelDoJ+buoYOpk/nZwZTDz5+UdYMDv1s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3366
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Hi guys,
> >
> > > >
> > > > > > +
> > > > > > + 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.d=
ata
> > > > > 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.
> >
> > > >
> > > > > 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 some 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
> > > 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?
> > Also, we can defer that discussion to a separate thread, if we have an
> > agreement on the approach here.
> >
> [Shally] Just a thought here. It can also be supported by exposing an API=
to
> application, like pre-compute / pre-setup which can generate 'k' or 'PRF'=
for
> other algo usage purpose. If PMD support it, return will be success with
> relevant o/p.. if not, return will be failure. Or no offload at all. In a=
ny case,
> generation of prf or 'k' is heavy on data path... app can call these pre-=
setup
> APIs to save cycles on actual sign op.
[AK] - We can start another thread on that. For now this implementation is =
good too, we can extend API by PMD CSRN option later.
>=20
> Shally
> > > >
> > > > >
> > > > > > +
> > > > > > + 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.
[AK] It is ok to me.
> >
> > > >
> > > > > > +};
> > > > > > +
> > > > > > +/**
> > > > > > * 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