NSA tries to weaken mlkem standardisation?

Join the discussion

• Hacker News
• “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

  by sharpshadow
• 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.

  by mswphd
• 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.

  by realxrobau
• 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.

  by phyzome
• 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.
  by ryanisnan
• 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".

  by adrian_b
• 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.)

  by jauntywundrkind
• 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.
  by OutOfHere
• 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?
  by Ajedi32
• 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.
  by downrightmike
• 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.
  by kokonuts
• 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.

  by mswphd
• 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.

  by throw0101d
• 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?
  by advisedwang
• The inexplicable behavior is indistinguishable from behavior that could be explained by a conspiracy.
  by axus
• I don’t think the spy agency would use nsa.gov address to manipulate the technology trajectory.
  by iAMkenough
• https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koX...
  by throwaway29303
• 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)

  by mcpherrinm
• 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.

  by mswphd
• 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.

  by some_furry
• 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)

  by galadran
• 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.

  by adrian_b
• 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...

  by sweis
• Reminds me of the time when Joseph Touch (I think his name was) proposed the NULL cipher in TLS. "It's just a proposal."
  by commandersaki
• 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.

  by timschmidt
• 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...
  by miloignis
• 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.

  by digitalPhonix
• 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?

  by ebiederm
• 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".

  by athrowaway3z
• 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.

  by phasmantistes