Open vitalyk-radware opened 1 year ago
Is the ECDH curve used is X25519 ? If yes, drop is expected as X25519 is not accelerated in OpenSSL3.0 engine due to known issue https://github.com/openssl/openssl/issues/19047
thank you for the information about X25519 . I will check it. But it is not only this particular cipher. I checked AES-128 today and also see very big performance degradation. our computer's CPUs reach 100% under relatively low load. Is there any test we can do using openssl tools that measure performance , so that i could submit the report here? thanks!
You can use OpenSSL Speed tests as mentioned here to check algorithm level performance.
i would like to ask about PRF offloading, please. i see this code in e_qat.c:
if (!ENGINE_set_pkey_meths(e, qat_pkey_methods)) {
WARN("ENGINE_set_pkey_meths failed\n");
goto end;
}
i also see that in my test, functions such as qat_tls1_prf_ctrl are never called. can you please tell why qat_pkey_methods are disabled in openssl v3 ? Thank you!
It is disabled due to known issues. We are working on fix in the qatengine and in the openSSL PR below to enable pkey methods in OpenSSL3.0 Engine.
thank you for the update! does it mean that openssl project has fixed something and we just have to download this patch? or there is something to update in the Engine too? may we know your estimation when this functionality will be available , please? thank you!
@vitalyk-radware Needs fix from both OpenSSL (for X25519/X448) and QATEngine. Are you looking specifically PRF or entire pkey methods (X25519/X448, HKDF etc). For X25519, fix from OpenSSL is needed along with qatengine fix. For others OpenSSL fix is not needed but we are blocked by limitation of default sw_methods not available for PRF and HKDF from OpenSSL 3.0. So it might be possible PRF will still be not enabled and X25519/X448 will be enabled.
when we compared performance of openssl 1.1 and 3.0 , we noticed a significant degradation, and the most obvious possible explanation is that PRF is not done in hardware. Therefore we are looking for this feature. The curve (X25519/X448) is not in our focus at the moment. when you say "it might be possible PRF will still be not enabled", does it mean it is not going to be available is 3.0 / 3.1 at all? can we do antything about it? where we can learn more about these "known issues" with PRF offloading? many thanks, Vitaly
We are working on the fix/workarround at qatengine. I will keep you posted.
Below is the limitation at openSSL that I am talking about https://github.com/openssl/openssl/issues/19047
Thank you very much for your reply. I read in this thread that you said "There is provider and engine implementation in hardware. Our intention is to get OpenSSL default methods for fallback scenario". does it mean that we may get full QAT functionality (including PRF offload) if we load "qatprovider" provider (instead of "default" or "legacy") rather than load ENGINE "qat"?
thank you!
@vitalyk-radware Yes Provider supports full functionality but we didnt test with any real time application apart OpenSSL's S_Server as we don't have any application (Nginx, Haproxy) that supports provider yet.
curious, does qat engine support both openssl 1.1 and openssl 3.0/3.1? or openssl 1.1 only support qat engine while openssl 3.0 has to switch to qat provider?
We use openssl 3 with Engine. It is deprecated perhaps, but it works.
From: Zhangfei Gao @.> Sent: Thursday, May 23, 2024 12:54 PM To: intel/QAT_Engine @.> Cc: Vitaly Kroivets @.>; Mention @.> Subject: Re: [intel/QAT_Engine] performance of QAT with openssl-3.0 / 3.1 vs. openssl-1.1 (Issue #236)
CAUTION:External Email, Do not click on links or open attachments unless you recognize the sender and know the content is safe.
curious, does qat engine support both openssl 1.1 and openssl 3.0/3.1? or openssl 1.1 only support qat engine while openssl 3.0 has to switch to qat provider?
- Reply to this email directly, view it on GitHubhttps://github.com/intel/QAT_Engine/issues/236#issuecomment-2126697370, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6ECPGOLPRDSWWOVVAS4VL3ZDW4C5AVCNFSM6AAAAAAWCJFSU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGY4TOMZXGA. You are receiving this because you were mentioned.Message ID: @.**@.>>
We use openssl 3 with Engine. It is deprecated perhaps, but it works.
Thanks @vitalyk-radware
Has anyone compared performance of ssl offloading using openssl-3.0 ? we run test using ECDHE-RSA-AES128-GCM-SHA256 and observe at least 30% degradation in transactions/second in comparison with same software based on openssl-1.1.
can you please advise where to look for the sourse of the problem? thank you!