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 0BEF8A0471 for ; Tue, 16 Jul 2019 15:51:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DBF961B964; Tue, 16 Jul 2019 15:51:08 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20073.outbound.protection.outlook.com [40.107.2.73]) by dpdk.org (Postfix) with ESMTP id A122F1B95C for ; Tue, 16 Jul 2019 15:51:07 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mNS0BLKuuX/z0mXrNmSEGPaiPsXG7sXyUxZUgHoZMxdkhVuBvI5bovxkRUJN/Mqh9qbbhUW0VNu2uI9g+d1C7y4yxSBX4Gj/Sil5eC47f9gj/0PivobN1aBvUIAv8vaynkaVRvIUY71bAQxP2xA5Sb/jcPKz/ZylD5FWIaYRIa/0w6S5uHmYvtmRZRFMdx9cBkuSf+nXEs1H9Op0JrvFSZr83cDYzrzZ7/+Xp8VtsVU1fLmXlBAzzWax7BasEKJcrCeqNchNhP5vRkQx8FtuP5kDpSRJC0kGkgbGDnnyYg5TGI/BFML06gIoyXn9fGrG9+lznKkq/Fx/8XtbCb3yQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AR9MFEWhi6trZGkEvITFV1FBdmkIJYnxUuK+7zHsolM=; b=AIdyrLyGnC5C6gAPgojx7jLfAQeSPtQOQk6APJiwN+UrO6ofEhNy6D49W8AdZ91JhDmijBNYVae7rU4i2mf1Lj87ZVI70xAGKvbqcT6SrfauGw+Dt3o6YlYjlWuVzOIKwrn6NTHXe0B2ryKTh2a79sRVx/MUX3C8Av46mQRygx8MrEMtjgxlNGUisJvu7Hi8tj+tw8oO04p4A3aily7ruwLRcSAosYuzXzszdC93uuawbvZae6tv8X/6DTE6RsKf53a+RZQQcysacd4Oz/aB0HkcA1QLR5tDOMmRvsWikJ7WXlwxciknF2nU9JcBzIkvji0BnDCoIeapVNjiHrs3xg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nxp.com;dmarc=pass action=none header.from=nxp.com;dkim=pass header.d=nxp.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AR9MFEWhi6trZGkEvITFV1FBdmkIJYnxUuK+7zHsolM=; b=rw07CEjhfbqo582C/tB5nAr+XX0v3i7/6vbrjkoD1rdWITOcvjLgCSCQuV6KMJyKLmnhfG+kDFRoQTY7YPbLcVspq1iIC8MymlHBnuzuaz9OhwIgb1yJVPFLzh0hXnX0PZiTk6xrGb7qLu0VEUMpSBPqWhT0NQjMQQIYDMT9beE= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6544.eurprd04.prod.outlook.com (20.179.234.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 16 Jul 2019 13:51:06 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::d546:8474:f63a:5d22]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::d546:8474:f63a:5d22%6]) with mapi id 15.20.2073.012; Tue, 16 Jul 2019 13:51:06 +0000 From: Akhil Goyal To: "Kusztal, ArkadiuszX" , Shally Verma , "dev@dpdk.org" CC: "Trahe, Fiona" Thread-Topic: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm Thread-Index: AQHVMbV1qM1m/7trJEu8iS/qOhKLkqa6Z+KAgAMuKoCAA3AYAIABEVMAgAs/wVA= Date: Tue, 16 Jul 2019 13:51:06 +0000 Message-ID: References: <20190703153759.1508-1-arkadiuszx.kusztal@intel.com> <20190703153759.1508-2-arkadiuszx.kusztal@intel.com> <06EE24DD0B19E248B53F6DC8657831551B279302@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B27DBFB@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B27EFEA@hasmsx109.ger.corp.intel.com> In-Reply-To: <06EE24DD0B19E248B53F6DC8657831551B27EFEA@hasmsx109.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f314eac3-a9be-4a9c-ab6d-08d709f4a680 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6544; x-ms-traffictypediagnostic: VE1PR04MB6544: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(366004)(346002)(376002)(189003)(199004)(13464003)(305945005)(55016002)(52536014)(6436002)(6306002)(5660300002)(9686003)(66946007)(33656002)(4326008)(74316002)(25786009)(14444005)(256004)(76116006)(7696005)(76176011)(66066001)(476003)(11346002)(81166006)(81156014)(446003)(110136005)(2906002)(229853002)(316002)(8936002)(66446008)(2501003)(99286004)(68736007)(8676002)(45080400002)(966005)(44832011)(7736002)(478600001)(53946003)(53546011)(486006)(102836004)(3846002)(53936002)(6116002)(71200400001)(71190400001)(186003)(14454004)(64756008)(6246003)(66556008)(30864003)(26005)(66476007)(86362001)(6506007)(473944003); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6544; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: h229zMUt2SZJ1MgLndlXKyxXMDRn+LX6dEew+zCThXWB1pSUc5Ra+l5f/+9qsIrcOYSQw6mIRqXgl65Za7QwYEx2qT0rrCcbtpLfmCI3sYW0BIsDET1LRSqvmRpO3twYaKXUK4rj1Q29q7U9ck374BH1qCRHJPhPuXYE8kF/Yj18onpmSgMd79GMJRAfgaBzM6w481dgQBN2GozXchyk+ogk6DKCOR7Qt9LBLKhA1qI3TONi+cilbiltv/WsMfBnwWhed8w42acUd4sQLEetfolPW9/Kbo7rOUG5VFhMMv+ALoaafgUbyHixDlPHfPY5qT6TzlOZl3XRFp3PZrkmH7HE1seWWZuCKU9OyN5tZP+ZcLqoLWdFWuSy5A2TJD+HHDk8h5SKVCpfCKMRce01/9jXV2B92hjsuk3b0xQ4PAU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: f314eac3-a9be-4a9c-ab6d-08d709f4a680 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 13:51:06.4795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: akhil.goyal@nxp.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6544 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" Hi Shally, Do you have further comments on this series? If yes, we may need to defer this to next release. As cryptodev change shou= ld not be there beyond RC2. In fact all of them should be closed by RC1. Regards, Akhil > -----Original Message----- > From: Kusztal, ArkadiuszX > Sent: Tuesday, July 9, 2019 3:33 PM > To: Shally Verma ; dev@dpdk.org > Cc: Akhil Goyal ; Trahe, Fiona > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm >=20 > To clarify bit more > With [AK2] >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Kusztal, Arkadiusz= X > > Sent: Monday, July 8, 2019 7:44 PM > > To: Shally Verma ; dev@dpdk.org > > Cc: akhil.goyal@nxp.com; Trahe, Fiona ; > > shally.verma@caviumnetworks.com > > Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: rework api of rsa > > algorithm > > > > Hi Shally, > > > > With [AK] > > > > > -----Original Message----- > > > From: Shally Verma [mailto:shallyv@marvell.com] > > > Sent: Saturday, July 6, 2019 3:14 PM > > > To: Kusztal, ArkadiuszX ; dev@dpdk.org > > > Cc: akhil.goyal@nxp.com; Trahe, Fiona ; > > > shally.verma@caviumnetworks.com > > > Subject: RE: [PATCH v2 1/3] cryptodev: rework api of rsa algorithm > > > > > > > > > > > > > -----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 > > > > > > > > External Email > > > > > > > .. > > > > > > > > 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 verificat= ion > > > > > + * 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 alig= n > > > more to standard > > [AK] - Agree. > > > > > > > > > > + /**< 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 > > [AK] - RSA key size is a RSA modulus size, but can be changed. > > > > > > > > + * > > > > > + * 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 modulus length - 1 as perf rfc8017 > > [AK] > > example. 20 bytes was encrypted with 2048bit key PKCS_1.5 1. Padding > > PKCS_1.5 set - Upon decryption we return 20 bytes of recovered message. > > 2. Padding NONE set (padding done by user) - we return 236 bytes of pad= ding > > (one leading zero) | 20 bytes of message =3D 256 bytes. > > (like in example test case I have added) 3. Padding NONE set (textbook = rsa) - > > we return 236 bytes of zeroes | 20 bytes of message =3D 256 bytes. > > > > > > > > + > > > > > + 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 > > [AK] - Agreed > > > > > > > > */ > > > > > > > > > > - 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? > > > If yes, then why not just use that message buffer as an output of > > > VERIFY_OP than adding a new one? > > [AK] - it is output of signature verify (in openssl Public_Decrypt) for > > PADDING_NONE case. It will be used to check if signature is correct. > > In `message` then there could be original message. > > But yes, we can use message as an output buffer, I just though it would= be > > more transparent. > > Since user need to verify it by himself it is not that important to kee= p original > > message in `message` field, both ways will do. > > Waiting for opinions. > > > > > > > > + * 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 t= o > > > sign operation > > [AK] - `Sign` is the place to put signature into. > > > > > > > > + * 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 be 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 > > capability. > > > 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 = .. > > > does your hw support this offload for RSA? > > > So far , in our testing we observe openssl does it already before > > > calling private/public_key_enc so we should not be mentioning it in > > > spec unless any hw provide that combined offload hash + rsa > > > > [AK] - Openssl for PKCS1_5 signature use RSA_private_encrypt which does > > not handle algorithmIdentifier. > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.o= p > enssl.org%2Fdocs%2Fman1.0.2%2Fman3%2FRSA_private_encrypt.html&da > ta=3D02%7C01%7Cakhil.goyal%40nxp.com%7Cdb7fd9c8893144df755808d704549 > 746%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636982633668853 > 558&sdata=3DFGOMjneOQsB7DRg8fKYHWhn5TKH3eO8QKA1bGbbt25w%3D& > amp;reserved=3D0 > > And it is not said what data should be provided for signing. To be prop= erly > > signed input buffer should be DER encoded concatenation of > > algorithmIdentifier and message digest. > > There would be much work to be done by user then: adding OID, computing > > Hash of message, ASN.1 call. Waiting for comments on that. >=20 > [AK2] - we do not specify what data should user provide to be signed. >=20 > > > > > > > > > > + * > > > > > + * - 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 rfc8017 for further discussion. > > > if we have any PMD whose HW provide full RSAES-OAEP offload i.e. > > > doing EME-OAEP followed by RSAEP, 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. > > > > > [AK] - I thought to add PSS/OAEP to Openssl. Though OAEP and PSS for su= re > > will be implemented having custom MGF is not that necessary. Waiting fo= r > > opinions. >=20 > > > > > > > > > > > > > + /**< > > > > > + * 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 guide to check for RNG requirement and other pre-requisites used > > > in hash generation. > > > However , this feedback is relevant if we are retaining full OAEP off= load. > > > > > > > > */ > > > > > }; > > > > > > > > > > -- > > > > > 2.1.0