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 95ACAA0471 for ; Wed, 17 Jul 2019 12:41:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A0BF1DBF; Wed, 17 Jul 2019 12:41:05 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 248E21DBE for ; Wed, 17 Jul 2019 12:41:03 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2019 03:41:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,274,1559545200"; d="scan'208";a="167928540" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga008.fm.intel.com with ESMTP; 17 Jul 2019 03:41:02 -0700 Received: from fmsmsx162.amr.corp.intel.com (10.18.125.71) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jul 2019 03:41:02 -0700 Received: from lcsmsx153.ger.corp.intel.com (10.186.165.228) by fmsmsx162.amr.corp.intel.com (10.18.125.71) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jul 2019 03:41:01 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.134]) by LCSMSX153.ger.corp.intel.com ([169.254.8.138]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 13:40:59 +0300 From: "Kusztal, ArkadiuszX" To: Shally Verma , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "Trahe, Fiona" Thread-Topic: [EXT] [PATCH v3 09/11] cryptodev: add RSA padding none description Thread-Index: AQHVPAfJOEpKFSXB7Ea8OBVmBcM7A6bOZ24AgAA1USA= Date: Wed, 17 Jul 2019 10:40:59 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B280942@hasmsx109.ger.corp.intel.com> References: <20190716185304.12592-1-arkadiuszx.kusztal@intel.com> <20190716185304.12592-10-arkadiuszx.kusztal@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] [EXT] [PATCH v3 09/11] cryptodev: add RSA padding none description 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: Wednesday, July 17, 2019 12:18 PM > To: Kusztal, ArkadiuszX ; dev@dpdk.org > Cc: akhil.goyal@nxp.com; Trahe, Fiona > Subject: RE: [EXT] [PATCH v3 09/11] cryptodev: add RSA padding none > description >=20 >=20 >=20 > > -----Original Message----- > > From: Arek Kusztal > > Sent: Wednesday, July 17, 2019 12:23 AM > > To: dev@dpdk.org > > Cc: akhil.goyal@nxp.com; fiona.trahe@intel.com; Shally Verma > > ; Arek Kusztal > > Subject: [EXT] [PATCH v3 09/11] cryptodev: add RSA padding none > > description > > > > External Email > > > > ---------------------------------------------------------------------- > > This patch adds RSA padding none description. > > > > Signed-off-by: Arek Kusztal > > --- > > lib/librte_cryptodev/rte_crypto_asym.h | 10 +++++++++- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h > > b/lib/librte_cryptodev/rte_crypto_asym.h > > index 5026042..7f630f0 100644 > > --- a/lib/librte_cryptodev/rte_crypto_asym.h > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h > > @@ -90,7 +90,10 @@ enum rte_crypto_asym_xform_type { > > */ > > enum rte_crypto_asym_op_type { > > RTE_CRYPTO_ASYM_OP_ENCRYPT, > > - /**< Asymmetric Encrypt operation */ > > + /**< RSA no padding scheme. > > + * In this case user is responsible for provision and verification > > + * of padding. > > + */ > > RTE_CRYPTO_ASYM_OP_DECRYPT, > > /**< Asymmetric Decrypt operation */ > > RTE_CRYPTO_ASYM_OP_SIGN, > > @@ -409,6 +412,11 @@ struct rte_crypto_rsa_op_param { > > * - padding PSS > > * data provided should contain message digest of the message > > * to be signed > > + * > > + * When padding field is set to RTE_CRYPTO_RSA_PADDING_NONE > > + * and RTE_CRYPTO_ASYM_OP_DECRYPT op_type used returned > > data size > > + * will be equal to the size of RSA key in bytes. All leading > > + * zeroes will be preserved. > [Shally] its bit unclear here. So, app is supposed to pass buffer with pa= dding > removed or padding intact? Are leading 0's padding bytes? > If so, I believe app can use any kind of padding, BT2 or OAEP so it does = not > have to be necessarily 0. Or May be I am missing some info here. Could yo= u > point me to source which says, for padding none, data will always be padd= ed > with leading 0s? >=20 OEAP, PKCS1_5 have leading zero. Example: We decrypt message that was encrypted using pkcs1_5 padding but we use PADD= ING_NONE (let say pmd does not support others). We decrypted P =3D (0x0 | 0= x02 | PS| 0x0 | Message) then user would use some padding check function l= et say openssl RSA_padding_check_PKCS1_type_2. This function will fail if f= irst byte (p[0]) is not equal to zero. So we cannot trim. Openssl behaves e= xactly this way so does our driver. It is only hint that zeroes should not = be trimmed. > > */ > > > > > > -- > > 2.1.0