Why do they want non-hybrid KEMs and signatures, anyway? Seems like a bad idea to protect all of everything with nothing but unproven crypto.
@argv_minus_one I have an introductory chart https://blog.cr.yp.to/20260221-structure.html showing the arguments and counterarguments.
Most common argument from proponents: NSA is asking for non-hybrids, ergo support non-hybrids. This argument works for (1) companies chasing NSA money, (2) companies that take any excuse for extra options as a barrier to entry for competitors, and (3) people who think that "NSA Cybersecurity" isn't a conduit for https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf but rather an independent pro-security agency.
@rsalz DJB sees a conspiracy where one may not exist ... but has a history of seeing one where it did very much in fact exist.
I think cryptographers erring on the side of extreme caution is a net benefit (and his points about unjustified and unexplained foot-dragging and resistance on Classic McEliece adoption have been well documented)
@rsalz Dual_EC specifically is an example of NSA hijacking the standards process for nefarious purposes. Maybe that was the only one ever, and an anomaly! (But see also DES back in the 90s ...)
But it would be wise to proceed with skepticism on all future contributions from a source that proved to be a bad actor. When an actor has a documented history of bad behavior, it's both natural and wise that all their future behavior face extra scrutiny and skepticism.
More recently, the arguments against hybrids seem ... weak. See e.g., https://blog.cr.yp.to/20240102-hybrid.html and https://blog.cr.yp.to/20251004-weakened.html (which has six sequels)
DJB has always been touchy and can really get into the weeds on some conspiracy theory. really smart guy but i tend to take his rants with a heavy grain of salt.
it's been this way since early usenet days.
@paulehoffman @rsalz Paul, great to see you showing up here!
We're currently discussing Rich's delusion that NSA doesn't attack IETF. On that topic, can you please state for the record how much NSA paid you for your promotion of TLS randomness extensions in IETF (https://web.archive.org/web/20260331174508/https://sockpuppet.org/blog/2015/08/04/is-extended-random-malicious/)? Or are you denying that this happened?
Also, do you dispute https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/checkoway saying that Dual EC becomes thousands of times cheaper to attack whenever those randomness extensions are deployed?
Everything I wrote is simple and consistent and, if you look at the context of when they were made, easy to follow. For those just jumping in.
1. As a long-time person involved with the IETF I have not seen any hidden/coercive NSA involvement.
2. I accept that the EFF budget piece is accurate.
3. The term "crazy conspiracy thinking" referred to your blog posts on this topic.
I do not argue with NSA/NIST and pointed out why they could do that in the past. I find it amusing that ISO refused to standardize NSA's Simon and Speck. Perhaps they're not as good at influence as they used to be.
@rsalz @djb @darkuncle dumb questions from the sidelines:
1: doesn’t it make sense to treat NSA preferences with a bit of suspicion given their history and mission?
2: if there is strong opposition to non-hybrid, besides djb’s, doesn’t that bear listening to? What’s the benefit here in overriding the concerns?
Very much not a crypto expert, I’m assuming there’s a lot I don’t know or understand here. Appreciate any answers.
@jzb To answer your questions:
1. If it were only the NSA, sure, be suspicious. But it's not (IEEE, Ericsson I believe, others) and I do not believe they were all cofrupted.
2. Sure, the IETF is having that discussion. See what you think of https://github.com/tlswg/draft-ietf-tls-mlkem/pull/14/changes for example.
@rsalz @darkuncle Okay, so you're not disputing the authenticity of https://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220/ regarding NSA paying the RSA company to roll out Dual EC.
Now let's look at an IETF part of the Dual EC story. Are you disputing the accuracy of, e.g., https://web.archive.org/web/20251229182801/https://blog.cryptographyengineering.com/2017/12/19/the-strange-story-of-extended-random/ and https://web.archive.org/web/20260331174508/https://sockpuppet.org/blog/2015/08/04/is-extended-random-malicious/ saying NSA paid your colleagues Paul Hoffman and Eric Rescorla to coauthor with NSA a series of IETF drafts on "Extended Random" etc.? The payment is again overt leverage towards the consultants.
Do you have another explanation for the inexplicable push for the IETF to specify non-hybrid ML-KEM?
I looked at the list of arguments compiled by @djb at https://blog.cr.yp.to/20260221-structure.html and I don't see any particularly compelling argument in favor of such a move. Nor can I think of one myself. Certainly nothing to justify going full speed ahead like this.
"Do you have another explanation for the inexplicable push for the IETF to specify non-hybrid ML-KEM?" I don't know why you see it as inexplicable. Some people want it for various reasons, and not because they are NSA fronts.
I can see various places where the size differential (time, bits on the wire, CPU cost) are not negligible to the environment, or where the cost of eventually transitioning off hybrid are not practical (subs, satellites, zillions of telephone poles, etc).
The cost argument sounds like splitting hairs, to be honest.
RSA is far more costly than X25519—that's why we're using X25519 in the first place—and people were routinely running RSA on basic home PCs in the 1990s.
The phone in my pocket is a world-class supercomputer by 1990s standards. It can *easily* run ML-KEM+X25519. Let alone what a big beefy server can do.
As for satellites and telephone poles, I wasn't under the impression that those do encryption at all. But even if they do, since when was the nature of that encryption defined by the IETF TLS committee? They can use ML-KEM alone if they really want to, can they not? I don't see why they would need the IETF's permission.