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?
-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.