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 4BF9CA0507 for ; Fri, 1 Apr 2022 15:41:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1CF6442911; Fri, 1 Apr 2022 15:41:26 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 97FEA4067E for ; Fri, 1 Apr 2022 15:41:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1648820483; x=1680356483; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=q9vxOi6/352Ymap+pc9k4PVyAHfANyo64eN+g1F2PFI=; b=lWD32bGk+rj5oMhwEwIx7bfV7FOx17wk9jWYEqK4Dlzd0lKwh7W8G7k0 ClTt5U1dEHaGhZ2zAgb2GupF1MYEzXmZ5aaTLubrcnaKoSJusiXX7G7JF lbQ3/Pqakd8kbtMFGhGcISugFrYdXzBWwbWr9si7DCA366LetgIokrgEd oSsS3QGy/Tw2UlYwp9iE52b5gPR1egRFHzxkQyBT1ktQAJHl9Airkzzkr H9OdL4UI8wH1RrUS3oj0XUBUhiK6e3rCi1WGBqJcXu9gM91CaAyJ2IBGo 7qOAkHBRuiVObci4O7Y9UtcChEl1rBWbkjV8OHjtZ+xTX+JUCNLllzy2l w==; X-IronPort-AV: E=McAfee;i="6200,9189,10304"; a="242283841" X-IronPort-AV: E=Sophos;i="5.90,227,1643702400"; d="scan'208,217";a="242283841" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2022 06:40:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,227,1643702400"; d="scan'208,217";a="655729244" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga004.jf.intel.com with ESMTP; 01 Apr 2022 06:40:59 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx601.amr.corp.intel.com (10.18.126.81) 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 06:40:59 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx603.amr.corp.intel.com (10.18.126.83) 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 06:40:59 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.174) by edgegateway.intel.com (192.55.55.71) 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 06:40:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P+5VtpTIfUc7yMstzwle1yZBUETGrcXSt48fftjLNCFruTZZOdpjXNbwVTxbGKAG5uP3mvjApn7Wzjr9wBkhzuIrSxNT+wOu96I2mfyadszFjeoyg75fq5ZVpbdB9rWbdC2p7cIkdzRqSkwIURUXKTC5IOi5UhgCFpw+Rkfn2CstgGNWux6FhNUdefk+vvWSXzgAJZQ04TLfrHyYaxJoC7LVGL0nWMcLnrPjCxKpL3YZE/oW+sEZE8L4RhyFOuzAlfdeRX8S/A6HbL9vfRDI1pFNF/rFcfnMNCn261FD2qr2DPhEvyL6dx6ilgdznQ1cwIAeRZO43yuyfAvCYkhVIg== 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=lLdS5JvTn+PaEA+QPPT8p4UEODHzHIW0cjslY3VvHoc=; b=QSEEvmRWdGQ9gFgvBiOtpdLesXvxYHqYoW3FyO6+cguWixapkC0K1mzUDVtM6GX0OA/ISnIm7d0TmcucKImRu1tJRbCmAQtc+cdlBZMrWUGx76S5eyuQ2lbIczs3L0lDL+CKMq1whnmBiI2vEGUD7YU5BgS1zYmcKVAw/EIO7+81PDlZ9+64VZjQZMuK9ZNzcmTuxsG1/2SqNLHzApNG+6G+3pTQnZ5urjMi9m936iZ6YsV98/eoiImeNoOEDEXTYR2xNibESLpEWKDeca3dtIHLAF0HPdGL2z7z/w6ZZ3sM3r/fKG75/9NuNOmDmJMNrH2Kcvr0m/A6/WffdAyRlA== 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 PH0PR11MB5013.namprd11.prod.outlook.com (2603:10b6:510:30::21) by CY4PR11MB1542.namprd11.prod.outlook.com (2603:10b6:910:5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.21; Fri, 1 Apr 2022 13:40:57 +0000 Received: from PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::8189:36b8:ed0e:2501]) by PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::8189:36b8:ed0e:2501%6]) with mapi id 15.20.5102.023; Fri, 1 Apr 2022 13:40:57 +0000 From: "Kusztal, ArkadiuszX" To: ossama ahmed , "users@dpdk.org" CC: "Zhang, Roy Fan" , "Ji, Kai" Subject: RE: OpenSSL Crypto Poll Mode Driver Thread-Topic: OpenSSL Crypto Poll Mode Driver Thread-Index: AQHYRa5kOEuGDhcdxUeKvNPpYAQuUqza6MSIgAAjG+A= Date: Fri, 1 Apr 2022 13:40:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: 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: 0628ed2b-d1af-4986-f58a-08da13e54037 x-ms-traffictypediagnostic: CY4PR11MB1542: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: /mFWcKNYPSa4XS4QEZcAwtOO36kx0ccF2eTwhARdFaWn34JMxjxnaTO4J4Utl4BrJvhcM6Dh6Knzu5xh6ToDnK7Pc9RhaKuTnej2F4p57blfG1OACt6tOH7kMAdkej8YQX6jRK6raXbCVyE167KEodn5h+AWBjHm+fb0P2sCDG+s8G4QjTO9gJqUkbonkgWF+7lEpRnO2CfReoJOgfexvb9Bm2i3KWIV0daRELKIPvfpufOPGLi6Itjk8loorJm3xLFiAwDBhz8wYe3eqpUeJjZ1uyuxwDp/O6FHrPWrAXt9+qONUBM+7ynmQ70y7iVIZU85/o8uHVaw3ETnXYroEkh4Y1jU4LAp7eu+ypqIz2e8uIBF2c8c7lNLOuNoRxaT6RaXFzMm68UWgIpZnkNvzTDZgPpmZMyTPZZXSdgf7Uid7d5gb/Y/zjaU7Cc7Ch3sEj3dJVsnoSUKUBTz63hpUX54ZZrFeKG4Sa8NEofD22JpCYfMsvQq6WH4gM8yJ41IXVbTAQKL11Bo4OElWkZa1JNUnFq/h3cTH2FTlby6WpRNMg0NmgT+9BLz6qxbny/OLYZ9A+qE/4cgHUGUzHy2Dtm4wVb2hCTCeshbm/Y7by/zAUsxy/56P5Dp97hQPxRTd1eM7/V2FxDIjO7zO1AVuNaTCD4U37tAxacj4sdnDWRVwW4819R3AYkozGsQUyu1dUvAM8ZS3h9BIorP0DAnSAtOiQ1xh/csHkJPOfH+0scCLDLneR+ZEV7wNdgcrdALseG5KUBkWf2NESzRj5bSrrg09HgGMgHXTA6RNVpqHy3facsDCTjLP9zHkLCtpHYrJ1KVVzPhE4skX/FvYWxotXl7L95gCOn0YqTIw81NRoRRBnsDfBWxyYWVdaF7SYR/ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5013.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(53546011)(6506007)(110136005)(66946007)(7696005)(76116006)(2906002)(71200400001)(66446008)(316002)(66476007)(64756008)(86362001)(4326008)(54906003)(9686003)(8676002)(166002)(66556008)(45080400002)(7066003)(82960400001)(21615005)(122000001)(508600001)(5660300002)(8936002)(966005)(38070700005)(38100700002)(33656002)(83380400001)(107886003)(55016003)(9326002)(26005)(52536014)(186003)(473944003)(10090945011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?m/zmhEawyx2fajXpOqxm3SHVQE0NMFyWKKNmX/XPkZOTbnUpIKZvGe2VwR5+?= =?us-ascii?Q?6nl8ebzaS5gpSJ9b74cDKq22R4/v0L11Q4yDrU53BbmtJDHbAXfFf97CnrnA?= =?us-ascii?Q?rHhb2QAcxz8QZQO1Dl+d2e4+shzZHhDrbLCA8N/2Vd42IajizrxEClUk9MQ8?= =?us-ascii?Q?0bm5R/Nua5vkU1dcmO2T1/32mgV+fdlsFGSbyVYpFMBYc/tzcP4c3a8acV6J?= =?us-ascii?Q?PRmO5KaDZybR7Ntm3nBuMOQ/0nrrwOK4ZhmpIWd5A2g7dISmnbggovcUgMl1?= =?us-ascii?Q?kUOxQd02P4cFm9w69+dFjKxsIncn3dX49Je4JO7qZzzDuj5MHtR506GZ0uK5?= =?us-ascii?Q?gjHTTDL8RYxtMv9grueMW2E7oj32DsqaazUSuNH8VzjhGIU0JPpWo42PG5x+?= =?us-ascii?Q?3rkATIIsJnH+Q7wAFHf6e9kymT4cEKUEMINDX0bntSuoBKu0KVSY0Opcidjk?= =?us-ascii?Q?zdjVjbzg6nKucr4lycYLiKyL3u3+8HVSRiuPJknVOKROAmHTsNdSsF4cr+Bh?= =?us-ascii?Q?FW7Oe2HkrPQwq+cq2eAbOjfRONXhDgM3ULQ0zlyITwXHdLmMB1n/xzygTkjB?= =?us-ascii?Q?735GF+HpjlRSydkS41g6CEBaYtHrXD4fRqSTYYK9D1WTBsTEMLd7tLk2Y7au?= =?us-ascii?Q?wtlU2P5qtXeGYNi986QCabwmQInIx0czrw2lj6G3Dmq8D8UYQjBSdf6f9QEB?= =?us-ascii?Q?++cdnVWHLRig1igMpPHxL7y8+cTjEnM3iOvU0BT1kEvpiE/0BZuf4ipLUXjB?= =?us-ascii?Q?4PR4RS+x++KxTvWs87bI9VDkmK95vXQkuYU5T2ZYwz3UhWi+lyJd6EZDGVNX?= =?us-ascii?Q?bwbLfGgP9i5w3YpzdXkLDx4AJNfollw6x9nLHkzjC8rMEe9EsPKQ1z3/wAQ2?= =?us-ascii?Q?HGL1i2fABdNjAoYvDCLSi1CunH29mCiHYRg+b2bTqb7pn45lrmfaXiT/P8W/?= =?us-ascii?Q?8PMIj5FJVXuBLHqsornEsXugQHthH5JsRKzuNTCjqdTGENMyCZxMK8RY0CW2?= =?us-ascii?Q?IJn87jSJG5J90e7mw7nNyHop3jGKgBd9aWTqdFHPm2owdgxBvM+pC0DAnOiE?= =?us-ascii?Q?AJzQjGkv1bVRQ0PYi9oEYePNxzsqCip4Ls1ctagNv/NQPiM4j2tLWbnXfiyK?= =?us-ascii?Q?FV6tWi9ohmHwxmk3wWQI8/DgOiPdPnJ7A94NeY1BgFDGvuz7ACm60RCm60s8?= =?us-ascii?Q?82GJN0F/Or9+jrQ04vryE8sQKsuwDN/US1GepM1bF0rP5rqiDQNXw+nLcJSs?= =?us-ascii?Q?EgQ+N+vvOB34uCz7ELkvImuXcEGLlqGkloADQynY7xzq+5gXA35lHtTrSoZ4?= =?us-ascii?Q?y/EFHQF4IPb2bR/jeb5fOnCmmRDNi6JirhOyf4Q8le+R8lgVkcX1Sz2CM1Ic?= =?us-ascii?Q?yV7miIKuUAfmKYVDas/wbQCQXSWICRSHUv3MeN6gUOkuVWQkBZOUobNQSAu3?= =?us-ascii?Q?dgnGjVusQ6x/JTsEJtERCI3Mec9XUZZ0Rgxouz95p8aygCtKSs8OAb77CpxL?= =?us-ascii?Q?IIGPCRwnbwWJ90GKZfGmld7N9YN9NiIvDDJeN+QpvAh3xTsdn3ByRzHma2GX?= =?us-ascii?Q?OapjlenOum9O2lyXS/KJg4A47aXxtXRzdnaCw/gTZlR8cTUkx43Wz5BHWQI8?= =?us-ascii?Q?ChQy+7ZyOu00IMtH5sWtjvvW73d8GoW0bnPZ4gayDccPbJz1+tALK1yzgMDK?= =?us-ascii?Q?0nnVKJhhhIKmnNthU3h3stlb90WlAz+mob9ylF3iWrrujxWE3HYSUcKvpeoS?= =?us-ascii?Q?Hg7QFlGlD40B4YzY3HwW4MOb3I84t10=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB50131EFB407F9C0BED35653D9FE09PH0PR11MB5013namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5013.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0628ed2b-d1af-4986-f58a-08da13e54037 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2022 13:40:57.1256 (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: RvdceayDNkekjG9rXu66kcp67FcptthbYjQiDO2LnO6sk04zDj6NfWLIXnYLDJZqs7KdHxdD3PuHvHu04lm+Y0KJn4fbJiUXjEjSAFNujzo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1542 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_PH0PR11MB50131EFB407F9C0BED35653D9FE09PH0PR11MB5013namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_PH0PR11MB50131EFB407F9C0BED35653D9FE09PH0PR11MB5013namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ossama,

 

Please see answers inline with [Arek]

 

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

 

&n= bsp;

&n= bsp;

Sent from Outlook

Hello,

 

I would like to highlight following issues in OpenSS= L Crypto Poll Mode Driver and OpenSSL vdev related to RSA Sign and Verify o= perations.

 

ISSUES:

ISSUE1 (RSA_private_encrypt and RSA_public_decryp= t)

 

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 reas= ons, 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 APIs "RSA_private_e= ncrypt" and "RSA_public_decrypt" but in case of RSA_PKCS1_PA= DDING it is recomended that when generating or verifying

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

 

POSSIBLE SOLUTION

1. Use RSA_sign, RSA_verify, EVP_DigestSignFinal, EV= P_DigestSign etc instead.

 

[Arek] – RSA_sign and RSA_verify are now depre= cated too.

 

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

 

For example in case if RSA is using SHA256 for diges= t 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 algorithm identifiers) m= ust 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_s= ign, RSA_verify, EVP_DigestSignFinal, EVP_DigestSign and verify respectively.

 

 

[Arek] – yes, you are perfectly correct, this = Is general Cryptodev API problem. Proposals to fix that were sent already:<= o:p>

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

When PKCS1 we should not worry about algorithmIdenti= fier from user perspective, although there was an option to do PKCS1 paddin= g without it too (pre tls1.2 PKCS1.5 padding was used with 36 bytes hash co= ncatenation for example), discussion was started on dev mailing list. As for OpenSSL PMD simultaneously 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 generated using RSA PSS Padding. Also with respect to = latest version of DPDK there is no handling available in OpenSSL Crypto Pol= l 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 verif= ication.

 

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

 

1. EVP_DigestSignFinal, EVP_DigestSign etc instead.<= o:p>

 

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

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

            int ret;

            if (!setup= _tbuf(rctx, ctx))

              &nb= sp; return -1;

            ret =3D RS= A_public_decrypt(siglen, sig, rctx->tbuf, rsa, RSA_NO_PADDING);

           

            if (ret &l= t;=3D 0)

              &nb= sp; return 0;

            ret =3D RS= A_verify_PKCS1_PSS_mgf1(rsa, tbs, rctx->md, rctx->mgf1md, rctx->tb= uf, rctx->saltlen);

[Arek] – whole openssl low level api is deprec= ated now, these functions as well so we wont be using it.

            if (ret &l= t;=3D 0)

              &nb= sp; return 0;

            return 1;<= o:p>

        }

However, in order to use above implementation change= s are required in OpenSSL Crypto Poll Mode Driver (drivers/crypto/openssl/r= te_openssl_pmd.c +1945) for example

 

       case RTE_CRYPTO_ASYM_OP_V= ERIFY:

              &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 fa= iled");

              &nb= sp;         cop->status =3D RTE_CRYPTO_OP_STATUS_ERR= OR;

              &nb= sp;         break;

              &nb= sp; }

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

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

              &nb= sp;                 tmp,=

              &nb= sp;                 rsa,=

              &nb= sp;                 pad);

 

              &nb= sp; OPENSSL_LOG(DEBUG,

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

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

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

              &nb= sp; //FIXME

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

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

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

              &nb= sp;                 op->rsa.mess= age.length))) {

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

              &nb= sp;         cop->status =3D RTE_CRYPTO_OP_STATUS_ERR= OR;

              &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

&n= bsp;

&n= bsp;

I have = handled the above mentioned issues in DPDK using my own custom implementati= on. I would love to share details if required for further clarification

&n= bsp;

Regards= ,

Ossama = Ahmed Mughal

 

--_000_PH0PR11MB50131EFB407F9C0BED35653D9FE09PH0PR11MB5013namp_--