>> Where do you draw the line? > > Simple: require hybrids. Any upgrade from pre-quantum crypto to > post-quantum crypto is obliged to keep the pre-quantum crypto and to > use the post-quantum crypto as an extra layer of defense, rather than > removing the pre-quantum crypto.
Why do you draw the line there? What “probability of disaster” is acceptable to you, why, and how do you compute it? >> I recognize (though disagreeing with) the arguments of those who want >> hybrid KEMs. I do not buy the arguments for hybrid signatures at all. > > Sorry, can you please say what the relevant difference is supposed to be > between encryption and signatures? Sorry – my fault: I should’ve stated that in my original email. As was shown in the thread, there’s more than one way to skin a cat (e.g., see Ilari’s post). But I meant a simple and obvious practical difference in TLS context (and given that currently there are no known attacks, or even promising approaches for one, on standardized PQ algorithms): * If a practical attack appears in the future against a PQ KEM, an adversary could break/decrypt sensitive traffic recorded today and protected by that KEM – thus, a consideration; * If a practical attack appears in the future against a PQ DSA, there’s no way the adversary could break my signature and authenticate as me into a TLS session that already happened – thus, unlike the KEM case, no consideration whatsoever, as the risk is zero, not just negligible. People do argue about the likelihood of (a) an attack appearing against the approved NIST PQC, and (b) CRQC being built ever, or within the next 10-40 years. But that’s a different story and a different discussion. > Compared to just PQ, whether for encryption or for signatures, ECC+PQ > reduces the damage caused by PQ breaks. We can argue about the likelihood of damage caused by PQ KEM breaks, and whether it’s worth hedging against it. NSA & GCHQ say is isn’t, BSI says it is. There’s no damage possible (at least, in the TLS context) caused by PQ DSA break (see above), so there’s nothing to reduce.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
