> Most cryptographers would still recommend the hybrid over pure ML-KEM. This RFC (for pure MLKEM) is marked "recommended to implement = N". It is purely for settings where the implementors independently want to use pure ML-KEM for some reason.

That's exactly how it was with Dual_EC_DRBG.

E.g. https://www.schneier.com/essays/archives/2007/11/did_nsa_put...

   I don’t understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It’s public, and rather obvious. It makes no sense from an engineering perspective: It’s too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.
  
  My recommendation, if you’re in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances.

So most cryptographers _recommended_ staying the hell away from Dual_EC_DRBG. But hey, harmless, no one serious about security would actually use it right?

Except as we know now, after the standardization NSA was able to persuade/bribe vendors to implement it.

RSA is still a viable cryptography vendor, after accepting money to backdoor their product for paying customers. The standardization gave them a fig leaf of plausible deniability. Honest mistake, could happen to anyone, right? If they had needed to implement a "non-standard" backdoor, or if it had been officially struck from the standard, it would have been a lot harder to row away from.

▲ mswphd 3 days ago | parent [-]

there has been no hint of a backdoor in ML-KEM. In fact, it (and every lattice-based scheme) has been made less efficient on purpose to rule out the only possible backdoor (the ephemeral "a" part in LWE-type samples could be fixed/standardized to something. There are plausibly some mild savings associated with this. Every "real" LWE-type scheme since the New Hope scheme, deployed in Chrome a decade ago, has chosen not to do this out of an abundance of caution).

For DUAL_EC_DRBG, the mechanism that could yield a backdoor was known pre-standardization. To get the backdoor RSA had to specifically use government chosen parameters.

These are not new concerns. If even a candidate backdoor had appeared in ML-KEM (similarly to how DUAL_EC_DRBG was), it would be a very different story. But nobody has ever even suggested something might be off!

So no, it's not exactly the same as DUAL_EC_DRBG. Different things are in fact different. Note that there are similarities to DUAL_EC_DRBG in contemporary cryptography. Russia has a block cipher Kuznyechik that has some very fishy structure in its S-box. We don't know how such structure is exploitable, but I would bet money that it is. Despite not being able to see an attack, we can see that things seem off in a concrete way. Nobody has *ever* suggested that for ML-KEM.

▲

timschmidt 3 days ago | parent [-]

> there has been no hint of a backdoor in ML-KEM

Wanting to standardize it's use without the secondary layer of protection provided by existing algorithms over the objections of a well known cryptographer counts as a hint to me.

In the same way that paying RSA to make Dual-EC DRBG the default RNG in it's security products when it was newer and more expensive than alternatives was a hint.

▲

mswphd 3 days ago | parent [-]

those are not remotely the same things though? You're also (formally) wrong about DUAL_EC_DRBG for two reasons

1. the payment to RSA (in 2004) was secret. So it could not have been a public indication of a problem, as it was not discovered until nearly a decade after it happened (in 2013, when it became public)

2. the problematic part of DUAL_EC_DRBG (the "hint of a backdoor") I was mentioning was known pre-2004.

blind paranoia is not a rational approach to cryptography. I say this as someone who prefers hybrid schemes! I just don't think it is sensible to attempt to "ban" the usage of pure ML-KEM by not standardizing it. It won't work! It'll just increase the risk of non-interoperable implementations.

	▲	timschmidt 3 days ago \| parent [-]
		1: We were all aware of the default change before we became aware of the payment. But the payment is old news today. And the default change was fishy before the payment was discovered. Discovery of the payment confirmed the earlier suspicion. You're arguing a detail like a lawyer while missing the message entirely. Perhaps intentionally. 2: And? You're missing a second part to this statement. Did you intend it to support some conclusion? > blind paranoia Characterizing criticism this way, instead of listening, internalizing, and adjusting your position is exactly why DJB's references to previous NSA interference stick. Y'all don't just have technical differences, you're going for character assassination. DJB has been consistent and explicit about the technical nature of his objections. I find his prose on the matter clear and well reasoned. Your arguments seem disjointed, unorganized, specious, and lacking, in comparison, and less credible for the way you respond. > I just don't think it is sensible to attempt to "ban" the usage of pure ML-KEM by not standardizing it. It won't work! It'll just increase the risk of non-interoperable implementations. I think it's entirely reasonable to dissuade people from building non-hybrid systems during a transition period, and refusing to standardize them is an entirely reasonable way to signal that people shouldn't build or trust such systems during such a time, even stronger than a recommended_to_implement = N. No one has attempted to "ban" anything, so that's another gross mischaracterization.