The QKD Misconception
There is a persistent narrative in the security industry that defending against quantum computers requires quantum hardware. This narrative is primarily driven by vendors selling Quantum Key Distribution (QKD) systems, which use quantum mechanical properties of photons to detect eavesdropping on a communication channel. QKD is genuinely interesting physics. It is also completely impractical for securing the internet.
QKD requires dedicated dark fiber between every pair of communicating endpoints. It operates point-to-point only, with no routing, no multiplexing, and no store-and-forward. Each link requires specialized hardware costing $100,000 to $500,000 per endpoint. The maximum reliable distance is approximately 100 kilometers without quantum repeaters, which do not yet exist as commercial products. QKD cannot traverse the public internet. It cannot protect a REST API call from a mobile phone to a cloud server. It cannot secure an email. It cannot protect stored data.
NIST has explicitly stated that it does not recommend QKD for most applications. In their 2024 guidance, they describe QKD as having "practical limitations" including "the requirement for special purpose equipment" and "the inability to integrate with existing network infrastructure." NIST standardized post-quantum cryptography (PQC), not QKD, as the recommended defense against quantum attacks.
Post-Quantum Cryptography: A Software Upgrade
Post-quantum cryptography takes the opposite approach from QKD. Instead of using quantum physics to protect communication channels, PQC uses mathematical problems that no known quantum algorithm can efficiently solve. The critical distinction: these algorithms run on classical hardware. The same x86 and ARM processors that run your current workloads. The same cloud instances. The same on-premises servers.
NIST finalized three post-quantum standards in 2024:
- FIPS 203 (ML-KEM / CRYSTALS-Kyber) for key encapsulation, replacing ECDH and RSA key exchange. Security based on Module Learning With Errors (MLWE).
- FIPS 204 (ML-DSA / CRYSTALS-Dilithium) for digital signatures, replacing RSA and ECDSA signatures. Security based on MLWE + MSIS.
- FIPS 205 (SLH-DSA / SPHINCS+) for hash-based signatures as a conservative alternative. Security based on hash function preimage resistance.
Every one of these algorithms is implemented in software. No FPGA required. No ASIC required. No quantum photon detector required. The mathematical operations are polynomial arithmetic, number-theoretic transforms (NTTs), and matrix operations over finite fields. These are the same categories of operations that CPUs have been optimized for over decades.
QKD vs PQC: The Comparison Table
| Dimension | QKD (Quantum Key Distribution) | PQC (Post-Quantum Cryptography) |
|---|---|---|
| Hardware Required | Dedicated photon sources, detectors, dark fiber | None (existing CPUs) |
| Cost Per Link | $100K - $500K | $0 (software update) |
| Deployment Time | Months (physical installation) | Minutes to hours |
| Topology | Point-to-point only | Any (internet-native) |
| Max Distance | ~100 km (without repeaters) | Unlimited (routable) |
| Internet Compatible | No | Yes |
| Mobile Device Support | No | Yes |
| Protects Data at Rest | No (channel protection only) | Yes |
| NIST Standardized | No (explicitly not recommended) | Yes (FIPS 203/204/205) |
| Scalability | O(n²) for n endpoints | O(1) per endpoint |
Proof: 2.17 Million Ops/Sec on Commodity ARM
H33's entire post-quantum stack runs on a single AWS Graviton4 instance (c8g.metal-48xl). This is a commodity ARM server available to anyone with an AWS account. It is not custom silicon. It is not a quantum computer. It is not a specialized cryptographic accelerator. It is a standard 96-vCPU, 384 GiB cloud instance running Linux and compiled Rust binaries.
On this commodity hardware, H33 sustains 2,172,518 authentications per second over 120 seconds of continuous load, with variance of only 0.71%. Each authentication includes:
- BFV Fully Homomorphic Encryption (939 microseconds for a 32-user batch) performing biometric matching entirely on encrypted data. No plaintext ever touches the server.
- STARK Zero-Knowledge Proofs (0.059 microseconds cached lookup) verifying identity claims without revealing the underlying data.
- CRYSTALS-Dilithium signatures (291 microseconds per batch) attesting the result with NIST-standardized post-quantum digital signatures.
- ML threat detection agents (2.35 microseconds total) running harvest detection, side-channel analysis, and cryptographic health monitoring in real time.
The per-authentication cost is 38.5 microseconds. That is 38.5 millionths of a second. Faster than the time it takes light to travel 12 kilometers. And every single layer of this pipeline is quantum-resistant. On hardware you can rent right now for under $2.30 per hour.
At 2.17M auth/sec on a ~$2.00/hour instance, the per-authentication infrastructure cost is less than $0.000001. One millionth of a dollar. A million authentications cost less than a dollar in compute. Post-quantum is not expensive; it is effectively free at scale.
The Software-Only Migration Path
Migrating to post-quantum encryption does not require a hardware refresh, a network redesign, or a multi-year infrastructure project. It requires updating your cryptographic libraries and, ideally, calling a specialized API that handles the complexity for you. Here is what the migration actually looks like for different deployment models:
Option 1: API-First (Minutes)
The fastest path to post-quantum protection is using H33's API. Replace your authentication, encryption, or key exchange calls with a single H33 API call. The entire PQ stack executes on H33's infrastructure. Your application sends data over TLS, H33 processes it under full homomorphic encryption, and returns the result. You never handle key material. You never manage parameter sets. You never worry about side-channel resistance.
Integration is three lines of code in any language. The free tier includes enough credits to test the full pipeline in your staging environment. Production pricing is credit-based with volume discounts.
Option 2: Library Integration (Hours to Days)
For teams that need to run PQ cryptography in-process, every major language ecosystem now has ML-KEM and ML-DSA implementations. OpenSSL 3.2+ includes a PQ provider. BoringSSL (used by Chrome and Android) has had ML-KEM support since 2023. Rust's ecosystem offers multiple pure-Rust implementations. Go's standard library added experimental ML-KEM support in Go 1.23.
The integration pattern is identical to existing key exchange and signature operations. You generate a key pair. You encapsulate or sign. You decapsulate or verify. The API surface is the same; the underlying math is different. If your application already uses abstracted cryptographic interfaces (which it should), the change is a configuration-level swap.
Option 3: Infrastructure-Level (Days to Weeks)
For organizations that need PQ protection at the infrastructure layer, the migration targets are TLS termination, VPN gateways, and certificate authorities. Modern TLS stacks already support hybrid key exchange (X25519 + ML-KEM-768). Updating your TLS configuration to prefer hybrid cipher suites is a single configuration change in nginx, HAProxy, or your cloud load balancer. AWS ALBs and CloudFront distributions support post-quantum TLS natively.
What About Existing Data?
Software-only migration protects all future communications immediately. But what about data encrypted with classical algorithms and stored at rest? This is the harvest-now, decrypt-later problem in reverse: data encrypted today with RSA or AES-with-ECDH-exchanged-keys may be vulnerable if the key exchange is compromised.
The solution is re-encryption. For data at rest, you decrypt with the existing key and re-encrypt with a post-quantum scheme. For databases, this can be done as a background migration. For object stores, it is a batch operation. H33's storage encryption product handles this transparently, re-encrypting data in place using BFV FHE so that the plaintext is never exposed to the re-encryption service.
Pure Rust, No External Dependencies
H33's entire cryptographic stack is written in pure Rust with zero external C dependencies. No OpenSSL. No libsodium. No GMP. Every line of cryptographic code is auditable, memory-safe, and compiled from source. This matters for supply chain security: there is no transitive dependency on a C library that might introduce vulnerabilities. The compiler enforces memory safety. The type system prevents class errors. Constant-time operations are verified at the IR level.
This architectural choice is itself a form of "no hardware changes required." The Rust compiler targets every major platform: x86_64, aarch64 (ARM), RISC-V, WebAssembly. The same codebase runs on your laptop, your cloud servers, your edge nodes, and in the browser. One implementation. Every platform. No hardware dependencies.
Post-quantum encryption is a software upgrade. H33 makes it a single API call. Start with the free tier, explore the API documentation, or read the PQC architecture overview. No hardware purchase order required.
Conclusion
The quantum threat requires a cryptographic response, not a hardware response. NIST standardized software-based post-quantum algorithms precisely because they run on existing infrastructure. QKD is a physics experiment that cannot scale to the internet. PQC is a software deployment that runs on every CPU manufactured in the last decade. H33 proves this at scale: 2.17 million post-quantum operations per second on commodity ARM hardware, at less than one millionth of a dollar per operation.
The migration path is clear. The performance is proven. The standards are finalized. The only hardware change required is pressing Enter on your keyboard to deploy.