Post-Quantum Cryptography in the Browser
Post-Quantum Cryptography in the Browser
The Last Mile of the PQC Migration Is the One Every User Touches
Post-quantum migration usually gets discussed in terms of servers, certificate authorities, and VPN gateways — the infrastructure layer. But the web's actual trust decision — is this really my bank's website? — is made by a browser, on a device you're holding right now. If the browser can't verify a post-quantum signature, none of the upstream migration matters to the person using it.
Why This Matters
Every HTTPS connection rests on two promises: the certificate proves who a server is, and the TLS handshake proves the server actually holds the matching private key. Both promises are backed by digital signatures — and both are exactly what a cryptographically relevant quantum computer would break. A browser that only understands RSA and ECDSA signatures cannot make either promise once those algorithms fall.
This is also where "harvest now, decrypt later" becomes concrete for ordinary users: every TLS session, every certificate chain, every signed handshake happening in a browser today is exactly the kind of traffic that could be recorded now and broken open later. Migrating the browser closes that door at the one place all web traffic actually passes through.
Bringing a NIST-standardized post-quantum signature algorithm — ML-DSA (FIPS 204), the standardized form of CRYSTALS-Dilithium — into a browser's trust stack is what turns "the ecosystem supports PQC" into "your browser actually trusts a PQC-signed site."
Two Trust Checks, One Cryptographic Core
A browser doesn't make one trust decision per connection — it makes two, and a post-quantum signature has to satisfy both:
- Certificate validation — walking the certificate chain up to a trusted root and checking every signature along the way is genuine.
- The TLS 1.3 handshake — checking that the server on the other end of the connection actually holds the private key matching the certificate it presented.
These two checks happen in different parts of the browser's networking stack, at different points in a connection, for different reasons. Architecturally, the right design is for both to converge on the same cryptographic core rather than each growing its own post-quantum implementation — one place to get right, one place to audit, one place to harden.
Certificate validation and the TLS handshake are independent trust checks — but they should terminate at one shared cryptographic provider.
The FIPS Boundary Changes the Build, Not Just the Algorithm
The cryptographic core sits behind a FIPS cryptographic module boundary — a scoped, audited component that isn't allowed to reach outside itself for cryptography. That single constraint has an outsized architectural consequence: you cannot simply link in a third-party post-quantum library, however good it is. The new algorithm has to be implemented inside the boundary, in a form the module's validation covers.
That's a build and supply-chain decision as much as a cryptographic one — and it's a pattern that recurs everywhere PQC meets a regulated or audited cryptographic core, not just in browsers.
Why It's Harder Than "Add a New Algorithm"
A few architectural properties of post-quantum signatures make this more than a drop-in swap for RSA or ECDSA:
- No pre-hash step. Classical signature verification in a browser's TLS/PKI code has quietly assumed a "hash, then sign" shape for decades. ML-DSA signs the message directly — that assumption has to be unwound at every layer that hard-coded it.
- Much larger keys and signatures. A post-quantum signature measures in kilobytes, not the couple hundred bytes classical algorithms use. Code paths that never questioned "a signature fits in this fixed buffer" have to be revisited.
- The trust surface is wide. A signature algorithm touches certificate parsing, path validation, handshake logic, the cryptographic provider's mechanism table, and even user-facing certificate display — not just one isolated crypto routine.
None of this is a reason to wait. It's a reason to treat browser-level PQC as an architecture project, not a library upgrade.
Performance Doesn't Have to Be the Trade-off
A reasonable worry is that post-quantum signatures make browsing noticeably slower. In practice, signature verification — the operation a browser performs constantly, once per certificate and once per handshake — is inexpensive relative to a TLS handshake's overall budget. The cost of post-quantum signatures shows up mainly on the wire (larger certificates and handshake messages), not on the CPU. That's a bandwidth and protocol-design conversation, not a "PQC makes the web slow" one.
Where This Fits
Browser-side verification is the last link in a chain that starts at the certificate authority and runs through every server in between — which is exactly the layered problem Ellyptech's post-quantum product suite is built around: a Hybrid Certificate Authority issuing PQC-signed certificates is only as useful as the clients that can verify them. Getting post-quantum signatures working end-to-end, from CA to browser, is what makes a PQC migration real rather than aspirational.
Want to talk through what a PQC migration actually touches in your stack?