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

81–90 of 100 posts

Re: NSA tries to weaken mlkem standardisation?

#81

Post by lcnPylGDnU4H9OF »

mswphd wrote: post #54
adrian_b wrote: post #48

Earlier quoted context omitted.

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

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

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

Re: NSA tries to weaken mlkem standardisation?

#82

Post by lcnPylGDnU4H9OF »

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…

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.

Re: NSA tries to weaken mlkem standardisation?

#83

Post by lcnPylGDnU4H9OF »

ButlerianJihad wrote: post #45
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…

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.

Re: NSA tries to weaken mlkem standardisation?

#84

Post by throw0101d »

adrian_b wrote: post #33
galadran wrote: post #11

This is garbage from start to finish. There are already codepoints assigned for MLKEM 512/768/1024 (0x0200, 0x0201, 0x0202) and nearly every major library supports it already: - OpenSSL (ML-KEM-512/768/1024) - BoringSSL (ML-KEM-1024) - NSS (ML-KEM-1024) - AWS-LC (ML-KEM-512/768/1024) - Rustls (ML-KEM-768/1024) - s2n-tls (ML-KEM-1024) - Bouncy Castle (ML-KEM-512/768/1024) - Botan (ML-KEM-512/768/1024) - GnuTLS (ML-KEM…

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…

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

Re: NSA tries to weaken mlkem standardisation?

#85

Post by throw0101d »

adrian_b wrote: post #34
mswphd wrote: post #18

Earlier quoted context omitted.

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

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

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

Re: NSA tries to weaken mlkem standardisation?

#86

Post by throw0101d »

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.

Re: NSA tries to weaken mlkem standardisation?

#87

Post by lcnPylGDnU4H9OF »

mswphd wrote: post #50
iAMkenough wrote: post #42

Earlier quoted context omitted.

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

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

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

Re: NSA tries to weaken mlkem standardisation?

#88

Post by ButlerianJihad »

timschmidt wrote: post #63
sweis wrote: post #56

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

Like, who is "Dave"?

Re: NSA tries to weaken mlkem standardisation?

#89

Post by some_furry »

digitalPhonix wrote: post #77
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…

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.

Re: NSA tries to weaken mlkem standardisation?

#90

Post by some_furry »

lcnPylGDnU4H9OF wrote: post #81
mswphd wrote: post #54

Earlier quoted context omitted.

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

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

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

Post reply on HN