Comment by some_furry
4 days ago
The NSA isn't DJB's oppositiom here. It's the majority of the international community of cryptography experts.
4 days ago
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 weird that there are people arguing about a decision that should have been non-controversial.
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.
> 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.
1 reply →