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-DilithiumCRYSTALS-DilithiumThe research name for what became ML-DSA. If a datasheet says Dilithium and a standard says ML-DSA, they mean the same thing., 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 McElieceClassic McElieceOne of the oldest quantum-resistant designs, unbroken since the 1970s. Its keys are very large, which is why it stays in research use rather than everyday traffic. remains a research-only compatibility profile rather than a production default.

• ML-KEM-1024ML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today. — FIPS 203 aligned, 256-bit classical security
• ML-DSA-87 — FIPS 204 aligned, lattice-based signaturesLattice-based signaturesA digital seal attached to data or software. It proves who sent it and shows if anything changed, using grid-like mathematics designed to withstand quantum computers.
• SLH-DSA-SHA2-256sSLH-DSAA second quantum-safe signature built on a completely different kind of maths to ML-DSA. It is slower, and it exists as a fallback in case a weakness is ever found in the first approach. — FIPS 205 aligned, hash-based stateless signatures
• FN-DSA (Falcon)FN-DSA (Falcon)A quantum-safe signature that produces unusually small signatures, which matters for constrained devices. The standard is still being finalised. — compact NTRU lattice signatures, FIPS 206 in development

Hybrid ECDHHybrid modeRunning a classical and a quantum-safe algorithm side by side, so the connection stays secure as long as either one holds. It is the recommended way to cross the transition period. + 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-1024ML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today. 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-1024ML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today., 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-3FIPS 140-3The certification a key-storage device has to pass, covering the hardware itself rather than the maths. It is usually a procurement requirement in regulated sectors. module-boundary alignment when combined with a validated HSM path confirmed for the exact deployment.

• FIPS 203FIPS numbersFIPS is the US government publication series that makes an algorithm official. A FIPS number means the algorithm is approved for real deployment, not still a proposal. / 204 / 205 aligned implementations
• BSI TR-02102 and ENISA PQC report mapped
• CNSA 2.0The standards we followNIST and CNSA 2.0 are the official rulebooks that say which encryption is strong enough to survive quantum computers. “Mapped” means every algorithm we deploy has been matched to what those rulebooks require. 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-3FIPS 140-3The certification a key-storage device has to pass, covering the hardware itself rather than the maths. It is usually a procurement requirement in regulated sectors.-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.