@djb

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

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.

@darkuncle

@argv_minus_one

"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).

@rsalz

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.