On Mon, Nov 11, 2024 at 12:51 PM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > Christian Huitema <huit...@huitema.net> wrote: > > To summarize, the QUIC handshake will require an extra RTT: > > > * if the server flight is larger than 3 times the Client Hello, > > * if the Client Hello is larger than 12,000 bytes, > > * if the Server Hello is larger than 12,000 bytes. > > > If would be very nice to have PQC variants that fit inside that > budget. > > might it be worth doing a "legacy" crypto operation first, even if that is > broken by a CRQC, if the time to break it is less than the RTT? > The attacker has more time than just the RTT: you can perform a key recovery on any of the classical signatures within their validity time, and have the recovered private key ready to go for the next active attack. A proposal in similar spirit would be to keep using classical signatures for leaf and/or intermediate certificates, but reduce their validity time significantly. You still need a PQ signature from the root. Thus in the end, the saving would be similar as pursuing intermediate elission, but it's much more frail. Stepping back, I'm uncomfortable with the "quantum computers will take a long time to break a single key". That'll be the case for the first key broken. However, we need continued exponential progress in quantum computing if we are to reach a CRQC in our lifetimes. It'd be strange to expect that progress stops then. Best, Bas > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > > -- > Pqc mailing list -- p...@ietf.org > To unsubscribe send an email to pqc-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
