From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 51614A0507 for ; Fri, 1 Apr 2022 16:21:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 52E6542911; Fri, 1 Apr 2022 16:21:02 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id F40BA4067E for ; Fri, 1 Apr 2022 16:20:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1648822860; x=1680358860; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WbHEHrYZhC6M+EJcBUGmYjBsBRbKpDgQ4ypdzsaDE8o=; b=VMQpT7NGwxjk+w6TAwvctVCwbrUeXfiYmr/irjc+KqtkROenuyjICfbX HnM6soO80erg72/PaQtNH74z2LZeU3aTLO9lPD1ECHaT8n5zMc3EllwLH u0WWysBNVGCdC392O1c4NZBWpp263OnLhUzZN+ITVxO1Rz7ilQjtgerL6 F/qPT9BTD1anVbFMISvgoeRyP/+5IxZmNScr+oRAbk+iCTnQ8DgbY3Q9S sXRtquFd60BL29H1PDIcl8wcH5ZB2DnQBfk49JNRpMn51HaYoItd/6I1l ULLZkZIZ1TExOFYtSsLXbtn4PDsf5HyRj6oQiFpCnWjJrsGHmPSzRmhVA Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10304"; a="346584407" X-IronPort-AV: E=Sophos;i="5.90,227,1643702400"; d="scan'208,217";a="346584407" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2022 07:20:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,227,1643702400"; d="scan'208,217";a="522790479" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by orsmga006.jf.intel.com with ESMTP; 01 Apr 2022 07:20:58 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Fri, 1 Apr 2022 07:20:58 -0700 Received: from orsmsx604.amr.corp.intel.com (10.22.229.17) by ORSMSX607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Fri, 1 Apr 2022 07:20:57 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Fri, 1 Apr 2022 07:20:57 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Fri, 1 Apr 2022 07:20:57 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VsPyOkymnzzYc5jktiwlyDb8k6nxo1isYrIFCWbFxnKxpxKYzqw5B7i4km1nDPp/5sQDFlwNN2z7DcqHQ3QIvefqLbDBNormxHBDSFbRyAXF9BdHJp9sLCwG1LNRSbath3bWJxNB9vgUDLnjK5VQwlBKB5H+H065qryJJaaMbLafMKG/1mzvm9hXg0WROnPWCrUWPUVMDZypjKcsJcr+R/S/FRAHGxEC0XZCSd03hfPaAfJAkpGFstqxEGcW2vZNnpgb+zWMyaRf8tffafS7BbP1VqaO/CM1N8wP7MVtCP1oJOZqVFB1VpcT7CLHpGQz1mPOXBZOpki4mNKv9Wmz1w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZjBqh+KEYKxgbWzJxzZaovxKHdXGhRubEQkKJq8gTf0=; b=odkEj15HzyF8qkCn08p34sx5e4OzYRyPbl4XqnySxcfo/c7S/zpsfqrpvoRCyPEp4HtUVTnbn36P9p50W198Ywu2RBhx55B1vZgKbVav/pHVflk/OmLnVxNnoMCMV1AyWCEFa0oci9zU/dEPJAep2UMYdvQUri793wS5QYzSo3L8966Hl2cEJSzeaqDjiZkWkZI4Dd3BYQ0AgyvnF4KxlyZ+pMK2jEdBNVSs0vXRkl5UJxPwsLavrCWCuT2d1+6DVKX+gpLLemapJNYY6BzhGwwYQWFSf/c/jwSG2SgrD0ALWJSOsjsGRT8Wl5ZoNg0bGjXlF/Un3uKq6ASNr9G94w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from SN6PR11MB3408.namprd11.prod.outlook.com (2603:10b6:805:bc::22) by MWHPR11MB1453.namprd11.prod.outlook.com (2603:10b6:301:c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.28; Fri, 1 Apr 2022 14:20:52 +0000 Received: from SN6PR11MB3408.namprd11.prod.outlook.com ([fe80::2838:cc73:c54:7d7c]) by SN6PR11MB3408.namprd11.prod.outlook.com ([fe80::2838:cc73:c54:7d7c%7]) with mapi id 15.20.5123.026; Fri, 1 Apr 2022 14:20:52 +0000 From: "Ji, Kai" To: "Kusztal, ArkadiuszX" , ossama ahmed , "users@dpdk.org" CC: "Zhang, Roy Fan" Subject: RE: OpenSSL Crypto Poll Mode Driver Thread-Topic: OpenSSL Crypto Poll Mode Driver Thread-Index: AQHYRa5kOEuGDhcdxUeKvNPpYAQuUqza6MSIgAAjG+CAAAvd4A== Date: Fri, 1 Apr 2022 14:20:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fae7e8a5-6cb5-453e-adef-08da13ead3e2 x-ms-traffictypediagnostic: MWHPR11MB1453:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TNiG13owvGGWReHfKS81gmtQDVnDeuvtvxdM0uFx39+g+Wkwwoih2FDu0oHL0odtJ04aHHKrbVvTbChS3/77HXcSXqsBVn72A/b1LD4DaAsk5XqLVY4jdCLPufAg4n9uDjZ1b1qTm0MqpyCoBz1MQ9/3JbsanX/amoNtSDrYfY4w7yO8V9atX2LHKDPUOGx53iY8zCcCONB5sFte0LVZrnydrBgdWB9bAGYkQlnOufsz3y6jeWiDqNWV6IyRPkmGjT7hWLJq5MtHrTdX4F7XNzswS1qmMAEnnP1ZpRGvNp5+JzlgAI8TWUdib+OWTvvS9dKmlUBVKAiUHqoPgU7dIyoWa5wnfEsrHuvSdkXsxjoOyDO8CkfcxTJ2KkSaR6U4RVFgRbISksFo6TuMR0F1SpDPcxEfYm52RHHLYWrn2X0nIareOiS2Khgkej8v3GVZL5rj4bYlTj3e85uu3Fv6GJ9CqDUB/IiwXtFAuWsk7OZhyGLslJhyXTiotsVF1r8wyKJ/cQhODd1Noy9qx39q4FvZr4Ln8tZBbsg/7byDVx8Y1dy95rGkg5tUngx5iuT6rr9nDc2Jna1NorefIE/UhDoy/nftd6Gdh58/uo7fBWwp+piMtbGgcloQHzCCTcItw1G8WB+WGNbrkySAV8M0I24Ww/MBtnLKbY9klZ1cjWb5NoYMrkOvLhS/3lr4kQY/cWrU+RlWjeudG3oW2UxNKGzMsycgCT64nq7H8X/6efH8wLAeLnZEBSeIiWItHLCrMRsZkMSngTI53lYOaqBYLpGSmFK/rAGL0B/Bp4exTm4sTLRk5mTpb4h6jpx7lvXlSlD9gIkA483BHGXgxOHY3sAccBTpKtVDZ4n5kWR6i8gHsKTC77DheAQR1/2HDMpk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3408.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(8936002)(5660300002)(66556008)(45080400002)(52536014)(66946007)(76116006)(64756008)(66446008)(66476007)(4326008)(71200400001)(8676002)(33656002)(966005)(508600001)(7066003)(21615005)(86362001)(107886003)(55016003)(9686003)(186003)(26005)(83380400001)(122000001)(2906002)(38100700002)(38070700005)(82960400001)(7696005)(53546011)(6506007)(166002)(110136005)(316002)(473944003)(10090945011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CCoOownr3BYM/DyvmFIWTc4bGjG36DN6LL2WErtqdtZQYFBAz92WIDtB1oUx?= =?us-ascii?Q?QMmjVmTPhMwZIk/ABUd/7bSpt8B+O5AFizweIIsCfPJwiWcpjGOc7m7qu7AM?= =?us-ascii?Q?ul9xJ94OFbE7I0OIpvmF3McD4Lx81gV+LlheVyZZG9xT8+4tZktiVic2b10O?= =?us-ascii?Q?WP7JRG/gu5KhU0ZQZNyuj+O3IfslQHQeVY4JIa2satwbXpKabuQUcrLwOpSt?= =?us-ascii?Q?5U2R/4bGU3mkqLK55jFnXvTHSll3uaKsV8GmXG2ImxvT545iJTVWsFRgv+bp?= =?us-ascii?Q?zhFv/JanCERkMJC2z4c6DWZ+twTJ6v9G+5GQrvvIN0pEZd88r2Q+pN0m1ZwY?= =?us-ascii?Q?ZhSWM3SDapTLsAvJkyJL7RudiAIPlbHSOqXS58tB+WQxubi4G8ZylO22bHFu?= =?us-ascii?Q?uHvnBBca7U7y+4foTkW9Bi1Yhhq5e31TZBy2MoruyMNu2BAb6+5PnOIAcLJo?= =?us-ascii?Q?H3UoPBQHxEaiCXzXpe8nydu7SV7lrQPJAshZZCXQXwFFKbwV4RQl5Siv5hdE?= =?us-ascii?Q?tJON1FNRhwKAtpeD6M6mBV9QPCjo09kwlmnM4r/9mczpMaX3GbkBIn6Njwkr?= =?us-ascii?Q?XQEl+inXWGqKiIORvQZ6GZHiyp2N8gf3NcRFMfejUKmBXUSCVvrwI5F6QgZe?= =?us-ascii?Q?AkCpcyeETcxkwsclBIrWA4v6HiXtuS34GcZQ2Cr7TO8SEHfAtyTzt/eHnKku?= =?us-ascii?Q?FDC6WT4EqRP/cC6eh60ggrJ3PUEFwhbejbaReyw+ugcPu9+duC6Eh3T4qIuA?= =?us-ascii?Q?L3rckPgFLcPgmvm1K7UEFn+uyuK3fGWpR6KBztBFtGqg3GMcgGr+nMSAgSz9?= =?us-ascii?Q?BKGwT5xe5HtD61iuHPKqtVXN84X5m3JBxIBkvQjHp2L+2N55/aCi/LxsawGZ?= =?us-ascii?Q?NmbFbcpkdhQ+/dk3JAjcwhHhJL+irkb0GTxb6g1x0isGgBxpXYUTt4ZYSV10?= =?us-ascii?Q?XGevI+sbteqz7sPQJB6sKuRUoacIoyDR3nwFNssshuLWNo2+uop+pVEKBv3m?= =?us-ascii?Q?d9seEJAY+7TUx+/lJucGU1iW/hrTAEz5TUskGCA7BNI4TuLUEQr+eBmFMLHs?= =?us-ascii?Q?2eBSyHFGa2W7GEscyE6BflRMjxAUFRAlzh4yj0Qo0DXBwnZN+ZTZK20YAkwJ?= =?us-ascii?Q?vXwBmnLSDXfzmCkTFMoKZILJeAOlTjgbcAu7UVTa4/HAhn8z8WObTAW2Rm4+?= =?us-ascii?Q?J9+p3+yogw8zKKdmdlPGLCI74G7ySoqLssabV/x4eNZbsyy3IY3T50w9xAoa?= =?us-ascii?Q?w7/ZdanSJFqASmQn+y49iCECRGOcgoIgzOtKtJspVAe9GBeDMTPOQctfeIcS?= =?us-ascii?Q?+Ctgm4QA9q0hXEHEvWvR9wa5pHdeNLJ0qUEgqrd5wXdTAhoOrjmPX0pUv2sX?= =?us-ascii?Q?WqHVOA4SwiSpmrmT3WSFmriHG8N8GnlIVDVZzwy5KDJK/ui29bZ2NpBCHB5r?= =?us-ascii?Q?Y1hVGE7se6hlk50uGf3cZ2+gZlrkdSumVYIh5rlWSnjXZ/KWRFm2XZi/9gPF?= =?us-ascii?Q?NAoO2mdXKTm/uWHfMgafgS/Mb95v+B0k0XGtGd3ima5r8LlKYXOemWn+bmJO?= =?us-ascii?Q?KXpeKyeVskYGPfafJgAwOia7xtnlv/BoLR0XsTS07yYXxxPGrUXUjTxesFbo?= =?us-ascii?Q?IqOjA5Wn6T3kVaf7KbkZj5LEWSXyVSAwqEI5Krlkxs/M3CglJNtvRuvUsqnc?= =?us-ascii?Q?EFYhvlw1k5mya1SxpVLwyfhX0zF7hBOEd0SU/ie4n8H+3eQvD90e7ZWA5JNI?= =?us-ascii?Q?+uu9GlG+2g=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SN6PR11MB3408D2621FA46889F200FD8981E09SN6PR11MB3408namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3408.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fae7e8a5-6cb5-453e-adef-08da13ead3e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2022 14:20:52.2438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bZYBSe66Mk6ETu/QKxjJQ+IX9DpgEkz0T62czJr/J01IjT/FLiKtW0p0Osu9KhkVBJ5n7hmvrTH1uXs4jv8HDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1453 X-OriginatorOrg: intel.com X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --_000_SN6PR11MB3408D2621FA46889F200FD8981E09SN6PR11MB3408namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI: The support of Openssl 3.0 lib in Openssl cryptodev PMD is working in= progress, the following API changes current made into RSA routine in PMD: Deprecated RSA_private_encrypt() & RSA_public_decrypt() replaced with EVP_= PKEY_encrypt() & EVP_PKEY_decrypt() for rsa enc/dec ops Deprecated RSA_sing() & RSA_verify() replaced with EVP_PKEY_sign() & EVP_= PKEY_verify_recover() for rsa sign/verfy ops The EVP APIs offer flexible configurations where digest algorithm/ padding = can be defined. E.g: EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256() Regards Kai From: Kusztal, ArkadiuszX Sent: Friday, April 1, 2022 2:41 PM To: ossama ahmed ; users@dpdk.org Cc: Zhang, Roy Fan ; Ji, Kai Subject: RE: OpenSSL Crypto Poll Mode Driver Hi Ossama, Please see answers inline with [Arek] From: ossama ahmed > Sent: Friday, April 1, 2022 1:18 PM To: users@dpdk.org Subject: Fw: OpenSSL Crypto Poll Mode Driver Sent from Outlook ________________________________ From: ossama ahmed Sent: Friday, April 1, 2022 11:10 AM To: users-request@dpdk.org > Subject: OpenSSL Crypto Poll Mode Driver Hello, I would like to highlight following issues in OpenSSL Crypto Poll Mode Driv= er and OpenSSL vdev related to RSA Sign and Verify operations. ISSUES: ISSUE1 (RSA_private_encrypt and RSA_public_decrypt) With respect to https://www.openssl.org/docs/manmaster/man3/RSA_private_enc= rypt.html .Both of the functions are deprecated. Applications should instea= d use EVP_PKEY_sign_init_ex, EVP_PKEY_sign, EVP_PKEY_verify_recover_init, a= nd EVP_PKEY_verify_recover. Although I understand that due to compatibility reasons, DPDK is using nati= ve (in my case on Ubuntu 20.04.1 its 1.1.1f version of) OpenSSL but With re= spect to OpenSSL's version 1.1.1f APIs "RSA_private_encrypt" and "RSA_public_decr= ypt" but in case of RSA_PKCS1_PADDING it is recomended that when generating= or verifying PKCS #1 signatures, RSA_sign(3) and RSA_verify(3) should be used. POSSIBLE SOLUTION 1. Use RSA_sign, RSA_verify, EVP_DigestSignFinal, EVP_DigestSign etc instea= d. [Arek] - RSA_sign and RSA_verify are now deprecated too. 2. Append algorithm identifier field to digest before signing. Details can = be found in section EMSA-PKCS1-v1_5 availbel on https://datatracker.ietf.or= g/doc/html/rfc8017#section-9.2 For example in case if RSA is using SHA256 for digest generation then Diges= tInfo value is: SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 || H = where H is the digest of data Hence appropriate AIDs (i.e algorithm identifiers) must be appended to dige= st. Once this done then in case of RSA_PKCS1_PADDING, APIs RSA_private_encr= ypt and RSA_public_decrypt are compatible with RSA_sign, RSA_verify, EVP_Di= gestSignFinal, EVP_DigestSign and verify respectively. [Arek] - yes, you are perfectly correct, this Is general Cryptodev API prob= lem. Proposals to fix that were sent already: https://patchwork.dpdk.org/project/dpdk/list/?series=3D22203. When PKCS1 we should not worry about algorithmIdentifier from user perspect= ive, although there was an option to do PKCS1 padding without it too (pre t= ls1.2 PKCS1.5 padding was used with 36 bytes hash concatenation for example= ), discussion was started on dev mailing list. As for OpenSSL PMD simultane= ously we are working to fix that. ISSUE2 (OpenSSL Crypto Poll Mode Driver vs RSA PSS Padding) Current DPDK's OpenSSL Crypto Poll Mode Driver fails to verify signature ge= nerated using RSA PSS Padding. Also with respect to latest version of DPDK = there is no handling available in OpenSSL Crypto Poll Mode Driver for RTE_C= RYPTO_RSA_PADDING_PSS. Current implementation handles only RTE_CRYPTO_RSA_P= ADDING_NONE and RTE_CRYPTO_RSA_PADDING_PKCS1_5 for signing and verification. [Arek] - yes, PSS should be implemented too. Registration of openssl random= engine should allow us to check known answer tests too not only PWCT, coul= d you resend your proposal to dev list? 1. EVP_DigestSignFinal, EVP_DigestSign etc instead. 2. As coded in OpenSSL (crypto/rsa/rsa_pmeth.c +268): else if (rctx->pad_mode =3D=3D RSA_PKCS1_PSS_PADDING) { int ret; if (!setup_tbuf(rctx, ctx)) return -1; ret =3D RSA_public_decrypt(siglen, sig, rctx->tbuf, rsa, RSA_NO= _PADDING); if (ret <=3D 0) return 0; ret =3D RSA_verify_PKCS1_PSS_mgf1(rsa, tbs, rctx->md, rctx->mgf= 1md, rctx->tbuf, rctx->saltlen); [Arek] - whole openssl low level api is deprecated now, these functions as = well so we wont be using it. if (ret <=3D 0) return 0; return 1; } However, in order to use above implementation changes are required in OpenS= SL Crypto Poll Mode Driver (drivers/crypto/openssl/rte_openssl_pmd.c +1945)= for example case RTE_CRYPTO_ASYM_OP_VERIFY: tmp =3D rte_malloc(NULL, op->rsa.sign.length, 0); if (tmp =3D=3D NULL) { OPENSSL_LOG(ERR, "Memory allocation failed"); cop->status =3D RTE_CRYPTO_OP_STATUS_ERROR; break; } ret =3D RSA_public_decrypt(op->rsa.sign.length, op->rsa.sign.data, tmp, rsa, pad); OPENSSL_LOG(DEBUG, "Length of public_decrypt %d " "length of message %zd\n", ret, op->rsa.message.length); //FIXME if(pad =3D=3D RSA_NO_PADDING && ret) memcpy(op->rsa.message.data, tmp, op->rsa.sign.leng= th); else if ((ret <=3D 0) || (CRYPTO_memcmp(tmp, op->rsa.messag= e.data, op->rsa.message.length))) { OPENSSL_LOG(ERR, "RSA sign Verification failed"); cop->status =3D RTE_CRYPTO_OP_STATUS_ERROR; } //FIXME rte_free(tmp); break; Complete details are availble in section 8.1.2 of https://d= atatracker.ietf.org/doc/html/rfc8017#section-8.1.2 I have handled the above mentioned issues in DPDK using my own custom imple= mentation. I would love to share details if required for further clarificat= ion Regards, Ossama Ahmed Mughal --_000_SN6PR11MB3408D2621FA46889F200FD8981E09SN6PR11MB3408namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI:  The support of Openssl 3.0 lib in Openssl= cryptodev PMD is working in progress, the following API changes current ma= de into RSA routine in PMD:

 

Deprecated RSA_private_encrypt(= ) & RSA_public_decrypt()  replaced with EVP_PKEY_encrypt() & EVP_PKEY_decrypt() for rsa enc/dec ops=

Deprecated  RSA_sin= g() & RSA_verify() replaced with  EVP_PKEY_sign() & EVP_PKEY_v= erify_recover() for rsa sign/verfy ops

 

The EVP APIs offer flexible configurations where dig= est algorithm/ padding can be defined. E.g:

 

EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING)=

EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()=

 

Regards

 

Kai

 

From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
Sent: Friday, April 1, 2022 2:41 PM
To: ossama ahmed <ossamaahmedmughal@hotmail.com>; users@dpdk.o= rg
Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Ji, Kai <kai.= ji@intel.com>
Subject: RE: OpenSSL Crypto Poll Mode Driver

 

Hi Ossama,

 

Please see answers inline with = [Arek]

 

From: ossama ahmed <ossamaahmedmughal@hotmail.com>
Sent: Friday, April 1, 2022 1:18 PM
To: users@dpdk.org
Subject: Fw: OpenSSL Crypto Poll Mode Driver

 

 

 

Sent from Outl= ook

From:<= /span> ossama ahmed
Sent: Friday, April 1, 2022 11:10 AM
To: users-request@dpdk.org= <users-request@dpdk.org>
Subject: OpenSSL Crypto Poll Mode Driver=

 

Hello,

 

I would like to highlight follo= wing issues in OpenSSL Crypto Poll Mode Driver and OpenSSL vdev related to = RSA Sign and Verify operations.

 

ISSUES:

ISSUE1 (RSA_private_encrypt = and RSA_public_decrypt)

 

With respect to https://www.openssl.org/docs/manmaster/man3/RSA_private_encrypt.html .B= oth of the functions are deprecated. Applications should instead use EVP_PK= EY_sign_init_ex, EVP_PKEY_sign, EVP_PKEY_verify_recover_init, and EVP_PKEY_= verify_recover.

 

Although I understand that due = to compatibility reasons, DPDK is using native (in my case on Ubuntu 20.04.= 1 its 1.1.1f version of) OpenSSL but With respect

to OpenSSL's version 1.1.1f API= s "RSA_private_encrypt" and "RSA_public_decrypt" but in= case of RSA_PKCS1_PADDING it is recomended that when generating or verifyi= ng

PKCS #1 signatures, RSA_sign(3)= and RSA_verify(3) should be used.

 

POSSIBLE SOLUTION=

1. Use RSA_sign, RSA_verify, EV= P_DigestSignFinal, EVP_DigestSign etc instead.

 

[Arek] – RSA_sign and RSA= _verify are now deprecated too.

 

2. Append algorithm identifier = field to digest before signing. Details can be found in section EMSA-PKCS1-= v1_5 availbel on https= ://datatracker.ietf.org/doc/html/rfc8017#section-9.2<= /p>

 

For example in case if RSA is u= sing SHA256 for digest generation then DigestInfo value is:

SHA-256: (0x)30 31 30 0d 06 09 = 60 86 48 01 65 03 04 02 01 05 00 04 20 || H where H is the digest of data

Hence appropriate AIDs (i.e alg= orithm identifiers) must be appended to digest. Once this done then in case= of RSA_PKCS1_PADDING, APIs RSA_private_encrypt and RSA_public_decrypt are = compatible with RSA_sign, RSA_verify, EVP_DigestSignFinal, EVP_DigestSign and verify respectively.

 

 

[Arek] – yes, you are per= fectly correct, this Is general Cryptodev API problem. Proposals to fix tha= t were sent already:

https://patchwork.dpdk.org/projec= t/dpdk/list/?series=3D22203.

When PKCS1 we should not worry = about algorithmIdentifier from user perspective, although there was an opti= on to do PKCS1 padding without it too (pre tls1.2 PKCS1.5 padding was used = with 36 bytes hash concatenation for example), discussion was started on dev mailing list. As for OpenSSL PMD s= imultaneously we are working to fix that.

 

 

ISSUE2 (Open= SSL Crypto Poll Mode Driver vs RSA PSS Padding)

Current DPDK's OpenSSL Crypto P= oll Mode Driver fails to verify signature generated using RSA PSS Padding. = Also with respect to latest version of DPDK there is no handling available = in OpenSSL Crypto Poll Mode Driver for RTE_CRYPTO_RSA_PADDING_PSS. Current implementation handles only RTE_CRYPTO= _RSA_PADDING_NONE and

RTE_CRYPTO_RSA_PADDING_PKCS1_5 = for signing and verification.

 

[Arek] – yes, PSS should = be implemented too. Registration of openssl random engine should allow us t= o check known answer tests too not only PWCT, could you resend your proposa= l to dev list?

 

1. EVP_DigestSignFinal, EVP_Dig= estSign etc instead.

 

2. As coded in OpenSSL (crypto/= rsa/rsa_pmeth.c +268):

else if (rctx->pad_mode =3D= =3D RSA_PKCS1_PSS_PADDING) {

        &nb= sp;   int ret;

        &nb= sp;   if (!setup_tbuf(rctx, ctx))

        &nb= sp;       return -1;

        &nb= sp;   ret =3D RSA_public_decrypt(siglen, sig, rctx->tbuf, rsa, RSA_= NO_PADDING);

        &nb= sp;  

        &nb= sp;   if (ret <=3D 0)

        &nb= sp;       return 0;

        &nb= sp;   ret =3D RSA_verify_PKCS1_PSS_mgf1(rsa, tbs, rctx->md, rctx-&g= t;mgf1md, rctx->tbuf, rctx->saltlen);

[Arek] – whole openssl lo= w level api is deprecated now, these functions as well so we wont be using = it.

        &nb= sp;   if (ret <=3D 0)

        &nb= sp;       return 0;

        &nb= sp;   return 1;

        }

However, in order to use above = implementation changes are required in OpenSSL Crypto Poll Mode Driver (dri= vers/crypto/openssl/rte_openssl_pmd.c +1945) for example<= /p>

 

       case= RTE_CRYPTO_ASYM_OP_VERIFY:

        &nb= sp;       tmp =3D rte_malloc(NULL, op->rsa.sign.length, 0= );

        &nb= sp;       if (tmp =3D=3D NULL) {

        &nb= sp;               OPENSSL_LOG(ERR, "= ;Memory allocation failed");

        &nb= sp;               cop->status =3D RTE= _CRYPTO_OP_STATUS_ERROR;

        &nb= sp;               break;

        &nb= sp;       }

        &nb= sp;       ret =3D RSA_public_decrypt(op->rsa.sign.length,=

        &nb= sp;                     &= nbsp; op->rsa.sign.data,

        &nb= sp;                     &= nbsp; tmp,

        &nb= sp;                     &= nbsp; rsa,

        &nb= sp;                     &= nbsp; pad);

 

        &nb= sp;       OPENSSL_LOG(DEBUG,

        &nb= sp;                     &= nbsp; "Length of public_decrypt %d "

        &nb= sp;                     &= nbsp; "length of message %zd\n",

        &nb= sp;                     &= nbsp; ret, op->rsa.message.length);

        &nb= sp;       //FIXME

        &nb= sp;       if(pad =3D=3D RSA_NO_PADDING && ret)

        &nb= sp;               memcpy(op->rsa.mess= age.data, tmp, op->rsa.sign.length);

        &nb= sp;       else if ((ret <=3D 0) || (CRYPTO_memcmp(tmp, op= ->rsa.message.data,

        &nb= sp;                     &= nbsp; op->rsa.message.length))) {

        &nb= sp;               OPENSSL_LOG(ERR, "= ;RSA sign Verification failed");

        &nb= sp;               cop->status =3D RTE= _CRYPTO_OP_STATUS_ERROR;

        &nb= sp;       }

        &nb= sp;       //FIXME

        &nb= sp;       rte_free(tmp);

        &nb= sp;       break;

        &nb= sp;       

        &nb= sp;       Complete details are availble in section 8.1.2 of htt= ps://datatracker.ietf.org/doc/html/rfc8017#section-8.1.2

 

 

I have handled the above mentioned issues in DPDK using my own cust= om implementation. I would love to share details if required for further cl= arification

 

Regards,

Ossama Ahmed Mughal

 

--_000_SN6PR11MB3408D2621FA46889F200FD8981E09SN6PR11MB3408namp_--