Skip to content

Fix OKP importKey validation for Ed448/Ed25519/X25519/X448#8886

Open
tete17 wants to merge 3 commits intoLadybirdBrowser:masterfrom
tete17:crypto-okp-import-fixes
Open

Fix OKP importKey validation for Ed448/Ed25519/X25519/X448#8886
tete17 wants to merge 3 commits intoLadybirdBrowser:masterfrom
tete17:crypto-okp-import-fixes

Conversation

@tete17
Copy link
Copy Markdown
Contributor

@tete17 tete17 commented Apr 12, 2026

This MR fixes 3 issues with OKP key import in WebCryptoAPI:

  • Fix the Ed448 raw key length check — was checking for 448 bits but Ed448 public keys are 456 bits (57 bytes) per RFC 8032 Section 5.2.5. Note: the spec itself has this wrong, see Add Curve448 w3c/webcrypto#425 (comment)
  • Validate JWK key length after base64url-decoding the x/d fields for all 4 OKP curves
  • Validate JWK key pair consistency — derive public key from d and verify it matches x

This fixes ~230 previously failing WPT subtests across Ed25519, Ed448, X25519, and X448.

@tete17 tete17 force-pushed the crypto-okp-import-fixes branch from b1caed4 to 0cef96b Compare April 13, 2026 17:07
@tete17 tete17 requested a review from gmta April 13, 2026 17:08
tete17 added 3 commits April 14, 2026 01:48
Ed448 public keys are 57 bytes (456 bits), not 56 bytes (448 bits).
The curve is named "Ed448" after its 448-bit prime field, but per
RFC 8032 Section 5.2.5, the parameter b=456 and both private and
public keys are 57 bytes. This caused importKey to reject valid raw
Ed448 public keys with a DataError.

Note: The spec incorrectly says "not 448" for this check.
See w3c/webcrypto#425 (comment)
After base64url-decoding the x and d fields during JWK import,
verify the decoded byte length matches the expected key size for
the curve (32 for Ed25519/X25519, 57 for Ed448, 56 for X448).
A truncated value does not "contain the public/private key" as
required by RFC 8037 Section 2.
For private key JWK imports, after decoding both d and x, derive
the public key from d and verify it matches x. A private key that
doesn't correspond to the provided public key doesn't "contain the
private key" as required by RFC 8037 Section 2.
@tete17 tete17 force-pushed the crypto-okp-import-fixes branch from 0cef96b to f9ab2a5 Compare April 13, 2026 23:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants