Forward secrecy
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. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. 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.

Forward secrecy protects data on the transport layer of a network that uses common Transport Layer Security protocols, including OpenSSL, when its long-term secret keys are compromised, as with the Heartbleed security bug. 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 attack.

The value of forward secrecy is that it protects past communication. This reduces the motivation for attackers to compromise keys. For instance, if an attacker learns a long-term key, but the compromise is detected and the long-term key is revoked and updated, relatively little information is leaked in a forward secure system.

The value of forward secrecy depends on the assumed capabilities of an adversary. Forward secrecy has value if an adversary is assumed to be able to obtain secret keys from a device (read access) but is either detected or unable to modify the way session keys are generated in the device (full compromise).  In some cases an adversary who can read long-term keys from a device may also be able to modify the functioning of the session key generator, as in the backdoored Dual Elliptic Curve Deterministic Random Bit Generator. If an adversary can make the random number generator predictable, then past traffic will be protected but all future traffic will be compromised.

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 (MITM) attack.  Forward secrecy typically uses an ephemeral Diffie-Hellman key exchange to prevent reading past traffic.  The ephemeral Diffie-Hellman key exchange is often signed by the server using a static signing key.  If an adversary can steal (or obtain through a court order) this static (long term) signing key, the adversary can masquerade as the server to the client and as the client to the server and implement a classic Man-in-the-Middle attack.

History
The term "perfect forward secrecy" was coined by C. G. Günther in 1990 and further discussed by Whitfield Diffie, Paul van Oorschot, and Michael James Wiener in 1992 where it was used to describe a property of the Station-to-Station protocol.

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.

In 2000 the IEEE first ratified IEEE 1363, which establishes the related one-party and two-party forward secrecy properties of various standard key agreement schemes.

Definition
An encryption system has the property of forward secrecy if plain-text (decrypted) inspection of the data exchange that occurs during key agreement phase of session initiation does not reveal the key that was used to encrypt the remainder of the session.

Example

The following is a hypothetical example of a simple instant messaging protocol that employs forward secrecy:

 Alice and Bob each generate a pair of long-term, asymmetric public and private keys, then verify public-key fingerprints in person or over an already-authenticated channel. Verification establishes with confidence that the claimed owner of a public key is the actual owner. 
 Alice and Bob use a key exchange algorithm such as Diffie–Hellman, to securely agree on an ephemeral session key. They use the keys from step 1 only to authenticate one another during this process.
 Alice sends Bob a message, encrypting it with a symmetric cipher using the session key negotiated in step 2.
 Bob decrypts Alice's message using the key negotiated in step 2.
 The process repeats for each new message sent, starting from step 2 (and switching Alice and Bob's roles as sender/receiver as appropriate). Step 1 is never repeated.
Forward secrecy (achieved by generating new session keys for each message) ensures that past communications cannot be decrypted if one of the keys generated in an iteration of step 2 is compromised, since such a key is only used to encrypt a single message. Forward secrecy also ensures that past communications cannot be decrypted if the long-term private keys from step 1 are compromised. However, masquerading as Alice or Bob would be possible going forward if this occurred, possibly compromising all future messages.

Attacks
Forward secrecy is designed to prevent the compromise of a long-term secret key from affecting the confidentiality of past conversations. However, forward secrecy cannot defend against a successful cryptanalysis of the underlying ciphers being used, since a cryptanalysis consists of finding a way to decrypt an encrypted message without the key, and forward secrecy only protects keys, not the ciphers themselves. A patient attacker can capture a conversation whose confidentiality is protected through the use of public-key cryptography and wait until the underlying cipher is broken (e.g. large quantum computers could be created which allow the discrete logarithm problem to be computed quickly). This would allow the recovery of old plaintexts even in a system employing forward secrecy.

Weak perfect forward secrecy 
Weak perfect forward secrecy (Wpfs) is the weaker property whereby when agents' long-term keys are compromised, the secrecy of previously established session-keys is guaranteed, but only for sessions in which the adversary did not actively interfere. This new notion, and the distinction between this and forward secrecy was introduced by Hugo Krawczyk in 2005.
This weaker definition implicitly requires that full (perfect) forward secrecy maintains the secrecy of previously established session keys even in sessions where the adversary did actively interfere, or attempted to act as a man in the middle.

Protocols
Forward secrecy is present in several major protocol implementations, such as SSH and as an optional feature in IPsec (RFC 2412). Off-the-Record Messaging, a cryptography protocol and library for many instant messaging clients, as well as OMEMO which provides additional features such as multi-user functionality in such clients, both provide forward secrecy as well as deniable encryption.

In Transport Layer Security (TLS), cipher suites based on Diffie–Hellman key exchange (DHE-RSA, DHE-DSA) and elliptic curve Diffie–Hellman key exchange (ECDHE-RSA, ECDHE-ECDSA) are available. In theory, TLS can choose appropriate ciphers since SSLv3, but in everyday practice many implementations have refused to offer forward secrecy or only provide it with very low encryption grade. TLS 1.3 leaves ephemeral Diffie–Hellman (finite field and elliptic curve variants) as the only remaining key exchange mechanism, in order to ensure forward secrecy.

OpenSSL supports forward secrecy using elliptic curve Diffie–Hellman since version 1.0, with a computational overhead of approximately 15% for the initial handshake.

The Signal Protocol uses the Double Ratchet Algorithm to provide forward secrecy. Puncturable encryption scheme, introduced by Green and Miers in 2015, makes use of Hierarchical identity-based encryption and Attribute-based encryption to provide forward secrecy without requiring pre-keys, unlike the Signal Protocol which is vulnerable to pre-key exhaustion attacks. 

On the other hand, among popular protocols currently in use, WPA does not support forward secrecy.

Use
Forward secrecy is seen as an important security feature by several large Internet information providers.  Since late 2011, Google provided forward secrecy with TLS by default to users of its Gmail service, Google Docs service, and encrypted search services. Since November 2013, Twitter provided forward secrecy with TLS to its users. Wikis hosted by the Wikimedia Foundation have all provided forward secrecy to users since July 2014 and are requiring the use of forward secrecy since August 2018.

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. TLS 1.3, published in August 2018, dropped support for ciphers without forward secrecy. , 96.6% of web servers surveyed support some form of forward secrecy, and 52.1% will use forward secrecy with most browsers.

At WWDC 2016, Apple announced that all iOS apps would need to use App Transport Security (ATS), a feature which enforces the use of HTTPS transmission. Specifically, ATS requires the use of an encryption cipher that provides forward secrecy. ATS became mandatory for apps on January 1, 2017.

The Signal messaging application employs forward secrecy in its protocol, notably differentiating it from messaging protocols based on PGP.

See also

 Forward anonymity
 Diffie–Hellman key exchange
 Elliptic curve Diffie–Hellman

References

External links 
  IETF, H. Orman. The OAKLEY Key Determination Protocol
 Forward-secure-survey An overview
 Perfect Forward Secrecy can block the NSA from secure web pages, but no one uses it Computerworld June 21, 2013
 SSL: Intercepted today, decrypted tomorrow Netcraft June 25, 2013
 Deploying Forward Secrecy SSL Labs June 25, 2013
 SSL Labs test for web browsers
 SSL Labs test for web servers

Key management
Public-key cryptography
Transport Layer Security