Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NSA tries to weaken mlkem standardisation?

nsa.2026.action.cr.yp.to

Post reply on HN
Print view View original

71–80 of 100 posts

Re: NSA tries to weaken mlkem standardisation?

#71

Post by timschmidt »

advisedwang wrote: post #6
iAMkenough wrote: post #5

Earlier quoted context omitted.

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

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.

Re: NSA tries to weaken mlkem standardisation?

#72

Post by adgjlsfhk1 »

mswphd wrote: post #55
adrian_b wrote: post #52

Earlier quoted context omitted.

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…

if the proposal was ml-kem+ecc hybrid that removed sha2 and replaced it with sha3, no one would be objecting

Re: NSA tries to weaken mlkem standardisation?

#73

Post by throwaway81523 »

phasmantistes wrote: post #10

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 c…

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

Re: NSA tries to weaken mlkem standardisation?

#74

Post by throwaway81523 »

halJordan wrote: post #70
dooglius wrote: post #32

Earlier quoted context omitted.

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.

Re: NSA tries to weaken mlkem standardisation?

#75

Post by throwaway81523 »

galadran wrote: post #59
adrian_b wrote: post #33

Earlier quoted context omitted.

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…

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.

Re: NSA tries to weaken mlkem standardisation?

#76

Post by notpushkin »

mswphd wrote: post #57
notpushkin wrote: post #53

Earlier quoted context omitted.

> 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 c…

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

Re: NSA tries to weaken mlkem standardisation?

#77

Post by digitalPhonix »

miloignis wrote: post #13

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

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.

Re: NSA tries to weaken mlkem standardisation?

#78

Post by galadran »

throwaway81523 wrote: post #75
galadran wrote: post #59

Earlier quoted context omitted.

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

Re: NSA tries to weaken mlkem standardisation?

#79

Post by [deleted] »

mswphd wrote: post #25
iAMkenough wrote: post #5

Earlier quoted context omitted.

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 e…

[deleted]

Re: NSA tries to weaken mlkem standardisation?

#80

Post by Phemist »

mswphd wrote: post #23
ryanisnan wrote: post #22

Earlier quoted context omitted.

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 s…

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…

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.

Post reply on HN