ISTM that there are two distinct questions: 1. What is the risk now of continuing to use pure classical algorithms? 2. What is the risk of switching to pure PQ algorithms instead of hybrids?
The first question helps us assess the urgency of a transition to PQ. The second, whether we should deploy hybrids instead of pure PQ. As far as the first question goes, as Watson says, pure classical algorithms are only risky if the attacker has a CRQC at the time of (or more properly, prior to) the attack. Moreover, this risk exists as long as the relying party will accept a classical algorithm. Due to the inferior bandwidth properties of the PQ algorithms, many if not most uses of TLS are unlikely to switch off support for classical algorithms until there is stronger evidence of a probable CRQC. [0] As a result, partially transitioning to support of PQ algorithms doesn't help much, because the attacker can still attack traditional credentials [1]. Rather, it's really about setting us up for a transition to PQ-only if/when we have to. This brings us to the second question: suppose that we start by deploying some PQ algorithm (whether hybrid or pure). Once RPs accept it, then any weakness in that algorithm becomes a weakness in the system even if an individual endpoint only has a classical credential. For example, if clients will accept pure MLDSA and there is a classical attack on MLDSA, then an attacker can mount an impersonation attack on any server, regardless of what credential it actually has. The argument for hybrids in this context is that if if one has substantially higher confidence in the security of the traditional algorithm than the PQ one against classical attack, than it is safer to deploy hybrids. As as been discussed in detail, however, the threat model is different here because the attacker has to be able to break the vulnerable algorithm at the time of the connection (this is just a generalization of Watson's point), so the level of risk depends on (a) how rapidly you can disable the PQ algorithm if it's found to be vulnerable and (b) how likely you think it is that there will be a secret compromise the PQ algorithm so you don't know to disable it. You have to make this assessment on your own, but it's a distinct situation from HNDL, where there is action you can take to protect already-transmitted data. -Ekr [0] This may be different for systems such as SSH where the keys are often not authenticated via a global PKI and therefore it's possible for individual endpoint pairs to disable PQ safely. [1] See https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/ for a more in-depth discussion of the issues here. On Wed, May 27, 2026 at 2:19 PM Nico Williams <[email protected]> wrote: > On Wed, May 27, 2026 at 02:11:16PM -0700, Watson Ladd wrote: > > On Wed, May 27, 2026 at 2:08 PM Nico Williams <[email protected]> > wrote: > > > > > > On Wed, May 27, 2026 at 02:01:08PM -0700, Watson Ladd wrote: > > > > On Wed, May 27, 2026, 1:48 PM Simon Josefsson <simon= > > > > [email protected]> wrote: > > > > > Repeating that statement doesn't make it true. The analog > motivation > > > > > for doing PQ hybrids is Man-In-The-Middle attacks. If your > non-hybrid > > > > > PQ signature has a weakness (e.g., implementation bug), it > facilitate > > > > > man-in-the-middle's. > > > > > > > > > > > > > The only way to achieve that is to have a quantum computer at the > time of > > > > attack > > > > > > Not so. Find the victim's classical public key (they'll gladly tell > you > > > it), use a quantum computer to break it off-line and recover the > private > > > key, then use the private key at will to impersonate the victim, then > > > its counterparties become victims too. > > > > Correct: you have to have a quantum computer *before* mounting the > attack. > > > > Or to put another way, todays connections are not compromised by > > tomorrows computers. > > Sure, but today's _credentials_ -if they are still in use 'tomorrow'- > will be. Who wants to suddenly have to hurry up and deploy new code and > change keys all at once on PQ day? Worse: who wants to be dependent on > their counterparties to have to do that on PQ day? > > But at the same time the same pure-PQC vs. hybrid concerns arise. > Therefore if we thinkg HNDL justifies hybrid KEMs now then surely MITM > justifies hybrid signature algorithms now as well. > > Nico > -- > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
