NSA tries to weaken mlkem standardisation? • Hacker News Board

Re: NSA tries to weaken mlkem standardisation?

#51

Post by mswphd » Thu, Jul 02, 2026, 7:28 PM UTC

athrowaway3z wrote: post #46

mswphd wrote: post #29

Earlier quoted context omitted.

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.

Re: NSA tries to weaken mlkem standardisation?

#52

Post by adrian_b » Thu, Jul 02, 2026, 7:29 PM UTC

mswphd wrote: post #19

sharpshadow wrote: post #4

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

Re: NSA tries to weaken mlkem standardisation?

#53

Post by notpushkin » Thu, Jul 02, 2026, 7:31 PM UTC

mswphd wrote: post #29

athrowaway3z wrote: post #27

Earlier quoted context omitted.

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.

> and what his current post is doing.

Could you elaborate?

Re: NSA tries to weaken mlkem standardisation?

#54

Post by mswphd » Thu, Jul 02, 2026, 7:31 PM UTC

adrian_b wrote: post #48

some_furry wrote: post #41

Earlier quoted context omitted.

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

Re: NSA tries to weaken mlkem standardisation?

#55

Post by mswphd » Thu, Jul 02, 2026, 7:33 PM UTC

adrian_b wrote: post #52

mswphd wrote: post #19

Earlier quoted context omitted.

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

Re: NSA tries to weaken mlkem standardisation?

#56

Post by sweis » Thu, Jul 02, 2026, 7:35 PM UTC

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

Re: NSA tries to weaken mlkem standardisation?

#57

Post by mswphd » Thu, Jul 02, 2026, 7:36 PM UTC

notpushkin wrote: post #53

mswphd wrote: post #29

Earlier quoted context omitted.

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.

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

Re: NSA tries to weaken mlkem standardisation?

#58

Post by rurban » Thu, Jul 02, 2026, 8:03 PM UTC

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…

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.

Re: NSA tries to weaken mlkem standardisation?

#59

Post by galadran » Thu, Jul 02, 2026, 8:26 PM UTC

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…

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.

Re: NSA tries to weaken mlkem standardisation?

#60

Post by throwaway29303 » Thu, Jul 02, 2026, 9:18 PM UTC

advisedwang wrote: post #3

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?

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