Encryption

Algorithm families we ship

Quanten Security standardises on the first NIST post-quantum FIPS standards and tracks the additional algorithms moving through standardisation. For key encapsulation we ship ML-KEM-1024 (CRYSTALS-Kyber, FIPS 203), the NIST category-5 KEM parameter set with Kyber round-3 core-SVP estimates of 256 classical and 232 quantum bits. For digital signatures we ship ML-DSA-87 (CRYSTALS-Dilithium, FIPS 204) and SLH-DSA-SHA2-256s (SPHINCS+, FIPS 205) depending on whether signature size or signing throughput is the binding constraint. FN-DSA, based on Falcon, is tracked as the FIPS 206 signature path while that standard is in development.

Where a conservative, hash-based alternative is preferred over lattice constructions, SLH-DSA is a stateless option with a long security-analysis record. For key exchange diversity, HQC-256 is tracked as NIST’s selected backup KEM while the final standard develops. Classic McEliece remains a research-only compatibility profile rather than a production default.

• ML-KEM-1024 — FIPS 203 aligned, 256-bit classical security
• ML-DSA-87 — FIPS 204 aligned, lattice-based signatures
• SLH-DSA-SHA2-256s — FIPS 205 aligned, hash-based stateless signatures
• FN-DSA (Falcon) — compact NTRU lattice signatures, FIPS 206 in development

Hybrid ECDH + ML-KEM mode

The migration window between today’s classical infrastructure and a fully post-quantum estate is measured in years, not weeks. During that window, traffic must remain secure against both classical and quantum adversaries simultaneously. Quanten’s hybrid TLS profile runs ECDH-P384 alongside ML-KEM-1024 in the same TLS 1.3 handshake, carrying fixed-length key-share material through the concatenation approach described by the IETF TLS hybrid-design work and deriving traffic secrets through the standard TLS 1.3 key schedule. Neither algorithm’s weakness can compromise the combined key material unless both are broken at the same time.

Hybrid mode is the recommended starting point for production deployments. It requires no changes to application code. For ML-KEM-1024, the post-quantum key share contributes a 1,568-byte encapsulation key in the client offer and a 1,568-byte ciphertext in the server response, roughly 3.1 KB before the classical ECDH share and TLS framing.

Compliance alignment

FIPS 203, 204, and 205 define the NIST algorithm baseline for post-quantum key establishment and signatures. CNSA 2.0, BSI TR-02102, and ENISA guidance provide additional migration references for regulated teams. Our implementations are checked against the NIST Known-Answer Tests (KATs) for each parameter set and are designed for environments seeking FIPS 140-3 module-boundary alignment when combined with a validated HSM path confirmed for the exact deployment.

• FIPS 203 / 204 / 205 aligned implementations
• BSI TR-02102 and ENISA PQC report mapped
• CNSA 2.0 policy templates built in
• NIST KAT-checked for shipped parameter sets

What deployment looks like

Integration follows one of three paths. The TLS library path replaces OpenSSL or BoringSSL with our PQC-enabled fork, which exposes identical API surfaces so application code requires no changes. The proxy path inserts a PQC-aware TLS terminator in front of existing services, wrapping them without touching their configuration. The HSM path generates and stores ML-KEM key material inside a FIPS 140-3-aligned hardware module, keeping private key bytes off the host operating system entirely.

Ready to deploy? Talk to our security team — typical engagements start with a 30-minute scoping call to map existing certificate inventory against the migration timeline.