chore(sdk): consolidate key-algorithm types + typed accessors (DSPX-4040) - #971
Conversation
…X-4040)
Introduce a single source of truth for key algorithms in
crypto/declarations.ts: per-family arrays (EC_KEY_ALGORITHMS,
RSA_KEY_ALGORITHMS, KEY_ALGORITHMS), derived subtypes
(EcKeyAlgorithm/RsaKeyAlgorithm), guards (isEcKeyAlgorithm/
isRsaKeyAlgorithm/isKeyAlgorithm), and typed accessors
(ecAlgorithmToCurve/rsaAlgorithmToModulusBits). Replace
startsWith()/split(':')/ternary parsing at call sites and export
PUBLIC_KEY_ALGORITHMS from the public entrypoint.
Also fixes a latent bug: isPublicKeyAlgorithm previously accepted
only ec:secp256r1/rsa:2048 and rejected the other supported EC/RSA
algorithms; it now delegates to isKeyAlgorithm.
📝 WalkthroughWalkthroughThe SDK centralizes RSA and EC key-algorithm definitions, guards, and conversions. Crypto import, wrapping, encryption, access, and DPoP logic consume the shared helpers, while the public SDK export and CLI options use the centralized supported-algorithm list. ChangesKey algorithm centralization
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request centralizes the management of supported key algorithms by defining them in a single source of truth within crypto/declarations.ts. It introduces type guards and helper functions to replace error-prone string parsing and manual type casting throughout the codebase. The reviewer suggested an improvement to the isKeyAlgorithm implementation to enhance code reuse by leveraging existing type guards, which has been noted.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…HMS (DSPX-4040) Add choices: PUBLIC_KEY_ALGORITHMS to the encapKeyType and rewrapKeyType options so yargs rejects unsupported algorithms up front with the valid list, and narrows argv to the literal union.
2a7bd62 to
644cda0
Compare
|
X-Test Failure Report |



What
Extracts the EC/RSA key-algorithm type refactor that had accreted onto the ML-KEM feature PR #933 (DSPX-3229) into its own reviewable/rollback-able change off
main. No ML-KEM here — that stays on #933, which will rebase on top of this.crypto/declarations.tsis now the single source of truth for key algorithms: per-familyas constarrays (EC_KEY_ALGORITHMS,RSA_KEY_ALGORITHMS,KEY_ALGORITHMS), derived subtypes (EcKeyAlgorithm/RsaKeyAlgorithm), runtime guards (isEcKeyAlgorithm/isRsaKeyAlgorithm/isKeyAlgorithm), and exhaustive typed accessors (ecAlgorithmToCurve/rsaAlgorithmToModulusBits).dpop.ts,crypto/core/keys.ts,crypto/core/key-format.ts,client/index.ts) dropstartsWith('ec:'|'rsa:')/split(':')/ curve ternaries in favor of the guards and accessors.access.tsre-exports the historic surface as thin aliases over the source of truth:PUBLIC_KEY_ALGORITHMS = KEY_ALGORITHMS,KasPublicKeyAlgorithm = KeyAlgorithm,isPublicKeyAlgorithm = isKeyAlgorithm.PUBLIC_KEY_ALGORITHMSis exported from the public entrypoint.encapKeyType/rewrapKeyTypegainchoices: PUBLIC_KEY_ALGORITHMS, so unsupported values are rejected up front with the valid list.Why
Mixing a broad type refactor with the ML-KEM feature made #933 hard to review and hard to roll back. Landing the feature-independent slice on its own keeps each change reviewable and independently revertable.
Bug fix (intentional behavior change)
isPublicKeyAlgorithmpreviously accepted onlyec:secp256r1/rsa:2048and wrongly rejectedec:secp384r1,ec:secp521r1,rsa:4096. It now delegates toisKeyAlgorithmand accepts all supported EC/RSA algorithms.Consequence: the CLI now offers all 5 as
choices, but client-side wrapping still supports only a subset (ec:secp256r1,rsa:2048); unsupported picks now fail at wrap time rather than at arg-parse time.How to test
cd lib && npm run build && npm run lint && npm test— green (334 tests, coverage thresholds met);.d.tsgainsPUBLIC_KEY_ALGORITHMS/ subtypes / accessors,KasPublicKeyAlgorithm+isPublicKeyAlgorithmstill exported.make ithencd cli && npm run build && npm test— green.isPublicKeyAlgorithm('ec:secp384r1')and('rsa:4096')now returntrue.opentdf encrypt --encapsulation-algorithm rsa:9999 …is rejected up front with the choices list;ec:secp384r1is accepted.Scope / risk
Out of scope: all ML-KEM types/guards/accessors/KAO and edits to
tdf.ts/key-access.ts/ tests (those are ML-KEM-only on #933). Touches crypto type plumbing — see the bug-fix note above.DSPX-4040
Summary by CodeRabbit
New Features
Bug Fixes