NSA tries to weaken mlkem standardisation?

https://nsa.2026.action.cr.yp.to

by SuperSandro2000 • 20 days ago

158 98 20 days ago

nsa.2026.action.cr.yp.to

realxrobau• 20 days ago

I'm not sure this is as clear-cut as the article implies, but there is certainly a whiff of people behaving badly.

The latest post to the list, as of this post, is supporting the anti-ecdhe side, with the reasoning being that there is no code written for ecdhe, which is obviously stretching the truth beyond reasonable doubt.

advisedwang2• 20 days ago

Clicking around I don't see any "nsa.gov" email addresses for the positions this site says are from the NSA. Have I just missed some things that are clearly from the NSA? If not, how would one know that these various academic and personal email addresses have some kind of NSA tie?

iAMkenough3• 20 days ago

I don’t think the spy agency would use nsa.gov address to manipulate the technology trajectory.

advisedwang2• 20 days ago

Of course, but is there any actual evidence that these accounts are NSA related? Or is it an assumption because they are supporting the proposal (which would be very circular logic)

mswphd20• 20 days ago

this is literally what happened with previous NSA meddling though? Both DUAL_EC_DRBG and DES were done "officially" by the NSA.

Additionally, the main authors behind ML-KEM are all european. The design of ML-KEM is "very boring", in the sense that it's essentially the scheme that most (lattice) cryptographers would have suggested. There were 2 other NIST PQC schemes that went very far (New Hope and Saber) that were essentially the same scheme (there were minor technical differences, but it's really not that big).

axus• 20 days ago

The inexplicable behavior is indistinguishable from behavior that could be explained by a conspiracy.

mcpherrinm• 20 days ago

The underlying context is the US government only wants to buy systems which support pure post-quantum cryptography for use on top-secret networks, as part of the requirements of (via its Commercial National Security Algorithm Suite 2.0 standard).

So all the companies who want to sell anything using TLS to the government want to standardize this, so they can be CNSA2 compliant.

Everyone already supports this in major libraries; but some folks feel they need an IETF RFC specifying it.

(I don't have to comply with CNSA2 so I might have details slightly off)

adrian_b8• 20 days ago

Do you have a citation for "only wants to buy systems which support pure post-quantum cryptography" ?

Because this would seem pretty stupid, i.e. to disqualify something that supports both post-quantum algorithms and previous algorithms.

I have looked just now at CNSA2 and it only says that post-quantum algorithms should be used exclusively for key exchange and digital signatures after 2033.

So during this 7-year transition period it should be normal to use both post-quantum and classic algorithms, even based on what CNSA2 says.

Moreover, even "exclusively" can be interpreted in various ways, i.e. it can also be interpreted that there should be no key exchanges/digital signatures that do not use post-quantum algorithms, but without forbidding them to also use other algorithms, because such a prohibition does not make sense.

mswphd20• 20 days ago

DJB has for years claimed anyone who disagrees with him is affiliated with the NSA. See for example this post as part of the NIST-PQC competition

https://blog.cr.yp.to/20220805-nsa.html

Some people seem to be unable to rationally consider the possibility that NSA is sabotaging post-quantum cryptography. I've heard people saying, for example, that submissions to the NIST Post-Quantum Cryptography Standardization Project (NISTPQC) were publicly designed and evaluated by top experts, and that NSA can't have bribed the submission teams. Let's look at the facts.

Note that the authors of ML-KEM are overwhelming European.

adrian_b8• 20 days ago

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

ML-KEM is much more expensive than the current algorithm, so using both does not increase much the cost.

I do not see any flaw in his arguments, while anyone who says that ML-KEM should be used alone is making a bet for which there exists no justification, i.e. the risk is extremely high and the reward is extremely low.

In cryptography bets must be done only when the odds are extremely favorable, which is not the case for the proposal criticized by DJB.

throwaway29303• 20 days ago

https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koX...

sharpshadow• 20 days ago

“Surveillance agency NSA and its partner GCHQ are trying to have standards-development organizations endorse weakening ECC+PQ down to just PQ.”[0]

That’s pretty weak just stripping down the hybrid approach.

0. https://blog.cr.yp.to/20251004-weakened.html

mswphd20• 20 days ago

this is not an accurate picture of what is happening. Hybrid KEMs are already widely supported within the IETF, and are supported in an RFC with "recommended to implement = yes".

This is about a separate RFC with "recommended to implement = no".

If the IETF was trying to have these positions swapped, it would be consistent with DJBs post. It is not though. His post does not seem to be grounded in reality.

adrian_b8• 20 days ago

Another poster has already given a link to the technical arguments of DJB,

https://blog.cr.yp.to/20260221-structure.html

where he combats very well your argument.

For me, his argumentation seems far more grounded in reality than what you have said.

Ajedi32• 20 days ago

What exactly is the problem with the IETF publishing a standard that's theoretically weaker than another standard? They're not forcing anyone to use it, right?

kokonuts• 20 days ago

Why do they forcibly retire weak algorithms? I think it does matter if half of SaaS services you use could be forcibly using them for your data and in some cases you might be a serious target mixed in among less serious targets.

mswphd20• 20 days ago

The IETF has published the russian TLS 1.2 standard (RFC 9189). This includes Kuznyechik, which is has a certain design choice consistent with it being backdoored.

https://en.wikipedia.org/wiki/Kuznyechik#Cryptanalysis

(the work by Perrin that is mentioned is what I'm referring to).

The (pure) mlkem standard is also marked "recommended to implement = No". people are interested in implementing it. The IETF can't change that. They can try to ensure such implementations are interoperable though.

downrightmike• 20 days ago

Its called downgrade attacks, they are very bad, and they are caused by weak standards still being used. 3DES shouldn't be used anymore, but it is in the list of an acceptable cipher, so there goes the security out the window.

jauntywundrkind• 20 days ago

Forming a (imo particularly rancid conspiracy brained) social media rage campaign to get a bunch of new people to inject themselves into cryptography space is... a move.

Maybe giving this thread more visibility here than it wants but ...

https://bsky.app/profile/filippo.abyssdomain.expert/post/3mp...

(Personally it seems so so unacceptable to me to accuse so many good hardworking people of such bitter conspiracy.)

phasmantistes3• 20 days ago

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 called out in RFC 7282, and named as a "degenerate", "pathological", and "dysfunctional" state for the working group to be in. Shame on DJB for attempting to drive the working group into terminal dysfunction.

ryanisnan3• 20 days ago

Is that what he's trying to do? I am no cryptographer, but when I read his post, his arguments about ECC+PQ make intuitive sense.

I'm out of fresh tin-foil hats as well, but it would not surprise me in the least if any government was actively engaged in weakening security and privacy protections.

Literally look at what they are all doing in almost every sphere. The current political zeitgeist is all about automated surveillance everywhere. The motivations are worn on their sleeves.

mswphd20• 20 days ago

the NSA has a history of weakening cryptography in a very specific way, known as "NOBUS"

https://en.wikipedia.org/wiki/NOBUS

DES key-size weakening is consistent with NOBUS (given the computational dominance of the US at the time). DUAL_EC_DRBG is consistent with NOBUS. DES S-box strengthening (vs linear/differential cryptanalysis, I forget which) is also consistent with NOBUS.

There have been *no* proposed mechanism that would allow NSA to have a NOBUS-style attack against ML-KEM.

Separately, this RFC (pure ML-KEM) is marked "recommended to implement = N". It is highly likely all browsers etc will use hybrids. In certain areas (say hardware) it is not free to use a hybrid. You all of a sudden need both a SHA2 and SHA3 implementation, for example. Some organizations that view the threat of quantum computers as more credible may also not want to drag around the ECC component (which is known to be broken, once a CRQC appears. Google and the US government have publicly stated concerns this may occur within the next ~5 years after recent QC breakthroughs).

dooglius• 20 days ago

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

some_furry7• 20 days ago

None of the NSA (or even ex-NSA) people I know have participated in this discussion at all. I imagine they're preoccupied with the current administratiom's stupid decisioms disrupting their work.

halJordan• 20 days ago

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.

ButlerianJihad2• 20 days ago

djb has always been as outlandishly activist and combative as he is intelligent and competent.

Anyone who attributes public motives or activity or blame to "the NSA" automatically gets dropped into the "conspiracy theorist" bin, as far as I'm concerned.

lcnPylGDnU4H9OF5• 19 days ago

Funny thing about conspiracy "theory" is that a lot of the time the theory turns out to be true. In my view, the impulse to dismiss any suggestion of clandestine group activity (except if it's China's government, or Russia's, or Iran's, or...) as a "theory" is most likely the result of a psychological operation.

The Dale Gribbles of the world are not a particularly common character to meet in real life but that's the image evoked by "conspiracy theorist" no matter who the pejorative is aimed at, no matter the arguments they make nor the evidence they present. "Conspiracy theorist" is a thought-stopping, ad hominem cliché, with no place in serious discussion, yet it is widely used in exactly that; the possibility of conspiracy itself is what is eschewed in such discussions.

danudey2• 18 days ago

DJB is the same person who created qmail, the mail transfer agent which was ridiculously secure because of a series of over-the-top design decisions; for example, each file in the mail queue was named after the inode it was stored in, meaning you couldn't copy your mail queue to another server if your original one was having issues (unless you cloned the whole filesystem). Also, all configuration was done at compile time, including what UIDs and GIDs to run as, meaning it was very difficult to build it once and re-use it on multiple systems unless you were very careful to make them identical, which is fine because you weren't allowed to distribute compiled binaries.

He maintained that it was the most secure option available, which was technically true until the technology around mail transfer started improving with things like SPF records. qmail didn't support them and wouldn't support them, patches weren't accepted, and the only way to use things like SPF (to reduce spam) was through unofficial community patches that could never be upstreamed.

qmail was far better than sendmail at the tiume, and honestly it probably still is to a large degree, but, like forcing users to change their password every week, it was a case of security being so tight that users had to break it in order to make the system functional.

All this to say that, while DJB is undoubtedly insightful and intelligent, I'm wary of any of his claims of 'this isn't secure enough' because of his past history of making things so secure as to be inflexibly unmanagable.

rurban• 20 days ago

Rather shame on you for supporting the NSA here for dumbing down the next standard.

But call me surprised that Filippo Valsorda and Rich Salz supported the NSA here.

reinitctxoffset• 20 days ago

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.

phasmantistes3• 15 days ago

Sure, you make a good point. I certainly didn't expect to end up at the top of this thread, and stopped paying attention immediately after posting it (for the same reason I don't read every message on the TLS WG list).

The kindest reading of DJB's position is simple: pure ML-KEM is strong against fewer potential future scenarios than hybrid algorithms are, so people should use hybrid algorithms instead.

And in fact, I agree with this statement! The marginal cost of hybrid algorithms is very small, and the extra safety provided by being hybrid is (in my opinion) slightly larger than that cost. My cost/benefit analysis says that hybrid is the way to go for most people.

However, there are two major flaws with DJB's actual argument:

1. He's making the jump from "most people shouldn't use pure ML-KEM by default" to "the ability to use pure ML-KEM shouldn't be standardized at all". He's making overblown assertions about the power and meaning of an Informational IETF document, and using those to attempt to prevent simple interoperability standardization. Just because I think hybrids are the safer default in general doesn't mean that pure ML-KEM should be verboten; people deserve options, and the role of this document is to provide interoperability instructions for that option.

2. He's resorting to character attacks to imply that ML-KEM simply isn't safe at all. He frequently points to support from NSA and GHCQ as evidence that ML-KEM has been suborned in the same way as DUAL_EC_DRBG, despite widespread agreement in the cryptography community that the ML-KEM parameter space simply doesn't allow such attacks. He frequently points to support from cryptographers at Google and Cisco in the same breath, implying that they too are in the pay of the NSA. He's refusing to acknowledge that his implications that ML-KEM is unsafe imply that he should also oppose standardization of ML-KEM hybrids.

So while there's a kernel of truth to DJB's argument, I strongly believe that he has both taken the conclusion too far, and taken his argumentation tactics too far. It has lowered my respect for him as a person even further than it already was by his defense of Jacob Applebaum.

throwaway815233• 20 days ago

garner support for one side of the debate simply because DJB says so

DJB saying so sounds good enough for me, considering the alternative. Dual_EC_DRBG anyone?

lcnPylGDnU4H9OF5• 19 days ago

This (also not unbiased) comment doesn't provide any substantive arguments other than a character attack on DJB. You'd also be hard-pressed to find an appeal to authority in this article. Lastly, I'm pretty sure the comment I'm replying to is at least partially LLM-generated.

Ironically, it's the incredibly weak pro-standardization arguments that appear to be the most convincing evidence that the proposed standard is actually an instance of NSA meddling.

phasmantistes3• 15 days ago

Zero percent LLM-generated, but this is the first time I've had to defend myself against that claim, so thanks for that!

galadran3• 20 days ago

This is garbage from start to finish.

There are already codepoints assigned for MLKEM 512/768/1024 (0x0200, 0x0201, 0x0202) and nearly every major library supports it already:

  - OpenSSL (ML-KEM-512/768/1024)
  - BoringSSL (ML-KEM-1024)
  - NSS (ML-KEM-1024)
  - AWS-LC (ML-KEM-512/768/1024)
  - Rustls (ML-KEM-768/1024)
  - s2n-tls (ML-KEM-1024)
  - Bouncy Castle (ML-KEM-512/768/1024)
  - Botan (ML-KEM-512/768/1024)
  - GnuTLS (ML-KEM-768/1024)
  - WolfSSL (ML-KEM-512/768/1024)

adrian_b8• 20 days ago

What you say has nothing to do with TFA, which is not about ML-KEM but about the session key establishment protocol used in TLS, in which ML-KEM is just a component.

DJB supports the use of ML-KEM in TLS, but he correctly says that using only ML-KEM is unwise, because absolutely nobody can guarantee that no method to break ML-KEM will be discovered in the next years, as it already happened with the algorithm that was preferred before ML-KEM, until it was broken a few years ago.

galadran3• 20 days ago

I'm afraid you've misunderstood. These codepoints are for the pure MLKEM key establishment that DJB is railing against.

All of these libraries also support the hybrid forms, which have different codepoints and are used by default. Nothing in the IETF process has any bearing on this.

throw0101d3• 19 days ago

DJB supports the use of ML-KEM in TLS, but he correctly says that using only ML-KEM is unwise

Then don't use it if you don't want to? Use hybrid? ML-KEM (CRYSTALS-Kyber) is a NIST standard, FIPS 203:

* https://csrc.nist.gov/pubs/fips/203/final

* https://en.wikipedia.org/wiki/ML-KEM

There's also HQC, FIPS 207:

* https://csrc.nist.gov/presentations/2025/fips-207-hqc-kem

Unless you're doing government work, there's no reason why you'd be force to use Officially Approved™ algorithms:

* https://en.wikipedia.org/wiki/Commercial_National_Security_A...

If the (US) government wants to use (allegedly) compromised algorithms with-in itself that's up to them. The rest of us can use whatever we want.

miloignis• 20 days ago

This has been discussed before, and I believe the general consensus is that djb's objections don't make sense. The Key Material blog addresses this in a very good larger ML-KEM mythbusting post: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/#:~:te...

ebiederm• 20 days ago

What?

That post says very clearly at the beginning that hybrids are the preferred approach right now.

No one except the NSA actually wants a non-hybrid.

Which raises the question what is the NSA up to.

Especially since the NSA has a mission statement, a track record, and a billion dollar budget to subvert other peoples cryptography. When they aren't beyond transparent why should anyone give them the benefit of the doubt?

athrowaway3z2• 20 days ago

The two opening arguments are rather weak.

- European group could not be infiltrated by a state-actor with 100billion/y budget and a history of doing so?

- NOBUS today would not be secret in the algorithm but a quantum algorithm/device. Just a month ago HN was getting flooded with "PQC is probably required by 2030".

mswphd20• 20 days ago

quantum algorithm would make pure ML-KEM bad to support for the NSA. If the NSA has a quantum computer, they would want to delay proliferation of post-quantum schemes as long as possible, so they could get as much milage out of it as possible before people switch over.

Ironically, this (delaying PQC rollout/standardization) is arguably what DJB has been doing the ~decade, and what his current post is doing.

digitalPhonix2• 20 days ago

This post makes a bad argument.

Saying that there's no "Nobody but us backdoor" to prove there's *no* backdoor of *any kind* is clearly naive at best, dishonest at worst.

As an example - if there's a weakness that affects 50% of keys (replace with whatever hypothetical number), NSA can make sure it doesn't use those affected keys but still retain the ability to decrypt 50% of everyone else's communications. And using the entropy analysis from this post, that would require 1 bit hidden in the parameters which is clearly within the entropy budget.

some_furry7• 19 days ago

A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak" would not explain "let's move the entire fucking federal governnent to this algorithm including implementations sourced by the private sector that don't do our secret sauxe".

Dual_EC_DRBG is the shape of backdoor that would need to apply here: even if you knew the structure of it, you would need an additional private number to attack it. Recall the Juniper vulnerability where another threat actor simply replaced the EC public key used by Juniper's Dual_EC implementation.

NOBUS without some mathematical assurance that, even should an adversary discover the same break through, they cannot decrypt the same traffic would be too risky when you consider the NSA's self interest and dual mission.

phyzome• 20 days ago

For those who don't know, djb is both highly regarded as a cryptographer and known to be something of a crank. (The former part is the only reason this is getting any attention.) Frankly, I don't know what's gotten into him.

The linked piece is not representative of the broader cryptography community. ML-KEM is fine.

ryanisnan3• 20 days ago

What would you say about his critique that simply ditching double-encryption is a bad idea? That seems like a fair point embodying a belt and suspenders approach.

mswphd20• 20 days ago

this RFC is marked "recommended to implement = N". It is not suggesting everyone should use pure ML-KEM. It is suggesting it should be an option, if hybrid encryption is not suitable for certain usecases. Think hardware, where hybrid encryption would require devoting chip area to both SHA2 and SHA3 for no real benefit.

adrian_b8• 20 days ago

He did not claim that ML-KEM is not fine.

The use of dual algorithms is without doubt the prudent decision for a transition period.

ML-KEM is still too new for anyone to be able to claim that no way to break it will be discovered in the next few years.

This is supported by the fact that one of the algorithms previously proposed for standardization has already been broken, which was a surprise.

Because ML-KEM is significantly more expensive than the current algorithm, using both does not increase much the cost.

The arguments of DJB are perfectly valid, which is why at the previous meeting most people have voted like him.

I know very well everything that DJB has published during the last 30 years, many of which have been important advances in cryptography. Some of his work has been very influential in the development of "post-quantum" cryptography and he was one of the main promoters of the idea that such cryptographic algorithms must be standardized ASAP.

Moreover, I have also run continuously on my servers, 24/7, for about a quarter of century, various programs written by DJB, which unlike the majority of the programs that I have ever seen, have done very well whatever they were intended to do, without ever needing any updates for security problems or other bugs. Very few programmers, even among the best, can present such a resume.

I do not believe that "crank" is the right word to describe DJB. It is true that he has distinguished himself by an unwillingness to accept compromises, even when he was for various reasons in opposition with the US government, but I do not think that this is crazy. On the contrary, I believe that the world is how it is right now precisely because most people go with the flow and they are eventually willing to accept almost anything when opposing that appears to be too difficult. Things would have been much better if there had been more such "cranks".

OutOfHere• 20 days ago

The NSA and NIST can never be trusted. They have sabotaged things before, and it is par for the course for them. The formation of standards and defaults should never be left to them.

some_furry7• 20 days ago

If you're reading this thread wondering why the IETF wants an informational (non-standards track), Recommended=N RFC that specifies how to use ML-KEM without ECDH, there's some important background reading.

https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...

https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

Additionally, I wrote my own blog posts recently that toucbed on the subject.

Signatures: https://soatok.blog/2026/04/13/hybrid-constructions-the-post...

Threat modeling but also KEMs: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...

The main industry that's hamstrung by an RFC being blocked are telecom companies (e.g., Verizon) who by policy need an RFC and also have other regulations.

I prefer hybrid KEMs, but support publication because getting those companies onto PQ is harm reduction against Harvest Now, Decrypt Later (HNDL) attacks, and ECDH doesn't help if our confidence in the security of ML-KEM turned out to be wrong.

sweis• 20 days ago

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

timschmidt5• 20 days ago

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.

ButlerianJihad2• 19 days ago

Like, who is "Dave"?

commandersaki• 16 days ago

Reminds me of the time when Joseph Touch (I think his name was) proposed the NULL cipher in TLS. "It's just a proposal."

throw0101d3• 19 days ago

Perhaps worth noting Section 6, "Security Considerations", of the most recent draft has:

Recommended: N

* https://datatracker.ietf.org/doc/html/draft-ietf-tls-mlkem-0...

Pure, non-hybrid implementations of ML-KEM (FIPS 203, previously "Kyber") are already in the major crypto libraries. So given code is being written, there can either be an IETF document available to ensure interoperability or not: the IETF would prefer interop it seems.

The list of IETF-recommended TLS algorithms can be found under the (sortable) "Recommended" column of officially registered TLS parameters:

* https://www.iana.org/assignments/tls-parameters/tls-paramete...

The list is currently: X25519MLKEM768, x448, x25519, secp384r1, secp256r1. The document being discussed/debated would not change it.

NSA tries to weaken mlkem standardisation?

Related Stories