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 20465A00E6 for ; Mon, 8 Jul 2019 20:04:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 27F0537B0; Mon, 8 Jul 2019 20:04:23 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id DB402325F for ; Mon, 8 Jul 2019 20:04:21 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2019 10:44:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,466,1557212400"; d="scan'208";a="176230325" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga002.jf.intel.com with ESMTP; 08 Jul 2019 10:44:42 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 10:44:27 -0700 Received: from lcsmsx156.ger.corp.intel.com (10.186.165.234) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 8 Jul 2019 10:44:27 -0700 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.134]) by LCSMSX156.ger.corp.intel.com ([169.254.15.216]) with mapi id 14.03.0439.000; Mon, 8 Jul 2019 20:44:24 +0300 From: "Kusztal, ArkadiuszX" To: Shally Verma , "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: AQHVMbV6Xkv9IeQaakqByLm+ywdiNqa6Z6HwgAL8IICAA34rsA== Date: Mon, 8 Jul 2019 17:44:24 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B27DBFB@hasmsx109.ger.corp.intel.com> References: <20190703153759.1508-1-arkadiuszx.kusztal@intel.com> <20190703153759.1508-2-arkadiuszx.kusztal@intel.com> <06EE24DD0B19E248B53F6DC8657831551B279302@hasmsx109.ger.corp.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.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.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" 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 >=20 >=20 >=20 > > -----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 > > > .. >=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 mo= re > to standard [AK] - Agree. >=20 > > > + /**< 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 > > > }; > > > > ... >=20 > > > 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 modul= us > length [AK] - RSA key size is a RSA modulus size, but can be changed. >=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 > modulus length - 1 as perf rfc8017 [AK]=20 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 m= essage. 2. Padding NONE set (padding done by user) - we return 236 bytes of padding= (one leading zero) | 20 bytes of message =3D 256 bytes.=20 (like in example test case I have added) 3. Padding NONE set (textbook rsa) - we return 236 bytes of zeroes | 20 byt= es of message =3D 256 bytes. >=20 > > > + > > > + 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 >=20 > > > > > > 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 >=20 > > > */ > > > > > > - 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 VERI= FY_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 PAD= DING_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.=20 Since user need to verify it by himself it is not that important to keep or= iginal message in `message` field, both ways will do. Waiting for opinions. >=20 > > > + * 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 si= gn > operation [AK] - `Sign` is the place to put signature into. >=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= be 0 > ... modulus_len - 1 >=20 > > > + * 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 VERI= FY, > can we club them and make description shorter? >=20 > > > > > > - 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 capabil= ity. > Refer to >=20 > > > + */ > > > + 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 a= ny > hw provide that combined offload hash + rsa [AK] - Openssl for PKCS1_5 signature use RSA_private_encrypt which does not= handle algorithmIdentifier. https://www.openssl.org/docs/man1.0.2/man3/RSA_private_encrypt.html And it is not said what data should be provided for signing. To be properly= signed input buffer should be DER encoded concatenation of algorithmIdenti= fier and message digest. There would be much work to be done by user then: adding OID, computing Has= h of message, ASN.1 call. Waiting for comments on that. >=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 doub= t 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. >=20 [AK] - I thought to add PSS/OAEP to Openssl. Though OAEP and PSS for sure w= ill be implemented=20 having custom MGF is not that necessary. Waiting for opinions. >=20 >=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 g= uide > to check for RNG requirement and other pre-requisites used in hash > generation. > However , this feedback is relevant if we are retaining full OAEP offload= . >=20 > > > */ > > > }; > > > > > > -- > > > 2.1.0