fix: deduplicate and canonicalize CryptoKey.usages#1020
Merged
Conversation
Closes #1000 WebCrypto requires `CryptoKey.usages` to be deduplicated and returned in a canonical order: encrypt, decrypt, sign, verify, deriveKey, deriveBits, wrapKey, unwrapKey, encapsulateKey, encapsulateBits, decapsulateKey, decapsulateBits Tracked in #995. Reference: Node commit fe7ebccd0ce. ## Changes - New `getSortedUsages` helper in `utils/validation.ts` that dedupes and reorders a `KeyUsage[]` per the canonical order. - Applied in the `CryptoKey` constructor — the single choke point that every `subtle.generateKey`, `subtle.importKey`, and `KeyObject#toCryptoKey` path flows through. JWK exports populate `key_ops` from `key.usages`, so they pick up the canonical order automatically. ## Testing New `subtle.usage-canonicalization` suite covers: - `generateKey`: HMAC, AES-CTR/CBC/GCM (symmetric); RSA-OAEP, RSA-PSS, ECDSA, ECDH, Ed25519, X25519, ML-DSA-65, ML-KEM-768 (key pairs). - `importKey` raw: AES-GCM, HMAC, HKDF, PBKDF2 — verifies the generic-secret import path. - `importKey` jwk: AES-CBC. - `KeyObject#toCryptoKey`: HMAC, AES-GCM via `createSecretKey`. - JWK export `key_ops`: AES-CTR, HMAC, RSA-OAEP pair, ML-KEM-768 pair — confirms canonical order propagates from `key.usages` to `jwk.key_ops`.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
🤖 End-to-End Test Results - iOSStatus: ✅ Passed 📸 Final Test ScreenshotScreenshot automatically captured from End-to-End tests and will expire in 30 days This comment is automatically updated on each test run. |
Contributor
🤖 End-to-End Test Results - AndroidStatus: ✅ Passed 📸 Final Test ScreenshotScreenshot automatically captured from End-to-End tests and will expire in 30 days This comment is automatically updated on each test run. |
The WebCrypto spec requires `key.usages` to be a frozen array. Apply `Object.freeze` to the canonicalized usages array in the CryptoKey constructor so external code can't mutate it. Spread into a fresh array when exporting JWK `key_ops` to keep that field mutable. Follow-up cleanups from review of the prior canonicalization commit: - Drop the `length <= 1` early return in `getSortedUsages` so every input flows through the canonical filter (avoids a code path that would silently pass through invalid usages if validation upstream ever regressed). - Document `getUsagesUnion`'s contract — dedup and ordering are the constructor's job, so future contributors don't re-add ad-hoc dedup at call sites. - Type the canonicalization test vectors with `SubtleAlgorithm` / `KeyUsage` / `AnyAlgorithm` instead of `any`, and add regression tests asserting `key.usages` is frozen and that `jwk.key_ops` mutation does not leak back into the source key.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1000 (tracked in #995).
Summary
WebCrypto requires
CryptoKey.usagesto be deduplicated and returned in a canonical order:RNQC's
CryptoKeyconstructor previously stored the input array verbatim — no dedup, no reorder. Tests usingincludes()worked, but tests asserting array equality or comparing JWKkey_opsorder (and interop with Node-generated keys) would fail.Reference: Node commit
fe7ebccd0ce(crypto: deduplicate and canonicalize CryptoKey usages),lib/internal/crypto/util.js:731-755.Changes
getSortedUsageshelper inutils/validation.tsthat dedupes and reorders aKeyUsage[]per the canonical order.CryptoKeyconstructor — the single choke point everysubtle.generateKey,subtle.importKey, andKeyObject#toCryptoKeypath flows through.jwk.key_opsfromkey.usages, so they pick up the canonical order automatically (no separate change needed).Test plan
New
subtle.usage-canonicalizationsuite (~30 tests):generateKey— HMAC, AES-CTR/CBC/GCM (symmetric); RSA-OAEP, RSA-PSS, ECDSA, ECDH, Ed25519, X25519, ML-DSA-65, ML-KEM-768 (key pairs).importKeyraw — AES-GCM, HMAC, HKDF, PBKDF2 (exercises the generic-secret import path).importKeyjwk — AES-CBC.KeyObject#toCryptoKey— HMAC, AES-GCM viacreateSecretKey.JWK export
key_ops— AES-CTR, HMAC, RSA-OAEP pair, ML-KEM-768 pair — confirms canonical order propagates fromkey.usagestojwk.key_ops.Tests pass in the example app on iOS
Tests pass in the example app on Android
No regression in existing WebCrypto / key suites
🤖 Generated with Claude Code