Post-Quantum Readiness

Three-family post-quantum signatures shipped today. Federal-grade. NIST-aligned.

Federal evidence retention windows outlive the cryptographic primitives the evidence was signed with. RSA and ECDSA signatures retained for twenty-five years will be cryptographically broken before the retention window closes. H33 ships post-quantum signatures today: ML-DSA-65, FALCON-512, and SLH-DSA-128f. Three independent algorithm families. If any one family is broken, the others survive.

The cryptographic transition problem

RSA-2048 has been the federal default for digital signatures for decades. A cryptographically-relevant quantum computer breaks RSA. Shor's algorithm running on sufficient quantum hardware factors RSA's underlying composite integer in polynomial time. Once that capability exists, every RSA signature ever produced is forgeable, retroactively, indefinitely. The same is true for ECDSA. Federal evidence retained for twenty-five years signed with RSA-2048 is a bet that no cryptographically-relevant quantum computer will exist before the retention window closes. That bet is increasingly hard to defend.

NIST's response

NIST initiated the post-quantum cryptography standardization process in 2016. After a multi-year competitive evaluation, NIST has finalized: FIPS 204 (ML-DSA) — Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium. FIPS 205 (SLH-DSA) — Stateless Hash-Based Digital Signature Algorithm, formerly SPHINCS+. FIPS 206 (FN-DSA, anticipated) — Falcon-based signature algorithm. NSA's CNSA 2.0 mandates ML-DSA-87 for National Security Systems, with transition timelines spanning 2027–2033. H33 ships ML-DSA-65, FALCON-512, and SLH-DSA-128f today.

Why three families

A single post-quantum algorithm family is insufficient for evidence retention windows that span decades. Cryptographic algorithms occasionally fail. A single-algorithm signature scheme retained for 25 years is exposed to the risk that the algorithm fails during the retention window. A three-family signature scheme mitigates this risk. The three families rest on independent mathematical assumptions: ML-DSA on module lattice (Module-LWE, Module-SIS); FALCON on NTRU lattice with different security analysis; SLH-DSA on hash function security only, no algebraic assumption. A break of one family does not affect the others.

Algorithm summary

ML-DSA-65 (Dilithium-3): NIST level 3 security, lattice-based (Module-LWE), public key ~2 KB, signature ~3.3 KB, fast signing and verification. FALCON-512: NIST level 1 security with explicit diversity from ML-DSA, lattice-based (NTRU), public key ~900 bytes, signature ~660 bytes, fast verification, smaller signatures. SLH-DSA-128f (SPHINCS+-128f): NIST level 1 security, hash-based with no algebraic assumption, public key ~32 bytes, signature ~17 KB, slow signing and verification but zero algebraic security assumption. Combined signature footprint approximately 21 KB per artifact.

Use cases

Federal AI evidence with 25-year retention. AI decision artifacts signed today must remain verifiable through 2050+. Three-family PQ signatures meet that requirement. Classified evidence retention. Indefinite retention requirements need maximum algorithmic redundancy. Three independent families provide it. Inter-agency evidence sharing across PQ transitions. Agencies transitioning to PQ at different rates can share artifacts valid under multiple algorithm families. Future-proofing existing evidence. Artifacts already on file can be augmented with additional PQ signatures using schema versioning.

Common questions

Why not just ML-DSA?
ML-DSA is the NIST primary standard, but a single algorithm is insufficient redundancy for decade-scale retention. A break would invalidate every artifact signed solely with it. The three-family scheme survives single-algorithm failure.

Is this CNSA 2.0 compliant?
ML-DSA-65 satisfies CNSA 2.0's ML-DSA requirement at NIST level 3. CNSA 2.0 specifies ML-DSA-87 for NSS at the highest classification level; H33 supports that algorithm variant on request.

Are the keys FIPS 140-3 compatible?
Yes. The signing keys can be held in FIPS 140-3 validated HSMs.

Can I upgrade existing artifacts?
Yes. Additional signatures can be added to existing artifacts via schema versioning.

Is FALCON in FIPS yet?
Falcon is anticipated as FIPS 206. H33 implements FALCON-512 per the current Falcon specification.

Get Started

Run the demo Download the verifier Download a bundle