Hybrid or pure? The argument the post-quantum world is actually having

The new NIST algorithms are standardised, shipped, and running in your browser right now. So why do some of the world's best-known cryptographers say they should never be used alone? A tour of the one genuinely unsettled question in PQC — and where Cryptsoft chooses to stand.

§1 — the threatWhat a quantum computer actually breaks.

The thing the industry is worried about is a cryptographically relevant quantum computer — one with enough qubits to run Shor's algorithm against the classical asymmetric cryptography that underpins essentially everything deployed today: RSA, DSA, Diffie-Hellman, ECDSA, and elliptic curves in general. Shor's algorithm is theoretical only in the sense that the machine to run it doesn't exist yet. The mathematics is done.

There are two escape routes. One is physics: quantum key distribution sidesteps algorithms entirely, using the properties of entangled photons so that Alice and Bob end up holding the same secret without that secret ever being transmitted between them. The other is mathematics: find algorithms built on different problems — ones with no known quantum speed-up — and migrate to those. That second route is post-quantum cryptography, and it is the one the internet has actually taken.

§2 — the trust problemNew algorithms, and the people who don't trust them.

The NIST winners — ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures — have no known quantum attack against them. They also aren't as elegant as what they replace: the trade-off is larger keys, or slower operations, or both. And they are relatively young. The mathematical foundations simply haven't absorbed decades of attack the way RSA and elliptic curves have.

That youth is the opening for the skeptics. Some well-known cryptographers have publicly criticised the NIST selection process, arguing the chosen algorithms may not be as strong as claimed and pointing at the involvement of the US government in the standardisation. They favour alternative post-quantum schemes with longer research pedigrees — which come with their own less desirable properties. And here it helps to remember how security actually works: you can't prove an algorithm is secure — you can only demonstrate it's insecure by finding an attack. The day before an attack is published, you believe you're secure; the day after, you're not. Security is never an absolute you can guarantee. It's a trade-off, and what the skeptics are saying is that — given the parameters, who is behind them, and how relatively young the mathematics is — they don't believe this trade-off is the right one. That doesn't mean they know it's broken. And the absence of a published break doesn't make it secure.

§3 — the easy callFor key exchange, hybrid won. Fast.

Out of that distrust came a pragmatic idea: don't use the new algorithms instead of the old ones — use them together. A hybrid key exchange runs ML-KEM and a classical mechanism like ECDH side by side, combined so that an attacker has to break both to break the session. If the new mathematics turns out to have a flaw, the old mathematics still protects you.

For key exchange the argument is close to airtight, because the failure mode is catastrophic: break the key exchange and you've exposed everything encrypted underneath it — including traffic recorded years earlier by a harvest-now-decrypt-later adversary. That's why the browser vendors and the major server vendors moved to hybrid ML-KEM with unusual speed once NIST finalised the standards, and why it's what your browser is using on this page right now. It's what shipped in OpenSSL Library v3.5: hybrid key exchange, classical and post-quantum together.

§4 — the real argumentSignatures are where it gets interesting.

Signatures are different, and this is where the community genuinely splits. Breaking a signature scheme doesn't expose data — it lets someone forge. You lose confidence that a signature is real; people can repudiate what they signed. How much that matters depends entirely on what the signature is for.

So the honest answer to "should signatures be hybrid?" is: it depends what you're signing. The skeptics hold that ML-DSA and SLH-DSA should never be used alone, full stop. Others consider hybrid signatures pointless ceremony for ephemeral use cases. Both camps have a case. That is what makes it a real argument rather than a settled one.

§5 — where we landedOur token signs with both halves of the future.

When Cryptsoft built its post-quantum authentication token — the hybrid FIDO2 passkey we wrote about in April — we had to pick a side for signatures. We picked hybrid: a classical signature and an ML-DSA signature, both present, both checked.

Partly that was engineering conservatism: because people are arguing about it this much, do both. Partly it was ambition — we were already pushing the envelope running Rust on a small device, doing hybrid signatures instead of pure, and fitting the result into Passkeys outside the web context where they normally live. Some people think hybrid signatures are wrong. Some think they're absolutely essential. Ours ships with both, so the argument can continue without your credentials depending on who wins.