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 essentially the same scheme (there were minor technical differences, but it's really not that big).
The TFA has nothing to do with ML-KEM, but only about how to transition from the current algorithms to post-quantum algorithms.
For now, it is completely unknown how secure ML-KEM really is, because it is too new. For many complex cryptographic algorithms a decade or even a few decades have been required until someone discovered how to break them. The predecessor of ML-KEM, SIKE, has already been broken. Perhaps nobody will break ML-KEM, or perhaps it will be broken in a couple of years.
The only risk-free strategy is to use both ML-KEM and the current key exchange algorithm. This adds a negligible cost, because ML-KEM is much more expensive.
Therefore I agree with DJB about this, because I never bet that the worst case will not happen. Any good design must work fine even when the worst happens.
DJB wrote this article after asking people to brigadge the current TLS-WG's attempt to get rough consensus on a current draft RFC for pure ML-KEM. This is clearly part of this tirade for that.
ML-KEM is not new. It's hardness is based on MLWE. LWE (a slightly harder problem) has been around for 20 years. Attacks against it stablized to be 2^{cn} time maybe 15 years ago. The value of c has been stable for nearly 10 years.
MLWE is mildly different, but still from > 1 decade ago. The only improved attacks are ~8x faster (and they are relatively naive). It has been a very popular cryptanalytic target since it was suggested (LWE has been dominating cryptography for the last >10 years).
It does not add negligible cost in all settings. In hardware, a hybrid scheme requires an implementation of SHA2 and SHA3. This is expensive.
Any good design must not do fine when even the worst happens. When we did the AES competition, we did not combine AES with DES (or 3DES) in case AES was weak.
This is beside the point though. Most cryptographers would still recommend the hybrid over pure ML-KEM. This RFC (for pure MLKEM) is marked "recommended to implement = N". It is purely for settings where the implementors independently want to use pure ML-KEM for some reason. In these settings, they should implement it against some standard, so it is interoperable.
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.
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.
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 essentially the same scheme (there were minor technical differences, but it's really not that big).
DJB did not criticize anything about ML-KEM.
The TFA has nothing to do with ML-KEM, but only about how to transition from the current algorithms to post-quantum algorithms.
For now, it is completely unknown how secure ML-KEM really is, because it is too new. For many complex cryptographic algorithms a decade or even a few decades have been required until someone discovered how to break them. The predecessor of ML-KEM, SIKE, has already been broken. Perhaps nobody will break ML-KEM, or perhaps it will be broken in a couple of years.
The only risk-free strategy is to use both ML-KEM and the current key exchange algorithm. This adds a negligible cost, because ML-KEM is much more expensive.
Therefore I agree with DJB about this, because I never bet that the worst case will not happen. Any good design must work fine even when the worst happens.
DJB wrote this article after asking people to brigadge the current TLS-WG's attempt to get rough consensus on a current draft RFC for pure ML-KEM. This is clearly part of this tirade for that.
ML-KEM is not new. It's hardness is based on MLWE. LWE (a slightly harder problem) has been around for 20 years. Attacks against it stablized to be 2^{cn} time maybe 15 years ago. The value of c has been stable for nearly 10 years.
MLWE is mildly different, but still from > 1 decade ago. The only improved attacks are ~8x faster (and they are relatively naive). It has been a very popular cryptanalytic target since it was suggested (LWE has been dominating cryptography for the last >10 years).
It does not add negligible cost in all settings. In hardware, a hybrid scheme requires an implementation of SHA2 and SHA3. This is expensive.
Any good design must not do fine when even the worst happens. When we did the AES competition, we did not combine AES with DES (or 3DES) in case AES was weak.
This is beside the point though. Most cryptographers would still recommend the hybrid over pure ML-KEM. This RFC (for pure MLKEM) is marked "recommended to implement = N". It is purely for settings where the implementors independently want to use pure ML-KEM for some reason. In these settings, they should implement it against some standard, so it is interoperable.
5 replies →
2006's NSA is not 2026's NSA
The NSA isn't DJB's oppositiom here. It's the majority of the international community of cryptography experts.
4 replies →
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.
4 replies →
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.