Introduction to Perfect Forward Secrecy

Background

The idea of ‘Perfect Forward Secrecy’, or sometimes simply ‘Forward Secrecy’, is that something that in encrypted and so considered ‘secret’ now, should remain encrypted and so not easier discovered in the future. If there is a means whereby the ‘secret’ can be revealed in the future, then there is no ‘forward secrecy’, meaning that while the information may be protected now, it may not be at some future point in time.

Secure online web communication is based on SSL or its more recent derivative, TLS. These are based on a mixture of Public/Private key asymmetric cryptography and symmetric key encryption. Of course with the disclosure of the POODLE SSL 3.0 vulnerability, SSL is now effectively dead and really we should get accustomed to talking about TLS, but to get back on track...

Asymmetric cryptography is a mechanism where one key is used to encrypt a message, but cannot then be used to reverse the encryption which can only be achieved by use of the other key. Typically a party keeps one key secret, the so-called private key, and makes the other key freely available, the so-called public key. This allows a message to be encrypted with the party’s public key and transmitted to the party who is then able to decrypt the message with the secret private key.

A downside to asymmetric encryption is that it is much more computing-intensive than symmetric encryption where the same key is used to both encrypt and decrypt a message, consequently in SSL and TLS, asymmetric encryption is used by the two parties – the client machine and server – to exchange and set-up how they are going to communicate with each other, part of which is the agreement over a symmetric encryption key they will use for the session that follows.

The relevance to ‘Perfect Forward Security’ (PFS) is that the above described mechanism of using asymmetric encryption to agree a symmetric encryption key which is then used for the remainder of the SSL/TLS session, is dependent entirely on the secrecy of the private key. If the private key is ever disclosed, even in the future, it is possible to go back and decrypt entire key exchange conversation and from that obtain the encryption key used for the symmetric encryption used for the remainder of the ‘secure’ session.

This holds true of every SSL/TLS session using that private key. Even though each secure session will have used a separate and quite different symmetric encryption key, they will all have agreed and set that unique key using the single private key and so possession of that single private key allows discovery of all the separate symmetric encryption keys and with them the decryption of every secure communication exchange with that server.

Perfect Forward Security is designed to overcome this inherent weakness and is so-called as it protects a secure message exchange from future disclosure by breaking of the encryption due to loss or disclosure of the private key used in the key exchange. It achieves this by extending the key exchange mechanism and using an intermediate temporary encryption to protect the exchange of the symmetric encryption key. This means a future loss or disclosure of the private key can no longer be used to decrypt the secure message, e.g. perfect forward security.

Implementation of PFS

SSL and TLS are essentially frameworks for the establishing of a secure communication channel. They do not mandate the actual encryption cipher that must be used nor the means of key exchange. These are mutually agreed between the client and the server during the initiation of each secure connection. This is how, for instance, ‘server gating’ operates where a server can mandate that only certain cipher suites may be used. The connection negotiation therefore includes an exchange of information about which cipher suites the client can support and the server then selects a preferred scheme to be used for the session. The server may also decline all offered cipher suites and in effect say; “I’m sorry, but you are not able to offer a suitably secure cipher suite for me to talk to you” – sever gating in practice.

Therefore, to implement PFS it is necessary to make suitable cipher suites available on the server receiving the connections and for the client – typically a browser – to support the matching cipher suites. Then during the connection negotiation the server can select to use a PFS cipher suite, thereby protecting that session against future decryption through a party gaining knowledge of the server’s private key.

It is the key exchange element of the cipher suite that is important to PFS as it is this element of the connection negotiation that protects the symmetric encryption key selected for use for the following secure session. PFS-compliant key exchange mechanisms that are available include:

  1. ECDHE_RSA - Ephemeral Elliptic Curve Diffie-Hellman with RSA signatures
  2. DHE_RSA - Ephemeral Diffie-Hellman with RSA signatures


For further information refer to RFC 5246 “Transport Layer Security (TLS) Protocol, Version 1.2” and RFC 4492 “Elliptic Curve Cryptography (ECC) Cipher Suites, for Transport Layer Security (TLS)”.

PFS in practice
Server overhead

The use of more advanced encryption techniques demands additional computing resource as both ECDHE_RSA and DHE_RSA place greater strain on a server supporting and using these ciphers. Of the two, ECDHE_RSA is believed to be more efficient, adding an approximate 20% overhead of SSL/TLS processing, while DHE-RSA is reported as being much less efficient.

Browser support

PFS cipher suites are being adopted by newer versions of browsers. Google’s Chrome browser is generally considered to be at the front of PFS support although current versions of Firefox, Internet Explorer, Safari and other browsers also now support PFS.

Users of Windows XP and Internet Explorer cannot use PFS or indeed most high-grade encryption ciphers, e.g. AES , due to restrictions in the Microsoft encryption libraries made available to Windows XP, however, PFS is available to Windows XP users using Google Chrome, Firefox and other modern browsers.

Adoption and usage of PFS

Google have been a major proponent of PFS and have offered PFS cipher suites on Gmail and Google Docs for some considerably time. If you therefore use these services via a current browser, you will be making use of PFS.

Twitter has also supported PFS since late 2013 as have a few other US-based services.

Cipher suites

Typical cipher suites using both high-grade encryption ciphers (AES256, AES128 and 3DES ) and also using ECDHE_RSA taken from Firefox v28 are:

Cipher suite Encryption key size Key exchange mechanism
ECDHE-RSA-AES128-GCM-SHA256 128 Bit ECDH, encryption: AES, MAC: SHA256
ECDHE-RSA-AES128-SHA 128 Bit ECDH, encryption: AES, MAC: SHA1
ECDHE-RSA-AES256-SHA 256 Bit ECDH, encryption: AES, MAC: SHA1
ECDHE-RSA-3DES-EDE-SHA 168 Bit ECDH, encryption: 3DES, MAC: SHA1
ECDHE-RSA-RC4128-SHA 128 Bit ECDH, encryption: RC4, MAC: SHA1
Table 1 – Example ECDHE_RSA high-grade encryption cipher suites