[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?

[mswphd]

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.

[adrian_b]

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.

[mswphd]

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

[mswphd]

actually another more basic point: SIKE is much more closely related to elliptic-curve cryptography than lattices. People would not use SIKE to argue that ECC is unreliable though.

[throw0101d]

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

And who is making that 'ML-KEM alone' argument? AIUI, the IETF currently recommends hybrid.

It's on the US government talking to itself that would maybe do non-hybrid:

* https://en.wikipedia.org/wiki/Commercial_National_Security_A...

If the US government wants to compromise itself… then fine?

Also, HQC (FIPS 207) has been chosen as a backup / alternative to ML-KEM (formerly "Kyber"):

* https://www.nist.gov/news-events/news/2025/03/nist-selects-h...

[some_furry]

I recommend reading this perspective

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.

[mcpherrinm]

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]

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.

[throwaway29303]

https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koX...

[iAMkenough]

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

[mswphd]

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

[adrian_b]

DJB did not criticize anything about ML-KEM.

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.

[mswphd]

DJB wrote this article after asking people to brigadge the current TLS-WG's attempt to get rough consensus on a current draft RFC for pure ML-KEM. This is clearly part of this tirade for that.

ML-KEM is not new. It's hardness is based on MLWE. LWE (a slightly harder problem) has been around for 20 years. Attacks against it stablized to be 2^{cn} time maybe 15 years ago. The value of c has been stable for nearly 10 years.

MLWE is mildly different, but still from > 1 decade ago. The only improved attacks are ~8x faster (and they are relatively naive). It has been a very popular cryptanalytic target since it was suggested (LWE has been dominating cryptography for the last >10 years).

It does not add negligible cost in all settings. In hardware, a hybrid scheme requires an implementation of SHA2 and SHA3. This is expensive.

Any good design must not do fine when even the worst happens. When we did the AES competition, we did not combine AES with DES (or 3DES) in case AES was weak.

This is beside the point though. Most cryptographers would still recommend the hybrid over pure ML-KEM. This RFC (for pure MLKEM) is marked "recommended to implement = N". It is purely for settings where the implementors independently want to use pure ML-KEM for some reason. In these settings, they should implement it against some standard, so it is interoperable.

[tveita]

> Most cryptographers would still recommend the hybrid over pure ML-KEM. This RFC (for pure MLKEM) is marked "recommended to implement = N". It is purely for settings where the implementors independently want to use pure ML-KEM for some reason.

That's exactly how it was with Dual_EC_DRBG.

E.g. https://www.schneier.com/essays/archives/2007/11/did_nsa_put...

   I don’t understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It’s public, and rather obvious. It makes no sense from an engineering perspective: It’s too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.
  
  My recommendation, if you’re in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances.

So most cryptographers _recommended_ staying the hell away from Dual_EC_DRBG. But hey, harmless, no one serious about security would actually use it right?

Except as we know now, after the standardization NSA was able to persuade/bribe vendors to implement it.

RSA is still a viable cryptography vendor, after accepting money to backdoor their product for paying customers. The standardization gave them a fig leaf of plausible deniability. Honest mistake, could happen to anyone, right? If they had needed to implement a "non-standard" backdoor, or if it had been officially struck from the standard, it would have been a lot harder to row away from.

[mswphd]

there has been no hint of a backdoor in ML-KEM. In fact, it (and every lattice-based scheme) has been made less efficient on purpose to rule out the only possible backdoor (the ephemeral "a" part in LWE-type samples could be fixed/standardized to something. There are plausibly some mild savings associated with this. Every "real" LWE-type scheme since the New Hope scheme, deployed in Chrome a decade ago, has chosen not to do this out of an abundance of caution).

For DUAL_EC_DRBG, the mechanism that could yield a backdoor was known pre-standardization. To get the backdoor RSA had to specifically use government chosen parameters.

These are not new concerns. If even a candidate backdoor had appeared in ML-KEM (similarly to how DUAL_EC_DRBG was), it would be a very different story. But nobody has ever even suggested something might be off!

So no, it's not exactly the same as DUAL_EC_DRBG. Different things are in fact different. Note that there are similarities to DUAL_EC_DRBG in contemporary cryptography. Russia has a block cipher Kuznyechik that has some very fishy structure in its S-box. We don't know how such structure is exploitable, but I would bet money that it is. Despite not being able to see an attack, we can see that things seem off in a concrete way. Nobody has *ever* suggested that for ML-KEM.

[iAMkenough]

2006's NSA is not 2026's NSA

[some_furry]

The NSA isn't DJB's oppositiom here. It's the majority of the international community of cryptography experts.

[adrian_b]

Your claim does not match the reality, because at the previous IETF meeting most have voted like DJB.

I cannot see how any true "expert" would have the courage to claim that in a cryptography standard it is admissible to accept risks that cannot be quantified.

For the variant supported by DJB there are no risks, while for the variant supported by NSA nobody can estimate the risks.

It is as simple as this, so it is weird that there are people arguing about a decision that should have been non-controversial.

[mswphd]

all cryptographic risks cannot be quantified. Every cryptographer knows this. It is consistent with everything we know that oneway functions do not exist, and cryptography as a field is limited to things like Merkle Puzzles/things that are secure under physical assumptions (e.g. the wiretap channel).

The variant DJB suggests there are explicit risks. For example

1. both ECC and ML-KEM can be broken (obviously)

2. additional code complexity could increase the LoC of teh crypto implementation, making it more plausible there are implementation bugs

regardless, this is a red herring. Nearly all cryptographers still support hybrids!!! The current RFC is *not* about "use pure ML-KEM". It is instead about "if you're going to use pure ML-kem (and we explicitly recommend not doing so), here is how to do it in a standardized way".

The people arguing about this decision don't even know what the decision being made is in the first place.

[mswphd]

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]

The “technical arguments” are documented here: https://blog.cr.yp.to/20260221-structure.html

[adrian_b]

And those technical arguments are quite thorough, covering both the pro and the contra arguments.

[mswphd]

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

[advisedwang]

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]

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.

[axus]

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