Sounds great, right? But what if the process of exchanging key-related information isn\u2019t secure and the server\u2019s private key or the secret shared session key becomes compromised? Then you\u2019ll find out just how quickly things can go wrong and how past session data relying on even one of a compromised key can become exposed.<\/p>\n\n\n\n
This article will explore perfect forward secrecy to understand what it is and why it\u2019s critical to data security on the internet.<\/p>\n\n\n\n
What Is Perfect Forward Secrecy?<\/h2>\n\n\n\n
Generally speaking, perfect forward secrecy, or PFS, is the \u201csecret sauce\u201d that prevents all the encrypted data you\u2019ve sent previously via encrypted sessions from being decrypted by bad guys, even if your server\u2019s private cryptographic key gets compromised in the future.<\/p>\n\n\n\n
If you\u2019re raising a quizzical eyebrow, give us a moment to explain. When you connect to a secure website, you\u2019re connecting via a secure session that requires the use of cryptographic keys that, if not stored securely, can fall into the wrong hands. Perfect forward secrecy is about preventing data shared via secure (encrypted) connections from becoming exposed due to key compromise issues by<\/p>\n\n\n\n
- \n
- Using a new private key each session, and<\/li>\n\n\n\n
- Not allowing session keys to be stored for future use.<\/li>\n<\/ul>\n\n\n\n
In a more technical sense, perfect forward secrecy is a set of key agreement protocols designed to keep your session keys \u2014 i.e., the keys you use to transmit data to a website\u2019s server in a typical website connection \u2014 secure, even if the server\u2019s private key becomes compromised. It does this by making session keys one-time use tools, much like how medical providers use hypodermic needles and medical gloves once and then dispose of them.<\/p>\n\n\n\n
To understand perfect forward secrecy more fully, you have at least a basic understanding of encryption. So, let\u2019s detour briefly to quickly recap what encryption is and circle back by talking about how PFS plays a role in internet security.<\/p>\n\n\n\n
An Overview of Encryption and PFS\u2019s Role In Creating Secure, Encrypted Sessions<\/h3>\n\n\n\n
In general, encryption is the process of taking plaintext, readable data and converting it into something that can only be read by someone who has a specific key. Encryption is considered a two-way process because encrypted data is designed to be decrypted using the appropriate private key:<\/p>\n\n\n\n
- \n
- Asymmetric encryption<\/strong><\/a>.<\/strong> In this method of encryption, there are two keys that split those duties \u2014 a public key that encrypts it and a private key that decrypts it. This combination of keys is used to create a secure channel through which important key-related values are shared between parties. This data is used to create a symmetrically encrypted session that will be used for the rest of the connection to exchange data with less computational overhead.<\/li>\n\n\n\n
- Symmetric encryption<\/strong><\/a>.<\/strong> In this type of encrypted connection, there\u2019s one key that encrypts and decrypts data. In this case, this is the secure session key that\u2019s generated by both parties using their private keys in combination with publicly shared values they exchange through the SSL\/TLS handshake process, which we\u2019ll explain in just a moment.<\/li>\n<\/ul>\n\n\n\n
What happens when that secure session key becomes compromised? Nothing good, we assure you. But we\u2019ll speak more to that in a bit. But first, let\u2019s consider your website as an example.<\/p>\n\n\n\n
When a customer connects to your website, their browser and your web server engage in a TLS handshake. This is a process that enables their client to verify your server\u2019s identity, protect data integrity, and create a secure session that protects data confidentiality. (It\u2019s also what enables them to use the secure HTTPS protocol and makes the little padlock icon appear in their browser\u2019s address bar.)<\/p>\n\n\n\n
But what does this process look like? When a customer connects to your website via a TLS handshake:<\/p>\n\n\n\n
- \n
- Their client and your server use asymmetric encryption to exchange cipher information and special values that can be used to create a symmetric session key.<\/li>\n\n\n\n
- The client uses your web server\u2019s public key to encrypt its value so that no one (aside from your server) can read it.<\/li>\n\n\n\n
- Your server then uses that data, along with special parameters, to create that secret session key to enables it to establish a secure session with the customer\u2019s client. This symmetrically encrypted connection is what will be used for the rest of the session.<\/li>\n<\/ul>\n\n\n\n
Perfect Forward Secrecy Is Mandated in TLS 1.3<\/h2>\n\n\n\n
Traditionally (up through TLS 1.2), a server used RSA or traditional Diffie-Hellman key exchange functions:<\/p>\n\n\n\n
- \n
- RSA key exchanges involve sharing key-related data is transmitted between parties.<\/li>\n\n\n\n
- Diffie-Hellman key exchanges involve both parties exchanging public values (non-sensitive data) they combine with their individual secret values to generate a single key.<\/li>\n<\/ul>\n\n\n\n
These traditional key exchange scenarios involved using the server\u2019s key to protect the secure session key values it would share. This was great so long as the server\u2019s private key didn\u2019t become compromised. If that key were to become compromised, then the attacker could use it to decrypt any data they\u2019ve saved that was encrypted using the key\u2019s corresponding public counterpart.<\/p>\n\n\n\n
To avoid this from happening in TLS 1.3<\/a>, the Internet Engineering Task Force (IETF) mandated the use of ephemeral<\/em> (i.e., dynamic and unique) key values as part of the SSL\/TLS handshake. This entails using the elliptic curve Diffie-Hellman ephemeral (ECDHE) key exchange instead of the traditional, non-ephemeral DH. This way, every secure session that\u2019s created using an SSL\/TLS handshake has its own set of parameters (rules) that create the session.<\/p>\n\n\n\n
According to the IETF<\/a>:<\/p>\n\n\n\n
\n
\u201cIn contrast to TLS 1.2, TLS 1.3 provides additional privacy for data exchanges by encrypting more of the negotiation handshake to protect it from eavesdroppers. This enhancement helps protect the identities of the participants and impede traffic analysis. TLS 1.3 also enables forward secrecy by default which means that the compromise of long term secrets used in the protocol does not allow the decryption of data communicated while those long term secrets were in use. As a result, current communications will remain secure even if future communications are compromised.\u201d<\/em><\/p>\n<\/blockquote>\n\n\n\n
In a static key exchange, such as a traditional Diffie-Hellman key exchange, one or both of those parameters can be reused. But despite what any earth-saving activists say, not everything should be recycled. (At least, this is true when it comes to public key cryptography). For example, in a Diffie-Hellman ephemeral, or DHE, key agreement, those parameters have to change to create each new session and can\u2019t be reused. This changing of the values every session enables perfect forward secrecy, meaning that every session is independent of those that precede and follow them.<\/p>\n\n\n\n
This brings us to our next related talking point\u2026<\/p>\n\n\n\n
Forward Secrecy vs Perfect Forward Secrecy \u2014 Believe It Or Not, They\u2019re Not the Same<\/h3>\n\n\n\n
It\u2019s likely, at some point, you\u2019ve come across the term forward secrecy<\/em>. When you look at the words perfect forward secrecy<\/em> and forward secrecy<\/em>, and organizations often use the terms synonymously, it\u2019s easy to think they\u2019re the same. (Look at the IETF quote above for such an example.)<\/p>\n\n\n\n
However, there is actually an important difference between these two terms:<\/p>\n\n\n\n
- \n
- Forward secrecy<\/strong> is something that is enabled simply by using a traditional (non-ephemeral) Diffie-Hellman key exchange. This entails two parties connecting using a mutually calculated secret key that\u2019s never exchanged directly. However, both parties will use that same shared key for future sessions.<\/li>\n\n\n\n
- Perfect forward secrecy<\/strong> is something you\u2019ll need to take things a step further to achieve. This will require using an ephemeral<\/em> cryptographic key, such as through an ephemeral Diffie-Hellman key agreement. What this means is that each new session will require a unique key, regardless of whether it\u2019s two new parties or two parties that have connected previously.<\/li>\n<\/ul>\n\n\n\n
Let\u2019s consider these two concepts using the following illustrations:<\/p>\n\n\n\n
![\"A](\"https:\/\/sectigostore.com\/blog\/wp-content\/uploads\/2023\/03\/perfect-forward-secrecy-vs-forward-secrecy.png\")
<\/figure>\n\n\n\nImage caption: A set of basic graphics that illustrate the difference between forward secrecy and perfect forward secrecy.<\/em><\/p>\n\n\n\n
How Perfect Forward Secrecy Works<\/h2>\n\n\n\n
At its core, perfect forward secrecy is what results when you use a unique encryption\/decryption key for every SSL\/TLS session. The way to achieve PFC is to use ephemeral Diffie-Hellman or elliptic curve ephemeral Diffie-Hellman key exchanges as part of the SSL\/TLS handshake.<\/p>\n\n\n\n
Why Perfect Forward Secrecy Is Necessary<\/h2>\n\n\n\n
On its own, forward secrecy would be fine in a perfect world \u2014 a magical place where every person, company, and organization adheres to secure key management best practices. But since this is the real world and they often don\u2019t \u2014 and since cybercriminals are always looking for ways to get their hands on everyone\u2019s private keys to decrypt data they\u2019ve saved from previous sessions they intercepted \u2014 then it means that the server\u2019s private key could become compromised down the road.<\/p>\n\n\n\n
This is why ephemeral Diffie-Hellman key exchanges are mandated in TLS 1.3; they ensure that new Diffie-Hellman key exchange parameters are utilized for each session. This way, bad guys who\u2019ve been saving up encrypted data from your sessions won\u2019t be able to decrypt it later because the key will be destroyed after use and will not be stored on the server. It mitigates the potential damages and data exposure you\u2019d otherwise sustain if you used the same session key for each user to secure their subsequent connections.<\/p>\n\n\n\n
Cipher Suites That Support Perfect Forward Secrecy<\/h2>\n\n\n\n
Now that we know what perfect forward secrecy is, what it does, and why it\u2019s necessary, let\u2019s take a look at the cryptographic cipher suites<\/a> (i.e., combinations of cryptographic algorithms) that make it possible. To do this, we\u2019ll compare it to TLS 1.2 cipher suites so we can see the differences between them.<\/p>\n\n\n\n
TLS 1.2 Cipher Suites<\/h3>\n\n\n\n
According to NIST\u2019s special publication 800-52 revision 2<\/a>, TLS 1.2 cipher suites are combinations of protocols and algorithms for key exchanges, encryption, and message authentication. For example, a TLS 1.2 cipher suite looks something like this:<\/p>\n\n\n\n
Protocol_KeyExchangeAlgorithm_WITH_EncryptionAlgorithm_MessageAuthenticationAlgorithm <\/em> <\/p>\n\n\n\n
In all, there are 37 cipher suites supported by TLS 1.2.<\/a> However, supporting all of them isn\u2019t necessarily advisable because some of them don\u2019t support PFS. Here\u2019s a quick visual of how one of these cipher suites look:<\/p>\n\n\n\n
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<\/p>\n\n\n\n
TLS 1.3 Cipher Suites<\/h3>\n\n\n\n
Now, let\u2019s compare this to a TLS 1.3 cipher suite, which discards the key exchange algorithm and uses this format instead:<\/p>\n\n\n\n
Protocol_AHEADcipherMode_HashCipher<\/em><\/p>\n\n\n\n
In that previously linked resource, NIST recommends only four cipher suites that TLS 1.3 servers should be configured to support:<\/p>\n\n\n\n
- \n
- TLS_AES_128_GCM_SHA256<\/li>\n\n\n\n
- TLS_AES_256_GCM_SHA384<\/li>\n\n\n\n
- TLS_AES_128_CCM_SHA256<\/li>\n\n\n\n
- TLS_AES_128_CCM_8_SHA256<\/li>\n<\/ol>\n\n\n\n
- Perfect forward secrecy<\/strong> is something you\u2019ll need to take things a step further to achieve. This will require using an ephemeral<\/em> cryptographic key, such as through an ephemeral Diffie-Hellman key agreement. What this means is that each new session will require a unique key, regardless of whether it\u2019s two new parties or two parties that have connected previously.<\/li>\n<\/ul>\n\n\n\n
- Forward secrecy<\/strong> is something that is enabled simply by using a traditional (non-ephemeral) Diffie-Hellman key exchange. This entails two parties connecting using a mutually calculated secret key that\u2019s never exchanged directly. However, both parties will use that same shared key for future sessions.<\/li>\n\n\n\n
- Symmetric encryption<\/strong><\/a>.<\/strong> In this type of encrypted connection, there\u2019s one key that encrypts and decrypts data. In this case, this is the secure session key that\u2019s generated by both parties using their private keys in combination with publicly shared values they exchange through the SSL\/TLS handshake process, which we\u2019ll explain in just a moment.<\/li>\n<\/ul>\n\n\n\n
- Asymmetric encryption<\/strong><\/a>.<\/strong> In this method of encryption, there are two keys that split those duties \u2014 a public key that encrypts it and a private key that decrypts it. This combination of keys is used to create a secure channel through which important key-related values are shared between parties. This data is used to create a symmetrically encrypted session that will be used for the rest of the connection to exchange data with less computational overhead.<\/li>\n\n\n\n