Implement perfect forward secrecy (PFS)
PFS ensures that compromising long-term keys does not reveal past session keys. Learn the ephemeral key exchange pattern that makes this possible.
- 1
PFS requires ephemeral (temporary) key pairs for each session. The parties perform Diffie-Hellman with these ephemeral keys, derive the session key, then destroy the ephemeral private keys. Even if long-term keys are later stolen, past sessions remain secure because the ephemeral keys no longer exist.
- 2 Random Bytes Generator →
Generate an ephemeral private key for this session. This key will be destroyed immediately after the key exchange — it must never be stored to disk.
- 3 Modular Exponentiation →
Perform the DH computation with the ephemeral key. Send the public ephemeral value, receive the peer's value, and compute the shared secret. Derive the session key from this shared secret using HKDF.
- 4
In TLS 1.3, PFS is mandatory — all key exchanges use ephemeral Diffie-Hellman (DHE or ECDHE). In TLS 1.2, you must explicitly enable DHE/ECDHE cipher suites and disable static RSA key exchange. Use ECDHE with X25519 or P-256 for best performance.
Frequently asked questions
- Does PFS protect against future key compromise?
- Yes — that is its purpose. If an attacker records all traffic and later steals the server's long-term private key, they cannot decrypt past sessions because the ephemeral session keys were destroyed. Only future sessions (before key rotation) are affected.
- Why is PFS mandatory in TLS 1.3?
- Static RSA key exchange (TLS 1.2 and earlier) does not provide PFS — if the RSA private key is compromised, all past traffic can be decrypted. TLS 1.3 removed static RSA and mandates ephemeral DH, making PFS the default.
Learn more
Want to understand why?