From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 37AFD1B20B for ; Tue, 12 Feb 2019 12:12:30 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2019 03:12:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,361,1544515200"; d="scan'208";a="137947786" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 12 Feb 2019 03:12:28 -0800 Received: from fmsmsx162.amr.corp.intel.com (10.18.125.71) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 12 Feb 2019 03:12:28 -0800 Received: from hasmsx106.ger.corp.intel.com (10.184.198.20) by fmsmsx162.amr.corp.intel.com (10.18.125.71) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 12 Feb 2019 03:12:27 -0800 Received: from HASMSX109.ger.corp.intel.com ([169.254.3.174]) by HASMSX106.ger.corp.intel.com ([169.254.10.140]) with mapi id 14.03.0415.000; Tue, 12 Feb 2019 13:12:24 +0200 From: "Kusztal, ArkadiuszX" To: Shally Verma , Ayuj Verma , "Trahe, Fiona" CC: "akhil.goyal@nxp.com" , Kanaka Durga Kotamarthy , Sunila Sahu , "dev@dpdk.org" Thread-Topic: [PATCH 0/3] adding op-type crt sign and decrypt Thread-Index: AQHUvg1gQkJoFzcev0ymVfke48+GsaXVmWXEgACVmtCAA+zJ5IAAVXaggAAS47CAAYLbIA== Date: Tue, 12 Feb 2019 11:12:24 +0000 Message-ID: <06EE24DD0B19E248B53F6DC8657831551B13B21B@hasmsx109.ger.corp.intel.com> References: <20190206111405.30860-1-ayverma@marvell.com> , <348A99DA5F5B7549AA880327E580B435896EBE65@IRSMSX101.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B13B064@hasmsx109.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.104.14.186] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/3] adding op-type crt sign and decrypt 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: , X-List-Received-Date: Tue, 12 Feb 2019 11:12:30 -0000 Hi Shally, Ayuj Answers with [AK] > -----Original Message----- > From: Shally Verma [mailto:shallyv@marvell.com] > Sent: Tuesday, February 12, 2019 6:27 AM > To: Kusztal, ArkadiuszX ; Ayuj Verma > ; Trahe, Fiona > Cc: akhil.goyal@nxp.com; Kanaka Durga Kotamarthy > ; Sunila Sahu ; > dev@dpdk.org > Subject: RE: [PATCH 0/3] adding op-type crt sign and decrypt >=20 > HI Arek, >=20 > From: Kusztal, ArkadiuszX > Sent: 11 February 2019 17:11 > To: Ayuj Verma ; Trahe, Fiona > ; Shally Verma > Cc: akhil.goyal@nxp.com > Subject: [EXT] RE: [PATCH 0/3] adding op-type crt sign and decrypt >=20 > External Email > ________________________________________ > Hi Ayuj, >=20 > Few comments from me. >=20 > Some PMDs can only support RSA private key operations using CRT keys > (quintuple) only. Thus it is required to add in PMD RSA xform capability > which key type is supported to perform sign and decrypt ops. >=20 >=20 > Thus add an another op_type RTE_CRYPTO_OP_TYPE_SIGN_CRT and > RTE_CRYPTO_OP_TYPE_DECRYPT_CRT, which would mean perform an > private key op using CRT keys (quintuple) only. > [AK] - What would be the purpose of enum rte_crypto_rsa_priv_key_type > key_type in RSA XFORM then? >=20 > [Shally] PMDs, like openssl, can support private key ops with both key ty= pe > i.e. one can invoke RSA_Sign() with quintuple keys or exponent keys. > Openssl in its capability would reflect it support ops with both key type= s. > that's why key_type is still required in xform. [AK] But still I wonder if we could not just use this enum to distinguish b= etween crt and mod exp rsa? I am not very keen on adding SIGN_CRT op type as it is RSA only. Another op= tion would be to add flags to rsa op like uint64_t flags; >=20 > PMD would reflect its capability to support these operations using its > op_type mask. App should query RSA xform capability API to check if speci= fic > op_type is supported, thus call operation with relevant key type. >=20 > Another proposal is, it is not known if non-crt keys is used at all to pe= rform > otherwise naturally slow RSA private keys operations. > So, it is also possible to deprecate RSA_KEY_TYPE_EXPONENT altogether and > just use quintuple key type for private key operations. > In that case, there is no need to add another SIGN/DECRYPT_CRT variant, > current SIGN and DECRYPT operation default to using quintuple RSA keys. > [AK] - even if I generally agree that all drivers will be using CRT by de= fault > (when quintuple keys provided) I think that if some PMD cannot support > mod exp, it should fail on session init or should receive unsupported err= or on > dequeue. >=20 > [Shally] Sorry this isn't clear to me when you say "if some PMD cannot > support mod exp, it should fail on session init" . modexp is exported as > separate xform on lib, if PMD doesn't support this xform, it will not be = in its > capability. > Or do you mean to say, we can leave exponent key type support , if PMD > doesn't support operations using this type, it can will fail during > session_init()? [AK] Yes > modexp is base for all RSA operation, so any PMD has to support it intern= ally > in any case. >=20 > Ayuj Verma (3): > =A0 lib/cryptodev: add crt sign and decrypt ops > =A0 crypto/openssl: update op-type mask with crt ops > =A0 test/crypto: check for rsa capa for op-type >=20 > =A0drivers/crypto/openssl/rte_openssl_pmd_ops.c |=A0 4 +- > =A0lib/librte_cryptodev/rte_crypto_asym.h=A0=A0=A0=A0=A0=A0 |=A0 8 ++++ > =A0test/test/test_cryptodev_asym.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= | 47 ++++++++++++++++++++ > =A03 files changed, 58 insertions(+), 1 deletion(-) >=20 > -- > 2.20.0 >=20 > Regards, > Arek