That 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
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.
>> 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.
Ah! This corroborates a point I made in another comment:
> 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.
The "setting where you REALLY want to use pure ML-KEM" is when you are are a US government contractor and therefore required by your contract to follow the NSA's recommendations (CNSA2). Given the discussion, it seems a bit dishonest not to mention that part, no?
And those technical arguments are quite thorough, covering both the pro and the contra arguments.
That 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/_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.
> 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.
Ah! This corroborates a point I made in another comment:
> 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.
https://news.ycombinator.com/item?id=48773930
The "setting where you REALLY want to use pure ML-KEM" is when you are are a US government contractor and therefore required by your contract to follow the NSA's recommendations (CNSA2). Given the discussion, it seems a bit dishonest not to mention that part, no?