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 1B28CA0487 for ; Sat, 6 Jul 2019 15:14:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A641044C3; Sat, 6 Jul 2019 15:14:30 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id C3F761041 for ; Sat, 6 Jul 2019 15:14:29 +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 x66D5R6w000594; Sat, 6 Jul 2019 06:14:28 -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=VyAV/BSWZ2BllKf8g/1jGOe7wyWu3yOY8gH9GwhRj0g=; b=KgahIJTWQr2wqZJc7ms6T4b2wdY38Cwox2iEGxIntP9ZVwq7oy2N97ouZQ0uEEbXRGW8 SQQ8AUsRe4BhHG5LCKF34rrBfTnE+V+ogaJAm5SLMlK8hYbRAblePxBwk7E9JYWsgkDN ZytJIKYqPUeqpZCjYyEPlFYnMyiDnVrd3BOS+I8LlMfLGqcRtTSI3myp6hoDKzZ3Nyun d0uYPf9Emg3i5pWYMbO440NR+aPtXu2LidrBMlnBDKqvuyBY7EuV6RMFaGT8R+WT6uuc 3DjFRfPpbOkdDXEb40gk3V3Sjr1jqIHuBgYlnAIeUA2zdoVJ0uZGVsFZtYrAigVAhobV Rw== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2tjs0nrj72-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 06 Jul 2019 06:14:28 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 6 Jul 2019 06:14:27 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (104.47.48.59) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Sat, 6 Jul 2019 06:14:27 -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=VyAV/BSWZ2BllKf8g/1jGOe7wyWu3yOY8gH9GwhRj0g=; b=sUBXdGEk/NAXI6GgvZlc9+WbT+ywNCE5Qkxm7WH3hU0I72adavCw4k8YVwilahGBEiYUOzTAYYUTRrOlafDsVUPVuPbSYCdOcNcvFExwrF3soee7/r/fOqFLieATSCoYVwB3TmR+Q+YzHLUKPiXALYwHoaiL6f2sgDgl6AOU0h0= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB1858.namprd18.prod.outlook.com (10.161.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Sat, 6 Jul 2019 13:14:26 +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.022; Sat, 6 Jul 2019 13:14:25 +0000 From: Shally Verma To: "Kusztal, ArkadiuszX" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "Trahe, Fiona" , "shally.verma@caviumnetworks.com" Thread-Topic: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm Thread-Index: AQHVMmWvxVvMCdHMQ02sLQVtc3LKbKa9WKjQ Date: Sat, 6 Jul 2019 13:14:25 +0000 Message-ID: References: <20190703153759.1508-1-arkadiuszx.kusztal@intel.com> <20190703153759.1508-2-arkadiuszx.kusztal@intel.com> <06EE24DD0B19E248B53F6DC8657831551B279302@hasmsx109.ger.corp.intel.com> In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B279302@hasmsx109.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: e72c5143-c0df-40a3-e1ca-08d70213dea3 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:BN6PR1801MB1858; x-ms-traffictypediagnostic: BN6PR1801MB1858: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00909363D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39850400004)(396003)(136003)(366004)(346002)(13464003)(199004)(189003)(486006)(476003)(33656002)(7736002)(55236004)(6436002)(102836004)(6116002)(3846002)(9686003)(8676002)(55016002)(186003)(446003)(8936002)(26005)(81166006)(81156014)(11346002)(76176011)(14454004)(25786009)(7696005)(74316002)(229853002)(256004)(99286004)(53546011)(14444005)(305945005)(6506007)(110136005)(4326008)(54906003)(2906002)(316002)(68736007)(5660300002)(53936002)(66066001)(52536014)(86362001)(71200400001)(71190400001)(66556008)(66446008)(478600001)(6246003)(66476007)(64756008)(2501003)(66946007)(76116006)(73956011)(473944003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB1858; 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: RWGVcUXeMdk1TyioFeXCOZxZMLr8GjsLldmShAz4kWlUKCv9ptimPLp2rgaX8bnGe8ZKZumlJpapuW1OV/0G2eY2cOe55zyc3BxEqRkZXUK2WrCV216SIKBElvVwMwYac6nz5BjBaBatlgnAo3Lnyzkyo3wjZM4oNJi6uZ7F9z6kGKWzPMYcE61A/jXVPGXKIdfdtCOKl+jnaETiNZE7BnelxPkwZuJ99VXXwRrdTt2U+M5hOU6MSHuW+GD/73bLHZiBn2CjHyus5r36Lb31b7F7x/blkjvbVmCYdBGsMqFFc8jq6rzlhjmbWX6E19sTtJiGnbffHDdrvhFMIuPFrguD0QCZCioCqTrqVpgawm9lEVug7d5stbLfu/3iqZtqtO+Bxi8gsrtw8ddyDoNG4Joeg6R1++vujZuSYrrANms= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e72c5143-c0df-40a3-e1ca-08d70213dea3 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2019 13:14:25.7431 (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: BN6PR1801MB1858 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-06_03:, , signatures=0 Subject: Re: [dpdk-dev] [PATCH v2 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: Kusztal, ArkadiuszX > Sent: Thursday, July 4, 2019 6:10 PM > To: dev@dpdk.org > Cc: akhil.goyal@nxp.com; Trahe, Fiona ; > shally.verma@caviumnetworks.com; Shally Verma > Subject: [EXT] RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm >=20 > External Email >=20 .. > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h > > b/lib/librte_cryptodev/rte_crypto_asym.h > > index 8672f21..486399c 100644 > > --- a/lib/librte_cryptodev/rte_crypto_asym.h > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h > > @@ -111,23 +111,21 @@ 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 > > + /**< RSA no padding scheme. > > + * In this case user is responsible for provision and verification > > + * of padding. > > */ > > - 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 > > + RTE_CRYPTO_RSA_PADDING_PKCS1, [Shally] My preference would still be to rename as PKCS1_V1.5 to align more= to standard > > + /**< RSA PKCS#1 PKCS1-v1_5 padding scheme. For signatures block > > type 01, > > + * for encryption block type 02 are used. > > */ > > RTE_CRYPTO_RSA_PADDING_OAEP, > > - /**< RSA PKCS#1 OAEP padding scheme */ > > + /**< RSA PKCS#1 OAEP padding scheme, can be used only for > > encryption/ > > + * decryption. > > + */ > > RTE_CRYPTO_RSA_PADDING_PSS, > > - /**< RSA PKCS#1 PSS padding scheme */ > > + /**< RSA PKCS#1 PSS padding scheme, can be used only for > > signatures. > > + */ > > RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END > > }; > > ... > > 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. > > */ > > > > @@ -397,9 +395,36 @@ 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. > > + * > > + * Octet-string network byte order format. > > + * > > + * This field is an input to RTE_CRYPTO_ASYM_OP_ENCRYPT > > + * operation, and output to RTE_CRYPTO_ASYM_OP_DECRYPT > > operation. > > + * > > + * When RTE_CRYPTO_ASYM_OP_DECRYPT op_type used length in > > bytes > > + * of this field needs to be greater or equal to the length of > > + * corresponding RSA key in bytes. [Shally] better rephrased " When an op_type ASYM_OP_DECRYPT used, length of= output buffer should be greater than or equal to RSA key modulus length=20 > > + * > > + * When padding field is set to RTE_CRYPTO_RSA_PADDING_NONE > > + * returned data size will be equal to the size of RSA key > > + * in bytes. All leading zeroes will be preserved. > > + */ [Shally] Is it in context of OP_TYPE_DECRYPT? Even if it is PADDING_NONE, = whether it is encrypted/decrypted, o/p length can vary between 0 .. RSA mod= ulus length - 1 as perf rfc8017 > > + > > + rte_crypto_param cipher; > > + /**< > > + * Pointer to data > > + * - to be decrypted for RSA private decrypt. > > + * > > + * Octet-string network byte order format. > > + * > > + * This field is an input to RTE_CRYPTO_ASYM_OP_DECRYPT > > + * operation, and output to RTE_CRYPTO_ASYM_OP_ENCRYPT > > operation. > > + * > > + * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used length in > > bytes > > + * of this field needs to be greater or equal to the length of > > + * corresponding RSA key in bytes. > > */ [Shally] recommend rephrasing as above > > > > rte_crypto_param sign; > > @@ -408,27 +433,88 @@ struct rte_crypto_rsa_op_param { > > * 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. > > + * Octet-string network byte order format. > > + * > > + * When RTE_CRYPTO_ASYM_OP_SIGN op_type used length in bytes > > + * of this field needs to be greater or equal to the length of > > + * corresponding RSA key in bytes. [Shally] field ---> buffer > > */ > > > > - 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 > > + rte_crypto_param message_to_verify; > > + /**< > > + * Pointer to the message 'm' that was signed with > > + * RSASP1 in RFC8017. >> It is the result of operation RSAVP1 > > + * defined in RFC8017, where field `sign` is the input > > + * parameter `s`. > > + * [Shally] This is confusing. Are you trying to say "this is output to VERIFY= _OP ? where output should be same as message buffer provided above?=20 If yes, then why not just use that message buffer as an output of VERIFY_OP= than adding a new one? > > + * Used only when padding type is set to > > RTE_CRYPTO_RSA_PADDING_NONE [Shally] I think regardless of padding, we can provide it as output to sign= operation=20 > > + * and `op_type` is set to RTE_CRYPTO_ASYM_OP_VERIFY. > > + * > > + * Returned data size will be equal to the size of RSA key > > + * in bytes. All leading zeroes will be preserved. > > + * [Shally] Again, I think it should instead be mentioned as return size can b= e 0 ... modulus_len - 1 > > + * When RTE_CRYPTO_ASYM_OP_VERIFY op_type used length in > > bytes > > + * of this field needs to be greater or equal to the length of > > + * corresponding RSA key in bytes. > > */ [Shally] There're multiple statements starting with when op_type =3D VERIFY= , can we club them and make description shorter? > > > > - enum rte_crypto_auth_algorithm mgf1md; > > + enum rte_crypto_rsa_padding_type padding; > > + /**< > > + * 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 can be > > + * found in in specific driver guide. [Shally] better rephrase " PMD expose padding type support in its capabilit= y. Refer to > > + */ > > + enum rte_crypto_auth_algorithm padding_hash; > > + /**< > > + * - For PKCS1-v1_5 signature (Block type 01) this field > > + * represents hash function that will be used to create > > + * message hash. [Shally] Currently PMD input pre-computed hash atleast for PKCSV_1.5 .. doe= s your hw support this offload for RSA? So far , in our testing we observe openssl does it already before calling p= rivate/public_key_enc so we should not be mentioning it=20 in spec unless any hw provide that combined offload hash + rsa > > + * > > + * - For OAEP this field represents hash function that will > > + * be used to produce hash of the optional label. > > + * > > + * - 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 not set driver will use default value. > > + */ > > + union { > > + struct { > > + enum rte_crypto_auth_algorithm mgf; > > + /**< > > + * Mask genereation function hash algorithm. > > + * > > + * If not set driver will use default value. > > + */ > > + 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; [Shally] Though it is mentioned in current spec, but I have similar doubt = here do we need to provide this offload in spec? I will use terms from rfc8= 017 for further discussion. if we have any PMD whose HW provide full RSAES-OAEP offload i.e. doing EM= E-OAEP followed by RSAEP,=20 then it make sense to have it in spec. But if we don't have any PMD example= which support that full offload, then we can redefine spec only to support= RSAEP and omit md and mgf from spec. > > + /**< > > + * Mask genereation function hash algorithm. > > + * > > + * If not set driver will use default value. > > + */ > > + 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 > > + * can be found specific driver guide. [Shally] I would suggest it to rephrase again " app should refer to PMD gui= de to check for RNG requirement and other pre-requisites used in hash gener= ation. However , this feedback is relevant if we are retaining full OAEP offload. > > */ > > }; > > > > -- > > 2.1.0