On Wed, May 27, 2026 at 2:18 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?
First off there is a signature scheme guaranteed to be secure if any signature scheme is. Why not use it for long lived credentials? Secondly credentials need to have limited lifetime due to compromise risks already. I have to rotate my SSH key with my employer every 90 days or so. > > 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 > -- -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
