dr. Bas Westerbaan

email github scholar notes

<Hybrid Signature Troubles

17 Jun 2026

It seems like a no-brainer to deploy PQ/T hybrid signatures instead of post-quantum signatures on its own. However, on closer inspection, hybrids come with a serious drawback: they increase the number of options and tempt reuse of existing infrastructure. Because of this they delay agreement on what to deploy. Thus especially in more fragmented ecosystems, supporting standalone post-quantum signatures is the safest bet for interoperability and thus quantum security.

What we see here is disagreement on the traditional part, the post-quantum part, and even the way these are combined. Picking a hybrid requires resolving all three at the same time.

This blog post collects scattered remarks made in various presentations and IETF e-mail discussions.

A PQ/T hybrid signature is where you combine a post-quantum signature together with a traditional (non post-quantum) signature scheme. Let’s start with the advantages.

  1. If the post-quantum algorithm (eg. ML-DSA-44) turns out to be weak, the hybrid signature is still as secure as the traditional component (eg. ECDSA-P256.)

  2. Even if the post-quantum algorithm is secure, the implementation of it might not be secure. The hybrid also helps there.

  3. If you need a certain certification (eg. FIPS), you can reuse the one you already have for the traditional part while you wait for the post-quantum part to be certified. Similarly, with hybrids you can achieve some hardware guarantees you have for the traditional part, that you don’t yet have for the post-quantum part.

Ok, great. With that in mind, what signature algorithm should we choose to deploy in the WebPKI? At the time of writing, this is the essential 1 list of options including non hybrids.

Obviously servers can’t provision 33 certificates each. It’ll be a struggle for many servers to deploy two certificates: one traditional for legacy clients and post-quantum for upgraded clients. We might well need to hack both into what seems to be a single legacy certificate, but that’s an interesting topic for another time.

It’s not just provisioning certificates: adding each variant requires code and testing. Interestingly, most incompatibilities in early testing of hybrids wasn’t between the post-quantum part, but between the traditional parts. And in more constrained ecosystems, there is a real cost to the extra support.

So it’s best if each ecosystem agrees on a few or ideally just one post-quantum option for broad deployment. When I give talks about this, so far, everyone fully agrees.

So, which option? During these talks (eg. 1, 2, 3) I go through my thinking, eliminating a bunch of options slide by slide. With each slide there is always clear mumbling and groaning from the audience.

  1. TLS is only as secure as its key agreement. ML-KEM is the only option available today, so relying on ML-DSA does not add much of a security assumption. Thus, we can cross out the SLH-DSA options.

  2. Ciphertexts need to be secure forever. Certificates only need to survive long enough to be rotated. ML-DSA-44 has a comfortable margin above 128-bits. Thus we can cross out the ML-DSA-65 and ML-DSA-87 (hybrid) options.

  3. RSA’s benefit over ECC is its fast verification time. That benefit is negated by combining it with ML-DSA-44. Thus we can cross out the RSA hybrids.

  4. Ed25519 is a better signature algorithm than ECDSA-P256, but its support in the WebPKI is very limited today. Better not to impose unnecessary extra work.

That leaves MLDSA44-ECDSA-P256 and ML-DSA-44 as my picks. But what I’d prefer is not important: we need agreement.

I’ve received a lot of comments on my selection. Just to name a few:

It’s tempting to discuss the merit in these, but that’s missing the point. What we see here is disagreement on the traditional part, the post-quantum part, and even the way these are combined. Picking a hybrid requires resolving all three at the same time.

At the IETF, for certificates we attempted to create a shortlist of hybrid options. Initially this contained MLDSA44-ECDSA-P256, but quickly ballooned to six options so far.

So what will happen going forward? That will depend by ecosystem. Some have a set formal process to come to agreement. In others, especially the most distributed ones, there will be in essence a vote by deployment. If you’re early and you’re a large player, you can deploy something broadly acceptable. Others will have an incentive to match to prevent another round of deployment. We saw alignment on the hybrid key-agreement X25519MLKEM768, not because it was the only choice proposed, but because it was already deployed widely and acceptable for others to adopt too. Given the shortened timelines it’s likely we’ll see a lot of post-quantum signature deployment by different parties coming out at the same time.

Let’s think through the reasoning of a party that prefers a hybrid. They know that their particular choice (probably influenced by their existing PKI) might not be shared by other parties. They could add support for other hybrids, but the easiest path for compatibility is also adding support for ML-DSA on its own. When would such a party insist on hybrid?

We can draw a square:

Quantum attack far away Quantum attack imminent
ML-DSA solid Either on their own solid Traditional part broken
ML-DSA broken ML-DSA/T hybrid helps Need PQ backup, not traditional one

If you’re concerned about quantum attack and ML-DSA being broken, then an ML-DSA/T hybrid doesn’t help much. You’d want to line up a post-quantum backup for ML-DSA and ML-KEM if it’s a problem with the algorithm. If you’re worried about the implementation, you’d want to put effort into improving the implementation itself (testing, formal verification, etc), as the traditional part doesn’t give you the post-quantum security.

So what’s left? It appears that insisting on PQ/T hybrids in the face of fragmentation is a bet that quantum attack is far away.

Getting back to parties in an ecosystem. We see that those that are concerned about quantum attack on shorter term, might give their preferred PQ/T hybrid a shot for the side-benefits such as compliance. But when it comes down to it, they still have a clear incentive to also support standalone post-quantum signatures, to maximize interoperability and thus quantum security.

  1. This is the list of post-quantum signature algorithms for which a TLS codepoint has been assigned at the time of writing or is likely to be assigned soon. This list will grow as there are many signature schemes on the horizon. ↩︎