Bernstein's Blog

Posted Dec 10, 2025 11:03 UTC (Wed) by johill (subscriber, #25196)
In reply to: Bernstein's Blog by farnz
Parent article: Disagreements over post-quantum encryption for TLS

Definitely true, though I think

> they know a way to break all known hybrid algorithms

is highly unlikely. There isn't even a single hybrid construction, you have hybrid KEMs (of use e.g. for TLS), hybrid PAKEs (likely of no use for TLS), and probably others, those are the two I've recently looked into (for 802.11.)

(KEM = Key Encapsulation Mechanism, PAKE = Password Authenticated Key Exchange)

Now from a TLS perspective you could argue that hybrid KEMs are the only interesting case, but even then it seems pretty hard to imagine that effectively doing two KEMs (say ECDH and ML-KEM) in parallel and mixing the results with a strong hash would result in something weaker than each portion. Even if one side was broken to the point of always returning zeroes, you can't predict the output of a say SHA-2 has over the combination (which might be but is not necessarily simple concatenation.)
There's a current TLS draft (https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/) that's widely deployed which simply concatenates the two secrets. Obviously that only works if the full resulting secret is always used, but TLS always uses an HMAC (HKDF-Extract) to derive other keys from it.

PAKEs are more complicated because ML constructions apparently don't have indistinguishability properties, so an attacker can statistically check offline whether or not they guessed the right password, so you have to be really careful when designing hybrid PAKEs to not make it weakest-of-both, for example a trivial "parallel + combine-by-hash" would be weakest-of-both since an attack on each one lets an attacker discover the shared password.

Ultimately, I think it's extremely unlikely that there's a class attack against hybrid constructions to the point of making it something that's fundamentally broken/undesirable for all use cases/all kinds of hybrids.

In the FAQ (I think) NIST brings one example where a hybrid is needed for "protocol reasons" (IKEv4 I think), but I don't really understand what "protocol reasons" means while we're changing a protocol to include PQ crypto. I think if they (or adjacent folks) knew about a class attack against that, they'd recommend redesigning those protocols entirely (and possibly breaking backward compat instead, which I assume could be the only "protocol reason".)

Not that any of this gives us more information as to their motivations :)

Personally, I'm leaning towards hybrids because I really see no good reason not to and I'd think it's better to guard against all sides. Yes, in general one needs to be careful about how ones does that. Also, the overhead is pretty small (data exchanged for ML-KEM is at least an order of magnitude bigger data than for say ECDHE).

to post comments

What does the NSA know?

Posted Dec 10, 2025 11:53 UTC (Wed) by farnz (subscriber, #17727) [Link]

The problem is that we don't know whether there's an underlying break that applies to all the current hybrid constructions, or whether the NSA has a set of 100 known tools that between them break all the known hybrid constructions.

And because the NSA is so hugely secretive, we have no way of knowing whether or not they've got a huge set of tools that break hybrid algorithms but not pure PQC or whether they're pushing for pure PQC because they've broken the pure PQC algorithms suggested, but not the hybrids.

Indeed, it's even possible that both are true, and we're screwed either way, with one bit of the NSA pushing for pure PQC because they can break all the hybrid options and want security, and another bit pushing for pure PQC because they've broken that and want insecurity.