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.
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).