Standards & Regulatory Alignment — Post-Quantum Financial Architecture
The algorithms and formats Crypto Service Suite implements, mapped to the standards that define them, with the limits of what that implementation claims.
The Global Standards & Regulatory Alignment Matrix
This matrix lists the standards whose algorithms or formats Crypto Service Suite implements. "Implemented" means the algorithm is available in the code; it is not a certification. No module in the suite is FIPS 140-3 validated, and the post-quantum algorithms come from @noble/post-quantum, which is not independently audited.
| Standard / Regulation | Authority | Mandate & Scope | Implementation in Suite | Status |
|---|---|---|---|---|
| NIST FIPS 203 | NIST (United States) | Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) | @sebastienrousseau/crypto-lib (512, 768, 1024) | Implemented (not validated) |
| NIST FIPS 204 | NIST (United States) | Module-Lattice-Based Digital Signature Algorithm (ML-DSA) | @sebastienrousseau/crypto-lib (ML-DSA-44, 65, 87) | Implemented (not validated) |
| NIST FIPS 205 | NIST (United States) | Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) | @sebastienrousseau/crypto-lib (SHA-2 & SHAKE variants) | Implemented (not validated) |
| NIST SP 800-38D & RFC 8439 | NIST & IETF | Authenticated symmetric ciphers (AES-GCM; ChaCha20-Poly1305 in HPKE; XChaCha20-Poly1305 in crypto-lib, crypto-prisma and crypto-typeorm) | @sebastienrousseau/crypto-lib, crypto-prisma, crypto-typeorm | Implemented (not validated) |
| RFC 9180 | IETF | Hybrid Public Key Encryption (HPKE), base and PSK modes, checked against the RFC 9180 test vectors. The hybrid X25519 + ML-KEM KEM uses a library-specific combiner, not RFC 10024. | @sebastienrousseau/crypto-lib (X25519 + ML-KEM) | Implemented (not validated) |
| EU DORA (Regulation 2022/2554) | European Commission (EBA/ESMA) | ICT risk management framework and related technical standards (including encryption and key management) | @sebastienrousseau/crypto-cbom & crypto-kms | Supporting tools only; no compliance claim |
| NSA CNSA 2.0 | National Security Agency | Commercial National Security Algorithm Suite requirements (2025–2030) | @sebastienrousseau/crypto-lib (ML-KEM-1024, ML-DSA-87 available) | Algorithms available; not validated |
| CycloneDX 1.6 & SPDX 3.0 | OWASP Foundation / Linux Foundation | Cryptographic Bill of Materials (CBOM) machine-readable spec | @sebastienrousseau/crypto-cbom CLI & API | Generator available (not run in CI) |
Deep Technical Invariants & Assurance Floors
Every package enforces 100% line and function coverage in CI, and every package except crypto-lib (99.5%) enforces 100% branch coverage. Statement coverage is not separately gated.
@sebastienrousseau/crypto-lib has six runtime dependencies: @noble/ciphers, @noble/curves, @noble/hashes, @noble/post-quantum, openpgp and @openpgp/web-stream-tools. Lattice operations, NTTs and hash functions come from these libraries; they are not implemented in crypto-lib.
The suite makes no constant-time guarantee and has not been evaluated against timing side channels. @noble/post-quantum does not guarantee constant-time execution, and not every secret comparison in crypto-lib is constant-time.
crypto-lib exports wipeMemory() and SecureBuffer for callers, but its own APIs do not call them. Keys are mostly handled as hex strings, which JavaScript cannot wipe, so key material can remain on the heap until garbage collection.
Plan Your Post-Quantum Migration
Talk to the maintainers about architecture reviews, cryptographic inventories for DORA work, and deploying hybrid post-quantum key exchange.