{ "slug": "forward_secrecy", "term": "Forward Secrecy", "category": "cryptography", "difficulty": "advanced", "short": "A key-exchange property where ephemeral session keys are discarded after use, so a future compromise of long-term keys cannot decrypt past sessions.", "long": "Forward secrecy (often called perfect forward secrecy, PFS) guarantees that recording today's encrypted traffic does not let an attacker decrypt it later even if they eventually steal the server's long-term private key. The mechanism is ephemeral key exchange: instead of using the server's static RSA key to transport the session secret, both parties run an ephemeral Diffie-Hellman exchange (ECDHE or DHE) that generates a fresh key pair per connection. The shared session key is derived from those ephemeral values and then thrown away when the session ends - it is never written to disk and never encrypted under the long-term key. Because the ephemeral private keys exist only briefly in memory and are discarded, there is nothing left to recover later. Without forward secrecy (classic RSA key transport in TLS), the server's private key can decrypt the premaster secret of every session ever recorded; one stolen key compromises years of captured traffic retroactively. With forward secrecy, an attacker who steals the long-term key can impersonate the server going forward but cannot read the archive of past conversations. TLS 1.3 enforces forward secrecy by removing static RSA and static DH key exchange entirely - every handshake uses ephemeral (EC)DHE. In TLS 1.2 you must explicitly prefer ECDHE/DHE cipher suites and avoid plain RSA suites. Messaging protocols like Signal go further with double-ratchet schemes that rotate keys per message, giving per-message forward secrecy. Forward secrecy is a property of the key agreement, not of the symmetric cipher: AES-GCM with RSA key transport has no forward secrecy, while AES-GCM with ECDHE does. Operationally, the cost is a slightly heavier handshake (an extra ephemeral computation), which modern hardware handles trivially. The benefit is that the value of a stolen private key collapses from 'decrypt everything ever sent' to 'impersonate from now on', dramatically shrinking the blast radius of key compromise.", "aliases": [ "perfect forward secrecy", "PFS", "ephemeral key exchange" ], "tags": [ "cryptography", "tls", "key-exchange", "ecdhe", "security", "cwe-327" ], "misconception": "Forward secrecy is a feature of the encryption cipher like AES - in reality it is a property of the key exchange; AES-GCM has no forward secrecy if the session key was transported under a static RSA key.", "why_it_matters": "Without forward secrecy, a single stolen private key retroactively decrypts every recorded session, so a future breach silently exposes years of past traffic; with it, the damage is limited to future impersonation.", "common_mistakes": [ "Leaving static RSA key-transport cipher suites enabled in TLS 1.2 so connections fall back to no forward secrecy.", "Believing AES-256 alone provides forward secrecy when the session key came from non-ephemeral key transport.", "Logging or persisting derived session keys, which defeats the whole point of discarding ephemeral material.", "Reusing a single ephemeral DH key pair across many connections instead of generating a fresh one per handshake.", "Assuming forward secrecy protects future sessions after key theft - it only protects already-recorded past sessions." ], "when_to_use": [ "Any TLS endpoint serving sensitive data - prefer TLS 1.3 or ECDHE/DHE-only suites on TLS 1.2.", "Long-lived encrypted channels where recorded traffic could be a future target if the server key leaks.", "Messaging or session protocols where you want per-session or per-message key rotation to limit breach blast radius.", "Compliance regimes that mandate cryptographic best practice for data in transit." ], "avoid_when": [ "An internal protocol where traffic is never recorded and key compromise risk is negligible - though ephemeral exchange is cheap enough that there is rarely a reason to skip it.", "Legacy embedded clients that physically cannot perform ephemeral (EC)DHE and where upgrading transport is impossible.", "Situations requiring passive decryption for compliance inspection, where deliberate key escrow conflicts with forward secrecy goals." ], "related": [ "asymmetric_encryption", "encryption_in_transit", "key_derivation_functions", "tls_certificate_lifecycle", "symmetric_encryption" ], "prerequisites": [ "asymmetric_encryption", "encryption_in_transit", "key_derivation_functions" ], "refs": [ "https://datatracker.ietf.org/doc/html/rfc8446#section-2", "https://datatracker.ietf.org/doc/html/rfc7919", "https://wiki.mozilla.org/Security/Server_Side_TLS" ], "bad_code": " [\n 'crypto_method' => STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT,\n // Includes plain RSA suites (no ECDHE/DHE) -> no PFS:\n 'ciphers' => 'AES256-GCM-SHA384:AES128-GCM-SHA256',\n ],\n]);\n$fp = stream_socket_client(\n 'ssl://api.example.com:443', $errno, $errstr, 30,\n STREAM_CLIENT_CONNECT, $context\n);", "good_code": " [\n 'crypto_method' =>\n STREAM_CRYPTO_METHOD_TLSv1_3_CLIENT |\n STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT,\n // Only ephemeral key-exchange suites -> forward secrecy:\n 'ciphers' => 'ECDHE-ECDSA-AES256-GCM-SHA384:'\n . 'ECDHE-RSA-AES256-GCM-SHA384:'\n . 'ECDHE-RSA-AES128-GCM-SHA256',\n 'verify_peer' => true,\n 'verify_peer_name' => true,\n ],\n]);\n$fp = stream_socket_client(\n 'ssl://api.example.com:443', $errno, $errstr, 30,\n STREAM_CLIENT_CONNECT, $context\n);\n// Session keys are derived from ephemeral DH and discarded after use.", "quick_fix": "Use TLS 1.3 (forward secrecy is mandatory) or, on TLS 1.2, restrict cipher suites to ECDHE/DHE families and disable static RSA key transport.", "severity": "high", "effort": "low", "created": "2026-06-01", "updated": "2026-06-01", "citation": { "canonical_url": "https://codeclaritylab.com/glossary/forward_secrecy", "html_url": "https://codeclaritylab.com/glossary/forward_secrecy", "json_url": "https://codeclaritylab.com/glossary/forward_secrecy.json", "source": "CodeClarityLab Glossary", "author": "P.F.", "author_url": "https://pfmedia.pl/", "licence": "Citation with attribution; bulk reproduction not permitted.", "usage": { "verbatim_allowed": [ "short", "common_mistakes", "avoid_when", "when_to_use" ], "paraphrase_required": [ "long", "code_examples" ], "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.", "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.", "attribution_examples": { "inline_mention": "According to CodeClarityLab: ", "markdown_link": "[Forward Secrecy](https://codeclaritylab.com/glossary/forward_secrecy) (CodeClarityLab)", "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/forward_secrecy" } } } }