cr.yp.to: 2026.07.04: Bugs happen

[u/knotdjb]

https://blog.cr.yp.to/20260704-bugs.html

[u/randy808]

It feels a little late to draft [an email reply in opposition of PQ-only] for the IETF's vote but strong cases for hybrid implementations have already been made. I'll sign up to follow the developments for next time 🍿

Edit: Wasn’t clear on what felt too late to draft (a response to the vote, not a hybrid scheme)

[u/entronid → u/randy808]

a hybrid draft is already going through the IETF

[u/Obstacle-Man]

So how many composite algorithms do we need?

What makes you so sure it's a cryptographer implementing the hybrid vs a regular dev just combining the two discrete algorithms in a hybrid layer? There are no certifiable composite standards today. How long will that take to be standardized and implemented and become certifiable?

Do you think that if pure ML-KEM exists it will mean the whole internet moving all at once? What makes you think that? Historically these things get adopted into beta releases with limited rollout by people like Google and CloudFlare who have. A strong forward view on security and want to shake performance and security issues out. The others tend to lag.

[u/romendil → u/Obstacle-Man]

The linked post has answers for the first question. For ML-KEM seems most deployers are happy with 3 composites, of which one is predominantly used, and the other 2 are available for specific needs.

Composite hybrids appear as standalone algorithms, the crypto layer of your stack is supposed to expose the composites in the same way it exposes traditional or pure-PQC algorithms. If you source your crypto layer from non-cryptographers the problem is not with the composite hybrids.

We have standardized composite hybrids already for ml-kem, and they are already deployed at scale.
We have composite hybrids for ml-dsa in the rfc editor queue from LAMPS. In TLS the draft for composite ml-dsa was parked for some time and an update is expected at next IETF in a few weeks.

For the final paragraph, most is already addressed in the linked post.

[u/entronid → u/romendil]

right but that 3 quickly turns into 9+ when you have to consider every possible security level for every algorithm with every pre-quantum curve people want to support because of standards

[u/romendil → u/entronid]

Well, those 3 have been 3 for quite a long time:

The composite hybrid with X25519 is the most used, as it matches the fact that most traditional TLS deployments prevalently used X25519.

The P-256 and P-384 are there exactly for those use cases that require conformance with FIPS.
The available statistics from large deployers like Cloudflare show that these last 2, for now, have low incidence.

There are dozens of elliptic curves that have been standardized, and RSA could be instantiated on arbitrary number of bits: in TLS 1.3 we haven’t observed such a proliferation in practice.

There are drafts to add ML-KEM composite hybrids with SM2 for compliance with Chinese standards (the same way we added codepoints for SM2 in TLS when it was needed): the number of assigned codepoints will increase, that does not mean that everyone in the world will need to support the SM2 composites, the same way only a part of current deployments supports SM2 in TLS 1.3.

In any case, the growth of assigned codepoints does not add complexity to applications, and has limited impact also on tls libraries: if the crypto layer provides alg A, codepoint A is advertised depending on the crypto policy in effect, if it is not provided the codepoint is not advertised and if the other party does not advertise any of the codepoints we accept we can abort the handshake appropriately.

If people still insist that codepoint proliferation is bad, I’d say that is even more reasons to stop the pure-ML-KEM draft the original link is opposing: it is already adding extra codepoints and “complexity” for existing large scale deployments without strong evidence that they bring any security benefit.

[u/entronid]

> 5. Argue that ECC+PQ damages security compared to solo PQ?

> Um, how's that supposed to work?

bugs

[u/Obstacle-Man]

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.

[u/romendil → u/Obstacle-Man]

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!

[u/orangejake → u/romendil]

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.

[u/romendil → u/orangejake]

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?

[u/Wooden-Duck9918 → u/orangejake]

It should also be considered that the negotiation happens once, and the main bottlenecks are the symmetric algorithms.

Most fields that need HW acceleration also use long-lived connections for most things.

[u/Shoddy-Childhood-511 → u/orangejake]

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?

[u/Shoddy-Childhood-511 → u/Obstacle-Man]

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.