NSA tries to weaken mlkem standardisation

SSuperSandro2000 about 6 hours ago 24 commentsRead Article on nsa.2026.action.cr.yp.to

RU version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

50% Positive

Analyzed from 1160 words in the discussion.

Discussion (24 Comments)Read Original on HackerNews

phasmantistes•33 minutes 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.

ryanisnan•12 minutes 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.

mswphd•5 minutes 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).

miloignis•30 minutes 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•4 minutes 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?

galadran•31 minutes 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)

advisedwang•about 2 hours 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?

mswphd•23 minutes 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.

mcpherrinm•26 minutes 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)

axus•40 minutes ago

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

iAMkenough•about 1 hour ago

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

mswphd•2 minutes 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).

advisedwang•about 1 hour 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)

Ajedi32•40 minutes 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?

mswphd•29 minutes 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.

kokonuts•31 minutes 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.

downrightmike•28 minutes 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.

sharpshadow•about 2 hours 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

mswphd•20 minutes 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.

phyzome•26 minutes 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.

ryanisnan•19 minutes 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.

realxrobau•about 2 hours 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.

OutOfHere•17 minutes 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.

jauntywundrkind•36 minutes 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.)