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 3696FA0507 for ; Fri, 1 Apr 2022 17:22:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BF9DA40E03; Fri, 1 Apr 2022 17:22:03 +0200 (CEST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05olkn2045.outbound.protection.outlook.com [40.92.89.45]) by mails.dpdk.org (Postfix) with ESMTP id 074A14067E for ; Fri, 1 Apr 2022 17:22:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bnk84bO/6SPXjeGljp2FLAb9HsENwvZOVPtx/nQb30U1EkEcd8AUUSSQWAOnh0r6l1DReZgfHiCAOckxWPT1n9GMrNQ19r//4y6iS1n02+7H5cEtHIU2ZVSzSSmbe5GQLtUla3rE18i7EEgKod8hX6y8c73926r4CfRrFrA47Z4wRChQAQLXTOYkcNFkN1W2d2UOdsCu7+XBoekaN56Fwb75PbyjgfpT62j4f96gti+H2ZK3/O1c4ZwHMaBDEweDfnwt1JSDeJCwplgKXzwRoMjmNqpSb1zguAVCQrZs/kR0D59hDC4NSFMPIsd4h2cDB4AGo7f51wBR0Pqg4vCr1w== 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=7g5+yt5qaR5jWh3ifZPN5/zn3TJomQtPx2ICmxpJBqU=; b=B203xnMLQrKKrNp0JnfQmh+zjhSp6++6FgvuxKIy3t3s5OPj02a/IMQs9/AX3d745jW7PSfWj7bxm01t5v1adjT2NN7FhtgVf8HL9baZf9RLVfZQpMTKqPp98jjzzhQsD9qai7bjUrfPhdNtzM2OsT0/aFvdcJ8iZalr2WgltVXK6O+bPjD9emUnvvtGG51No6sxhEoAkcZCPZ2m6Bkr9jiYENOyauMPpap8KhN8jFLqS0Sr5hEjSS81HAqsuekbOt0fVUxDWYeg5HT/++zIssqutLZ62s3UcbvDDWYWXzFI2VXedeuYfGYurN1xbh7nST1dzB9Ic88AbKnH6ayc1A== 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=7g5+yt5qaR5jWh3ifZPN5/zn3TJomQtPx2ICmxpJBqU=; b=kWWpY3PStPXC0Todh3gPyOB6tMtp3Sp9J/r9Pq9mrmkJwME8wUXFdpuQALPUa/GBTEepfKr2n9WcBKG7q3fbNQ34eOgOVEnpmaGxpmu70mz1jMwAHRccXu/M/N/onTywSIU1HJ1WU8ybJQeCdFUiXNsNR+tA0KqmDjuJc3bdn0Fxooj6mZ0e8KC90bjOFi++joKnuC+7Ww043yboZUJQ2TZCr7aNR9xyw74ZqC9RHr3JfnIcvOoWweEwB16Qeh4vzkVpkAjeAxf2rpzfq4Zu7vxbsTxn4UIs74czGbNQeTT+Z9gNxigAZpRJOBqyN2LXzhVLCUqVE+aAHFvlyHSflA== Received: from DB9P195MB1225.EURP195.PROD.OUTLOOK.COM (2603:10a6:10:295::10) by AM0P195MB0515.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:16a::18) 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 15:22:02 +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 15:22:02 +0000 From: ossama ahmed To: "Ji, Kai" , "Kusztal, ArkadiuszX" , "users@dpdk.org" CC: "Zhang, Roy Fan" Subject: Re: OpenSSL Crypto Poll Mode Driver Thread-Topic: OpenSSL Crypto Poll Mode Driver Thread-Index: AQHYRa5kOEuGDhcdxUeKvNPpYAQuUqza6MSIgAAjG+CAAAvd4IAAFRJh Date: Fri, 1 Apr 2022 15:22:02 +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: [+hPfza9AdLsMcY8uavLo5Z9u6mi41nFP] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac5b9913-8aef-4fdd-e54c-08da13f35f38 x-ms-traffictypediagnostic: AM0P195MB0515:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Cll3X9JPQaaqFWGYdPDiw+AT62TeIq2rmPqZeUNCvjBAGqeC7s8qxXDpFdLD5Hsu44qEGiS9/58fDdH8gS+SGsPpIRc/Cf1BHTVz1bEu6El06TiFcsH/CdE0KpNot+8flOXUHo/UD/nxzkiW6m3Qd7o4MxV2Pmc3e34iZMT/evNjqAgc04UYBXKzWOvX0jF3ps1HH/0EO/VDi4A3awJ+smXAN4iZz9XM4/yknFllMdzOMb0sVG+MrgXMqFQFCracMI+YU8bnf2C2P7NWv0qGfN3neKy1/HZU9pS3Gtdl/CvjhOd9/eWBIBUxXiWqqYjP1Jtb9sh5QG4+BYROWb055JO4RkbXTHbbX0dwcmnXIDq4YI88VJhnMdmBiFo/LbJvy9lsqBs0iIJsykZqw9Ni2UnlXqo8GKoqT3hUbZfG3OBSsGQn01kotP7RnyXSOMjsr/mW5lvwNHxUQKs/ODRdEAdpUdqbUhUcF63MZ/29m7bDUrUKJamX73AbQpUJTKb3KyKhbCXqTszCMOZK0SjbivBVMUDJkFX2MJLi4g3irHo7bRppUgO4d/ChOoKM4GUMb+xbtgM+PhLkBjzEDeAETkGV3pXzdvnZoGeYeePELR4gkC4tr+lxT6ZiwgbxFGZpSCeR7eKXZX93njws+3g2sQ== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?CX3QGfctl880WutjbKl/cjM/lV4ReYzTBKARSolLe9P3YZSv02zdWQam?= =?Windows-1252?Q?s9fzTsQzEwuMI8ujkdZspefzFJZsLzNeyqmHz+scXTeN9G8xYbSXLUhb?= =?Windows-1252?Q?WmlnRH40aU+UCDm2AehFysBXnAEu1vi8ZKBTHMaqlZGWYsUvx9rYe6HR?= =?Windows-1252?Q?XRN1VRsSGatPBctxLkYPQYGOtjbYXZbIX42yWd8Yy+CWqgTCeLSrdQ51?= =?Windows-1252?Q?oYpGhXcTfjBfwfX46v9VPn20vn5rp0xsacm+sshJECw2gLipPUmZPmhr?= =?Windows-1252?Q?YgojLni/kpguKlrms+xEKg9vVgWouMJ8YhDnEpLYkxDg0bSzRbYwkoBA?= =?Windows-1252?Q?lPtWrg340NE9GOGoFsVWcrrKErYElJ9WvDqdPrOpIRUeeSgTzm65YKrY?= =?Windows-1252?Q?sDkMuSGKREkLupuajx8dFgOgaKKxd9ebeVE7IjzG6tG0XE12GbKCpixz?= =?Windows-1252?Q?UPZrP2QNOwVTm7TMwu+27TiHBNn4OfB1/RUe0IAFZRTOhsjl1DmJRmfc?= =?Windows-1252?Q?y43JigecVbKnlcO6fwWG7ttQnv6jCg/A8iGzVuycUq55baFMImxD/2QX?= =?Windows-1252?Q?byMnrOV3bOX5J3t38bokDWXzKfceyYp8sKtmAAzo1IV0mMP3sxs0xzig?= =?Windows-1252?Q?dG5R/L9rZGHbX7jOFpmPTmx+DHteAjjDSMX5Ns9teNKFmXJTWwCNkbhz?= =?Windows-1252?Q?GCPKHmYpM/XEZtbXu0Tzwvj+F1rbRaUbzsXcRPe2SV7fube91kdInw8q?= =?Windows-1252?Q?g2XaZ7GgaAtisIFEgFMpO18AuBbNldLFG/HDmIAHwPFAksVMWNqKETXd?= =?Windows-1252?Q?UlY7BhY2XgeJzLYCnqWUYV228npCHXIBoNokBmYCl0f9D5SQMjU0esRY?= =?Windows-1252?Q?Z1RAguf5e/0RRIG79t9gELMoGJ2uWIMqRZDGBxb2r20WVV88PKy54FDE?= =?Windows-1252?Q?iX10CszFVRzk8OYTVikgHm18+l0lsxcsKxWDixCS53sVOlcGOuSoKz+Q?= =?Windows-1252?Q?LgTN6eRhmqrUtAF0fi47oQDypcj5g5gfDmwMXBgHxBGhobNSxEiroUdt?= =?Windows-1252?Q?72L/lcwu/5gJrskr5RV17c1GoOFlWVDpY7wehiReBbfX6c5JEQrZ5ykv?= =?Windows-1252?Q?BriHsWitNDkdMwQQrt61PDW6c89Frky5tDGO4m0VlX5kt2fZ+0f3Nf7U?= =?Windows-1252?Q?kWJwHrOYEkgSnNXwKi1zqxzqwB633rVp6F3WNf10+McTx3UpXMGbf6hK?= =?Windows-1252?Q?FaKs+C8Q/cp3HTEstlmDQ25sjSHkE+YPQ3p/pJfIOA/jo6q//VUHPSOj?= =?Windows-1252?Q?w5BBRbNprgcacmOOyBvfiO6i0/3kA0goVn/HvoUbczjIrCgOHp1HlmU6?= =?Windows-1252?Q?kwbhW8hSnMQn6HyAd8iExO1mg6m4xLkR8BiaTU/CGO9zaPi8uI+jQuCT?= =?Windows-1252?Q?DB6uy0Fk6DcO0vcZlYth0Gd0BR3Dppvs2YpUVXOwTyLTFpvfi/iOSC8d?= =?Windows-1252?Q?bxkaBhWYgIpyXQ8ohqRbLwCVq8z2IoJ5LX+gch/cVIC00e4X8ttFjnSu?= =?Windows-1252?Q?w/4TwDVrr1c98JkIFjSy0j1EpzCaYJP41yyO3w=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DB9P195MB12255F647017A2D29506F678B2E09DB9P195MB1225EURP_" 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: ac5b9913-8aef-4fdd-e54c-08da13f35f38 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2022 15:22:02.1110 (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: AM0P195MB0515 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_DB9P195MB12255F647017A2D29506F678B2E09DB9P195MB1225EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for your response. Let me go through these details and will ping you= in case of any query. Get Outlook for Android ________________________________ From: Ji, Kai Sent: Friday, April 1, 2022 7:20:52 PM To: Kusztal, ArkadiuszX ; ossama ahmed ; users@dpdk.org Cc: Zhang, Roy Fan Subject: RE: OpenSSL Crypto Poll Mode Driver 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] =96 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] =96 yes, you are perfectly correct, this Is general Cryptodev API pr= oblem. 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] =96 yes, PSS should be implemented too. Registration of openssl rand= om engine should allow us to check known answer tests too not only PWCT, co= uld 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] =96 whole openssl low level api is deprecated now, these functions a= s 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_DB9P195MB12255F647017A2D29506F678B2E09DB9P195MB1225EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks for your response. Let me go through these details and will ping you= in case of any query.
From: Ji, Kai <kai.ji@in= tel.com>
Sent: Friday, April 1, 2022 7:20:52 PM
To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; ossama= ahmed <ossamaahmedmughal@hotmail.com>; users@dpdk.org <users@dpdk= .org>
Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
Subject: RE: OpenSSL Crypto Poll Mode Driver
 

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

 

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

Deprecated  RSA_s= ing() & RSA_verify() replaced with  EVP_PKEY_sign() & EVP_PKEY= _verify_recover() for rsa sign/verfy ops

 

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

 

EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDIN= G)

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 wit= h [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= : 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 fol= lowing issues in OpenSSL Crypto Poll Mode Driver and OpenSSL vdev related t= o RSA Sign and Verify operations.

 

ISSUES:

ISSUE1 (RSA_private_encryp= t 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 du= e to compatibility reasons, DPDK is using native (in my case on Ubuntu 20.0= 4.1 its 1.1.1f version of) OpenSSL but With respect

to OpenSSL's version 1.1.1f A= PIs "RSA_private_encrypt" and "RSA_public_decrypt" but = in case of RSA_PKCS1_PADDING it is recomended that when generating or verif= ying

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 instead.

 

[Arek] =96 RSA_sign and RSA_v= erify are now deprecated too.

 

2. Append algorithm identifie= r field to digest before signing. Details can be found in section EMSA-PKCS= 1-v1_5 availbel on https= ://datatracker.ietf.org/doc/html/rfc8017#section-9.2

 

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

SHA-256: (0x)30 31 30 0d 06 0= 9 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 a= lgorithm identifiers) must be appended to digest. Once this done then in ca= se of RSA_PKCS1_PADDING, APIs RSA_private_encrypt and RSA_public_decrypt ar= e compatible with RSA_sign, RSA_verify, EVP_DigestSignFinal, EVP_DigestSign and verify respectively.

 

 

[Arek] =96 yes, you are perfe= ctly correct, this Is general Cryptodev API problem. Proposals to fix that = were sent already:

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

When PKCS1 we should not worr= y about algorithmIdentifier from user perspective, although there was an op= tion to do PKCS1 padding without it too (pre tls1.2 PKCS1.5 padding was use= d 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 (= 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 availabl= e in OpenSSL Crypto Poll Mode Driver for RTE_CRYPTO_RSA_PADDING_PSS. Current implementation handles only RTE_CR= YPTO_RSA_PADDING_NONE and

RTE_CRYPTO_RSA_PADDING_PKCS1_= 5 for signing and verification.

 

[Arek] =96 yes, PSS should be= implemented too. Registration 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_D= igestSign etc instead.

 

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

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

        &= nbsp;   int ret;

        &= nbsp;   if (!setup_tbuf(rctx, ctx))

        &= nbsp;       return -1;

        &= nbsp;   ret =3D RSA_public_decrypt(siglen, sig, rctx->tbuf, rsa, RS= A_NO_PADDING);

        &= nbsp;  

        &= nbsp;   if (ret <=3D 0)

        &= nbsp;       return 0;

        &= nbsp;   ret =3D RSA_verify_PKCS1_PSS_mgf1(rsa, tbs, rctx->md, rctx-= >mgf1md, rctx->tbuf, rctx->saltlen);

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

        &= nbsp;   if (ret <=3D 0)

        &= nbsp;       return 0;

        &= nbsp;   return 1;

        }=

However, in order to use abov= e implementation changes are required in OpenSSL Crypto Poll Mode Driver (d= rivers/crypto/openssl/rte_openssl_pmd.c +1945) for example

 

       ca= se RTE_CRYPTO_ASYM_OP_VERIFY:

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

        &= nbsp;       if (tmp =3D=3D NULL) {

        &= nbsp;               OPENSSL_LOG(ERR, &qu= ot;Memory allocation failed");

        &= nbsp;               cop->status =3D R= TE_CRYPTO_OP_STATUS_ERROR;

        &= nbsp;               break;

        &= nbsp;       }

        &= nbsp;       ret =3D RSA_public_decrypt(op->rsa.sign.lengt= h,

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

        &= nbsp;                    =   tmp,

        &= nbsp;                    =   rsa,

        &= nbsp;                    =   pad);

 

        &= nbsp;       OPENSSL_LOG(DEBUG,

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

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

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

        &= nbsp;       //FIXME

        &= nbsp;       if(pad =3D=3D RSA_NO_PADDING && ret)

        &= nbsp;               memcpy(op->rsa.me= ssage.data, tmp, op->rsa.sign.length);

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

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

        &= nbsp;               OPENSSL_LOG(ERR, &qu= ot;RSA sign Verification failed");

        &= nbsp;               cop->status =3D R= TE_CRYPTO_OP_STATUS_ERROR;

        &= nbsp;       }

        &= nbsp;       //FIXME

        &= nbsp;       rte_free(tmp);

        &= nbsp;       break;

        &= nbsp;       

        &= nbsp;       Complete details are availble in section 8.1.2 o= f htt= ps://datatracker.ietf.org/doc/html/rfc8017#section-8.1.2

 

 

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

 

Regards,

Ossama Ahmed Mughal

 

--_000_DB9P195MB12255F647017A2D29506F678B2E09DB9P195MB1225EURP_--