node:crypto: expand WebCrypto modern algorithm coverage

[andrewtdiz]

Summary

Perry's WebCrypto coverage includes the core deterministic algorithms currently covered by the granular crypto suite, but it does not yet cover Node's newer WebCrypto algorithm/method surface such as P-384/P-521, Ed448/X448, AES-OCB, ChaCha20-Poly1305, KMAC, ML-KEM, or SubtleCrypto.supports() / encapsulation helpers.

Missing surface

• WebCrypto curves/algorithms beyond the implemented core set: P-384/P-521, Ed448, X448, AES-OCB, ChaCha20-Poly1305, KMAC128/KMAC256, and ML-KEM variants
• SubtleCrypto.supports(op, algorithm, length?)
• subtle.encapsulateBits(...) / subtle.decapsulateBits(...)
• subtle.encapsulateKey(...) / subtle.decapsulateKey(...)

Evidence

• The granular crypto suite README lists WebCrypto P-384/P-521, Ed448/X448, AES-OCB, ChaCha20-Poly1305, PQC/KMAC/Argon2 surfaces as follow-up work (test-parity/node-suite/crypto/README.md:16-21).
• docs/runtime-parity.md lists the corresponding Node WebCrypto methods and algorithms (docs/runtime-parity.md:4664-4703) and notes Node's expanded post-quantum/KMAC WebCrypto coverage (docs/runtime-parity.md:5551).
• Source search for P-384, P-521, Ed448, X448, AES-OCB, ChaCha20, KMAC, ML-KEM, encapsulateBits, decapsulateBits, encapsulateKey, decapsulateKey, and SubtleCrypto.supports found no implementation in crates/perry-stdlib/src/webcrypto, runtime dispatch, or the API manifest.

Expected Node-compatible behavior

crypto.webcrypto.subtle should expose Node-compatible support detection and algorithm behavior for the newer WebCrypto algorithms Perry chooses to support. Unsupported algorithms should fail with Node-compatible rejection/error behavior rather than falling through as missing methods or unsupported algorithm strings.

Duplicate check

Searched issues and PRs for WebCrypto P-384 P-521 Ed448 X448 AES-OCB ChaCha20 KMAC ML-KEM. No existing tracker or PR was found. #2517 covers top-level node:crypto Argon2 and crypto.encapsulate / crypto.decapsulate; this issue is scoped to crypto.webcrypto.subtle algorithm and method coverage.

Verification note

I could not run a fresh local Perry parity probe in this workspace because there is no local perry binary. This issue is based on committed parity metadata and current source inspection.

[andrewtdiz]

I’m taking a focused first PR-sized slice of this WebCrypto modern-surface issue.

Planned scope:

• expose Node 25’s static SubtleCrypto.supports(operation, algorithm, length?) function shape (typeof, name, length, descriptors)
• return support booleans for the WebCrypto algorithms Perry already implements in the relevant supports() operation contexts
• return false for selected modern-operation probes that Node also reports as unsupported, so feature detection does not fall through as a missing method
• add focused parity coverage for the static method and leave crypto.subtle.supports absent, matching Node

Non-goals for this cut: implementing P-384/P-521, Ed448/X448, AES-OCB, ChaCha20-Poly1305, KMAC, ML-KEM, Argon2 WebCrypto operations, or encapsulate/decapsulate methods. Node reports some of those algorithms as supported for specific operations; those remain real #2518 follow-up slices rather than being advertised here before Perry can execute them.

[andrewtdiz]

Opened a focused SubtleCrypto.supports() slice in #4146.

Scope in this PR:

• exposes Node 25's static SubtleCrypto.supports(operation, algorithm, length?) function shape
• matches name, length, descriptor shape, omitted-argument ERR_MISSING_ARGS, and explicit-undefined false results
• reports support for Perry's currently implemented WebCrypto algorithms in the same operation contexts covered by Node's static method
• keeps crypto.subtle.supports absent, matching Node
• adds focused parity plus adjacent webcrypto and subtle sweeps

Still intentionally left for later #2518 slices: P-384/P-521, Ed448/X448, AES-OCB, ChaCha20-Poly1305, KMAC, ML-KEM, Argon2 WebCrypto operations, and WebCrypto encapsulate/decapsulate methods. Node reports some of those as supported for specific supports() operations, but this PR does not advertise algorithms Perry cannot execute yet.

[andrewtdiz]

I am taking the next focused WebCrypto algorithm slice for this issue.

Intended PR cut: add P-384 and P-521 support alongside the existing P-256 WebCrypto EC paths for ECDSA/ECDH where the same implementation surface applies: generateKey, raw/JWK import-export, sign/verify, deriveBits, and SubtleCrypto.supports() reporting for those curves. I will add focused Node parity fixtures for P-384/P-521 success paths and validation/error cases.

Non-goals: Ed448/X448, AES-OCB, ChaCha20-Poly1305, KMAC, ML-KEM, Argon2 WebCrypto operations, and encapsulate/decapsulate methods.

[andrewtdiz]

Opened draft PR #4258 for the P-384/P-521 WebCrypto EC slice: #4258

Scope covered:

• ECDSA/ECDH P-384 and P-521 generateKey support.
• Raw public import/export and JWK public/private import/export for both curves.
• ECDSA sign/verify and ECDH deriveBits/deriveKey paths through the curve-aware key material plumbing.
• CryptoKey metadata/default usages and SubtleCrypto.supports() reporting for the added curves.
• Cross-curve ECDH derives now reject with InvalidAccessError.

Validation run:

• npm exec --yes --package=node@26 -- node --experimental-strip-types test-parity/node-suite/crypto/webcrypto/ec-p384-p521.ts
• CARGO_TARGET_DIR=/tmp/perry-node-ec-curves-p384-p521-check cargo check -p perry-stdlib --no-default-features --features crypto
• cargo fmt --all -- --check
• git diff --check
• ./scripts/check_file_size.sh

Known validation gap: the focused Perry parity/manual fixture run did not complete locally before producing a Perry fixture binary/output in this environment, so the draft currently has Node oracle plus targeted Rust build coverage but not a local Perry-vs-Node fixture diff.

Left out intentionally for follow-up: Ed448/X448, AES-OCB, ChaCha20-Poly1305, KMAC/PQC algorithms, and WebCrypto encapsulate/decapsulate.