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 D435BA04FD; Tue, 14 Jan 2020 06:12:40 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6B1781C2AE; Tue, 14 Jan 2020 06:12:40 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 69AF91C2AD for ; Tue, 14 Jan 2020 06:12:38 +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 00E5AU6a029136; Mon, 13 Jan 2020 21:12:37 -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=CslMnbR13bfYVrimrvxW/J4fpKq1y5NYwkMIeH1gayA=; b=Q96ILRUE3Ep0yA/6I/jhuEVBmyIxfTEqN47N/+yOoRP+LfemtKIm1aboFjGajVDD40kd /tGUNnK4rJoJA6Y3S/1+t1+VGijxwnjlBDkIKs0CwPlDF8kSj6id62MIOsPmGT4aTUFN vy3pHfLJ+FDoS8GqIO4gdwNhdf65bC+FT8RspSU03UJKcf+k7rXveI/eqMr/NPt/n5TC Tr9E6OGlSeT0l8/wLsuRBmpTXgWvoBlY//fr0bZsgFicpJqnmJM5CmT9W1msD7jA1e2Z rptbXv7lEoDAYvUhlAYnoErJ6l561zfEsi46Gx3iXjtiPWX1P3AwdWlJ9IPkZGAwh8Ae /w== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2xfckurqhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 13 Jan 2020 21:12:37 -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; Mon, 13 Jan 2020 21:12:35 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.109) 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 21:12:35 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VEYWp6qFFpv1cpBgywsqamKGobtMyHWP6Tnymao/wEnNLrruZLc+H2wZNZCnmK5XgveZIm1rtZysYa1eU5McFJBEFGe3YXabS28QifvkO7LBWLqr3HHIGuXhqfoi/5hOUXKFc99oko941/3mfgSf8l+msNL02szqMhF8Gf6kabaTABJ67+a6T72ccIkq8l2UMdS7sQXSSJAekT/BLZhdx2WxID77WyA5fdC+Uhm/MmMCt/Q7uOqoxGUhsjSdUNgSM1cu3hMAvq20sBZPm7xUZFj3VK2mjftBNEuROask1rbQwk6YrzClnwVX7iXuPGOiF8wkCRS9ABDqIWigif123w== 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=CslMnbR13bfYVrimrvxW/J4fpKq1y5NYwkMIeH1gayA=; b=h4y82h4nQIvcVP3QFQNev0gHiTHn4Ja23Hc5aL0I/SNKCdgXth5e8NXt6wsIgv8OJEMwmn0T22R5wI/Ll5yO4NXejRuzwaBd0raQ+Bsr2sj2ZQtgmI/zv12vtjE71sx6DRPNVCiQflYfZb6+iYz6Q4NnUOPM7O1B3KKuF9b4H9smqsWqhPSLD2ARzoWsAwDKXEpO/pRjV0hOhg8OF633f1/7kYuxBWeP8XbHoJIoQI6dhO8iOxYU+ZwKBtzMWQ7nE1nX5v3rL6Yn4IupE1iaGMSWxOZl80kIwEKHIO0c2e2Y9IdmTn2puktlneFrpgbm4MdWi32QqpqClDEWyKfQSA== 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=CslMnbR13bfYVrimrvxW/J4fpKq1y5NYwkMIeH1gayA=; b=uWPze5JTHMdPYKSNyy8EJsWwXNco8+K3gJDirNOw8TFf1Ldfcpcs/iyaaYKpUdZBMQwbccVcNybA9+jjNkKvOOVPFFw/VjJPChS4UYx6G7DYOTNatE7w1lRXomhxjbe6x0ZafkCzspgLAARzm6pZK8/BfUMxevYSTH1SZ8O/n1E= Received: from BN8PR18MB2867.namprd18.prod.outlook.com (20.179.72.89) by BN8PR18MB2452.namprd18.prod.outlook.com (20.178.223.204) 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 05:12:34 +0000 Received: from BN8PR18MB2867.namprd18.prod.outlook.com ([fe80::cd4f:93a0:2523:ff69]) by BN8PR18MB2867.namprd18.prod.outlook.com ([fe80::cd4f:93a0:2523:ff69%5]) with mapi id 15.20.2623.015; Tue, 14 Jan 2020 05:12:34 +0000 From: Shally Verma To: Anoob Joseph , "Kusztal, ArkadiuszX" , Akhil Goyal , "Doherty, Declan" , "De Lara Guarch, Pablo" CC: Ayuj Verma , "Trahe, Fiona" , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Ankur Dwivedi , Sunila Sahu , "dev@dpdk.org" Thread-Topic: [PATCH 1/4] lib/crypto: add support for ECDSA Thread-Index: AQHVq2FkZOWtmE2mHE2drt+YAjPhwafDR/CAgBPlNACAC1aIAIAGhNQAgADRrNA= Date: Tue, 14 Jan 2020 05:12:34 +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: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b004f07f-6987-4276-cb80-08d798b05d47 x-ms-traffictypediagnostic: BN8PR18MB2452: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(376002)(366004)(199004)(189003)(81156014)(76116006)(2906002)(9686003)(55016002)(8676002)(81166006)(4326008)(478600001)(316002)(33656002)(186003)(110136005)(71200400001)(8936002)(66556008)(55236004)(66946007)(54906003)(86362001)(5660300002)(66446008)(52536014)(64756008)(26005)(7696005)(66476007)(6506007)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR18MB2452; H:BN8PR18MB2867.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: JiTQ6qA8l591YJY7kRFMQO3/ytWJ37krKgrjCDKkuKni5UgTiYkD750C58/n/3iQVazY0YtAsquEOqv4ArdE7kKTDs6txdY7zfc/rP1nj/FL4AW0p4yCat8apLa1u4qUyyPgN+cgM1l7isQXdnMARjymlNv2W/boFinktX2ocVKoQRp6YC1JDZWkxEd1QWWGQQdwAnaRzBKo9RX2TDSfFCgdUO2DbNZU+kj8sJJcUeq5HQmN+4np1xWiwpvfzpIcBM5+l8MDRjHuUrFA/6hgdygmOwXSR5PqubqP7ORj2aKJnk40CHQwkYxg8Bk57MgQ8EinxUHL54mirdmCP5jFZnhtYvpAnQTuH1Yd+AIm9+oQNqMb877Jn8LulfHRddiqcd824+SdwfJWh5F3nOEuZtgb0mkeT1k8YpMhLNInJp90wOOACRAQhL6f3LGzWo1+ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b004f07f-6987-4276-cb80-08d798b05d47 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 05:12:34.0867 (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: 2UFgDDw8GjF58o8z8NSxqbNIC+bo6YI4IY2U0wQBoMb/HpUNJk69KCxeGiyUFWL432jFCiop02xvnTNIkk4NkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR18MB2452 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-13_08: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 Anoob, Akhil > -----Original Message----- > From: Anoob Joseph > Sent: Monday, January 13, 2020 10:07 PM > 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 .... >=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 l= ike: > > > > 'if k.data =3D=3D NULL =3D> PMD will generate 'k' internally, k.dat= a > > > > 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. >=20 > [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 some hw can do DSA/ECDSA by generating 'k' by itself it would have t= o be > added anyway. > > Other option is to add aforementioned callbacks (for HW that not genera= te > 'k' > > by itself) >=20 > [Anoob] I think we can support either case. Our h/w also can generate CSR= N > 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. >=20 [Shally] Just a thought here. It can also be supported by exposing an API t= o 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 wi= th relevant o/p.. if not, return will be failure. Or no offload at all. In = any case, generation of prf or 'k' is heavy on data path... app can call th= ese pre-setup APIs to save cycles on actual sign op. 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. >=20 > [Anoob] How about updating the description of 'rte_crypto_param' to refle= ct > 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