Related · tier-1 reading. For how to migrate before the NIST deadline and stay verifiable, see Post-Quantum.
Deploy FIPS 203/204/205 compliant post-quantum cryptography as an overlay on your existing infrastructure. Three independent signature families. Sub-millisecond overhead. No code changes to your application.
Traditional post-quantum migration follows a rip-and-replace model: identify every cryptographic dependency, replace each one with a post-quantum equivalent, test, and deploy. For an enterprise with hundreds of systems, this process takes 12-24 months of engineering effort, introduces significant risk of regression, and requires specialized cryptographic expertise that most organizations do not have.
The H33 overlay approach eliminates this timeline. Instead of replacing cryptographic primitives inside your applications, the overlay adds a post-quantum layer on top. Your existing systems continue to operate unchanged. The overlay handles ML-KEM key exchange, ML-DSA signatures, and three-family attestation as middleware that sits between your clients and your backend.
The H33 Gateway deploys as a reverse proxy in front of your existing API or web application. It terminates incoming connections using hybrid TLS (classical ECDH + ML-KEM per FIPS 203), ensuring quantum-safe key exchange without requiring client-side changes. Clients that support hybrid TLS negotiate quantum-safe connections automatically. Clients that do not fall back to classical TLS, maintaining backward compatibility.
Every response passing through the gateway receives an ML-DSA signature (FIPS 204) and an H33-74 attestation. The signature provides non-repudiation and tamper evidence. The attestation provides long-term verifiable proof that the response was generated at a specific time by a specific server, using three independent post-quantum signature schemes.
H33 does not rely on a single post-quantum algorithm. Every attestation is signed with three independent families based on three independent mathematical hardness assumptions:
| Family | Algorithm | Standard | Hardness Assumption |
|---|---|---|---|
| Lattice (MLWE) | ML-DSA-65 | FIPS 204 | Module Learning With Errors |
| Lattice (NTRU) | FALCON-512 | Pending FIPS | NTRU lattice problem |
| Hash-based | SLH-DSA-SHA2-128f | FIPS 205 | Stateless hash function security |
This means the attestation is secure unless MLWE lattices, NTRU lattices, AND stateless hash functions are simultaneously broken -- three independent mathematical bets. No single-algorithm deployment provides this level of defense-in-depth.
FIPS 203 (ML-KEM): The gateway uses ML-KEM-768 for hybrid key encapsulation in TLS handshakes. The combined key derivation uses both the ECDH shared secret and the ML-KEM shared secret, ensuring quantum-safe session establishment.
FIPS 204 (ML-DSA): Every API response is signed with ML-DSA-65, providing 128-bit post-quantum security for digital signatures. Signature generation takes approximately 100 microseconds.
FIPS 205 (SLH-DSA): The three-key signer includes SLH-DSA-SHA2-128f-simple as the hash-based signature component. This provides a fundamentally different hardness assumption from the lattice-based schemes.
Deploy the H33 Gateway as a Docker container or standalone binary in front of your existing API. Configure the upstream URL, TLS certificate, and H33 API key. The gateway begins proxying requests and adding PQC headers immediately.
Enable hybrid TLS for clients that support ML-KEM. Monitor the percentage of quantum-safe connections. Classical clients continue to work without changes.
Enable continuous attestation for all API interactions. Build the attestation chain that provides long-term verifiable proof of your quantum-safe deployment. Present attestation records to auditors, insurers, and regulators.
| Operation | Overhead | Impact |
|---|---|---|
| Hybrid TLS handshake | ~1ms additional | Amortized across connection lifetime |
| ML-DSA response signing | ~100 microseconds | <0.1% for typical API responses |
| H33-74 attestation | ~50 microseconds | Negligible per-request overhead |
| Total per-response | ~150 microseconds | Less than typical network RTT |
The overlay architecture provides complete rollback capability. If any issue arises with the post-quantum layer, change the gateway configuration from "hybrid" to "classical" and restart. Your backend is completely unaffected. Clients automatically negotiate classical TLS. The rollback takes seconds, not hours.
This is the fundamental advantage of the overlay approach: you get quantum-safe protection immediately with zero risk to your existing systems, because your existing systems are not modified.
Deploy NIST-compliant post-quantum cryptography in days, not months. No rebuild required.