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 2D677A0507 for ; Fri, 1 Apr 2022 13:17:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E302B42911; Fri, 1 Apr 2022 13:17:36 +0200 (CEST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-oln040092075089.outbound.protection.outlook.com [40.92.75.89]) by mails.dpdk.org (Postfix) with ESMTP id 16F384067E for ; Fri, 1 Apr 2022 13:17:35 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZWMpKkRvWjpQvCbsZ1fIg5WughJNHdzxaBgYiizy3+wOM5fDiE/Skka62brUjIR46LGDBSKgMF/p2He3HvsWyPrHSvE6zYHjMvfygZXFOA6sgHrI4hDKNuugJP8FXG1OewB7tBwie48GMYhDnaVCQ2DFzU4NbgLVzL0UQWrsd6MaWeBVplO/AzNY+82ohUTDuRi6EQmQLVudNvTEojdaP+u9gfmywS8ccS/ZQBB51ohIptMzMDVr/sHyUSmc/7xUahM3zqDSTuNZDfCr1Ht+RnH0rjalr9ZBXt1aiD3ngK1ibvL9XzRYdkJp0r0YT0o73UnTXuUg5jMwmSp+mzHb1w== 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=tG51sX2mZMIxRs8mxmhXg91IvTw8GZQ1VEZiRQ4pQOY=; b=GT1Dif2PUAyPO5+eOZrcJZZ1NfU5fXlw7TfRErboY80aSNgJYpKhiNMLdei0++d0tQ5ACb0e/jfjqWvPsDBHNP7pgHyRMut8RE1E3yy0ghtdHXVWkwe5z2WHVoFwjWHIB7TX6UZb5X6EZRs5wQ92LenFZn8EbZf92Ksckp8uTwRT9UHIFon91WGTBjKaepONmT8mPcq4k/6P3nTSQqIGwEqxDNJs/bWZ7BGFrLF7yEKDy0n85ytc2YoDqxB2ImkGzgpu7ImDRLH1uIm3Yhe5HH+BcJza1UY4uTilU/7A7cizuJjl9RLlU6T0XwUTc39eJ8s3pAGR9oty+vmf+moU8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tG51sX2mZMIxRs8mxmhXg91IvTw8GZQ1VEZiRQ4pQOY=; b=DOifc3QP1GZhpKpIX2uUCQ7Ga8aW+JqafLExirY733XrnP+go6WTuKy9Qo4ftxmr0kw0sXiMppm+JXj8OofdH3FR+a3UULJs3Pjl9U/ivIbWUwMM4zpuybrIzzD3oVR9TT8UkmbEIlYaFtw5Ukj3WG+njS/8/AfXgwmSNdWPrm6xV5Aj7nAJY6qm90nJFKpyA+JXwHXPLky5ASFjnwjhF9usDdf8HtW+ucxtCUO9cqfsGvOotcGAwd1aQeCSQAqVcq4j2jETTxKB/C0/wDLIB1JSrSDZoQtUqlntKAqu3UAx2gLskwMy903/UT/q/wdstxbwDsKkWbQ51GvOLFpFZg== Received: from DB9P195MB1225.EURP195.PROD.OUTLOOK.COM (2603:10a6:10:295::10) by PR3P195MB0928.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:a6::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.25; Fri, 1 Apr 2022 11:17:34 +0000 Received: from DB9P195MB1225.EURP195.PROD.OUTLOOK.COM ([fe80::a886:f434:45b6:1136]) by DB9P195MB1225.EURP195.PROD.OUTLOOK.COM ([fe80::a886:f434:45b6:1136%4]) with mapi id 15.20.5123.025; Fri, 1 Apr 2022 11:17:34 +0000 From: ossama ahmed To: "users@dpdk.org" Subject: Fw: OpenSSL Crypto Poll Mode Driver Thread-Topic: OpenSSL Crypto Poll Mode Driver Thread-Index: AQHYRa5kOEuGDhcdxUeKvNPpYAQuUqza6MSI Date: Fri, 1 Apr 2022 11:17:33 +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: x-tmn: [zT+SaIrao3489wZFCG4L72/W9UQJyyzo] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6cd454d8-17f7-4384-e9f7-08da13d13852 x-ms-traffictypediagnostic: PR3P195MB0928:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pnZawqUPKhrXjfYLakZkfWxSDkh84I7tKhXo9Iz7yBpBreorubLbGPzG9KXO0/Gu3j5D6FUPiG5IvxkxO8Z7S2cPa9nIOoKJv2kECFOS+KcX0nxH6ECbUpmsCbeCbbRLOcy7uiHs6TwRcY9Zh1loAu2u7yrUK0gc0JTFxszINX4ahNOt6oBtiAcGCrPkhlcPIqX1JekTsi5H2aNihk0S1U06On6fbrFVs/7puX0ZwfBFj4zMzRZbuDC3QVkvu8NqEJWj4GYQAXfJEhxjPld8z6+L30ZXXKYKgmQs3zYwGMGVj1AmD0Wnh1B1RibYSK4TqmAak3Vml5ITNbvEOg61BUQtErlpOoF58NMaFSFEqP1HLQot3ebuJD1xgiufQ70CJcmXir/xTNydapgUEvKadGjXDRNh27RjnRYjbk533MbexIUdC6IXRXaeb2cLHEMV4drzOB+weHup4mzVDuaS5eYOV7tBCuATSPCzLJcC+oTM0JkMX0NxayxiiTUcKI84PA8O/R5z/Ta93qO0OdzDfKJk+Joi6qYBQ8yNnsx3/7bSvJ0ZW1ygjOlU/bCdV9vho8dnbHa6D3diG7bazwqiFr/Yf1cMc18UcKO99WyDk9aQDYybdF5TsJm6vd0me6UuJjadv2isStTFCb78LdYy369dU55ouwWOzG1Ax9eeBFA= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?JntVhhQ+NpLVk0vEnn3H9NieusLDrEzKQbQMAYUZcZDM1qJRjN22U14zaf81?= =?us-ascii?Q?gSJWClwTNhMAYEHc3SP2g/roxC+TTdbP9lwd+uyXkiPy5YCQbhApJ1AvJu/R?= =?us-ascii?Q?VaedHwUzOqughjVXWAeWR+EzceCUywP7fq37nhUYwKzJlGrQKGfsixFHfjSO?= =?us-ascii?Q?6VwKkpIsCbyUnQeYU8LqbcI90rtcenQUAb3u5cC9Of9S60qMLIqHYkVO3wiN?= =?us-ascii?Q?7953QZ/vNfHoeR5ie1XubNZNiQFp5Mhon9126P6g3cEDd0ixK8zhVq9bBAHx?= =?us-ascii?Q?A9EJ/3IqCyrwriyb962kaBP57QhU95Wqlq4JaLr29PqnEny6THT/lyLnVZi1?= =?us-ascii?Q?CphTbxOijLfkLTh/0/LPKwBLB5E9NHiad62FjwuHf7IE5HFBnR0zRfsPezPN?= =?us-ascii?Q?xwqq9wB/UxXf02TmOvvNh2GMIA16UYN6Xpa5i3YpG8zdjgCTQPa6mZSPB7Zr?= =?us-ascii?Q?RPakVCpf/k+jSoQZ/jX6kdybZYTwPTZ0yXbIKXSxl/974Di0+492r/OFNkjP?= =?us-ascii?Q?bPuFadf03n5o9cn1iTB/sioUYFpwknfp2znEUS0qtkgJMPc7g5N4lJ63R0lT?= =?us-ascii?Q?Lxdiawuf0IrkvBhhggbcXCzV3eEm4pDH2LpGWOLKMcUA9UToPhvMT9qY11n3?= =?us-ascii?Q?Dwsyesx9y16wZ/nl//LVtr5B/KwFUcvk4Y0sgrQKHgSBWrIGUDGJCs1kJsv7?= =?us-ascii?Q?wsB3r0foVOaeLdGoyW542dtxBq8BhzzOIh7wDTZGdKLmOEqqJT5W5gtAwT6c?= =?us-ascii?Q?dZ+I2tGCNsuHG1CYEfd1pzn4+ssUY3R7EWN/kqBtfqtKGshaVgcxKx6OiQ6y?= =?us-ascii?Q?u7t4IuXXTNewVvnDLDUYBPaBMNbeJzgBghXnj9sC6RfWk9E1IUtUgVpbPeol?= =?us-ascii?Q?AvRnJBKOJyO1qjtKRMT5tjIHGu28wd/ytUqoZlQEwhIKInYRAYzNr6d6iejU?= =?us-ascii?Q?8WcMQ3vHlUQcMkRRCYZCQcxd3CGaMiTHyoJeQ0Ofjy/cLfes7lncLrWPng54?= =?us-ascii?Q?E/oWaDfeOZXYGLCHOP6ZpC/KfL+yQcSAqYMyInqAhkodV4Km5z8hUpdiwQxC?= =?us-ascii?Q?6KlWWi/qYW/I63SYA1s9k7gJv/HnyF606KGB44ncNhRkp9/N47k8pA0n9W+B?= =?us-ascii?Q?kxguap74Iz8MTzdwQiPjI5/alh8Rg9WryMTtp/L8q5+yjhl9SgwxeI1i6zYH?= =?us-ascii?Q?TNsZUPfPartpzdyhz5Kevfz+MkxZTn7fKXgLGBpnyZ4jk4Wwm5/C/fflJIow?= =?us-ascii?Q?qR2Hle8kh1Tg2qxCbz4o96oBH2FEy76kGrqrUdWQ/sz256SVd629WxUhB/OM?= =?us-ascii?Q?RLW0hwQP1DmZe++dTgyTGcGtb7bNP8Mp1RrgABZlmRZaglfN4MIO1nTQ/krU?= =?us-ascii?Q?42EzF9aw9wA+0au21jJWU58kTXSAPlof2x/2UqFoebMbkVgJsKkpLThSawTb?= =?us-ascii?Q?MAHAkRy0lGY1RNwB9oVmA5+V0bhdl228?= Content-Type: multipart/alternative; boundary="_000_DB9P195MB12254755390BB7662CAB6873B2E09DB9P195MB1225EURP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-49ed2.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9P195MB1225.EURP195.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 6cd454d8-17f7-4384-e9f7-08da13d13852 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2022 11:17:33.9615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P195MB0928 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_DB9P195MB12254755390BB7662CAB6873B2E09DB9P195MB1225EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. 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. 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. 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); 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_DB9P195MB12254755390BB7662CAB6873B2E09DB9P195MB1225EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Sent from Outlook

From: 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 following 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_privat= e_encrypt.html .Both of the functions are deprecated. Applications should i= nstead use EVP_PKEY_sign_init_ex, EVP_PKEY_sign, EVP_PKEY_verify_recover_in= it, and EVP_PKEY_verify_recover.

Although I understand that due to compatibil= ity 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 APIs "RSA_p= rivate_encrypt" and "RSA_public_decrypt" but in case of RSA_= PKCS1_PADDING it is recomended that when generating or verifying
PKCS #1 signatures, RSA_sign(3) and RSA_veri= fy(3) should be used.

POSSIBLE SOLUTION
1. Use RSA_sign, RSA_verify, EVP_DigestSignF= inal, EVP_DigestSign etc instead.

2. Append algorithm identifier field to dige= st before 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 f= or digest generation then DigestInfo value is:
SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 6= 5 03 04 02 01 05 00 04 20 || H where H is the digest of data
Hence appropriate AIDs (i.e algorithm identi= fiers) 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 wi= th RSA_sign, RSA_verify, EVP_DigestSignFinal, EVP_DigestSign and verify respectively.

ISSUE2 (RSA PSS Padding)
Current DPDK's OpenSSL Crypto Poll Mode Driver fails to verify signatu= re 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.

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))<= /div>
                return -1;
            ret =3D RSA_public_decrypt(s= iglen, 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->mgf1md, rctx->tbuf, rctx->saltl= en);
            if (ret <=3D 0)
                return 0;
            return 1;
        }
However, in order to use above implementation changes are required in = OpenSSL Crypto Poll Mode Driver (drivers/crypto/openssl/rte_openssl_pmd.c += 1945) for example

       case RTE_CRYPTO_ASYM_OP_VERIFY:
                tmp =3D rte_ma= lloc(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_pu= blic_decrypt(op->rsa.sign.length,
                    =             op->rsa.sign.data,
                    =             tmp,
                    =             rsa,
                    =             pad);

                OPENSSL_LOG(DE= BUG,
                    =             "Length of public_decrypt %d= "
                    =             "length of message %zd\n&quo= t;,
                    =             ret, op->rsa.message.length);<= /div>
                //FIXME
                if(pad =3D=3D = RSA_NO_PADDING && ret)
                    =     memcpy(op->rsa.message.data, tmp, op->rsa.sign.length);=
                else if ((ret = <=3D 0) || (CRYPTO_memcmp(tmp, op->rsa.message.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 detai= ls are availble in section 8.1.2 of https://datatracker.ietf.org/doc/html/r= fc8017#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_DB9P195MB12254755390BB7662CAB6873B2E09DB9P195MB1225EURP_--