Message ID | 20190206111405.30860-1-ayverma@marvell.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7F4D41B3EB; Wed, 6 Feb 2019 12:16:27 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id B7A185B2E for <dev@dpdk.org>; Wed, 6 Feb 2019 12:16:25 +0100 (CET) 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 x16BFfGo009831; Wed, 6 Feb 2019 03:16:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=zEtdqT3nwrpr0nVWdNod2Ruh5/XmqOnRpaeeMX2S0Ww=; b=Y5GWg3wQb86JBZBs6OoQ/aW2BnjyulWJGg0U7Ml109ULHwCT6uZSssylEbdgY5+ZhKz/ Jg6DeXZuoLifO7/xn51j53wMP7NRu6dt16ElKl3nmBj9jsVz2hE6CW+oZko4CV92v0Ed kDrd9hN2OXhuUeyd243pAqwn8PLhdDStzyRsPNhwfOa9APayEKuvRIkwoyJB/3iPQMyw j0JzLjuAjuZbHk5ixXjn+qWO8tUoX5/DFiwNYpDwrKt6T3hDJa107hat1oW3ORbWRSRY ZIm2mJFxrGE/y4G+x4EzFN92TZgYKV5eDkoNOYB1hUY7hYuPDKLZ7OmoGAvrlzkw5lTU Ig== Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0b-0016f401.pphosted.com with ESMTP id 2qfc17keee-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Feb 2019 03:16:25 -0800 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 6 Feb 2019 03:16:23 -0800 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.59) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 6 Feb 2019 03:16:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zEtdqT3nwrpr0nVWdNod2Ruh5/XmqOnRpaeeMX2S0Ww=; b=Wea8uibm0jZS0uYlzD4rNivAJbb7Vad9GT5LyKSIScn/SI07qJ6I7t0tRprxCxgYYFZVN1kVETuOcCE3NhicVD7jbYgM+imUB9KIcWW2WNWnu+3C5S/Kun0gXz80uXY/XXzF/2AYLC3z8fwW54ewazETTZb6vYDGsvfGN+VywiA= Received: from DM6PR18MB2908.namprd18.prod.outlook.com (20.179.50.12) by DM6PR18MB2378.namprd18.prod.outlook.com (20.179.71.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.19; Wed, 6 Feb 2019 11:16:17 +0000 Received: from DM6PR18MB2908.namprd18.prod.outlook.com ([fe80::d176:5cef:c5d7:b9ae]) by DM6PR18MB2908.namprd18.prod.outlook.com ([fe80::d176:5cef:c5d7:b9ae%5]) with mapi id 15.20.1601.016; Wed, 6 Feb 2019 11:16:17 +0000 From: Ayuj Verma <ayverma@marvell.com> To: "pablo.de.lara.guarch@intel.com" <pablo.de.lara.guarch@intel.com> CC: "fiona.trahe@intel.com" <fiona.trahe@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, Shally Verma <shallyv@marvell.com>, Sunila Sahu <ssahu@marvell.com>, Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>, Arvind Desai <adesai@marvell.com>, Ayuj Verma <ayverma@marvell.com> Thread-Topic: [PATCH 0/3] adding op-type crt sign and decrypt Thread-Index: AQHUvg1gQkJoFzcev0ymVfke48+GsQ== Date: Wed, 6 Feb 2019 11:16:17 +0000 Message-ID: <20190206111405.30860-1-ayverma@marvell.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: BMXPR01CA0030.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:c::16) To DM6PR18MB2908.namprd18.prod.outlook.com (2603:10b6:5:168::12) x-mailer: git-send-email 2.20.0 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [111.93.218.67] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR18MB2378; 20:WPOOt24vkgHTKcq+9cIdakcxn1/SY/LgEPgdhhMGVeOprJBNd2kN5BPdFP3k4euoXqwSgNtNcPPzxwjW/yK7WztpLQG4SA1l16j/DZFvYR9ybi9rNhGmLxmietBzGtFL+Gzv9VIsnvNV+UcysjCgct0PDVshjcqLuUj7dfugcxQ= x-ms-office365-filtering-correlation-id: 7c823d05-b604-4950-91f3-08d68c248341 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DM6PR18MB2378; x-ms-traffictypediagnostic: DM6PR18MB2378: x-microsoft-antispam-prvs: <DM6PR18MB23785F89FDB0801F0E50C158AD6F0@DM6PR18MB2378.namprd18.prod.outlook.com> x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(396003)(136003)(366004)(189003)(199004)(4326008)(106356001)(97736004)(81166006)(81156014)(105586002)(14444005)(8676002)(14454004)(53936002)(1076003)(316002)(102836004)(186003)(561944003)(478600001)(2906002)(66066001)(25786009)(50226002)(68736007)(486006)(8936002)(78486014)(2501003)(26005)(5640700003)(86362001)(99286004)(6486002)(52116002)(6512007)(54906003)(6436002)(2616005)(2351001)(476003)(6506007)(6916009)(386003)(7736002)(71190400001)(71200400001)(305945005)(256004)(107886003)(3846002)(6116002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR18MB2378; H:DM6PR18MB2908.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: b5mK6oa3bTiIqkY8xdsaEHIbp9HHmtu55n9nOCszsmpZ3lDVFibHeQgNqcTUh+zYp5MXFFf0+QZpjskNbkuV0xYflvHQMy6IRM+7M9fpwI8nGp18P7tyLoXFaSw6tTwPlfXWoIKFRf+XD2h71ulUg5rIe0uH7/P8qiQnGpYViZ2VjoihjcENw25yLSCXZaQtLmBIALllxzsdz3rS2iGRYI0X8ZLhfkQsJI2bYPYsWTbaqsQ00AZjyFcBizaKbMwW3zr+ZctqmywzaNd0aBNa8r8vYPYVVkcDyKfcoOYKB5iVUKI6xmEqJhAKu3UUxOaIdvvMA6JDk+vi1d3CjwWlSvVFc07CtQETRvL/504Af40hGDH9CKaF6rJ2Z+sdLsz2giomd/GvHF2qqpPI1uoGu0nq3uqoANCJOvISfNAK2vE= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7c823d05-b604-4950-91f3-08d68c248341 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 11:16:14.2067 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR18MB2378 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-06_07:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=935 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902060090 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
adding op-type crt sign and decrypt
|
|
Message
Ayuj Verma
Feb. 6, 2019, 11:16 a.m. UTC
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. 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. PMD would reflect its capability to support these operations using its op_type mask. App should query RSA xform capability API to check if specific op_type is supported, thus call operation with relevant key type. Another proposal is, it is not known if non-crt keys is used at all to perform 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. Ayuj Verma (3): lib/cryptodev: add crt sign and decrypt ops crypto/openssl: update op-type mask with crt ops test/crypto: check for rsa capa for op-type drivers/crypto/openssl/rte_openssl_pmd_ops.c | 4 +- lib/librte_cryptodev/rte_crypto_asym.h | 8 ++++ test/test/test_cryptodev_asym.c | 47 ++++++++++++++++++++ 3 files changed, 58 insertions(+), 1 deletion(-)
Comments
Hi Pablo,Fiona Did you get a chance to look into these. Thanks and regards Ayuj Verma
HI Arek,
From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
Sent: 11 February 2019 17:11
To: Ayuj Verma <ayverma@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>; Shally Verma <shallyv@marvell.com>
Cc: akhil.goyal@nxp.com
Subject: [EXT] RE: [PATCH 0/3] adding op-type crt sign and decrypt
External Email
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 <arkadiuszx.kusztal@intel.com>; Ayuj Verma > <ayverma@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com> > Cc: akhil.goyal@nxp.com; Kanaka Durga Kotamarthy > <kkotamarthy@marvell.com>; Sunila Sahu <ssahu@marvell.com>; > dev@dpdk.org > Subject: RE: [PATCH 0/3] adding op-type crt sign and decrypt > > HI Arek, > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com> > Sent: 11 February 2019 17:11 > To: Ayuj Verma <ayverma@marvell.com>; Trahe, Fiona > <fiona.trahe@intel.com>; Shally Verma <shallyv@marvell.com> > Cc: akhil.goyal@nxp.com > Subject: [EXT] RE: [PATCH 0/3] adding op-type crt sign and decrypt > > External Email > ________________________________________ > Hi Ayuj, > > Few comments from me. > > 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. > > > 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? > > [Shally] PMDs, like openssl, can support private key ops with both key type > 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 types. > 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 between crt and mod exp rsa? I am not very keen on adding SIGN_CRT op type as it is RSA only. Another option would be to add flags to rsa op like uint64_t flags; > > PMD would reflect its capability to support these operations using its > op_type mask. App should query RSA xform capability API to check if specific > op_type is supported, thus call operation with relevant key type. > > Another proposal is, it is not known if non-crt keys is used at all to perform > 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 default > (when quintuple keys provided) I think that if some PMD cannot support > mod exp, it should fail on session init or should receive unsupported error on > dequeue. > > [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 internally > in any case. > > Ayuj Verma (3): > lib/cryptodev: add crt sign and decrypt ops > crypto/openssl: update op-type mask with crt ops > test/crypto: check for rsa capa for op-type > > drivers/crypto/openssl/rte_openssl_pmd_ops.c | 4 +- > lib/librte_cryptodev/rte_crypto_asym.h | 8 ++++ > test/test/test_cryptodev_asym.c | 47 ++++++++++++++++++++ > 3 files changed, 58 insertions(+), 1 deletion(-) > > -- > 2.20.0 > > Regards, > Arek
Hi Arek >-----Original Message----- >From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com> >Sent: 12 February 2019 16:42 >To: Shally Verma <shallyv@marvell.com>; Ayuj Verma <ayverma@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com> >Cc: akhil.goyal@nxp.com; Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>; Sunila Sahu <ssahu@marvell.com>; >dev@dpdk.org >Subject: RE: [PATCH 0/3] adding op-type crt sign and decrypt > >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 <arkadiuszx.kusztal@intel.com>; Ayuj Verma >> <ayverma@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com> >> Cc: akhil.goyal@nxp.com; Kanaka Durga Kotamarthy >> <kkotamarthy@marvell.com>; Sunila Sahu <ssahu@marvell.com>; >> dev@dpdk.org >> Subject: RE: [PATCH 0/3] adding op-type crt sign and decrypt >> >> HI Arek, >> >> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com> >> Sent: 11 February 2019 17:11 >> To: Ayuj Verma <ayverma@marvell.com>; Trahe, Fiona >> <fiona.trahe@intel.com>; Shally Verma <shallyv@marvell.com> >> Cc: akhil.goyal@nxp.com >> Subject: [EXT] RE: [PATCH 0/3] adding op-type crt sign and decrypt >> >> External Email >> ________________________________________ >> Hi Ayuj, >> >> Few comments from me. >> >> 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. >> >> >> 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? >> >> [Shally] PMDs, like openssl, can support private key ops with both key type >> 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 types. >> 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 between crt and mod exp rsa? >I am not very keen on adding SIGN_CRT op type as it is RSA only. Another option would be to add flags to rsa op like uint64_t flags; [Shally] Ok .. you mean as feature flag? Example, RTE_CRYPTODEV_ASYM_FF_RSA_PRIV_KEY_OP_CRT? Thanks Shally ... >> Regards, >> Arek
> -----Original Message----- > From: Shally Verma [mailto:shallyv@marvell.com] > Sent: Tuesday, February 12, 2019 12:19 PM > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Ayuj Verma > <ayverma@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com> > Cc: akhil.goyal@nxp.com; Kanaka Durga Kotamarthy > <kkotamarthy@marvell.com>; Sunila Sahu <ssahu@marvell.com>; > dev@dpdk.org > Subject: RE: [PATCH 0/3] adding op-type crt sign and decrypt > > Hi Arek > > >-----Original Message----- > >From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com> > >Sent: 12 February 2019 16:42 > >To: Shally Verma <shallyv@marvell.com>; Ayuj Verma > ><ayverma@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com> > >Cc: akhil.goyal@nxp.com; Kanaka Durga Kotamarthy > ><kkotamarthy@marvell.com>; Sunila Sahu <ssahu@marvell.com>; > >dev@dpdk.org > >Subject: RE: [PATCH 0/3] adding op-type crt sign and decrypt > > > >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 <arkadiuszx.kusztal@intel.com>; Ayuj Verma > >> <ayverma@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com> > >> Cc: akhil.goyal@nxp.com; Kanaka Durga Kotamarthy > >> <kkotamarthy@marvell.com>; Sunila Sahu <ssahu@marvell.com>; > >> dev@dpdk.org > >> Subject: RE: [PATCH 0/3] adding op-type crt sign and decrypt > >> > >> HI Arek, > >> > >> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com> > >> Sent: 11 February 2019 17:11 > >> To: Ayuj Verma <ayverma@marvell.com>; Trahe, Fiona > >> <fiona.trahe@intel.com>; Shally Verma <shallyv@marvell.com> > >> Cc: akhil.goyal@nxp.com > >> Subject: [EXT] RE: [PATCH 0/3] adding op-type crt sign and decrypt > >> > >> External Email > >> ________________________________________ > >> Hi Ayuj, > >> > >> Few comments from me. > >> > >> 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. > >> > >> > >> 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? > >> > >> [Shally] PMDs, like openssl, can support private key ops with both > >> key type 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 types. > >> 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 > between crt and mod exp rsa? > >I am not very keen on adding SIGN_CRT op type as it is RSA only. > >Another option would be to add flags to rsa op like uint64_t flags; > [Shally] Ok .. you mean as feature flag? Example, > RTE_CRYPTODEV_ASYM_FF_RSA_PRIV_KEY_OP_CRT? [AK] Yes. > > Thanks > Shally > ... > >> Regards, > >> Arek