From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 771CAA0096 for ; Wed, 5 Jun 2019 14:12:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D9DD1B9F8; Wed, 5 Jun 2019 14:12:38 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 544BF1B9F4 for ; Wed, 5 Jun 2019 14:12:36 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x55C4K3g013053; Wed, 5 Jun 2019 05:12:35 -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=GqF9JkGkMHuoo5hgKYlFZjof1CV30B+/KWxWQSAq8rQ=; b=Cbla+57IDCkNO+YwS/3EfzssHaEF3rQFmLP5RaurgtcMwTA2BcLe46gJZ0OuFGzAcY2l ZRRpzRUi5Vivwmt1iK4P4KXGqZzd9jRc0ETi+oAIOe+fbVwLnUufQt64WoTJNhenHKUb +26pOofvs8RUDblz3TrGl8tXjUdTJz4Q88dkpiPFmXlHY5K1V9zyhmMIMde3QClw6VeB n7/80oeQnUA8IdPl7o5tZnM5TmII50gfzNCQ51UlESscAUnODjIFvguylp+tSvm/7iXb AkZ86Xz0xtyCfuEZo+/ZpbR4lvAlb7WMM4QbycfvUQ7ANaRQ9V2bCaoWho2kBwDUOfmJ Og== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 2sx3kf9yxg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 05 Jun 2019 05:12:35 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 5 Jun 2019 05:12:32 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.53) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 5 Jun 2019 05:12:32 -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=GqF9JkGkMHuoo5hgKYlFZjof1CV30B+/KWxWQSAq8rQ=; b=hjJkVUIQi+1RXSzRul7sceMgZyDcd4CO5zo8f5F0fKTHmnGTjK0bLNruVVUhYRPhTV94kGzAVZLLHiMIXfkO1LbTKO2S3MiU8g6/sPvfm+Lhmn6519FwnwueXmooqLl0siBoqkJas5xvi2K7MucJh3b/v5mrb82mFx6n4P9mQzE= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB1859.namprd18.prod.outlook.com (10.161.154.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.13; Wed, 5 Jun 2019 12:12:26 +0000 Received: from BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::9170:db9e:4ac1:f76e]) by BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::9170:db9e:4ac1:f76e%5]) with mapi id 15.20.1943.018; Wed, 5 Jun 2019 12:12:26 +0000 From: Shally Verma To: Arek Kusztal , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "fiona.trahe@intel.com" , "shally.verma@caviumnetworks.com" Thread-Topic: [EXT] [PATCH 1/3] cryptodev: rework api of rsa algorithm Thread-Index: AQHVF7hRoz4n0ySUf0GU5mbe3lbKjaaM2l1w Date: Wed, 5 Jun 2019 12:12:26 +0000 Message-ID: References: <20190531135231.10836-1-arkadiuszx.kusztal@intel.com> <20190531135231.10836-2-arkadiuszx.kusztal@intel.com> In-Reply-To: <20190531135231.10836-2-arkadiuszx.kusztal@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [223.230.109.201] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a545bdb6-10a3-4e91-c006-08d6e9af12ec x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR1801MB1859; x-ms-traffictypediagnostic: BN6PR1801MB1859: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(39860400002)(376002)(366004)(346002)(189003)(199004)(13464003)(446003)(11346002)(25786009)(476003)(5660300002)(9686003)(55016002)(86362001)(6436002)(486006)(71200400001)(71190400001)(53936002)(14454004)(74316002)(102836004)(4326008)(26005)(7736002)(229853002)(305945005)(53546011)(478600001)(6506007)(7696005)(76176011)(81166006)(8676002)(81156014)(14444005)(66066001)(8936002)(256004)(2501003)(99286004)(186003)(30864003)(54906003)(110136005)(6246003)(2906002)(52536014)(316002)(68736007)(76116006)(73956011)(66946007)(3846002)(33656002)(6116002)(66446008)(64756008)(66556008)(66476007)(473944003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB1859; H:BN6PR1801MB2052.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 2lMJdUNCQTj7ZF5GF86XHYKAJUIWpUWonGDK5W4tjBzvo6kyvDf/jh85iubsT3WFPnInKnMIekZiDelji6Ig7fk7VuJWe1zUQnl3KH1v7g7T7xMw2N2ZovdawfS0Co+sEC8fo3Ur347Rcorx8amZ+GCpFgTNhYK5wKcpd8Ws3atAvTJT/FzeeeHne6wKdHHKlAX99EKWCJeW73mer1+42Qgm2d1cX8H4CSrROtHrDa04Od1ujccv+NesSUfwVTeb3vnJtwEmvrOKUHzNpulhOmOSgtpVhxjKMwESjbh5NKZ6ppm1/cu4Tk3BZYNVrjGvwA33dEa5JQLxatCSVhg7jWq0N4xnu7Qqc11oDlMnTM/yzGHlOwhCHc94b5RO6EsZCIv5EnUOzEXcr8J/PkTTndMWi0eanIT3e6m9S+xpFIc= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a545bdb6-10a3-4e91-c006-08d6e9af12ec X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 12:12:26.4278 (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: BN6PR1801MB1859 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-05_07:, , 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" Hi Arek, > -----Original Message----- > From: Arek Kusztal > Sent: Friday, May 31, 2019 7:22 PM > To: dev@dpdk.org > Cc: akhil.goyal@nxp.com; fiona.trahe@intel.com; > shally.verma@caviumnetworks.com; Arek Kusztal > > Subject: [EXT] [PATCH 1/3] cryptodev: rework api of rsa algorithm >=20 > External Email >=20 > ---------------------------------------------------------------------- > This patch reworks API of RSA algorithm. > Major changes: > - Cipher field was introduced > - Padding struct was created > - PKCS1-v1_5 Block type 0 was removed > - Fixed comments about prime numbers >=20 > Signed-off-by: Arek Kusztal > --- > lib/librte_cryptodev/rte_crypto_asym.h | 149 > +++++++++++++++++++++++++-------- > 1 file changed, 114 insertions(+), 35 deletions(-) >=20 > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h > b/lib/librte_cryptodev/rte_crypto_asym.h > index 8672f21..bb94fa5 100644 > --- 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 verification > + * of padding. > + * In case RTE_CRYPTO_ASYM_OP_VERIFY op type is used if no > + * problems in public key 'encryption' detected driver SHALL return > + * 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? Secondly, Any public/private key encryption with NO_PADDING scheme, would = result in encryption data without any padding string.=20 And, if same is passed to PMD for decryption with PADDING_NONE, then PMD wo= uld assume encryption block is without any padding string.=20 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 sch= eme? > But it is USER > RESPONSABILITY to > + * remove padding and verify signature. > + */ > + RTE_CRYPTO_RSA_PADDING_PKCS1, > + /**< RSA PKCS#1 PKCS1-v1_5 padding scheme. For signatures block > type 01, > + * for encryption block type 02 are used. [Shally] Though I understand PKCS1_V1.5 dictates the use of specific BT for= pub/private key encryption/decryption, So, seems we are making that as an implicit decision by removing individual= control of BT by app. However, only point is then it states only about BT1= and BT2 not BT0. What if , an app want to use BT0 for padding, then how do we support that? = what is rationale for removing BT0 here? > + * > + * In case RTE_CRYPTO_ASYM_OP_VERIFY op type is used crypto op > status > + * is set to RTE_CRYPTO_OP_STATUS_SUCCESS when signature is > properly > + * verified, RTE_CRYPTO_OP_STATUS_ERROR when it failed. [Shally] This description should go under OP_TYPE_VERIFICATION than here. H= ere it should limit to description about padding scheme > */ > RTE_CRYPTO_RSA_PADDING_OAEP, > - /**< RSA PKCS#1 OAEP padding scheme */ > + /**< RSA PKCS#1 OAEP padding scheme, can be used only for > encryption/ > + * decryption. [Shally] Better to add version V2 here: RSA PKCS#1 V2 OAEP padding scheme > + */ > RTE_CRYPTO_RSA_PADDING_PSS, > - /**< RSA PKCS#1 PSS padding scheme */ > + /**< RSA PKCS#1 PSS padding scheme, can be used only for > signatures. [Shally] It is enough to mention till this here. following about op status = should better go to an op_type description than here > + * > + * Crypto op status is set to RTE_CRYPTO_OP_STATUS_SUCCESS > + * when signature is properly verified, > RTE_CRYPTO_OP_STATUS_ERROR > + * when it failed. > + */ > RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END > }; >=20 > @@ -199,8 +209,8 @@ struct rte_crypto_rsa_priv_key_qt { > */ > struct rte_crypto_rsa_xform { > rte_crypto_param n; > - /**< n - Prime modulus > - * Prime modulus data of RSA operation in Octet-string network > + /**< n - Modulus > + * Modulus data of RSA operation in Octet-string network > * byte order format. > */ >=20 > @@ -397,11 +407,23 @@ struct rte_crypto_rsa_op_param { > /**< > * Pointer to data > * - to be encrypted for RSA public encrypt. > - * - to be decrypted for RSA private decrypt. > * - to be signed for RSA sign generation. > * - to be authenticated for RSA sign verification. > */ >=20 > + rte_crypto_param cipher; > + /**< > + * Pointer to data > + * - to be decrypted for RSA private decrypt. [Shally] Since spec use terminology RSA Decryption for private key decrypti= on, so , it is enough to mention : "pointer to data to be decrypted." And s= ame is applicable to other as well. > + * > + * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used size in > bytes > + * of this field need to be equal to the size of corresponding > + * RSA key.=20 [Shally] Since it is meant as an input for decryption, reference to op_type= ENCRYPT look redundant here. It can simply stated as, " length of cipher d= ata should be equal to RSA modulus length." >Returned data is in Big-Endian format which means > + * that Least-Significant byte will be placed at top byte of an array > + * (at message.data[message.length - 1]), cipher.length SHALL > + * therefore remain unchanged. [Shally] Do we really need to mention it? > + */ > + > rte_crypto_param sign; > /**< > * Pointer to RSA signature data. If operation is RSA @@ -410,25 > +432,82 @@ struct rte_crypto_rsa_op_param { > * > * Length of the signature data will be equal to the > * RSA prime modulus length. > - */ > - > - enum rte_crypto_rsa_padding_type pad; > - /**< RSA padding scheme to be used for transform */ > - > - enum rte_crypto_auth_algorithm md; > - /**< Hash algorithm to be used for data hash if padding > - * scheme is either OAEP or PSS. Valid hash algorithms > - * are: > - * MD5, SHA1, SHA224, SHA256, SHA384, SHA512 > - */ > - > - enum rte_crypto_auth_algorithm mgf1md; > + * > + * Returned data is in Big-Endian format which means > + * that Least-Significant byte will be placed at top byte of an array > + * (at message.data[message.length - 1]), sign.length SHALL > + * therefore remain unchanged. > + */ [Shally] Again, this looks redundant info here. > + > + 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 ha= ve any capa struct changes to return this. So do you mean capability or PMD= release note here? > + enum rte_crypto_auth_algorithm hash; > + /**< > + * - For PKCS1-v1_5 signature (Block type 01) this field > + * represents hash function that will be used to create > + * message hash. This hash will be then concatenated with > + * hash algorithm identifier into DER encoded sequence. [Shally] This whole description is already in RFC. It looks like an overloa= d to add all such details here. If really intended it is better to give rfc= PKCS1 V2 reference here. > + * 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. [Shally] who will set it? PMD or application? Its bit unclear here where an= d when it will be set to INVALID / NONE? > + * > + * - For OAEP this field represents hash function that will > + * be used to produce hash of the optional label. > + * If RTE_CRYPTO_HASH_INVALID or > RTE_CRYPTO_HASH_NONE is set > + * driver will use default value. For OAEP usually it is SHA-1. > + * > + * - For PSS this field represents hash function that will be > used > + * to produce hash (mHash) of message M and of M' > (padding1 | mHash | salt) > + * If RTE_CRYPTO_HASH_INVALID or > RTE_CRYPTO_HASH_NONE is set > + * driver will use default value. > + * > + * - If driver supports only one function > RTE_CRYPTO_HASH_NONE > + * according to aformentioned restrictions should be used or > + * specific function should be set, otherwise on dequeue the > driver > + * SHALL set crypto_op_status to > RTE_CRYPTO_OP_STATUS_INVALID_ARGS. [Shally] Similar feedback here. > + */ > + union { > + struct { > + enum rte_crypto_auth_algorithm mgf; > + /**< > + * Mask genereation function hash algorithm. > + * If this field is not supported by the driver, > + * it should be set to > RTE_CRYPTO_HASH_NONE. > + */ > + rte_crypto_param label; > + /**< > + * Optional label, if driver does not support > + * this option, optional label is just an empty > string. > + */ > + } OAEP; > + struct { > + enum rte_crypto_auth_algorithm mgf; > + /**< > + * Mask genereation function hash algorithm. > + * If this field is not supported by the driver, > + * it should be set to > RTE_CRYPTO_HASH_NONE. > + */ > + int seed_len; > + /**< > + * Intended seed length. Nagative number > has special > + * value as follows: > + * -1 : seed len =3D length of output ot used > hash function > + * -2 : seed len is maximized > + */ > + } PSS; > + }; > + } padding; [Shally] having additional struct padding within op_param looks unnecessary= . Why do we need to rearrange it like this? It can simply be: struct rte_crypto_rsa_op_param { enum rte_crypto_asym_op_type op_type; /**< Type of RSA operation for transform */; rte_crypto_param cipher; /**< * Pointer to data to be decrypted with length of data equal to RSA modulu= s length */ rte_crypto_param message; /**< * Pointer to data * - to be encrypted. * - to be signed. * - to be verified. */ rte_crypto_param sign; /**< * Pointer to RSA signature data. If operation is RSA * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be * over-written with generated signature. * * Length of the signature data will be equal to the * RSA prime modulus length. */ enum rte_crypto_rsa_padding_type pad; /**< RSA padding scheme to be used for transform */ > + union { > + struct { > + enum rte_crypto_auth_algorithm mgf; > + /**< > + * Mask genereation function hash algorithm. > + * If this field is not supported by the driver, > + * it should be set to > RTE_CRYPTO_HASH_NONE. > + */ > + rte_crypto_param label; > + /**< > + * Optional label, if driver does not support > + * this option, optional label is just an empty > string. > + */ > + } OAEP; > + struct { > + enum rte_crypto_auth_algorithm mgf; > + /**< > + * Mask genereation function hash algorithm. > + * If this field is not supported by the driver, > + * it should be set to > RTE_CRYPTO_HASH_NONE. > + */ > + int seed_len; > + /**< > + * Intended seed length. Nagative number > has special > + * value as follows: > + * -1 : seed len =3D length of output ot used hash function > + * -2 : seed len is maximized > + */ > + } PSS; }; } > /**< > - * Hash algorithm to be used for mask generation if > - * padding scheme is either OAEP or PSS. If padding > - * scheme is unspecified data hash algorithm is used > - * for mask generation. Valid hash algorithms are: > - * MD5, SHA1, SHA224, SHA256, SHA384, SHA512 > + * Padding type of RSA crypto operation. > + * What are random number generator requirements and prequisites > + * SHALL be put in specific driver guide [Shally] Again, probably this reference is unnecessary here. > */ > }; >=20 > -- > 2.1.0