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

31–40 of 100 posts

Re: NSA tries to weaken mlkem standardisation?

#31

Post by iAMkenough »

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…

2006's NSA is not 2026's NSA

Re: NSA tries to weaken mlkem standardisation?

#32

Post by dooglius »

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…

Do you dispute his claims? And what about his argument that the NSA is doing the same thing?

Re: NSA tries to weaken mlkem standardisation?

#33

Post by adrian_b »

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 preferred before ML-KEM, until it was broken a few years ago.

Re: NSA tries to weaken mlkem standardisation?

#34

Post by adrian_b »

mswphd wrote: post #18
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?

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

Re: NSA tries to weaken mlkem standardisation?

#35

Post by some_furry »

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

Re: NSA tries to weaken mlkem standardisation?

#36

Post by mswphd »

ryanisnan wrote: post #28
mswphd wrote: post #26

Earlier quoted context omitted.

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

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

Re: NSA tries to weaken mlkem standardisation?

#37

Post by some_furry »

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.

Re: NSA tries to weaken mlkem standardisation?

#38

Post by adrian_b »

mcpherrinm wrote: post #16
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?

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…

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.

Re: NSA tries to weaken mlkem standardisation?

#39

Post by mswphd »

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…

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

Re: NSA tries to weaken mlkem standardisation?

#40

Post by mswphd »

iAMkenough wrote: post #31
mswphd wrote: post #25

Earlier quoted context omitted.

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…

2006's NSA is not 2026's NSA

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.
Post reply on HN