From 91eccadf3b0d011ae6e3d90e251eae8205352d74 Mon Sep 17 00:00:00 2001 From: Joachim Henze Date: Tue, 25 Oct 2022 02:17:33 +0200 Subject: [PATCH] [0.4.13][BCRYPT] Add ECDSA P384 to known algorithms (#4236) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Today 2022-10-25 was the day, when I spotted the first URL in rapps that is not longer happy with just having ECDSA_P256 but now needs even ECDSA_P384 to make the rapps download succeed. *eye-rolling* It was https://bitbucket.org/Swyter/tld-downloads/downloads/diabloiidemo.exe that failed the rapps download with fixme:(dll/win32/bcrypt/bcrypt_main.c:359) algorithm L"ECDSA_P384" not supported err:(win32ss/user/user32/windows/messagebox.c:1048) MessageBox: L"Paket konnte nicht geladen werden! Pr\00fcfen Sie Ihre Internetverbindung!" So I have no choice but to follow the totally stupid crypto-rat-race and add the missing structs and handlers in BCryptOpenAlgorithmProvider(). When will the world ever learn that the new cryptos do outdate faster than the new shit even can be implemented in time everywhere? Each additional crypto algorithm effectively enlarges the attack surface of the end-points instead of making stuff more secure. The world is rushing towards totally breaking backward compatibility to older systems. This is built-in obsolescence. For which gain? This race can never be won. Each crypto-iteration just intensifies the existing chaos. Enough ranting... fix picked from 0.4.15-dev-3662-g c3e0df06113b67a4c3967cd018220c4f2bd7fa2b It is a cherry-pick a part of Michael Müller's commit from Wine https://source.winehq.org/git/wine.git/commit/76b6c360fa7f3d6a0a14ed935075f5eb10f2f719 The commit doesn't fix CORE-14198 at all, same like on master, but since the original commit was linked to that JIRA ticket as well, I decided to do the same with the backport. --- dll/win32/bcrypt/bcrypt_main.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/dll/win32/bcrypt/bcrypt_main.c b/dll/win32/bcrypt/bcrypt_main.c index 042e906bb7d..56234006bcd 100644 --- a/dll/win32/bcrypt/bcrypt_main.c +++ b/dll/win32/bcrypt/bcrypt_main.c @@ -267,7 +267,8 @@ enum alg_id ALG_ID_SHA256, ALG_ID_SHA384, ALG_ID_SHA512, - ALG_ID_ECDSA_P256 + ALG_ID_ECDSA_P256, + ALG_ID_ECDSA_P384, }; static const struct { @@ -280,7 +281,8 @@ static const struct { /* ALG_ID_SHA256 */ { 32, BCRYPT_SHA256_ALGORITHM }, /* ALG_ID_SHA384 */ { 48, BCRYPT_SHA384_ALGORITHM }, /* ALG_ID_SHA512 */ { 64, BCRYPT_SHA512_ALGORITHM }, - /* ALG_ID_ECDSA_P256 */ { 0, BCRYPT_ECDSA_P256_ALGORITHM } + /* ALG_ID_ECDSA_P256 */ { 0, BCRYPT_ECDSA_P256_ALGORITHM }, + /* ALG_ID_ECDSA_P384 */ { 0, BCRYPT_ECDSA_P384_ALGORITHM }, }; struct algorithm @@ -354,6 +356,7 @@ NTSTATUS WINAPI BCryptOpenAlgorithmProvider( BCRYPT_ALG_HANDLE *handle, LPCWSTR else if (!strcmpW( id, BCRYPT_SHA384_ALGORITHM )) alg_id = ALG_ID_SHA384; else if (!strcmpW( id, BCRYPT_SHA512_ALGORITHM )) alg_id = ALG_ID_SHA512; else if (!strcmpW( id, BCRYPT_ECDSA_P256_ALGORITHM )) alg_id = ALG_ID_ECDSA_P256; + else if (!strcmpW( id, BCRYPT_ECDSA_P384_ALGORITHM )) alg_id = ALG_ID_ECDSA_P384; else { FIXME( "algorithm %s not supported\n", debugstr_w(id) );