Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: df27b87957a98585c0d8642e98ad63932f6adc29
      
https://github.com/WebKit/WebKit/commit/df27b87957a98585c0d8642e98ad63932f6adc29
  Author: Claudio Saavedra <[email protected]>
  Date:   2026-10-05 (Mon, 05 Oct 2026)

  Changed paths:
    M LayoutTests/platform/win/TestExpectations
    A 
LayoutTests/platform/win/imported/w3c/web-platform-tests/WebCryptoAPI/import_export/ec_importKey.https.any-expected.txt
    M Source/WebCore/crypto/openssl/CryptoKeyECOpenSSL.cpp

  Log Message:
  -----------
  [OpenSSL] JWK export of an EC private key drops leading zero bytes of d
https://bugs.webkit.org/show_bug.cgi?id=326107

Reviewed by Patrick Griffis.

CryptoKeyEC::platformAddFieldElements() pads the x and y coordinates to the
coordinate size but encodes the private scalar with BN_bn2bin(), which
omits leading zero bytes. RFC 7518 requires d to have the size of the curve
order, 32, 48 and 66 bytes for the supported curves, the same as a
coordinate, and a key exported shorter does not round-trip. For P-521 the
scalar is 521 bits in 66 bytes, so the leading byte is zero for about half
of all keys; the WPT P-521 import vector is one of them.

Verified on a WPE build with USE_OPENSSL_BACKEND=ON against OpenSSL 3.5.5:
the six P-521 JWK subtests of ec_importKey.https.any.html, in both the
window and the worker variant, fail before this change and pass after it,
and ecdh-generate-export-jwk-key-p521.html fails 20 of 40 iterations before
and none after.

The Windows bot has had the three ecdh-generate-export-jwk-key tests, which
check the length of d, marked flaky with a note that generated keys can
encode shorter than expected: that is this bug. Expect them to pass again,
and run the WPT EC import test on Windows, which round-trips the P-521
vector.

* LayoutTests/platform/win/TestExpectations:
* 
LayoutTests/platform/win/imported/w3c/web-platform-tests/WebCryptoAPI/import_export/ec_importKey.https.any-expected.txt:
 Added.
Taken from the Windows EWS run; LibreSSL supports compressed points, which
the generic baseline expects to be rejected.
* Source/WebCore/crypto/openssl/CryptoKeyECOpenSSL.cpp:
(WebCore::CryptoKeyEC::platformAddFieldElements const): Pad d like x and y.

Canonical link: https://commits.webkit.org/322678@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to