3 ms·
Snarf packets now. Keep the dump. When pqc hits, decode the session. Since session key secrecy depends on the rsa alg key exchanges subsequent rekey is not prot
by ggm 2y ago
Snarf packets now. Keep the dump. When pqc hits, decode the session. Since session key secrecy depends on the rsa alg key exchanges subsequent rekey is not protective. Each session will require a fresh rsa key exchange, but if the algorithm is broken under pqc, this isn't very special.
Disk is cheap.
- tptacek 2y agoThat's not what forward secrecy means, as a term of art. Forward secrecy is the property whereby compromising a key today doesn't allow you to recover all the plaintexts previously encrypted under that key (you normally get it by running a DH exchange for every session, so they have ephemeral keys).
- ggm 2y agoA good point. I should make sure I don't misuse a term of art. Thank you for the clarification/correction! "Protected into the future" ?
- tptacek 2y ago"Harvest now, decrypt later" is how I've heard the attack described; there isn't really an engineering feature of protocols or ciphers that (a) has a name and (b) directly addresses this problem. But you're roughly right that the interactive nature of how DNSSEC (and signatures more generally) are used makes them of secondary importance in PQ upgrades.