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 3 days ago | parent [-]

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 3 days ago | parent | next [-]

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 3 days ago \| parent [-]
		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 3 days ago | parent | prev [-]

> and what his current post is doing.

Could you elaborate?

▲

mswphd 3 days ago | parent [-]

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 3 days ago \| parent \| next [-]
		> 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 3 days ago \| parent \| prev [-]
		if no one should implement it, why standardize it?