For those who don't know, djb is both highly regarded as a cryptographer and known to be something of a crank. (The former part is the only reason this is getting any attention.) Frankly, I don't know what's gotten into him.
The linked piece is not representative of the broader cryptography community. ML-KEM is fine.
He did not claim that ML-KEM is not fine.
The use of dual algorithms is without doubt the prudent decision for a transition period.
ML-KEM is still too new for anyone to be able to claim that no way to break it will be discovered in the next few years.
This is supported by the fact that one of the algorithms previously proposed for standardization has already been broken, which was a surprise.
Because ML-KEM is significantly more expensive than the current algorithm, using both does not increase much the cost.
The arguments of DJB are perfectly valid, which is why at the previous meeting most people have voted like him.
I know very well everything that DJB has published during the last 30 years, many of which have been important advances in cryptography. Some of his work has been very influential in the development of "post-quantum" cryptography and he was one of the main promoters of the idea that such cryptographic algorithms must be standardized ASAP.
Moreover, I have also run continuously on my servers, 24/7, for about a quarter of century, various programs written by DJB, which unlike the majority of the programs that I have ever seen, have done very well whatever they were intended to do, without ever needing any updates for security problems or other bugs. Very few programmers, even among the best, can present such a resume.
I do not believe that "crank" is the right word to describe DJB. It is true that he has distinguished himself by an unwillingness to accept compromises, even when he was for various reasons in opposition with the US government, but I do not think that this is crazy. On the contrary, I believe that the world is how it is right now precisely because most people go with the flow and they are eventually willing to accept almost anything when opposing that appears to be too difficult. Things would have been much better if there had been more such "cranks".
What would you say about his critique that simply ditching double-encryption is a bad idea? That seems like a fair point embodying a belt and suspenders approach.
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 afford ECC.
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 < dimension 100 (though that isn't the only relevant parameter). There might be some records elsewhere that push this mildly higher, but my understsanding is the record attack is
1. definitely << 200, and
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).