Let's talk about perfect forward secrecy

Perfect forward secrecy (PFS) is a security feature that comes up fairly regularly in debates about privacy, but historically it gets little discussion. At least, far less discussion than what are perceived as "core" features of a cryptosystem like key strength, message verification, or the web of trust. But that disparity is in part the result of a perception that PFS guards against some unlikely attack scenarios, such as a well-funded adversary capturing months or years' worth of traffic. Thanks to the recent revelations of bulk NSA surveillance, however, those scenarios suddenly seem a lot less unlikely to a lot of users, so PFS is attracting considerable attention.

The basic definition of forward secrecy is that compromising one encrypted conversation does not enable an attacker to then compromise any subsequent conversations. The simplest negative example would be using the same key to encrypt every session: if the key is discovered, the attacker can decrypt the current session and every session that follows. The fact that said attacker can also decrypt older sessions has not traditionally been a been part of the discussion (although it is true), probably because of the unlikelihood that most attackers would have been capturing sessions all along to begin with. After all, old SSL connection traffic is not recorded on servers at your favorite online shopping site—at least as far as anyone knows.

Thus, forward secrecy is a property that stems from how and when keys are generated and used, rather than from the ciphers involved. It essentially means that encryption keys must be ephemeral. Note that OpenPGP, for example, does not have forward secrecy, since its key pairs are by definition long-term assets. If a user's private key becomes public knowledge, the key can no longer be trusted by the user for future encryption and must be replaced, but all old messages encrypted with it are suddenly vulnerable to decryption, too.

There is a bit less agreement on what perfect forward secrecy means above and beyond mere forward secrecy (if indeed there is such a distinction), but the term PFS is typically used to indicate stronger guarantees against the domino-like compromise of one session from another. For example, if a long-term key is used to algorithmically derive a new ephemeral key for each session, some would argue that the forward secrecy is not "perfect." In such a scenario, if a session's ephemeral key was captured, no other sessions could be decrypted with it, but if the long-term key was captured, deriving the session keys—for multiple sessions—might be possible. Which key-derivation schemes and key-exchange protocols are perfect enough to count as PFS varies somewhat in the reading material. In common usage, however, the distinction rarely even comes into play, probably because so few encryption implementations in the wild offer forward secrecy at all.

PFS is a tad peculiar in at least one sense: it describes a property of a particular session that only provides protection to other sessions. That is, the presence or absence of PFS only comes into play when at least one private conversation has been decrypted (or one secret key can been captured). Perhaps it is no wonder, then, that it would remain an afterthought to hardening the rest of the system.

Present perfect

In practice, whether or not any given Internet connection has PFS depends on several factors. First and foremost is the availability of a key-exchange protocol that has PFS, but second is the practical question of whether the two parties in the conversation can agree on a PFS key exchange. That, of course, depends on things outside of the individual's control, such as the configuration of the remote web server.

The Diffie–Hellman key exchange protocol can offer PFS if it generates a new key (by using a new set of parameters) for every session. This is the default behavior, and the great majority of implementations use ephemeral parameters, but for clarity it is common to refer to this behavior as "ephemeral Diffie–Hellman" (EDH or DHE), just to be on the safe side.

PGP-style encryption, as it was noted above, does not offer PFS. But SSH does, since SSH session keys are ephemeral and are exchanged between hosts using DHE. Similarly, the Off-the-Record Messaging (OTR) protocol for instant messages uses DHE for key exchange, so it too offers PFS (in addition to several other privacy and security features). IPSec supports PFS as an option; when enabled, a new DHE key exchange is performed for each new session. But as a percentage of total Internet connections, all of these protocols account for but a fraction when compared to SSL/TLS, which is where the practical problem lies.

The SSL/TLS protocol supports a wide array of "cipher suites." Each cipher suite is a specific combination of a key-exchange algorithm, encryption algorithm, message authentication code, and pseudorandom function. In the handshake step of connection establishment, the client (e.g., web browser) and server each have their own cipher suite preferences; the client presents its list to the server, which is supposed to choose the top option that is supported by both.

DHE and its variant Elliptic Curve DHE (ECDHE) are two of the available options for key exchange, so users would be wise to place them at the top of their cipher-suite preferences. However, the majority of public web servers does not support DHE or ECDHE, so in practice most HTTPS connections are established without PFS. In June 2013, Netcraft published a look at PFS on the web, noting that of the eight most popular web service providers mentioned in the NSA surveillance scandal (Facebook, Twitter, Yahoo, Google, Microsoft, AOL, Apple, and Paltalk), only Google's servers negotiated for a PFS cipher suite during connection.

Most of the remaining web servers simply use public-key encryption to protect connection setup instead, with the client encrypting its part of the handshake with the server's public SSL certificate. The curious can investigate any server's configuration with SSL Labs's server test tool. While the RSA algorithm used for certificates has proven itself quite resistant to attack, to many it is not sufficient for NSA-proofing an SSL/TLS connection. A government agency could obtain the server's private key (i.e., the secret key which complements the SSL certificate that clients use to encrypt those initial messages to the server) with a court order or warrant, at which point any captured SSL/TLS connection from the server could be decrypted.

Naturally, an attacker in possession of the private key corresponding to the server's public SSL certificate can also do plenty of other bad things like man-in-the-middle attacks, so to some, worrying about PFS may sound like small potatoes. On the other hand, for many web users, government surveillance amounts to a different—not a lesser—threat. Strong cryptography might be the best safeguard against thieves and scammers, but PFS is the medicine prescribed for state-supported spying.

Forward progress

The good news is that all of the major free software browsers support PFS cipher suites for SSL/TLS, as do the free software web server projects. Among the servers, nginx is configured to prefer PFS cipher suites by default, and configuring the others to negotiate for it is a relatively simple affair.

Of course, Google only switched over to the PFS-enabled cipher suites on its web servers in 2011; any traffic captured before that could still (at least in theory) be decrypted if the right keys were found.

Looking forward, the NSA surveillance revelations have prompted a renewed interest in PFS, so there are a lot of discussions on Stack Exchange and similar forums about how to configure web servers to prefer PFS. The tide may indeed be changing, but some server administrators may be surprised to discover the costs associated with ephemeral key generation. Prior to the NSA story, there were several popular blog posts on the overhead that enabling DHE and ECDHE for SSL/TLS would impose on a web server. In 2011, for example, Vincent Bernat estimated DHE at a 300% performance hit, but ECDHE at only a 15–27% increase.

Whether such an increase in CPU cycles (and, potentially, hosting costs) is worth it is a question only the server owner can answer. As CPUs get faster over time, of course, the bottom-line calculations could change. But PFS is meant to protect the participants in a conversation for a very long time—hypothetically an attacker could store captured traffic forever. And in the very long run, the additional protections of PFS could be worth a high price indeed.