This is a dense article but what seems reasonably clear is that someone is pushing hard for an insecure standard.
There’s no reason at this point to put all your cryptographic eggs in the post-quantum crypto (PQC) basket. Elliptic curve crypto (ECC) is widely studied and understood; while it’s more vulnerable to quantum cryptanalysis, this is mitigated by the hybrid ECC+PQC proposals (except a bit of lost performance). On the flip side, the PQC stuff is new enough that new attacks are still being devised, so relying fully on that seems like a bad idea. Someone is trying to force the standardization of a PQC-only standard under the claim that it is secure enough, but ignores evidence from quite recent work showing that attacks continue to improve. This is before getting into the fact that PQC implementations are harder to get right and that popular PQC implementations have had nasty side-channel attacks.
For a counterpoint Sophie Schmieg recently wrote https://keymaterial.net/2026/06/18/on-hybrid-signatures/ arguing against hybrids. Putting EC and PQ algorithms together isn't trivial, and the complexity of using multiple algorithms in parallel can, itself, lead to more issues.
In response to the implementation errors in ML-KEM, companies have moved to formal verification. Apple, for example, recently released[1] a formally verified ML-KEM implementation, where they formally verified the assembly of the implementation to verify that it matches the specification and that it's side-channel free. AWS, similarly, is using a formally verified ML-KEM implementation: "All AArch64 and x86_64 assembly is proved to be functionally correct, memory-safe, and of secret-independent timing (constant-time)" [2].
There are similar efforts (by both Apple, Amazon, and others) to formally prove ML-DSA implementations as well.
It's actually extremely trivial in the most common usage of hybrids so far, TLS: You concatenate the output from the PQC (ML-KEM) and non-PQC (ECDH, 25519) and run it through the TLS PRF. It's one line of additional code (a memcpy() to get the extra data across) compared to taking just the output of one of the two and running them through the PRF.
For signatures, you do the same thing, have the PQC sig next to the non-PQC one. Unfortunately cryptographers want to apply every possible bell, gong, and whistle to things, which creates the mess we're in with hybrids. With (say) ECDSA you hash with SHA-256 and sign with P256, and you're done. With the PQC stuff they've used different hash functions (no problems with the old ones but they're so five minutes ago so we need to use all new ones that do the same thing but aren't compatible), non-hashed sigs (because djb doesn't like them and everyone else cargo-culted that even though it turns what should have been a standard signing operation into a giant headache), and a massive amount of other unnecessary complexity.
So it's not so much that hybrids are a pain, it's that cryptographers have gone out of their way to make hybrids a pain. They could be completely straightforward if they just applied them the same way as standard algorithms have been applied for decades.
I have no horses in this race and lack the expertise to judge, but this is part of a larger fight and djb seems to be on the other side of a lot of good cryptographers:
Filippo Valsorda doesn't work for Google. He left there several years ago. He runs an independent "buy contracts with me to support development of open source cryptography software" thing.
This is a dense article but what seems reasonably clear is that someone is pushing hard for an insecure standard.
There’s no reason at this point to put all your cryptographic eggs in the post-quantum crypto (PQC) basket. Elliptic curve crypto (ECC) is widely studied and understood; while it’s more vulnerable to quantum cryptanalysis, this is mitigated by the hybrid ECC+PQC proposals (except a bit of lost performance). On the flip side, the PQC stuff is new enough that new attacks are still being devised, so relying fully on that seems like a bad idea. Someone is trying to force the standardization of a PQC-only standard under the claim that it is secure enough, but ignores evidence from quite recent work showing that attacks continue to improve. This is before getting into the fact that PQC implementations are harder to get right and that popular PQC implementations have had nasty side-channel attacks.
For a counterpoint Sophie Schmieg recently wrote https://keymaterial.net/2026/06/18/on-hybrid-signatures/ arguing against hybrids. Putting EC and PQ algorithms together isn't trivial, and the complexity of using multiple algorithms in parallel can, itself, lead to more issues.
In response to the implementation errors in ML-KEM, companies have moved to formal verification. Apple, for example, recently released[1] a formally verified ML-KEM implementation, where they formally verified the assembly of the implementation to verify that it matches the specification and that it's side-channel free. AWS, similarly, is using a formally verified ML-KEM implementation: "All AArch64 and x86_64 assembly is proved to be functionally correct, memory-safe, and of secret-independent timing (constant-time)" [2].
There are similar efforts (by both Apple, Amazon, and others) to formally prove ML-DSA implementations as well.
[1]: https://security.apple.com/blog/formal-verification-corecryp... [2]: https://github.com/pq-code-package/mlkem-native
It's actually extremely trivial in the most common usage of hybrids so far, TLS: You concatenate the output from the PQC (ML-KEM) and non-PQC (ECDH, 25519) and run it through the TLS PRF. It's one line of additional code (a memcpy() to get the extra data across) compared to taking just the output of one of the two and running them through the PRF.
For signatures, you do the same thing, have the PQC sig next to the non-PQC one. Unfortunately cryptographers want to apply every possible bell, gong, and whistle to things, which creates the mess we're in with hybrids. With (say) ECDSA you hash with SHA-256 and sign with P256, and you're done. With the PQC stuff they've used different hash functions (no problems with the old ones but they're so five minutes ago so we need to use all new ones that do the same thing but aren't compatible), non-hashed sigs (because djb doesn't like them and everyone else cargo-culted that even though it turns what should have been a standard signing operation into a giant headache), and a massive amount of other unnecessary complexity.
So it's not so much that hybrids are a pain, it's that cryptographers have gone out of their way to make hybrids a pain. They could be completely straightforward if they just applied them the same way as standard algorithms have been applied for decades.
I have no horses in this race and lack the expertise to judge, but this is part of a larger fight and djb seems to be on the other side of a lot of good cryptographers:
https://mailarchive.ietf.org/arch/msg/tls/ZBpcicZX1Dxnam2gMa...
Everyone that oppose him that I look into have conflicting interests, which makes djb's point even more concerning.
The person you linked to works for Google, which he seems to omit mentioning in the mail you linked to.
Filippo Valsorda doesn't work for Google. He left there several years ago. He runs an independent "buy contracts with me to support development of open source cryptography software" thing.
djb is always on the other side of everyone. If everyone else is using big-endian, djb will use little-endian just because he can.