Two Paths to Post-Quantum Security: $18M or One API Call
There are two paths to post-quantum biometric authentication. One takes 3 years, $18 million fully loaded, and a team that doesn't exist on LinkedIn. The other takes one API call and costs $9,143 per year.
This isn't marketing. This is the real math — including equity compensation, employer taxes, benefits, recruiting fees, failed hires, patent filings, salary escalation, and the part nobody talks about: your ZKP layer probably isn't post-quantum.
PATH 1: Build It Yourself
Year 1 — Staffing & Research ($5.7M)
You need people who don't exist on LinkedIn. And someone to lead them.
Base Salaries 9 people
What your CFO will remind you about
Base salary is roughly 60 cents of every dollar you spend on a person. The other 40 cents are taxes, benefits, equity, and overhead. Most hiring managers forget this until Finance sends back the fully-loaded headcount model.
Equity Compensation non-negotiable
You're competing with Google, Microsoft, IBM, and Meta for PhD cryptographers. None of them will accept a cash-only offer. Budget 25–30% of base in RSUs or equity grants.
Employer Burden mandatory
Costs That Don't Show Up on a W-2
Average time to fill these roles: 6–9 months. Each.
While you're recruiting, quantum computers aren't waiting.
Year 1 — Choosing Your Stack
You'll evaluate, prototype, and fight with these:
Fully Homomorphic Encryption from scratch
Microsoft SEAL (C++, BFV/CKKS) or OpenFHE (C++, all schemes). Neither has production biometric matching built in. Neither does SIMD batching across users out of the box. You'll write that from scratch.
Zero-Knowledge Proofs NOT post-quantum
Here's where it gets uncomfortable.
arkworks (Rust, Groth16/Marlin) and Circom + snarkjs (JS, Groth16) are the standard open-source ZKP libraries. They're all based on elliptic curve pairings.
Elliptic curve pairings are broken by quantum computers.
Your "post-quantum" system isn't post-quantum if your ZKP layer uses Groth16 or Marlin. The only quantum-safe ZKP approach: hash-based STARK proofs. No production STARK library exists for biometric FHE verification.
You'll build that from scratch. That alone is a multi-year research project. And you still need to connect it to your FHE outputs. No library does that. You'll write that from scratch too.
The ZKP blind spot
Most teams building "post-quantum" systems quietly use Groth16 for their ZKP layer — which is based on elliptic curve pairings that Shor's algorithm breaks. They ship it anyway and hope nobody checks. If your ZKP isn't hash-based (STARKs), your system has a quantum-vulnerable component in the one place that matters most: the proof that your authentication is valid.
Post-Quantum Signatures from scratch
liboqs / Open Quantum Safe (C, ML-DSA Dilithium + ML-KEM Kyber). Reference implementations, not optimized for production throughput. No batch attestation support. You'll write that from scratch.
Post-Quantum Key Exchange from scratch
liboqs ML-KEM (Kyber). Works, but you need to build the hybrid TLS integration yourself. And the key management. And the rotation. And the revocation.
Integration Layer 12–18 months
Custom REST/gRPC API wrapping all four primitives. Custom key management service. Custom database schema for encrypted templates. Custom monitoring, alerting, logging for compliance.
12–18 months to proof of concept if everything goes right.
Nothing goes right the first time with FHE.
Year 2 — Optimization Hell ($5.4M)
Your proof of concept works. It's also unusably slow.
What Your Unoptimized Stack Actually Delivers ~3,700ms per auth
Your team now spends 12 months trying to optimize:
- Montgomery multiplication to remove division from the hot path
- NTT radix-4 butterflies for cache-friendly transforms
- Harvey lazy reduction to defer modular reduction between stages
- SIMD slot packing to batch multiple users per ciphertext
- NTT-domain persistence to eliminate redundant forward/inverse transforms
- Fused inner products to defer the final INTT
- Pre-computed NTT-form public keys to skip per-encrypt transforms
- Batch attestation to sign once per ciphertext, not once per user
- In-process proof caching to avoid regenerating ZKP proofs
Each of these takes 2–6 weeks of research, implementation, and benchmarking.
Several will fail.
We know because we tried them all. Arena pooling for Vec<Vec<u64>> — zeroing overhead exceeded allocation savings. Fused NTT twiddles — 15% microbenchmark win, but cache pollution under 96-worker contention made it a net negative. NEON 64-bit butterfly — ARM NEON lacks native 64×64→128 multiply. jemalloc on Graviton4 — 8% throughput regression.
You won't know which optimizations regress until you benchmark on production hardware under production contention. Budget accordingly.
Year 2 Fully Loaded
Year 3 — Production & Compliance ($6.9M)
Assuming your optimizations worked (they won't all work), you now need independent verification:
| Audit / Certification | Cost |
|---|---|
| Security audit of custom FHE implementation | $150K–$300K |
| Security audit of custom ZKP implementation | $150K–$250K |
| Security audit of custom STARK prover (if you built one) | $200K–$400K |
| Penetration testing | $50K–$100K |
| SOC 2 Type II certification (auditor + tooling + year of evidence) | $150K–$300K |
| HIPAA compliance (healthcare) | $100K–$200K |
| ISO 27001 certification | $100K–$200K |
Year 3 Fully Loaded
Then you maintain it. Forever. Every NIST draft update, every CVE, every compliance renewal, every departing engineer who takes institutional knowledge with them.
3-Year Total
Fully Loaded Cost Breakdown
What this doesn't include
Opportunity cost of 3 years to market. Board/investor pressure during a long R&D project with no revenue. Security incidents during development before production hardening. The cost of your lead FHE cryptographer getting poached by Google mid-project (it will happen). Office space. Travel for on-site collaboration on classified crypto work. The second round of audits when NIST changes the standard mid-build.
What you get for $18 million
- Maybe 0.27 auth/sec (unoptimized) to maybe 50 auth/sec (if your optimizations land)
- Quantum-safe only if you built a working STARK prover AND every other implementation is correct
- If you used Groth16 or Marlin for ZKP (like most teams do), your system is NOT post-quantum
- No independent verification of your custom crypto
- A team that can leave
PATH 2: H33
One API call.
curl -X POST https://api.h33.ai/v1/auth \
-H "Authorization: Bearer h33_pk_..." \
-d '{"template": "<encrypted_biometric>"}'What happens inside that call:
Verified on production hardware (AWS Graviton4 c8g.metal-48xl, 192 vCPUs, 96 workers). All 14 optimizations in production. Zero in any open-source library.
SOC 2 Type II. HIPAA. ISO 27001. Post-quantum across every primitive: lattice FHE, SHA3 ZKP, ML-DSA, ML-KEM.
Annual cost: $9,143.
The Math
($18.5M ÷ $9,143)
(2.15M ÷ 0.27 auth/sec)
Two thousand times more expensive. And that's before Year 4+ maintenance, re-certification, and the inevitable team turnover.
Where the 8 million× comes from
Speed Breakdown
None of these optimizations exist in SEAL, OpenFHE, arkworks, or liboqs. We know because we tried them all before writing our own.
The Part Nobody Talks About: Your ZKP Layer Isn't Post-Quantum
Most teams building "post-quantum" systems use arkworks or Circom for zero-knowledge proofs.
Both use Groth16. Groth16 is based on elliptic curve pairings. Elliptic curve pairings are broken by Shor's algorithm on a quantum computer.
$18M and 3 years — and your ZKP layer is the one thing a quantum computer can break
The ZKP layer proves your authentication is valid. It's the cryptographic foundation of trust in the entire pipeline. If that layer uses elliptic curves, your "post-quantum" system has a quantum-vulnerable core.
The fix: build a STARK prover. Hash-based. No elliptic curves. Actually quantum-safe. The problem: no production STARK library exists for FHE biometric verification. You'd build it from scratch. Add another 12–18 months and another $2M+ to your timeline.
Most teams give up and ship Groth16 anyway, hoping nobody checks.
H33: SHA3-256 hash-based proofs. Post-quantum by construction.
No elliptic curves. No pairings. No components vulnerable to Shor's algorithm. The ZKP layer is quantum-safe because it's built on symmetric cryptography — the one thing quantum computers can't efficiently break.
Quantum-Safe — Every Layer, Not Just the Easy Ones
DIY path: You hope your team correctly implements lattice FHE, builds a working STARK prover (or quietly ships Groth16 and calls it "post-quantum"), doesn't introduce side channels, survives every NIST draft revision, and gets it right across encryption, proofs, signatures, AND key exchange.
H33: Every primitive is quantum-safe today. Verified. In production.
| Component | Primitive | PQ-Secure | Basis |
|---|---|---|---|
| Encryption | BFV (lattice FHE) | Yes | Ring-LWE hardness |
| ZKP | SHA3-256 hash-based | Yes | Symmetric security |
| Signatures | ML-DSA (Dilithium) | Yes | Module-LWE hardness |
| Key Exchange | ML-KEM (Kyber) | Yes | Module-LWE hardness |
The entire authentication pipeline. Every layer. Post-quantum. In a single API call.
Probably not post-quantum where it matters most
Post-quantum across every primitive
The post-quantum transition isn't a research project. It's a Tuesday afternoon.
Skip the Research Project
One API call. Three cryptographic operations. 36 microseconds. Post-quantum across every layer.
Get Free API Key