NSA tries to weaken mlkem standardisation? • Hacker News Board

Re: NSA tries to weaken mlkem standardisation?

#61

Post by tveita » Thu, Jul 02, 2026, 9:37 PM UTC

mswphd wrote: post #47

adrian_b wrote: post #43

Earlier quoted context omitted.

DJB did not criticize anything about ML-KEM. The TFA has nothing to do with ML-KEM, but only about how to transition from the current algorithms to post-quantum algorithms. For now, it is completely unknown how secure ML-KEM really is, because it is too new. For many complex cryptographic algorithms a decade or even a few decades have been required until someone discovered how to break them. The predecessor of ML-KEM…

DJB wrote this article after asking people to brigadge the current TLS-WG's attempt to get rough consensus on a current draft RFC for pure ML-KEM. This is clearly part of this tirade for that. ML-KEM is not new. It's hardness is based on MLWE. LWE (a slightly harder problem) has been around for 20 years. Attacks against it stablized to be 2^{cn} time maybe 15 years ago. The value of c has been stable for nearly 10 ye…

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

Re: NSA tries to weaken mlkem standardisation?

#62

Post by mswphd » Thu, Jul 02, 2026, 10:42 PM UTC

tveita wrote: post #61

mswphd wrote: post #47

Earlier quoted context omitted.

DJB wrote this article after asking people to brigadge the current TLS-WG's attempt to get rough consensus on a current draft RFC for pure ML-KEM. This is clearly part of this tirade for that. ML-KEM is not new. It's hardness is based on MLWE. LWE (a slightly harder problem) has been around for 20 years. Attacks against it stablized to be 2^{cn} time maybe 15 years ago. The value of c has been stable for nearly 10 ye…

> 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 includi…

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.

Re: NSA tries to weaken mlkem standardisation?

#63

Post by timschmidt » Thu, Jul 02, 2026, 11:07 PM UTC

sweis wrote: post #56

The NSA is not trying to weaken ML-KEM. The IETF TLS working group is simply trying to publish a pure ML-KEM specification. It does not impact the hybrid ietf-tls-ecdhe-mlkem specification at all. The context of this is that D.J Bernstein has been moderated 7 times from the mailing list for repeated unprofessional and disruptive behavior: https://mailarchive.ietf.org/arch/msg/tls/lON9lKptnJ6ccq2-I1...

I've read the emails on that list in which DJB is accused of unprofessional behavior. Dave's concerns are not only relevant and well considered, he's taken an extraordinary amount of time to outline them and the discussion around them (both pros and cons) which you can see here: https://blog.cr.yp.to/20260221-structure.html

He's also responded directly to criticisms: https://nsa.2026.action.cr.yp.to/guide.html

By comparison the so-called "unprofessional behavior" cited is the sort of subjective abject procedural bureaucratic bullpucky often used to shut down inconveniently correct criticism.

Re: NSA tries to weaken mlkem standardisation?

#64

Post by timschmidt » Thu, Jul 02, 2026, 11:15 PM UTC

mswphd wrote: post #62

tveita wrote: post #61

Earlier quoted context omitted.

> 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 includi…

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 no…

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

Re: NSA tries to weaken mlkem standardisation?

#65

Post by mswphd » Thu, Jul 02, 2026, 11:36 PM UTC

timschmidt wrote: post #64

mswphd wrote: post #62

Earlier quoted context omitted.

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 no…

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

Re: NSA tries to weaken mlkem standardisation?

#66

Post by mswphd » Thu, Jul 02, 2026, 11:37 PM UTC

mswphd wrote: post #39

adrian_b wrote: post #34

Earlier quoted context omitted.

DJB did not claim that there exists any weakness in ML-KEM or that NSA had anything to do with ML-KEM. He just pointed that the predecessor of ML-KEM (SIKE) has already been broken. Because ML-KEM is also very new, there is a non-negligible probability that it will also be broken in a few years. It is very simple to guard against this, by using both ML-KEM and the currently used elliptic-curve Diffie-Hellman algorith…

SIKE is a completely different scheme based on completely different hardness assumptions from a completely different area of math. It is just as sensible to call elliptic curve cryptography to be a predecessor to ML-KEM. Nobody would do that. The hardness assumption from ML-KEM is from 2005 (in teh algebraically unstructured case. The biggest speedup known due to algebraic structure is ~3 bits, e.g. 8x speed improvem…

actually another more basic point: SIKE is much more closely related to elliptic-curve cryptography than lattices. People would not use SIKE to argue that ECC is unreliable though.

Re: NSA tries to weaken mlkem standardisation?

#67

Post by timschmidt » Thu, Jul 02, 2026, 11:46 PM UTC

mswphd wrote: post #65

timschmidt wrote: post #64

Earlier quoted context omitted.

> 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. bli…

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.

Re: NSA tries to weaken mlkem standardisation?

#68

Post by reinitctxoffset » Fri, Jul 03, 2026, 12:47 AM UTC

phasmantistes wrote: post #10

This is not an unbiased article about the situation unfolding on the TLS Working Group mailing list; this is a call to action to join one specific side of the argument that has been ongoing for over a year now. It's an appeal to authority, an attempt to garner support for one side of the debate simply because DJB says so, as part of his effort to flood the zone with messages in opposition. This tactic is explicitly c…

Your comment being top of thread, and you seemingly being conversant in the details of the issue, would be exceptionally well-placed to make an argument on the merits of the subject matter. Character portraits are sometimes useful, but technical detail is often conclusive.

What's the steelman of djb's position and why does it fail scrutiny? To the uninitiated, it sounds like his preference for the hybrid classical/BQP scene is prudent given the marginal computational burden.

But I'm guessing, it would be better if an expert weighed in with details.

Re: NSA tries to weaken mlkem standardisation?

#69

Post by adgjlsfhk1 » Fri, Jul 03, 2026, 2:32 AM UTC

mswphd wrote: post #57

notpushkin wrote: post #53

Earlier quoted context omitted.

> and what his current post is doing. Could you elaborate?

the IETF TLS working group has limited time/energy. He has been (very successfully) taking up a good deal of this with very annoying procedural techniques (and his most recent move, spreading falsehoods regarding an RFC then asking people to brigade a vote on the RFC). Explicitly, this slows down standards, which delays the PQ transition. Again explicitly, this is not the main RFC for PQ TLS, which details a hybrid c…

if no one should implement it, why standardize it?

Re: NSA tries to weaken mlkem standardisation?

#70

Post by halJordan » Fri, Jul 03, 2026, 3:19 AM UTC

dooglius wrote: post #32

phasmantistes wrote: post #10

This is not an unbiased article about the situation unfolding on the TLS Working Group mailing list; this is a call to action to join one specific side of the argument that has been ongoing for over a year now. It's an appeal to authority, an attempt to garner support for one side of the debate simply because DJB says so, as part of his effort to flood the zone with messages in opposition. This tactic is explicitly c…

Do you dispute his claims? And what about his argument that the NSA is doing the same thing?

The person making the claim bears the burden of proving it. Merely failing to agree doesn't shift the burden of pros to the questioner.