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 596CDA046B for ; Thu, 25 Jul 2019 19:51:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A57251C395; Thu, 25 Jul 2019 19:51:39 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 746B31C38E for ; Thu, 25 Jul 2019 19:51:38 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2019 10:51:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,307,1559545200"; d="scan'208";a="254001385" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 25 Jul 2019 10:51:36 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jul 2019 10:51:36 -0700 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jul 2019 10:51:36 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.134]) by HASMSX110.ger.corp.intel.com ([169.254.6.153]) with mapi id 14.03.0439.000; Thu, 25 Jul 2019 20:51:33 +0300 From: "Kusztal, ArkadiuszX" To: Shally Verma , "Nowak, DamianX" , "dev@dpdk.org" CC: "Trahe, Fiona" , Ayuj Verma , Sunila Sahu , Kanaka Durga Kotamarthy , Anoob Joseph , "Narayana Prasad Raju Athreya" Thread-Topic: [dpdk-dev] [PATCH v5 1/1] test: new test structure for asymmetric crypto Thread-Index: AQHU5IKFVp7P4HphXkK8vll685vq76bbkpHggAApGCCAAA1c8IAABSkAgAB6QkCAABCpYA== Date: Thu, 25 Jul 2019 17:51:32 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B282F46@hasmsx109.ger.corp.intel.com> References: <20190326141549.16125-1-damianx.nowak@intel.com> <20190327094521.16414-1-damianx.nowak@intel.com> <20190327094521.16414-2-damianx.nowak@intel.com> <06EE24DD0B19E248B53F6DC8657831551B282BC2@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B282C78@hasmsx109.ger.corp.intel.com> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v5 1/1] test: new test structure for asymmetric crypto 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" > -----Original Message----- > From: Shally Verma [mailto:shallyv@marvell.com] > Sent: Thursday, July 25, 2019 6:52 PM > To: Kusztal, ArkadiuszX ; Nowak, DamianX > ; dev@dpdk.org > Cc: Trahe, Fiona ; Ayuj Verma > ; Sunila Sahu ; Kanaka Durga > Kotamarthy ; Anoob Joseph > ; Narayana Prasad Raju Athreya > > Subject: RE: [dpdk-dev] [PATCH v5 1/1] test: new test structure for > asymmetric crypto >=20 >=20 >=20 > > -----Original Message----- > > From: Kusztal, ArkadiuszX > > Sent: Thursday, July 25, 2019 3:08 PM > > To: Shally Verma ; Nowak, DamianX > > ; dev@dpdk.org > > Cc: Trahe, Fiona ; Ayuj Verma > > ; Sunila Sahu ; Kanaka > Durga > > Kotamarthy ; Anoob Joseph > > ; Narayana Prasad Raju Athreya > > > > Subject: RE: [dpdk-dev] [PATCH v5 1/1] test: new test structure for > > asymmetric crypto > > > > > > > > > -----Original Message----- > > > From: Shally Verma [mailto:shallyv@marvell.com] > > > Sent: Thursday, July 25, 2019 11:17 AM > > > To: Kusztal, ArkadiuszX ; Nowak, > > > DamianX ; dev@dpdk.org > > > Cc: Trahe, Fiona ; Ayuj Verma > > > ; Sunila Sahu ; Kanaka > > Durga > > > Kotamarthy ; Anoob Joseph > > > ; Narayana Prasad Raju Athreya > > > > > > Subject: RE: [dpdk-dev] [PATCH v5 1/1] test: new test structure for > > > asymmetric crypto > > > > > > > > > > > > > -----Original Message----- > > > > From: Kusztal, ArkadiuszX > > > > Sent: Thursday, July 25, 2019 2:06 PM > > > > To: Shally Verma ; Nowak, DamianX > > > > ; dev@dpdk.org > > > > Cc: Trahe, Fiona ; Ayuj Verma > > > > ; Sunila Sahu ; Kanaka > > > Durga > > > > Kotamarthy ; Anoob Joseph > > > > ; Narayana Prasad Raju Athreya > > > > > > > > Subject: RE: [dpdk-dev] [PATCH v5 1/1] test: new test structure > > > > for asymmetric crypto > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Shally Verma [mailto:shallyv@marvell.com] > > > > > Sent: Thursday, July 25, 2019 9:18 AM > > > > > To: Nowak, DamianX ; dev@dpdk.org > > > > > Cc: Trahe, Fiona ; Kusztal, ArkadiuszX > > > > > ; Ayuj Verma > > ; > > > > > Sunila Sahu ; Kanaka Durga Kotamarthy > > > > > ; Anoob Joseph ; > > > > Narayana > > > > > Prasad Raju Athreya > > > > > Subject: RE: [dpdk-dev] [PATCH v5 1/1] test: new test structure > > > > > for asymmetric crypto > > > > > > > > > > Hi Damian, Fiona, Arek > > > > > > > > > > Though am bit late to come back to this. But I have question on > > > > > mod_exp test vector. > > > > > Please see below. > > > > > > > > > > > -----Original Message----- > > > > > > From: dev On Behalf Of Damian Nowak > > > > > > Sent: Wednesday, March 27, 2019 3:15 PM > > > > > > To: dev@dpdk.org > > > > > > Cc: fiona.trahe@intel.com; arkadiuszx.kusztal@intel.com; > > > > > > Damian Nowak > > > > > > Subject: [dpdk-dev] [PATCH v5 1/1] test: new test structure > > > > > > for asymmetric crypto > > > > > > > > > > > > This patch adds new test structure for modexp and modinv for > > > > > > asymmetric cryptography > > > > > > > > > > > > Signed-off-by: Damian Nowak > > > ... > > > > > > > > > +static const struct > > > > > > +modex_test_data modex_test_case[] =3D { { > > > > > > + .description =3D "Modular Exponentiation " > > > > > > + "(mod=3D128, base=3D20, exp=3D3, > > res=3D128)", > > > > > > + .xform_type =3D RTE_CRYPTO_ASYM_XFORM_MODEX, > > > > > ... > > > > > > + .modulus =3D { > > > > > > + .data =3D { > > > > > > + 0xb3, 0xa1, 0xaf, 0xb7, 0x13, 0x08, 0x00, > 0x0a, > > > > > There's already a testvector mod_p[] in file with leading 0. > > > > > Where as I see this one duplicate of that but without leading 0. > > > > > Could you tell me if you ever tested with mod_p[] with leading 0 > > > > > and if your qat PMD passed that? > > > > > > > > [AK] - Hi Shally, > > > > The problem with this vector is that it has 1024bit long number > > > > but > > > > sizeof(mod_p) Is 129 bytes (1032 bit). > > > > It is no problem for QAT to get correct result, but test will fail > > > > because QAT PMD will return 129 bytes of date (with leading zero, > > > > number right-shifted) so comparison will fail. This is the same > > > > question as > > > padding NONE for RSA. > > > > Should we trim zeroes, or shouldn't we. > > > [Shally] Ya. Now, I correlate changes that you proposed to another > > > RSA xform patch. Because Spec simply expect Key input as positive > > > integer and does not know if its DER formatted input. > > > > > > So, I have one question here: How QAT is handling leading 0? Do you > > > pass data as is to HW with 0 in it and it is still able to produce > > > correct result for you? > > [AK] - We pass as is (with 0), it will still produce correct result > > (4096 bits are size upper limit for QAT currently). So there may be > > any number of leading zeroes up to 512bytes, and we don't care. Right > > now there are discrepancies between OPENSSL and QAT in that as QAT > > will return shifted data and OPENSSL will not, we need to choose one wa= y > or other. > [Shally] "shifted data" mean? Can you help clarify with some example here= ? Sure. Let use aforementioned vector in test_mod_exp. Size of result is equa= l to sizeof(mod_p) so 129 bytes but number is 128 bytes long. So result[0] = =3D 0, result[1] =3D 0x2C, result[128] =3D 0x5A. >=20 > > > > Or, you take care in PMD to remove it and then append it back later > > at > > > o/p? > > > In case, you pass to HW, then does all bytes after 0 store correct o/= p? > > > > > > > > > > > > > > + 0x35, 0xdc, 0x2b, 0x20, 0x8d, 0xa1, 0xb5, > > 0xce, > > > > > > + 0x47, 0x8a, 0xc3, 0x80, 0xf4, 0x7d, 0x4a, > 0xa2, > > > > > > + 0x62, 0xfd, 0x61, 0x7f, 0xb5, 0xa8, 0xde, > 0x0a, > > > > > > + 0x17, 0x97, 0xa0, 0xbf, 0xdf, 0x56, 0x5a, > 0x3d, > > > > > > + 0x51, 0x56, 0x4f, 0x70, 0x70, 0x3f, 0x63, > 0x6a, > > > > > > + 0x44, 0x5b, 0xad, 0x84, 0x0d, 0x3f, 0x27, > > 0x6e, > > > > > > + 0x3b, 0x34, 0x91, 0x60, 0x14, 0xb9, 0xaa, > > 0x72, > > > > > > + 0xfd, 0xa3, 0x64, 0xd2, 0x03, 0xa7, 0x53, > 0x87, > > > > > > + 0x9e, 0x88, 0x0b, 0xc1, 0x14, 0x93, 0x1a, > 0x62, > > > > > > + 0xff, 0xb1, 0x5d, 0x74, 0xcd, 0x59, 0x63, > 0x18, > > > > > > + 0x11, 0x3d, 0x4f, 0xba, 0x75, 0xd4, 0x33, > > 0x4e, > > > > > > + 0x23, 0x6b, 0x7b, 0x57, 0x44, 0xe1, 0xd3, > > 0x03, > > > > > > + 0x13, 0xa6, 0xf0, 0x8b, 0x60, 0xb0, 0x9e, > > 0xee, > > > > > > + 0x75, 0x08, 0x9d, 0x71, 0x63, 0x13, 0xcb, > 0xa6, > > > > > > + 0x81, 0x92, 0x14, 0x03, 0x22, 0x2d, 0xde, > 0x55 > > > > > > + }, > > > > > > + .len =3D 128 > > > > > > + }, > > > > > > + .result_len =3D 128 > > > > > > +}, > > > > > .... > > > > > > /* modular operation test data */ uint8_t base[] =3D { > > > > > > 0xF8, 0xBA, 0x1A, 0x55, 0xD0, 0x2F, 0x85, > > > > > > -- > > > > > > 2.7.4