crypto: add raw key formats support to the KeyObject APIs

[panva]

notable-change PRs with changes that should be highlighted in changelogs. 👇

Add raw key format support (raw-public, raw-private, raw-seed) to KeyObject.prototype.export(), crypto.createPrivateKey(), and crypto.createPublicKey() for applicable asymmetric keys (EC, CFRG curves, ML-DSA, ML-KEM, and SLH-DSA). This intrinsically means it is supported as input to the other cryptographic APIs as well.

---

This also adds a much needed docs section on the different key formats and their usage examples.

Also wire these to their existing Web Cryptography APIs counterparts and remove the unnecessary KeyExportJob. The KeyExportJob classes were removed because the export operations they performed are not computationally expensive. They're just serialization of already-available key data (SPKI, PKCS8, raw bytes). Running them as async CryptoJobs on the libuv thread pool added unnecessary overhead and complexity for operations that complete instantly.

This is not a semver-major but bits of it depend on #62178 which is. I will try to open a partial backport to 25/24.

---

Key Type vs Format matrix

Key Type	'pem'	'der'	'jwk'	'raw-public'	'raw-private'	'raw-seed'
'dh'	✔	✔
'dsa'	✔	✔
'ec'	✔	✔	✔	✔	✔
'ed25519'	✔	✔	✔	✔	✔
'ed448'	✔	✔	✔	✔	✔
'ml-dsa-44'	✔	✔	✔	✔		✔
'ml-dsa-65'	✔	✔	✔	✔		✔
'ml-dsa-87'	✔	✔	✔	✔		✔
'ml-kem-512'	✔	✔		✔		✔
'ml-kem-768'	✔	✔		✔		✔
'ml-kem-1024'	✔	✔		✔		✔
'rsa-pss'	✔	✔
'rsa'	✔	✔	✔
'slh-dsa-sha2-128f'	✔	✔		✔	✔
'slh-dsa-sha2-128s'	✔	✔		✔	✔
'slh-dsa-sha2-192f'	✔	✔		✔	✔
'slh-dsa-sha2-192s'	✔	✔		✔	✔
'slh-dsa-sha2-256f'	✔	✔		✔	✔
'slh-dsa-sha2-256s'	✔	✔		✔	✔
'slh-dsa-shake-128f'	✔	✔		✔	✔
'slh-dsa-shake-128s'	✔	✔		✔	✔
'slh-dsa-shake-192f'	✔	✔		✔	✔
'slh-dsa-shake-192s'	✔	✔		✔	✔
'slh-dsa-shake-256f'	✔	✔		✔	✔
'slh-dsa-shake-256s'	✔	✔		✔	✔
'x25519'	✔	✔	✔	✔	✔
'x448'	✔	✔	✔	✔	✔

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[github-actions]

The notable-change PRs with changes that should be highlighted in changelogs. label has been added by @panva.

Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section.

[codecov]

Codecov Report

❌ Patch coverage is 82.76699% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.64%. Comparing base (abff716) to head (cacbfb1).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/crypto/crypto_keys.cc	66.90%	11 Missing and 35 partials ⚠️
lib/internal/crypto/cfrg.js	71.42%	8 Missing ⚠️
lib/internal/crypto/ec.js	86.53%	7 Missing ⚠️
lib/internal/crypto/rsa.js	68.18%	7 Missing ⚠️
lib/internal/crypto/keys.js	97.77%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62240      +/-   ##
==========================================
- Coverage   91.60%   89.64%   -1.97%     
==========================================
  Files         337      674     +337     
  Lines      140745   205630   +64885     
  Branches    21807    39468   +17661     
==========================================
+ Hits       128933   184332   +55399     
- Misses      11588    13523    +1935     
- Partials      224     7775    +7551     

Files with missing lines	Coverage Δ
lib/internal/crypto/ml_dsa.js	95.04% <100.00%> (-0.14%)	⬇️
lib/internal/crypto/ml_kem.js	91.89% <100.00%> (-0.24%)	⬇️
lib/internal/crypto/webcrypto.js	96.36% <100.00%> (+0.03%)	⬆️
src/crypto/crypto_dh.cc	67.37% <ø> (ø)
src/crypto/crypto_dh.h	11.11% <ø> (ø)
src/crypto/crypto_ec.cc	67.50% <ø> (ø)
src/crypto/crypto_ec.h	12.50% <ø> (ø)
src/crypto/crypto_keys.h	59.25% <ø> (ø)
src/crypto/crypto_rsa.cc	64.45% <ø> (ø)
src/crypto/crypto_rsa.h	58.33% <ø> (ø)
... and 6 more

... and 446 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[panva]

cc @ChALkeR @paulmillr FYI as it makes working with ECC much much easier

[paulmillr]

Great improvement!

[mcollina]

lgtm

[ChALkeR]

Yes, this is great, thanks!

(I did not review the impl though)

[panva]

@ChALkeR doing so would go a long way to be able to land this with more confidence.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71829/

[jasnell]

Code changes LGTM but the doc changes are a bit too repetitive and verbose... non-blocking tho.

[jasnell]

Running the benchmarks locally, this claim seems a bit inconsistent. raw-public for EC is the slowest when running the benchmarks locally and raw-public does not appear to provide benefit for ed25519 verify.

These are minor issues but I do question if we should be making claims in the docs of which is faster since that's something that can reasonably vary as time goes on.

[panva]

Ha. Thanks. I left the benchmark export to be compressed, so re-import is decompressing (re-calculating the y-coordinate). Do you think i should change the default export to be uncompressed then? I think so.

Image with uncompressed ec raw-public import, the claim that raw-public is generally the fastest is right (given that the ec export was done uncompressed)

Verify throughput is obviously dominated by the actual cryptography, not by the import itself.