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.

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

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.

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)

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.

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

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?

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.

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

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.

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.

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.

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

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

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

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

ML-KEM is not "very new" compared to the age of other algorithms historically deployed.

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

The TFA has nothing to do with ML-KEM, but only about how to transition from the current algorithms to post-quantum algorithms.

For now, it is completely unknown how secure ML-KEM really is, because it is too new. For many complex cryptographic algorithms a decade or even a few decades have been required until someone discovered how to break them. The predecessor of ML-KEM, SIKE, has already been broken. Perhaps nobody will break ML-KEM, or perhaps it will be broken in a couple of years.

The only risk-free strategy is to use both ML-KEM and the current key exchange algorithm. This adds a negligible cost, because ML-KEM is much more expensive.

Therefore I agree with DJB about this, because I never bet that the worst case will not happen. Any good design must work fine even when the worst happens.

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.

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

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

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