5 ms·
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 fro
by advisedwang 3mo ago
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?
- iAMkenough 3mo agoI don’t think the spy agency would use nsa.gov address to manipulate the technology trajectory.
- advisedwang 3mo agoOf 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)
- timschmidt 3mo agoThere'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.
- mswphd 3mo agothis 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).
- iAMkenough 3mo ago2006's NSA is not 2026's NSA
- mswphd 3mo agoit 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.
- iAMkenough 3mo agoThe “technical arguments” are documented here: https://blog.cr.yp.to/20260221-structure.html https://blog.cr.yp.to/20260221-structure.html
- adrian_b 3mo agoAnd those technical arguments are quite thorough, covering both the pro and the contra arguments.
- mswphd 3mo agoThat 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/_9i3uIVDQ3pDRswpm9US-E-X2cA/ 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.
- axus 3mo agoThe inexplicable behavior is indistinguishable from behavior that could be explained by a conspiracy.
- mcpherrinm 3mo agoThe 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)
- adrian_b 3mo agoDo 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.
- mswphd 3mo agoDJB 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 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.
- adrian_b 3mo agoDJB 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.
- some_furry 3mo agoI recommend reading this perspective https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce... Also, https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ ML-KEM is not "very new" compared to the age of other algorithms historically deployed.
- mswphd 3mo agoSIKE 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/_9i3uIVDQ3pDRswpm9US-E-X2cA/ https://mailarchive.ietf.org/arch/msg/tls/_9i3uIVDQ3pDRswpm9...
- throwaway29303 3mo agohttps://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koXOLooFpU54/ https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koX...