6 ms·

NSA tries to weaken mlkem standardisation?

158 points by SuperSandro2000 3mo ago

realxrobau 3mo 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.
advisedwang 3mo 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?
- throwaway29303 3mo ago
  https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koXOLooFpU54/ https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koX...
- iAMkenough 3mo ago
  I don’t think the spy agency would use nsa.gov address to manipulate the technology trajectory.
  - advisedwang 3mo 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)
    - timschmidt 3mo ago
      There's a history and a 'pattern or practice' of behavior between NSA (sometimes using other TLAs or plausibly deniable intermediaries) and standards bodies and regulatory agencies. Demonstrating a 'pattern or practice' is the legal standard one has to meet to bust qualified immunity and shift the burden of doubt on to authorities, so I'd say it goes a fair amount past 'reasonable suspicion', which in a court is itself enough to issue search warrants.
  - mswphd 3mo 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).
    - iAMkenough 3mo ago
      2006's NSA is not 2026's NSA
      - mswphd 3mo ago
        it is easy to point to ghosts in the corner. Random fearmongering is not a technical argument though. There have been no technical arguments to justify the random fearmongering. Pointing to prior behavior in a way that is inconsistent with the current situation is especially annoying fearmongering.
        iAMkenough 3mo ago
        The “technical arguments” are documented here: https://blog.cr.yp.to/20260221-structure.html https://blog.cr.yp.to/20260221-structure.html
        adrian_b 3mo ago
        And those technical arguments are quite thorough, covering both the pro and the contra arguments.
        mswphd 3mo ago
        That document is nonsense? The current RFC is not to say > use pure ML-KEM > hybrid ML-KEM. the current document is instead to say > If you are in a setting where you REALLY want to use pure ML-KEM (though we explicitly recommend you do not do it), this is the standard you would implement against. It is also technically inaccurate. The whole argument hinges on it being negligible cost in all environments to do hybrids. This is explicitly false. See this message on the TLS-WG on explicitly this point https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9... A large list of pros/cons detailing a question that isn't being debated that is technically inaccurate is what I would expect from an LLM, not from a competent cryptographer. I am unsurprised to see it from DJB given his behavior in the last decade regarding PQC.
- axus 3mo ago
  The inexplicable behavior is indistinguishable from behavior that could be explained by a conspiracy.
- mcpherrinm 3mo 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_b 3mo 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.
- mswphd 3mo 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 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_b 3mo 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.
    - some_furry 3mo ago
      I recommend reading this perspective https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce... Also, https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ ML-KEM is not "very new" compared to the age of other algorithms historically deployed.
    - mswphd 3mo ago
      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 improvement). It has taken exponential time to attack since then. Instantiating a standard ~20 years after introduction is slower than what we did with RSA, or with elliptic curve cryptography. Therea re settings where hybrids are not free, for example hardware. The standard hybrid suggestion (XWING) would require hardawre to implement both SHA2 and SHA3. See this recent TLS WG post detailing this https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9...
sharpshadow 3mo 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 https://blog.cr.yp.to/20251004-weakened.html
- mswphd 3mo 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_b 3mo ago
    Another poster has already given a link to the technical arguments of DJB, https://blog.cr.yp.to/20260221-structure.html 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.
    - mswphd 3mo ago
      Very explicitly, this is not the main RFC for incorporating PQ crypto into TLS 1.3. This is an RFC with recommendation to implement = N about how to do pure ML-KEM if you must for some reason, in a standards-compliant way. That blog post is written in a way that implies otherwise, namely that pure ML-KEM is being favored over hybrids for TLS 1.3. This is explicitly false. Moreover many parts are technically false. In particular, the claim that hybrids are negligible cost in all circumstances is false in low-spec hardware, as it necessitates both a SHA2 and SHA3 implementation. https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9...
      - 3mo ago
Ajedi32 3mo 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 3mo 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.
- mswphd 3mo 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 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 3mo 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 3mo 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/3mpdmwk2o7c2t 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 3mo 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 3mo 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 3mo ago
    the NSA has a history of weakening cryptography in a very specific way, known as "NOBUS" https://en.wikipedia.org/wiki/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).
galadran 3mo 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_b 3mo 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.
  - galadran 3mo 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.
    - throwaway81523 3mo ago
      Does the specification recommend using a hybrid? At the level of at least SHOULD if not MUST, in the sense of RFC 2119? I have the opposite impression but haven't checked.
      - galadran 3mo ago
        In effect, yes it does. The Recommended flag is set for X25519MLKEM768. It is not set for any of the pure PQ key exchanges. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete...
miloignis 3mo 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/#:~:text=hybrids https://keymaterial.net/2025/11/27/ml-kem-mythbusting/#:~:te...
- ebiederm 3mo 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?
- athrowaway3z 3mo 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".
  - mswphd 3mo 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.
    - athrowaway3z 3mo ago
      Is that true per se? I was under the impression certain dedicated single-algorithm quantum computers might be much easier to build; allowing you to attack some construct but not yet do full Shor. PS I'm not saying that's whats happening. Just trying to nail down the scope of what is possible (not plausible).
phyzome 3mo 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 3mo 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.
  - mswphd 3mo 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.
    - ryanisnan 3mo ago
      That makes sense. Thanks for responding! Someone elsewhere in the thread mentioned downgrade attacks. I presume if you wanted, on either the client or the server, you could disallow pure ML-KEM if you didn't trust it, preventing this vector. I don't know much about the hardware space - what do you make of the author's post that there hasn't been an articulated need for pure PQ encryption, where the device couldn't afford ECC.
      - mswphd 3mo ago
        That was articulated this morning explicitly on the TLS WG, you can see here https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9... In general most cryptographers don't do hardware. Most cryptographers would do something more conservative. I personally think what chrome is doing with the XWING combiner is fine/sensible. I do NOT think that stirring up so much trouble over pure ML-KEM is fine/sensible. Especially since it comes after nearly a decade of trying to disrupt the post-quantum transition by DJB (his behavior around the NIST PQC competition). It has made me view him as a bad actor in this space, which is a shame given his previous positive contributions to the field. RE downgrade attacks: you're right. For some prior downgrade attacks (TLS 1.2), see e.g. LogJam https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf My (admittedly hazy) memory of the attack was that they were able to take a client + server who both support "export grade" crypto (say 512-bit finite field DH), then 1. force them to choose this (over cipher suites they may prefer more), then 2. solve the resulting instance before the connection times out, and then 3. use this to rewrite the transcript history to be consistent with one of the sides only supporting 512-bit DH. This required both sides to support the 512-bit DH though, as well as having the ability to break it on the order of minutes. There is no public estimate that breaking ML-KEM is remotely that small. There are some public repositories of attack records on LWE, e.g. https://www.latticechallenge.org/lwe_challenge/challenge.php https://www.latticechallenge.org/lwe_challenge/challenge.php As you can see, the records are < dimension 100 (though that isn't the only relevant parameter). There might be some records elsewhere that push this mildly higher, but my understsanding is the record attack is 1. definitely << 200, and 2. attacks against ML-KEM have exponential time complexity, so scaling to ~500 would require quadratically more time. This is a huge difference in cryptography, e.g. the difference between a completely broken scheme (say complexity ~2^50-2^60) and AES (~2^120).
OutOfHere 3mo 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_furry 3mo 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_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce... https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ 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-quantum-safety-blanket/ 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-threat-models/ 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 3mo 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-I1DbxqoWrRA/ https://mailarchive.ietf.org/arch/msg/tls/lON9lKptnJ6ccq2-I1...
- timschmidt 3mo 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 https://blog.cr.yp.to/20260221-structure.html He's also responded directly to criticisms: https://nsa.2026.action.cr.yp.to/guide.html 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.
  - ButlerianJihad 3mo ago
    Like, who is "Dave"?
    - timschmidt 3mo ago
      Sorry, Daniel. I know better, but the fingers typed what they typed. I seem to be sick this morning so perhaps I was already coming down with something. :-/
- commandersaki 2mo 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."
throw0101d 3mo 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-08 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-parameters.xhtml#tls-parameters-8 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.

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 3mo 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?

throwaway29303 3mo ago
https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koXOLooFpU54/ https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koX...
iAMkenough 3mo ago
I don’t think the spy agency would use nsa.gov address to manipulate the technology trajectory.
- advisedwang 3mo 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)
  - timschmidt 3mo ago
    There's a history and a 'pattern or practice' of behavior between NSA (sometimes using other TLAs or plausibly deniable intermediaries) and standards bodies and regulatory agencies. Demonstrating a 'pattern or practice' is the legal standard one has to meet to bust qualified immunity and shift the burden of doubt on to authorities, so I'd say it goes a fair amount past 'reasonable suspicion', which in a court is itself enough to issue search warrants.
- mswphd 3mo 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).
  - iAMkenough 3mo ago
    2006's NSA is not 2026's NSA
    - mswphd 3mo ago
      it is easy to point to ghosts in the corner. Random fearmongering is not a technical argument though. There have been no technical arguments to justify the random fearmongering. Pointing to prior behavior in a way that is inconsistent with the current situation is especially annoying fearmongering.
      - iAMkenough 3mo ago
        The “technical arguments” are documented here: https://blog.cr.yp.to/20260221-structure.html https://blog.cr.yp.to/20260221-structure.html
        adrian_b 3mo ago
        And those technical arguments are quite thorough, covering both the pro and the contra arguments.
        mswphd 3mo ago
        That document is nonsense? The current RFC is not to say > use pure ML-KEM > hybrid ML-KEM. the current document is instead to say > If you are in a setting where you REALLY want to use pure ML-KEM (though we explicitly recommend you do not do it), this is the standard you would implement against. It is also technically inaccurate. The whole argument hinges on it being negligible cost in all environments to do hybrids. This is explicitly false. See this message on the TLS-WG on explicitly this point https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9... A large list of pros/cons detailing a question that isn't being debated that is technically inaccurate is what I would expect from an LLM, not from a competent cryptographer. I am unsurprised to see it from DJB given his behavior in the last decade regarding PQC.
axus 3mo ago
The inexplicable behavior is indistinguishable from behavior that could be explained by a conspiracy.
mcpherrinm 3mo 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_b 3mo 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.
mswphd 3mo 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 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_b 3mo 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.
  - some_furry 3mo ago
    I recommend reading this perspective https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce... Also, https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ ML-KEM is not "very new" compared to the age of other algorithms historically deployed.
  - mswphd 3mo ago
    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 improvement). It has taken exponential time to attack since then. Instantiating a standard ~20 years after introduction is slower than what we did with RSA, or with elliptic curve cryptography. Therea re settings where hybrids are not free, for example hardware. The standard hybrid suggestion (XWING) would require hardawre to implement both SHA2 and SHA3. See this recent TLS WG post detailing this https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9...

sharpshadow 3mo 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 https://blog.cr.yp.to/20251004-weakened.html

mswphd 3mo 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_b 3mo ago
  Another poster has already given a link to the technical arguments of DJB, https://blog.cr.yp.to/20260221-structure.html 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.
  - mswphd 3mo ago
    Very explicitly, this is not the main RFC for incorporating PQ crypto into TLS 1.3. This is an RFC with recommendation to implement = N about how to do pure ML-KEM if you must for some reason, in a standards-compliant way. That blog post is written in a way that implies otherwise, namely that pure ML-KEM is being favored over hybrids for TLS 1.3. This is explicitly false. Moreover many parts are technically false. In particular, the claim that hybrids are negligible cost in all circumstances is false in low-spec hardware, as it necessitates both a SHA2 and SHA3 implementation. https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9...
    - 3mo ago

Ajedi32 3mo 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 3mo 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.
mswphd 3mo 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 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 3mo 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 3mo 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/3mpdmwk2o7c2t 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 3mo 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 3mo 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 3mo ago
  the NSA has a history of weakening cryptography in a very specific way, known as "NOBUS" https://en.wikipedia.org/wiki/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).

galadran 3mo 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_b 3mo 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.
- galadran 3mo 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.
  - throwaway81523 3mo ago
    Does the specification recommend using a hybrid? At the level of at least SHOULD if not MUST, in the sense of RFC 2119? I have the opposite impression but haven't checked.
    - galadran 3mo ago
      In effect, yes it does. The Recommended flag is set for X25519MLKEM768. It is not set for any of the pure PQ key exchanges. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.iana.org/assignments/tls-parameters/tls-paramete...

miloignis 3mo 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/#:~:text=hybrids https://keymaterial.net/2025/11/27/ml-kem-mythbusting/#:~:te...

ebiederm 3mo 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?
athrowaway3z 3mo 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".
- mswphd 3mo 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.
  - athrowaway3z 3mo ago
    Is that true per se? I was under the impression certain dedicated single-algorithm quantum computers might be much easier to build; allowing you to attack some construct but not yet do full Shor. PS I'm not saying that's whats happening. Just trying to nail down the scope of what is possible (not plausible).

phyzome 3mo 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 3mo 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.
- mswphd 3mo 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.
  - ryanisnan 3mo ago
    That makes sense. Thanks for responding! Someone elsewhere in the thread mentioned downgrade attacks. I presume if you wanted, on either the client or the server, you could disallow pure ML-KEM if you didn't trust it, preventing this vector. I don't know much about the hardware space - what do you make of the author's post that there hasn't been an articulated need for pure PQ encryption, where the device couldn't afford ECC.
    - mswphd 3mo ago
      That was articulated this morning explicitly on the TLS WG, you can see here https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9... In general most cryptographers don't do hardware. Most cryptographers would do something more conservative. I personally think what chrome is doing with the XWING combiner is fine/sensible. I do NOT think that stirring up so much trouble over pure ML-KEM is fine/sensible. Especially since it comes after nearly a decade of trying to disrupt the post-quantum transition by DJB (his behavior around the NIST PQC competition). It has made me view him as a bad actor in this space, which is a shame given his previous positive contributions to the field. RE downgrade attacks: you're right. For some prior downgrade attacks (TLS 1.2), see e.g. LogJam https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf My (admittedly hazy) memory of the attack was that they were able to take a client + server who both support "export grade" crypto (say 512-bit finite field DH), then 1. force them to choose this (over cipher suites they may prefer more), then 2. solve the resulting instance before the connection times out, and then 3. use this to rewrite the transcript history to be consistent with one of the sides only supporting 512-bit DH. This required both sides to support the 512-bit DH though, as well as having the ability to break it on the order of minutes. There is no public estimate that breaking ML-KEM is remotely that small. There are some public repositories of attack records on LWE, e.g. https://www.latticechallenge.org/lwe_challenge/challenge.php https://www.latticechallenge.org/lwe_challenge/challenge.php As you can see, the records are < dimension 100 (though that isn't the only relevant parameter). There might be some records elsewhere that push this mildly higher, but my understsanding is the record attack is 1. definitely << 200, and 2. attacks against ML-KEM have exponential time complexity, so scaling to ~500 would require quadratically more time. This is a huge difference in cryptography, e.g. the difference between a completely broken scheme (say complexity ~2^50-2^60) and AES (~2^120).

OutOfHere 3mo 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_furry 3mo 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_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce... https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ 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-quantum-safety-blanket/ 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-threat-models/ 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 3mo 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-I1DbxqoWrRA/ https://mailarchive.ietf.org/arch/msg/tls/lON9lKptnJ6ccq2-I1...

timschmidt 3mo 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 https://blog.cr.yp.to/20260221-structure.html He's also responded directly to criticisms: https://nsa.2026.action.cr.yp.to/guide.html 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.
- ButlerianJihad 3mo ago
  Like, who is "Dave"?
  - timschmidt 3mo ago
    Sorry, Daniel. I know better, but the fingers typed what they typed. I seem to be sick this morning so perhaps I was already coming down with something. :-/
commandersaki 2mo 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."

throw0101d 3mo 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-08 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-parameters.xhtml#tls-parameters-8 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.