In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, limiting damage.
This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.
If forward secrecy is used, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered, for example via a man-in-the-middle (MITM) attack.
The value of forward secrecy is limited not only by the assumption that an adversary will attack a server by only stealing keys and not modifying the random number generator used by the server but it is also limited by the assumption that the adversary will only passively collect traffic on the communications link and not be active using a man-in-the-middle attack.
Forward secrecy typically uses an ephemeral Diffie–Hellman key exchange to prevent reading past traffic.
[2] The term "perfect forward secrecy" was coined by C. G. Günther in 1990[3] and further discussed by Whitfield Diffie, Paul van Oorschot, and Michael James Wiener in 1992[4] where it was used to describe a property of the Station-to-Station protocol.
[5] Forward secrecy has also been used to describe the analogous property of password-authenticated key agreement protocols where the long-term secret is a (shared) password.
Forward secrecy also ensures that past communications cannot be decrypted if the long-term private keys from step 1 are compromised.
Forward secrecy is designed to prevent the compromise of a long-term secret key from affecting the confidentiality of past conversations.
A protocol that permits the sender to transmit data without first needing to receive any replies from the recipient may be called non-interactive, or asynchronous, or zero round trip (0-RTT).
[19] Dallmeier et al. (2020) experimentally found that modifying QUIC to use a 0-RTT forward secure and replay-resistant key exchange implemented with puncturable encryption incurred significantly increased resource usage, but not so much as to make practical use infeasible.
[24] OpenSSL supports forward secrecy using elliptic curve Diffie–Hellman since version 1.0,[25] with a computational overhead of approximately 15% for the initial handshake.
Facebook reported as part of an investigation into email encryption that, as of May 2014, 74% of hosts that support STARTTLS also provide forward secrecy.