NSA tries to weaken mlkem standardisation?

realxrobau

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.

advisedwang

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?

sharpshadow

“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

Ajedi32

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?

jauntywundrkind

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

phasmantistes

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.

galadran

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)

miloignis

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

phyzome

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.

OutOfHere

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_furry

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

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