[athrowaway3z]

The two opening arguments are rather weak.

- European group could not be infiltrated by a state-actor with 100billion/y budget and a history of doing so?

- NOBUS today would not be secret in the algorithm but a quantum algorithm/device. Just a month ago HN was getting flooded with "PQC is probably required by 2030".

[mswphd]

quantum algorithm would make pure ML-KEM bad to support for the NSA. If the NSA has a quantum computer, they would want to delay proliferation of post-quantum schemes as long as possible, so they could get as much milage out of it as possible before people switch over.

Ironically, this (delaying PQC rollout/standardization) is arguably what DJB has been doing the ~decade, and what his current post is doing.

[athrowaway3z]

Is that true per se?

I was under the impression certain dedicated single-algorithm quantum computers might be much easier to build; allowing you to attack some construct but not yet do full Shor.

PS I'm not saying that's whats happening. Just trying to nail down the scope of what is possible (not plausible).

[mswphd]

you're talking about what is known as NISQ quantum computers, namely quantum computers before they can do full error correction. There are no claimed cryptanalytic benefits for NISQ machines. The main claims I've seen are for quantum chemistry simulation, but even those I've heard are not too credible.

Even dedicated single-algorithm quantum computers aren't magic. Given a dedicated single-algorithm quantum computer for attacking ML-KEM, the best current cost estimate we have for it is undoubtedly slower than the classical attack. Attacking ML-KEM quantumly is thought to take exponential (quantum) time. this is (clearly) not the case for ECC.

[notpushkin]

> and what his current post is doing.

Could you elaborate?

[mswphd]

the IETF TLS working group has limited time/energy. He has been (very successfully) taking up a good deal of this with very annoying procedural techniques (and his most recent move, spreading falsehoods regarding an RFC then asking people to brigade a vote on the RFC). Explicitly, this slows down standards, which delays the PQ transition.

Again explicitly, this is not the main RFC for PQ TLS, which details a hybrid construction. This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive, for example hardware where it necessitates both a SHA2 and SHA3 impl.

[notpushkin]

> This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive

I think the argument boils down to this, yeah.

I am not a cryptographer, nor I’m participating in IETF (yet :), but he does make a good argument on why sticking with a hybrid for the time being makes sense (in between of all the NSA tinfoil hat stuff). And from an outsider point of view, publishing this as an RFC would somewhat legitimize using ML-KEM alone even though it’s marked as Recommended: N. (I would rather prefer waiting until we can publish it as Recommended: Y instead!)

If there are environments where ECDHE-MLKEM is really that much more expensive than ML-KEM alone, could we figure out another hybrid construction instead? E.g. one that only uses SHA3, if that’s the problem.

[adgjlsfhk1]

if no one should implement it, why standardize it?

[mswphd]

this is not what I said before. As I mentioned in the post you replied to, there are certain scenarios (e.g. hardware) where pure ML-KEM has significant performance benefits. It instead should not be the default implementation suggestion.