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.
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.
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).
Clearly, NOBUS can work at multiple levels. DJB previously posted about DES (besides it being weak enough): NSA wanted DES to "drive out competitors", to "reduce the field that NSA had to be concerned about".
Simply reducing the complexity of the standard to "pure ML-KEM" could already be considered enough "NOBUS" to be workable, such that the focus of attacks can be only on it (and bonus NOBUS if weaknesses are already known).
Sure, it's not completely free, but the hardware and implementation points seem relatively minor. Once CRQC exists the capacity will certainly not be unlimited, so there will surely still be use for encryption using ECC and "dragging it around" is not so bad.
What? It's not being described a theorem (the technical term for a mathematical proposition for which there is a proof). It's an experienced cryptographer saying that a certain operation should be more conservatively designed than it is. He makes arguments that fall short of proof but are the best we can hope for, given the current state of knowledge.
As for the NSA, yes, he documents what is happening pretty well, though it's done through above board channels rather than envelopes full of cash. He quotes an NSA person as saying hybrid protocols are unlikely to receive approval for use in government systems. That is, "if you want the government to buy your stuff ($$$$$), it better not implement hybrid". Similar to Dual_EC_DRBG.
None of the NSA (or even ex-NSA) people I know have participated in this discussion at all. I imagine they're preoccupied with the current administratiom's stupid decisioms disrupting their work.
Your comment being top of thread, and you seemingly being conversant in the details of the issue, would be exceptionally well-placed to make an argument on the merits of the subject matter. Character portraits are sometimes useful, but technical detail is often conclusive.
What's the steelman of djb's position and why does it fail scrutiny? To the uninitiated, it sounds like his preference for the hybrid classical/BQP scene is prudent given the marginal computational burden.
But I'm guessing, it would be better if an expert weighed in with details.
This (also not unbiased) comment doesn't provide any substantive arguments other than a character attack on DJB. You'd also be hard-pressed to find an appeal to authority in this article. Lastly, I'm pretty sure the comment I'm replying to is at least partially LLM-generated.
Ironically, it's the incredibly weak pro-standardization arguments that appear to be the most convincing evidence that the proposed standard is actually an instance of NSA meddling.
djb has always been as outlandishly activist and combative as he is intelligent and competent.
Anyone who attributes public motives or activity or blame to "the NSA" automatically gets dropped into the "conspiracy theorist" bin, as far as I'm concerned.
Funny thing about conspiracy "theory" is that a lot of the time the theory turns out to be true. In my view, the impulse to dismiss any suggestion of clandestine group activity (except if it's China's government, or Russia's, or Iran's, or...) as a "theory" is most likely the result of a psychological operation.
The Dale Gribbles of the world are not a particularly common character to meet in real life but that's the image evoked by "conspiracy theorist" no matter who the pejorative is aimed at, no matter the arguments they make nor the evidence they present. "Conspiracy theorist" is a thought-stopping, ad hominem cliché, with no place in serious discussion, yet it is widely used in exactly that; the possibility of conspiracy itself is what is eschewed in such discussions.
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.
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
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.
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. :-/
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...
- 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".
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.
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).
you're talking about what is known as NISQ quantum computers, namely quantum computers before they can do full error correction. There are no claimed cryptanalytic benefits for NISQ machines. The main claims I've seen are for quantum chemistry simulation, but even those I've heard are not too credible.
Even dedicated single-algorithm quantum computers aren't magic. Given a dedicated single-algorithm quantum computer for attacking ML-KEM, the best current cost estimate we have for it is undoubtedly slower than the classical attack. Attacking ML-KEM quantumly is thought to take exponential (quantum) time. this is (clearly) not the case for ECC.
the IETF TLS working group has limited time/energy. He has been (very successfully) taking up a good deal of this with very annoying procedural techniques (and his most recent move, spreading falsehoods regarding an RFC then asking people to brigade a vote on the RFC). Explicitly, this slows down standards, which delays the PQ transition.
Again explicitly, this is not the main RFC for PQ TLS, which details a hybrid construction. This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive, for example hardware where it necessitates both a SHA2 and SHA3 impl.
> This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive
I think the argument boils down to this, yeah.
I am not a cryptographer, nor I’m participating in IETF (yet :), but he does make a good argument on why sticking with a hybrid for the time being makes sense (in between of all the NSA tinfoil hat stuff). And from an outsider point of view, publishing this as an RFC would somewhat legitimize using ML-KEM alone even though it’s marked as Recommended: N. (I would rather prefer waiting until we can publish it as Recommended: Y instead!)
If there are environments where ECDHE-MLKEM is really that much more expensive than ML-KEM alone, could we figure out another hybrid construction instead? E.g. one that only uses SHA3, if that’s the problem.
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?
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.
A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak" would not explain "let's move the entire fucking federal governnent to this algorithm including implementations sourced by the private sector that don't do our secret sauxe".
Dual_EC_DRBG is the shape of backdoor that would need to apply here: even if you knew the structure of it, you would need an additional private number to attack it. Recall the Juniper vulnerability where another threat actor simply replaced the EC public key used by Juniper's Dual_EC implementation.
NOBUS without some mathematical assurance that, even should an adversary discover the same break through, they cannot decrypt the same traffic would be too risky when you consider the NSA's self interest and dual mission.
> A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak"
That’s not a NOBUS backdoor. It’s a different type of backdoor and I’m pointing out that proving there is no NOBUS backdoor doesn’t mean there’s no other backdoor.
It’s a counterexample that I came up with in 5 minutes, not a proof that it’s useful to a state actor.
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.
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.
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.
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:
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?
> 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.
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.
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
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.
> 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:
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)
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.
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).
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.
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.
> 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.
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.
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.
Wanting to standardize it's use without the secondary layer of protection provided by existing algorithms over the objections of a well known cryptographer counts as a hint to me.
In the same way that paying RSA to make Dual-EC DRBG the default RNG in it's security products when it was newer and more expensive than alternatives was a hint.
those are not remotely the same things though? You're also (formally) wrong about DUAL_EC_DRBG for two reasons
1. the payment to RSA (in 2004) was secret. So it could not have been a public indication of a problem, as it was not discovered until nearly a decade after it happened (in 2013, when it became public)
2. the problematic part of DUAL_EC_DRBG (the "hint of a backdoor") I was mentioning was known pre-2004.
blind paranoia is not a rational approach to cryptography. I say this as someone who prefers hybrid schemes! I just don't think it is sensible to attempt to "ban" the usage of pure ML-KEM by not standardizing it. It won't work! It'll just increase the risk of non-interoperable implementations.
1: We were all aware of the default change before we became aware of the payment. But the payment is old news today. And the default change was fishy before the payment was discovered. Discovery of the payment confirmed the earlier suspicion. You're arguing a detail like a lawyer while missing the message entirely. Perhaps intentionally.
2: And? You're missing a second part to this statement. Did you intend it to support some conclusion?
> blind paranoia
Characterizing criticism this way, instead of listening, internalizing, and adjusting your position is exactly why DJB's references to previous NSA interference stick. Y'all don't just have technical differences, you're going for character assassination. DJB has been consistent and explicit about the technical nature of his objections. I find his prose on the matter clear and well reasoned.
Your arguments seem disjointed, unorganized, specious, and lacking, in comparison, and less credible for the way you respond.
> I just don't think it is sensible to attempt to "ban" the usage of pure ML-KEM by not standardizing it. It won't work! It'll just increase the risk of non-interoperable implementations.
I think it's entirely reasonable to dissuade people from building non-hybrid systems during a transition period, and refusing to standardize them is an entirely reasonable way to signal that people shouldn't build or trust such systems during such a time, even stronger than a recommended_to_implement = N. No one has attempted to "ban" anything, so that's another gross mischaracterization.
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.
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.
> 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".
This makes the push for the standard far more suspicious. Why is it so important for this to be a standard if it is explicitly not recommended to implement at the time of standardization? The typical benefits of a standard would be to avoid disparate implementations, which seems fine for something that isn't recommended to implement.
On the other hand, lots of folks from the NSA coming out (covertly, in this hypothetical context) in support of a weak standard with dubious arguments is... the NSA's modus operandi. Additionally, the fact that the standard is being proposed so US government contractors can checks notes meet the NSA's recommendations(!!) is another reason to suspect the NSA's involvement (it seems weird I even have to write that). Especially given the "not recommended to implement" part of it; something (CNSA2) tells me that this "not recommended" will be widely disregarded in favor of "but it's a standard" to the point that an explicitly-known-to-be-weaker implementation becomes one of the, if not the, most deployed implementation in practice. Which is also the NSA's MO.
Edit:
Now that I think about it, recommendations like CNSA2 also support the NSA's spying capabilities. A single standard (or small set of standards) is easier to crack and exploit than many bespoke implementations. Granted, that's a bit of a weak argument since many bespoke implementations are likely to have their own vulnerabilities. The reason the NSA might still prefer standards be used is that a bespoke implementation will more likely have a bespoke exploit, meaning they can't use already-developed exploits and will have to spend time making one.
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.
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
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.
>> 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.
Ah! This corroborates a point I made in another comment:
> Especially given the "not recommended to implement" part of it; something (CNSA2) tells me that this "not recommended" will be widely disregarded in favor of "but it's a standard" to the point that an explicitly-known-to-be-weaker implementation becomes one of the, if not the, most deployed implementation in practice. Which is also the NSA's MO.
The "setting where you REALLY want to use pure ML-KEM" is when you are are a US government contractor and therefore required by your contract to follow the NSA's recommendations (CNSA2). Given the discussion, it seems a bit dishonest not to mention that part, no?
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)
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.
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?
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.
(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.
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.
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.
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.
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.
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.
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 ...
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.
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".
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.
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.
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.
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
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.
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).
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.
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.
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.
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.
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.
the NSA has a history of weakening cryptography in a very specific way, known as "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).
Clearly, NOBUS can work at multiple levels. DJB previously posted about DES (besides it being weak enough): NSA wanted DES to "drive out competitors", to "reduce the field that NSA had to be concerned about".
Simply reducing the complexity of the standard to "pure ML-KEM" could already be considered enough "NOBUS" to be workable, such that the focus of attacks can be only on it (and bonus NOBUS if weaknesses are already known).
Sure, it's not completely free, but the hardware and implementation points seem relatively minor. Once CRQC exists the capacity will certainly not be unlimited, so there will surely still be use for encryption using ECC and "dragging it around" is not so bad.
> garner support for one side of the debate simply because DJB says so
DJB saying so sounds good enough for me, considering the alternative. Dual_EC_DRBG anyone?
Do you dispute his claims? And what about his argument that the NSA is doing the same thing?
The person making the claim bears the burden of proving it. Merely failing to agree doesn't shift the burden of pros to the questioner.
What? It's not being described a theorem (the technical term for a mathematical proposition for which there is a proof). It's an experienced cryptographer saying that a certain operation should be more conservatively designed than it is. He makes arguments that fall short of proof but are the best we can hope for, given the current state of knowledge.
As for the NSA, yes, he documents what is happening pretty well, though it's done through above board channels rather than envelopes full of cash. He quotes an NSA person as saying hybrid protocols are unlikely to receive approval for use in government systems. That is, "if you want the government to buy your stuff ($$$$$), it better not implement hybrid". Similar to Dual_EC_DRBG.
None of the NSA (or even ex-NSA) people I know have participated in this discussion at all. I imagine they're preoccupied with the current administratiom's stupid decisioms disrupting their work.
Your comment being top of thread, and you seemingly being conversant in the details of the issue, would be exceptionally well-placed to make an argument on the merits of the subject matter. Character portraits are sometimes useful, but technical detail is often conclusive.
What's the steelman of djb's position and why does it fail scrutiny? To the uninitiated, it sounds like his preference for the hybrid classical/BQP scene is prudent given the marginal computational burden.
But I'm guessing, it would be better if an expert weighed in with details.
This (also not unbiased) comment doesn't provide any substantive arguments other than a character attack on DJB. You'd also be hard-pressed to find an appeal to authority in this article. Lastly, I'm pretty sure the comment I'm replying to is at least partially LLM-generated.
Ironically, it's the incredibly weak pro-standardization arguments that appear to be the most convincing evidence that the proposed standard is actually an instance of NSA meddling.
djb has always been as outlandishly activist and combative as he is intelligent and competent.
Anyone who attributes public motives or activity or blame to "the NSA" automatically gets dropped into the "conspiracy theorist" bin, as far as I'm concerned.
Funny thing about conspiracy "theory" is that a lot of the time the theory turns out to be true. In my view, the impulse to dismiss any suggestion of clandestine group activity (except if it's China's government, or Russia's, or Iran's, or...) as a "theory" is most likely the result of a psychological operation.
The Dale Gribbles of the world are not a particularly common character to meet in real life but that's the image evoked by "conspiracy theorist" no matter who the pejorative is aimed at, no matter the arguments they make nor the evidence they present. "Conspiracy theorist" is a thought-stopping, ad hominem cliché, with no place in serious discussion, yet it is widely used in exactly that; the possibility of conspiracy itself is what is eschewed in such discussions.
Rather shame on you for supporting the NSA here for dumbing down the next standard.
But call me surprised that Filippo Valsorda and Rich Salz supported the NSA here.
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...
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.
Like, who is "Dave"?
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. :-/
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...
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".
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.
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).
you're talking about what is known as NISQ quantum computers, namely quantum computers before they can do full error correction. There are no claimed cryptanalytic benefits for NISQ machines. The main claims I've seen are for quantum chemistry simulation, but even those I've heard are not too credible.
Even dedicated single-algorithm quantum computers aren't magic. Given a dedicated single-algorithm quantum computer for attacking ML-KEM, the best current cost estimate we have for it is undoubtedly slower than the classical attack. Attacking ML-KEM quantumly is thought to take exponential (quantum) time. this is (clearly) not the case for ECC.
> and what his current post is doing.
Could you elaborate?
the IETF TLS working group has limited time/energy. He has been (very successfully) taking up a good deal of this with very annoying procedural techniques (and his most recent move, spreading falsehoods regarding an RFC then asking people to brigade a vote on the RFC). Explicitly, this slows down standards, which delays the PQ transition.
Again explicitly, this is not the main RFC for PQ TLS, which details a hybrid construction. This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive, for example hardware where it necessitates both a SHA2 and SHA3 impl.
> This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive
I think the argument boils down to this, yeah.
I am not a cryptographer, nor I’m participating in IETF (yet :), but he does make a good argument on why sticking with a hybrid for the time being makes sense (in between of all the NSA tinfoil hat stuff). And from an outsider point of view, publishing this as an RFC would somewhat legitimize using ML-KEM alone even though it’s marked as Recommended: N. (I would rather prefer waiting until we can publish it as Recommended: Y instead!)
If there are environments where ECDHE-MLKEM is really that much more expensive than ML-KEM alone, could we figure out another hybrid construction instead? E.g. one that only uses SHA3, if that’s the problem.
if no one should implement it, why standardize it?
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?
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.
A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak" would not explain "let's move the entire fucking federal governnent to this algorithm including implementations sourced by the private sector that don't do our secret sauxe".
Dual_EC_DRBG is the shape of backdoor that would need to apply here: even if you knew the structure of it, you would need an additional private number to attack it. Recall the Juniper vulnerability where another threat actor simply replaced the EC public key used by Juniper's Dual_EC implementation.
NOBUS without some mathematical assurance that, even should an adversary discover the same break through, they cannot decrypt the same traffic would be too risky when you consider the NSA's self interest and dual mission.
> A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak"
That’s not a NOBUS backdoor. It’s a different type of backdoor and I’m pointing out that proving there is no NOBUS backdoor doesn’t mean there’s no other backdoor.
It’s a counterexample that I came up with in 5 minutes, not a proof that it’s useful to a state actor.
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:
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.
> DJB supports the use of ML-KEM in TLS, but he correctly says that using only ML-KEM is unwise
Then don't use it if you don't want to? Use hybrid? ML-KEM (CRYSTALS-Kyber) is a NIST standard, FIPS 203:
* https://csrc.nist.gov/pubs/fips/203/final
* https://en.wikipedia.org/wiki/ML-KEM
There's also HQC, FIPS 207:
* https://csrc.nist.gov/presentations/2025/fips-207-hqc-kem
Unless you're doing government work, there's no reason why you'd be force to use Officially Approved™ algorithms:
* https://en.wikipedia.org/wiki/Commercial_National_Security_A...
If the (US) government wants to use (allegedly) compromised algorithms with-in itself that's up to them. The rest of us can use whatever we want.
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.
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.
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-paramete...
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.
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?
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.
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.
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...
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.
> 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...
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.
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)
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.
https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koX...
I don’t think the spy agency would use nsa.gov address to manipulate the technology trajectory.
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).
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.
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.
> 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...
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.
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.
> there has been no hint of a backdoor in ML-KEM
Wanting to standardize it's use without the secondary layer of protection provided by existing algorithms over the objections of a well known cryptographer counts as a hint to me.
In the same way that paying RSA to make Dual-EC DRBG the default RNG in it's security products when it was newer and more expensive than alternatives was a hint.
those are not remotely the same things though? You're also (formally) wrong about DUAL_EC_DRBG for two reasons
1. the payment to RSA (in 2004) was secret. So it could not have been a public indication of a problem, as it was not discovered until nearly a decade after it happened (in 2013, when it became public)
2. the problematic part of DUAL_EC_DRBG (the "hint of a backdoor") I was mentioning was known pre-2004.
blind paranoia is not a rational approach to cryptography. I say this as someone who prefers hybrid schemes! I just don't think it is sensible to attempt to "ban" the usage of pure ML-KEM by not standardizing it. It won't work! It'll just increase the risk of non-interoperable implementations.
1: We were all aware of the default change before we became aware of the payment. But the payment is old news today. And the default change was fishy before the payment was discovered. Discovery of the payment confirmed the earlier suspicion. You're arguing a detail like a lawyer while missing the message entirely. Perhaps intentionally.
2: And? You're missing a second part to this statement. Did you intend it to support some conclusion?
> blind paranoia
Characterizing criticism this way, instead of listening, internalizing, and adjusting your position is exactly why DJB's references to previous NSA interference stick. Y'all don't just have technical differences, you're going for character assassination. DJB has been consistent and explicit about the technical nature of his objections. I find his prose on the matter clear and well reasoned.
Your arguments seem disjointed, unorganized, specious, and lacking, in comparison, and less credible for the way you respond.
> I just don't think it is sensible to attempt to "ban" the usage of pure ML-KEM by not standardizing it. It won't work! It'll just increase the risk of non-interoperable implementations.
I think it's entirely reasonable to dissuade people from building non-hybrid systems during a transition period, and refusing to standardize them is an entirely reasonable way to signal that people shouldn't build or trust such systems during such a time, even stronger than a recommended_to_implement = N. No one has attempted to "ban" anything, so that's another gross mischaracterization.
2006's NSA is not 2026's NSA
The NSA isn't DJB's oppositiom here. It's the majority of the international community of cryptography experts.
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.
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.
> 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".
This makes the push for the standard far more suspicious. Why is it so important for this to be a standard if it is explicitly not recommended to implement at the time of standardization? The typical benefits of a standard would be to avoid disparate implementations, which seems fine for something that isn't recommended to implement.
On the other hand, lots of folks from the NSA coming out (covertly, in this hypothetical context) in support of a weak standard with dubious arguments is... the NSA's modus operandi. Additionally, the fact that the standard is being proposed so US government contractors can checks notes meet the NSA's recommendations(!!) is another reason to suspect the NSA's involvement (it seems weird I even have to write that). Especially given the "not recommended to implement" part of it; something (CNSA2) tells me that this "not recommended" will be widely disregarded in favor of "but it's a standard" to the point that an explicitly-known-to-be-weaker implementation becomes one of the, if not the, most deployed implementation in practice. Which is also the NSA's MO.
Edit:
Now that I think about it, recommendations like CNSA2 also support the NSA's spying capabilities. A single standard (or small set of standards) is easier to crack and exploit than many bespoke implementations. Granted, that's a bit of a weak argument since many bespoke implementations are likely to have their own vulnerabilities. The reason the NSA might still prefer standards be used is that a bespoke implementation will more likely have a bespoke exploit, meaning they can't use already-developed exploits and will have to spend time making one.
> Why is it so important for this to be a standard if it is explicitly not recommended to implement at the time of standardization?
This isn't a standard.
It's not on the standards track! Words mean things!
But to answer your question: some industries need an RFC. FIPS 203 also doesn't specify how to use ML-KEM in TLS.
Think phone companies.
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.
The “technical arguments” are documented here: https://blog.cr.yp.to/20260221-structure.html
And those technical arguments are quite thorough, covering both the pro and the contra arguments.
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.
> 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.
Ah! This corroborates a point I made in another comment:
> Especially given the "not recommended to implement" part of it; something (CNSA2) tells me that this "not recommended" will be widely disregarded in favor of "but it's a standard" to the point that an explicitly-known-to-be-weaker implementation becomes one of the, if not the, most deployed implementation in practice. Which is also the NSA's MO.
https://news.ycombinator.com/item?id=48773930
The "setting where you REALLY want to use pure ML-KEM" is when you are are a US government contractor and therefore required by your contract to follow the NSA's recommendations (CNSA2). Given the discussion, it seems a bit dishonest not to mention that part, no?
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)
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.
The inexplicable behavior is indistinguishable from behavior that could be explained by a conspiracy.
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?
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.
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.
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.
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.
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.
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.)
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.
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".
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.
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.
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.
That was articulated this morning explicitly on the TLS WG, you can see here
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).
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.
“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
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.
Another poster has already given a link to the technical arguments of DJB,
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.
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/_9i3uIVDQ3pDRswpm9...
if the proposal was ml-kem+ecc hybrid that removed sha2 and replaced it with sha3, no one would be objecting