One of Edward Snowden’s revelations was how the NSA decrypts much of the traffic on the Internet. The strategy is straightforward: they capture tons and tons of traffic that’s encrypted with TLS from important routers on the Internet. Separately, they break into and obtain private keys from servers across the Internet. If or when they have the private key for a given server, they can use it to decrypt the TLS traffic for all of that server’s connections.

Fortunately, it’s possible to protect all of that content even if a server’s private key is compromised. This is called “forward secrecy.” Even if the server’s private key is compromised, the encryption is not broken.

How can we achieve forward secrecy? Recall the ways that an asymmetric key pair can be used: the private key can be used to create a signature that the public key can verify, or the public key can be used to encrypt a message that only the private key can decrypt. The weakness is in encrypting a message using the server’s public key: this asymmetric key pair doesn’t change for potentially years at a time, because it’s tied to an X.509 certificate issued by some already-trusted third party (AKA a certificate authority).

Fortunately, there’s a simple alternative: rather than using the server’s long-term key pair for encryption, we can create a new key pair for each connection or “session”. We’ll use the long-term key pair only to sign the “session” public key. The session key pair can then be used to establish a shared symmetric key that’ll be used for an authenticated, encrypted communication channel going forward.

Using this strategy, when a private key is compromised by a third party, that third party can’t use the compromised key to decrypt the connection’s traffic! Forward secrecy is one of the improvements in TLS 1.3, which was just finalized in March 2018, and should be coming soon to a browser (and servers) near you.