Just for the record, this message is about signature algorithms... On Wed, May 27, 2026 at 2:27 PM Eric Rescorla <[email protected]> wrote:
> > 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]
