Every whitepaper about post-quantum cryptography describes what needs to be done. Very few describe what it actually feels like to do it — the specific decisions, the unexpected obstacles, and the moments where the theory meets the reality of a production system with real users.
QuantumShield™ is the result of that process. This is an account of how it was built, what the hardest problems were, and what was learned.
The Starting Point: Choosing ML-DSA-65
When NIST published its final post-quantum standards in August 2024, three signature algorithms were available: ML-DSA-44 (Security Level 2), ML-DSA-65 (Security Level 3), and ML-DSA-87 (Security Level 5).
The choice between them is a trade-off between security and performance. Higher security levels produce larger signatures and require more computation. The question was: how much security is appropriate for a payment platform authentication system?
ML-DSA-44 provides security equivalent to AES-128 — the standard for consumer applications. ML-DSA-87 provides AES-256 equivalent — appropriate for government classified systems. ML-DSA-65 sits between them at AES-192 equivalent, which NIST identifies as the recommended baseline for financial and critical infrastructure applications.
For QuantumShield™, ML-DSA-65 was the clear choice — high enough security for financial infrastructure, with performance characteristics that remain practical for real-time authentication.
ML-DSA-65 at a glance:
Security level: NIST Level 3 (AES-192 equivalent)
Signature size: ~3.3KB (published NIST specification)
Public key size: ~2KB (published NIST specification)
Performance: sub-millisecond signing and verification
The 3,293-Byte Problem
The first implementation challenge was the one that does not appear in any theoretical paper: the signature size.
An ECDSA signature is 71 bytes. An ML-DSA-65 signature is 3,293 bytes — 46 times larger. For a single authentication event, this is manageable. But payment platforms do not perform single authentication events. Every API call carries an authorization token. Every session validation involves signature verification. At scale, 46 times more data per request has real consequences for latency, bandwidth, and infrastructure cost.
The solution required rethinking the token architecture. Rather than attaching the full ML-DSA-65 signature to every request, QuantumShield™ performs the dual-signature verification at authentication and carries forward a compact attestation that quantum-safe verification occurred. The specific implementation of this architecture is proprietary.
The result: per-request overhead is reduced to practical levels while the security guarantee is preserved — every valid session was authenticated through both ECDSA and ML-DSA-65.
The Library Choice
Cryptographic libraries are not interchangeable. Using an unvetted implementation of a post-quantum algorithm is, paradoxically, less secure than using classical cryptography implemented correctly — the risk of subtle implementation errors in novel algorithms is significant.
For QuantumShield™, the library selection criteria prioritized auditability and strict NIST FIPS 204 specification compliance. The implementation follows the standard precisely without abstraction layers that obscure what is happening — a principle that applies to all cryptographic code where auditability is a security property. The specific library used is not disclosed publicly.
"In cryptography, the most dangerous code is code you cannot read. An auditable implementation of a correct algorithm is always preferable to an optimized implementation of an unknown one."
Constant-Time Implementation
One of the less obvious implementation requirements is constant-time execution. Cryptographic operations that take different amounts of time depending on secret values leak information through timing side-channels — an attacker measuring response times can, over many requests, infer information about private keys.
QuantumShield™ addresses this at two levels. First, the underlying library uses constant-time comparison operations throughout. Second, the authentication middleware pads response times to a minimum threshold — regardless of how quickly the cryptographic verification completes, responses are not returned before a minimum time has elapsed, eliminating timing information leakage at the API level.
Implementation note:
The specific implementation details of QuantumShield™'s timing protection are proprietary. The principle — padding authentication responses to eliminate timing variance — is well-established in cryptographic literature and described in NIST guidelines.
This adds a small, bounded latency cost to authentication. It eliminates an entire class of timing-based attacks.
The Hybrid Architecture Decision
The most consequential design decision was the hybrid approach itself — combining ML-DSA-65 with ECDSA rather than replacing ECDSA entirely.
The case for pure ML-DSA-65 replacement is straightforward: simpler, smaller, no classical cryptography surface to attack. The case against it is less obvious but more important: post-quantum algorithms are newer, less battle-tested, and potentially vulnerable to attacks not yet discovered.
ECDSA has been analyzed by cryptographers for thirty years. ML-DSA-65 has been analyzed for less than a decade. The hybrid approach means that breaking QuantumShield™ requires breaking both — and breaking two independent algorithms simultaneously is exponentially harder than breaking either one.
This is the same reasoning that led BIS, Cloudflare, and Mastercard to the same hybrid architecture independently. Not because any of them doubts ML-DSA-65, but because layered security is a fundamental principle: defense in depth means no single point of failure.
What Was Learned
Several things became clear through implementation that are not obvious from reading standards documents.
Performance is not the bottleneck. The theoretical performance overhead of ML-DSA-65 — approximately 3x signing time compared to ECDSA — is negligible in practice. Network latency, database queries, and request parsing dominate authentication latency. The cryptographic computation is not the limiting factor.
Signature size matters more than computation time. The 3,293-byte signature is the real engineering challenge, not the 0.3ms signing time. Infrastructure designed around small ECDSA signatures needs to be rethought for post-quantum token payloads.
The NIST specification is readable and implementable. FIPS 204 is a remarkably clear document compared to many cryptographic standards. Following it precisely produces a correct implementation without requiring deep expertise in lattice mathematics.
Crypto-agility is not optional. QuantumShield™ was designed from the beginning with the assumption that the algorithm will need to change. Every component that touches cryptographic operations is versioned and isolated. When ML-DSA-87 becomes appropriate, or when FIPS 206 (FN-DSA) is incorporated, the change should not require a rewrite — just a configuration update and a new key generation cycle.
What QuantumShield™ 4.0 Adds
The current implementation is version 3.0. The roadmap toward 4.0 addresses the next layer of the problem.
Quantum-recoverable authentication — drawing on Zcash's recent work — will allow users whose classical credentials are compromised to re-establish access using only their ML-DSA-65 key, without losing account history or requiring support intervention. The post-quantum layer becomes not just an additional security layer but a recovery mechanism.
ML-KEM (FIPS 203) key encapsulation will be added to protect the session key exchange — the part of TLS that establishes the encrypted channel — against harvest-now-decrypt-later attacks on session traffic.
An algorithm transparency dashboard will make the current cryptographic configuration publicly visible and auditable — a practice that no payment platform currently offers but that reflects the philosophy behind QuantumShield™: security through transparency, not obscurity.