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 C48F2A0487 for ; Sun, 30 Jun 2019 11:07:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CC3F35424; Sun, 30 Jun 2019 11:07:36 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 72E8C326D for ; Sun, 30 Jun 2019 11:07:35 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5U97Is3000851; Sun, 30 Jun 2019 02:07:34 -0700 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=A0GBGZiAwm/xe1TKYdGbRlm2ALGtwf2eZuRTKv32At8=; b=DsZ/peHMlcwZsBmpco3IB3fjgB8nCE9pOg+BSA1jYYsw3/HFFwnT/USLbPCij6iKjU2K NG0q7NfYMkFKFyUW+2Pucea7j4UIbOc4Ps24TYnl0CzsbWMT4devEsUR4TYxm6/pgGI9 7aScqagunhT7rscXrF0qP0R/9VvgUHhUD243HK73iiS2zjvnulpmbDaB1qqfkcJJ6k93 hZnaqomUKX0bKRhyqzzQDMK6pp12KIUTW4fQ1fc+CM3uiJOKGzG0iwmggkgwgG8c8RR/ XX7LEaxK/U9Cik5aKjXqmtBBey3GvJf+vpUNLmq31U8SZJhDc4G2HgvX8w99s6EMON8G aA== Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0a-0016f401.pphosted.com with ESMTP id 2te5bn37c6-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 30 Jun 2019 02:07:34 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 30 Jun 2019 02:07:33 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.53) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Sun, 30 Jun 2019 02:07:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A0GBGZiAwm/xe1TKYdGbRlm2ALGtwf2eZuRTKv32At8=; b=Drm1kGZAgJRbkSHEthAWm0O0/TQG7T8pPt0e94BKrfMUg+EMOIbEgNKpjwszotyRo/uKseMXSgjPhfXQAqj+KX3E4O1GtfueZOxBarVoOOHn8GoUPifN26ZQoJPdEIrbn1y+omFrUXTYZxn7RmlrS4eO4y9SnnOyytUJrqKk3NQ= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB2020.namprd18.prod.outlook.com (10.161.154.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.18; Sun, 30 Jun 2019 09:07:28 +0000 Received: from BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::b9c4:1fd1:a47e:cd72]) by BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::b9c4:1fd1:a47e:cd72%6]) with mapi id 15.20.2032.019; Sun, 30 Jun 2019 09:07:28 +0000 From: Shally Verma To: "Trahe, Fiona" , "Kusztal, ArkadiuszX" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "shally.verma@caviumnetworks.com" Thread-Topic: [EXT] [PATCH 1/3] cryptodev: rework api of rsa algorithm Thread-Index: AQHVF7hRoz4n0ySUf0GU5mbe3lbKjaaM2l1wgBIOMwCAEoyQAIACnALw Date: Sun, 30 Jun 2019 09:07:27 +0000 Message-ID: References: <20190531135231.10836-1-arkadiuszx.kusztal@intel.com> <20190531135231.10836-2-arkadiuszx.kusztal@intel.com> <06EE24DD0B19E248B53F6DC8657831551B26AC6B@hasmsx109.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435897A7DF1@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B435897A7DF1@IRSMSX101.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1268740a-620a-4e72-a34e-08d6fd3a601e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR1801MB2020; x-ms-traffictypediagnostic: BN6PR1801MB2020: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008421A8FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(396003)(39850400004)(376002)(346002)(13464003)(199004)(189003)(478600001)(14454004)(561944003)(7520500002)(316002)(54906003)(33656002)(186003)(55236004)(4326008)(99286004)(25786009)(26005)(86362001)(2906002)(53546011)(6506007)(2501003)(74316002)(66066001)(102836004)(76176011)(8676002)(229853002)(7696005)(81166006)(81156014)(446003)(11346002)(68736007)(6246003)(476003)(52536014)(9686003)(71200400001)(8936002)(14444005)(256004)(6436002)(3846002)(7736002)(71190400001)(486006)(53936002)(6116002)(5660300002)(110136005)(305945005)(55016002)(66476007)(66946007)(66446008)(76116006)(66556008)(64756008)(73956011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB2020; H:BN6PR1801MB2052.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-message-info: ysmMAj1loNWJ+Iu9G5TKKhvwWyO00FlXsGakwZfUSDu5D1I3hYfNmajhdvBv/f/Obg7TsfsiI6yy8O3xrzDc8ISMkkSjWusoFuXVoTOJJkDOtXN5C531kQ8cu3kVg/qGHj4+OmJHyN5J9LdG8nrpA4mwk+Pk+o6fgkVngKHBtemLW9lcFQXh3oMBOJagYfAOS0WZh26IoAvNyD5QKoI99w1WzV5FbnNUxJ1CcN3rKwNJCoeOFG4ky5K2HZaCHejtQVLyAawqmKnbPmZQFmqsksHEeHho3zbuQ45qPRrZ3QE0uf9qjC7jvhIY7Xq5yqkR4FgDJZ+/+NK4UK2HE/D7guEZgSozz8Zo4zyxeZNhrh3InnNdJ9OrsbDHh7ZVTLi2Ifz+ETQcaT5vi/wDdC/f2KlVL7fT/aiWxRMrdPeNwDg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1268740a-620a-4e72-a34e-08d6fd3a601e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2019 09:07:27.9686 (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: shallyv@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1801MB2020 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-30_03:, , signatures=0 Subject: Re: [dpdk-dev] [EXT] [PATCH 1/3] cryptodev: rework api of rsa algorithm 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: Trahe, Fiona > Sent: Friday, June 28, 2019 10:25 PM > To: Kusztal, ArkadiuszX ; Shally Verma > ; dev@dpdk.org > Cc: akhil.goyal@nxp.com; shally.verma@caviumnetworks.com; Trahe, Fiona > > Subject: RE: [EXT] [PATCH 1/3] cryptodev: rework api of rsa algorithm >=20 > Hi Arek, Shally, >=20 > Comments below. > @Arek, I'd suggest sending a v2 after this, updated with whatever issues = can > be closed and a listing of the issues still open. > As getting hard to follow the thread. > @Shally, can you reply please - just with whatever items below you're ok > with, so Arek can do the v2. > And we can continue discussion on the v2 on anything still open. >=20 ... > > > > --- a/lib/librte_cryptodev/rte_crypto_asym.h > > > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h > > > > @@ -111,23 +111,33 @@ enum rte_crypto_asym_op_type { > > > > */ > > > > enum rte_crypto_rsa_padding_type { > > > > RTE_CRYPTO_RSA_PADDING_NONE =3D 0, > > > > - /**< RSA no padding scheme */ > > > > - RTE_CRYPTO_RSA_PKCS1_V1_5_BT0, > > > > - /**< RSA PKCS#1 V1.5 Block Type 0 padding scheme > > > > - * as described in rfc2313 > > > > - */ > > > > - RTE_CRYPTO_RSA_PKCS1_V1_5_BT1, > > > > - /**< RSA PKCS#1 V1.5 Block Type 01 padding scheme > > > > - * as described in rfc2313 > > > > - */ > > > > - RTE_CRYPTO_RSA_PKCS1_V1_5_BT2, > > > > - /**< RSA PKCS#1 V1.5 Block Type 02 padding scheme > > > > - * as described in rfc2313 > > > > + /**< RSA no padding scheme. > > > > + * In this case user is responsible for providing and verificatio= n > > > > + * of padding. > [Fiona] Grammar: provision not providing >=20 > > > > + * In case RTE_CRYPTO_ASYM_OP_VERIFY op type is used if no > > > > + * problems in public key 'encryption' detected driver SHALL retu= rn > > > > + * RTE_CRYPTO_OP_STATUS_SUCCESS. > > > > > > [Shally] This is not clear to me. OP_VERIFY is public key > > > decryption, then why it is mentioned as 'encryption' above? > > > > [AK] - yes, you right 'decryption', public key but technically decrypti= on. > > > Secondly, Any public/private key encryption with NO_PADDING scheme, > > > would result in encryption data without any padding string. > > > And, if same is passed to PMD for decryption with PADDING_NONE, then > > > PMD would assume encryption block is without any padding string. > > > So, which case are we trying to clarify here? Or, do you intend to > > > mention case when app can pass data with padding for decryption with > > > NO_PADDING scheme? > > > > [AK] Yes. It may be common situation that HW drivers wont natively be > > doing any padding, Especially PSS and OAEP which expects very strong > > TRNG. NO_PADDING would mean that driver should not be responsible for > > padding, and not care what is in there as long as parameters are correc= t. > [Fiona] just to add to that - PADDING_NONE typically really means > PADDING_DONE_BY_APPLICATION But using the NONE terminology is > consistent with openssl lib, so I think we should stick with that. >=20 [Shally] I look forward to v2 to comment further on this. ... > > > > [AK] About BT 00 it is nothing else than zero padding, plaintext RSA, > > more or less the same thing as NO_PADDING. It has been silently > > abandoned long time ago. Only RFC 2313 mentions it. No 2437,3447 and > 8017. > [Fiona] Actually as PKCS#1 v1.5 is less secure for encryption than OAEP, > arguably it should be removed too from this enum to discourage its use. > However as it's still commonly used we need to keep it. We should make > sure that capability allows a PMD to opt out of supporting it if it choos= es to > only support PSS and OAEP. >=20 [Shally] We have been practically using it , so I can say it is still very = much in use. we can update capability to check for supported padding type if PMD does no= t support all.=20 Regarding BT0 did we conclude to remove BT0 as practically not in use and t= hen we're using PKCS _V1.5 only. If yes, am fine with this. > > .... > > > [Shally] Better to add version V2 here: RSA PKCS#1 V2 OAEP padding > > > scheme > > > > [AK] Usually V2 is not added to it. Example from openssl " > > RSA_padding_add_PKCS1_OAEP", > [Fiona] Agree with Arek, better to leave out v2. >=20 [Shally] Okay. Agree to both Arek, Fiona here.=20 ... > > > > > > >Returned data is in Big-Endian format which means > > > > + * that Least-Significant byte will be placed at top byte of an a= rray > > > > + * (at message.data[message.length - 1]), cipher.length SHALL > > > > + * therefore remain unchanged. > > > > > > [Shally] Do we really need to mention it? > > > > [AK] I have not pronounced myself very clear here, and I forgot to add = it to > the message data. > > For example we have 256 bytes allocated for RSA-2048 let say > > decryption. But we decrypted only 255 bytes (one leading zero). > > So should we trim this zero or not? If we trim, size is 255 and > > data[0] is some non zero byte. If we don't, size if 256 and data[0]=3D0= . > > One leading zero is a good example of PKCS1 padding. > > [Shally] Output of RSA public/private key encryption operation is length of= modulus. So it should return 256 length output here as is and let app use that. > > > > > > > + > > > > + struct { > > > > + enum rte_crypto_rsa_padding_type type; > > > > + /**< > > > > + * In case RTE_CRYPTO_RSA_PADDING_PKCS1 is selected, > > > > + * driver will distinguish between block type basing > > > > + * on rte_crypto_asym_op_type of the operation. > > > > + * > > > > + * Which padding type is supported by the driver SHALL be > > > > + * available in in specific driver guide or capabilities. > > > > + */ > > > [Shally] you mentioned it as part of capability, but this patch does > > > not have any capa struct changes to return this. So do you mean > > > capability or PMD release note here? > > > > [AK] - this would be part of v2. Thanks. [Shally] Okay. .... > > > > + * If RTE_CRYPTO_HASH_INVALID is set, driver default will be > > > > set. > > > > + * If RTE_CRYPTO_HASH_NONE is set, message will be signed > > > > as it is. > > [AK] - provided message fits into key size. > > > > > > [Shally] who will set it? PMD or application? Its bit unclear here > > > where and when it will be set to INVALID / NONE? > > > > [AK] PMD according to its default. Still only a proposal. [Shally] Okay. I look forward further discussion on this in v2. ... > > > [Shally] having additional struct padding within op_param looks > unnecessary. > > > Why do we need to rearrange it like this? It can simply be: > > > > [AK] - its proposal, to discuss I think. [Shally] I believe not needed though but look forward to v2 for further dis= cussion. ... Thanks Shally > > > > 2.1.0