Comment by tveita
4 days ago
> 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.
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.
> 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.
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.
1 reply →