What is Perfect Forward Secrecy?

Perfect forward secrecy (PFS), often just called forward secrecy, is a property of how a connection’s keys are established. With it, each session’s encryption keys are derived from a key pair generated for that session alone and discarded afterwards. The server’s long-term private key is used only to sign, proving identity — it never encrypts the session secret. So an adversary who captures ciphertext today and steals or compels the private key years later has nothing to decrypt it with.

Without forward secrecy — classically, static RSA key exchange — the client encrypts the session secret to the server’s public key. Anyone who later obtains that private key can decrypt every recorded session it ever protected. That is the “record now, decrypt later” threat model, and it is the reason PFS became a baseline expectation rather than a refinement.

How it is achieved

Ephemeral Diffie-Hellman key exchange, in practice ECDHE (elliptic curve) and less commonly DHE (finite field). Both sides contribute a fresh key share, derive a shared secret neither transmitted, and throw the private parts away when the session ends. The cost is a little extra computation per handshake, which modern hardware absorbs easily.

In TLS 1.2, forward secrecy depends on the negotiated cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 provides it, TLS_RSA_WITH_AES_256_GCM_SHA384 does not. In TLS 1.3 the question does not arise — every key exchange the protocol permits is ephemeral, so all TLS 1.3 connections have forward secrecy by construction. This is one of the clearest reasons to disable older versions and static-RSA suites during the TLS handshake.

Caveats

Forward secrecy is scoped to key exchange. It does not protect against an attacker who compromises the server while sessions are live, against endpoint compromise, or against a private key stolen and then used to impersonate the server in new connections — that is what certificate revocation and short certificate lifetimes address. Session-resumption mechanisms also need care: long-lived session ticket keys that are never rotated can undermine the guarantee for resumed sessions.

Related concepts

See cipher suite, TLS handshake, certificate authority and defence in depth.