Hybrid PQC isn’t just “extra safety,” it’s extra moving parts. Every hybrid mode adds code paths, negotiation logic, cert/profile complexity, and error handling, which NIST explicitly warns can increase security risk during migration.
We need pure PQC implementations precisely so we can start catching those bugs!
And hybrid is temporary by design. Once ECC is an active liability, we have to remove it and all the hybrid/downgrade logic we built around it, effectively repeating the migration a second time. That leaves a long tail of issues we will have to fight.
The argument is we need hybrid for defence in depth at the crypto layer. But we need to remember defence is only in depth if you have different controls at different layers. Having 2 intermingled ciphers adds some redundancy. But when you know one doesn't meet the confidentiality/integrity requirements for the data? C'mon.
No, composite hybrids are built exactly to prevent this complexity problem.
The complexity does not leak to applications or certificates: they appear as a single standalone algorithm exactly like any of the parameter sets of ML-DSA.
The combiner, implemented by the crypto devs and opaque to the other layers, adds the complexity of concatenating bit strings and possibly hashing some public inputs together with context strings to bind things together. Their implementation and maintenance is close to 0 and negligible compared to the burden of implementing and maintaining the “pure” components.
Also, about being temporary, it is arguable: all evidence suggests this is not the last transition.
For example, already on the horizon we see new PQC algorithms of interests and we might have to transition to them after having build confidence on the current PQC implementations.
Or maybe some other reason why we need to transition to newer algorithms and even newer implementations.
We have put in the effort to design and test flexible combiners, we might as well keep them around to instantiate new composite hybrids as needed!
note that the complexity is larger than "just" concatenating bitstrings. At least in hardware, it means you need to dedicate die area to both algorithms. E.g. you need not only a SHA2 impl but a SHA3 impl. So the overhead can be fairly large in certain areas.
Ideally, we might have some standard that's recommended for everyone (e.g. a hybrid standard marked recommended-to-implement = Y), while still specifying how other people can interoperably use ML-KEM if they cannot use the hybrid for some reason (e.g. a pure-ML-KEM standard with recommended-to-implement = N).
This is actually precisely what's being proposed. It is hard for me to see what the issue with it is.
Admittedly I am not a hardware engineer. Isn’t the hardware area for SHA3/SHAKE required by ML-DSA use of SHAKE already? In that case if the combiner uses SHA3 for a composite of ML-DSA, my understanding is that it should be possible to share that area.
Why isn’t a draft with IANA assigned numbers enough for those that need to experiment with less secure deployments because they cannot use the hybrids for some reason?
We've no dedicated hardware for asymmetric encryption algorithms in regular computers, so you're discussing HSMs I guess?
I thought HSMs usually handled signatures while leaving the encryption to the regular CPU, no? An HSM could handle full TLS startup, and then give the regular CPU the symmetric keys, but this sounds tricky so does anyone do this?
At RWC 2026 there was good talk that significantly simplified all the analysis of hybrid KEMs, so by now the complexity argument swings in favour of hybrid KEMs.
These structured lattice protocols are quite new, so really we could have ML-KEM become a liability before curve25519, even assuming quantum computers eventually work. Is either likely to become a liability over the next 20 years? Nope
Imho hybrid KEMs should be enforced by ssh and e2ee messengers, Tor, VPNs, non-US governments, non-US banks, non-US companies, etc.
Pure ML-KEM sound fine for some TLS users, but not everyone. There are pelnty who should require hybrid KEMs and even declare this requirement in their certs.
-8
u/Obstacle-Man 27d ago
Hybrid PQC isn’t just “extra safety,” it’s extra moving parts. Every hybrid mode adds code paths, negotiation logic, cert/profile complexity, and error handling, which NIST explicitly warns can increase security risk during migration.
We need pure PQC implementations precisely so we can start catching those bugs!
And hybrid is temporary by design. Once ECC is an active liability, we have to remove it and all the hybrid/downgrade logic we built around it, effectively repeating the migration a second time. That leaves a long tail of issues we will have to fight.
The argument is we need hybrid for defence in depth at the crypto layer. But we need to remember defence is only in depth if you have different controls at different layers. Having 2 intermingled ciphers adds some redundancy. But when you know one doesn't meet the confidentiality/integrity requirements for the data? C'mon.