Let’s say you had an encrypted conversation with Bob yesterday. Today Bob accidentally posts his secret key on the internet. You still want your conversation to be private, right? So what can you do? You can use a cryptographic protocol with perfect forward secrecy (PFS). That will protect you against similar blunders by your conversation partners and even your own blunders of this type. Sounds pretty desirable, right?
Since the Snowden leaks, we know for sure that a variety of state run intelligence services record your communication – some of them with the explicit intent to decrypt it later when possible. And with many protocols you just need to break one key to be able to decipher many messages. PFS also protects against that: you usually need to break every single message individually.
So both blunder, as well as outright malice, pose a sizeable threat, which therefore we need to consider when designing our threat models.
WHAT is PFS?
PFS is a property of key exchange algorithms. An algorithm is said to have perfect forward secrecy, when even with the knowledge of all persistent secrets and all communication, the communication cannot be decrypted.
Many protocols first agree on a transient session key and then use that session key for a common symmetric cipher, which is used to encrypt the conversation. For example, with classic hybrid encrytion the session key is selected by one party alone and then encrypted via an asymmetric cipher. But if the private key is leaked or the cipher is broken, the messages where that asymmetric key was used can be decrypted. There are ways to agree on the session key whereby one party alone cannot accidentally make it possible to decrypt the conversation at any point in the future*. This is PFS.
A short note on what I mean by a “persistent secret”: I would consider an asymmetric secret key persistent. The session key I would consider transient. The secret numbers of the Diffie-Hellman-key-exchange should be transient too, but you need to generate fresh ones for every session.
Some more examples: If the secret numbers of a Diffie-Hellman key exchange get computed or leaked, only this specific session key (and all messages of that session) can be decrypted. Another example would be that, if the Diffie-Hellman key exchange in principle is broken, then it may still technically have PFS, whilst not really protecting your past/present/future communication anymore.
* This assumes both parties have implemented the algorithm correctly. Especially important is deleting the session key, so it cannot be leaked at a later point in time. This also assumes that the ciphers involved stay secure.
Protocols & Algorithms with PFS
Let’s quickly have a look at a few protocols / applications, some of which you may have heard of:
| Protocol / Application | Uses Algorithm with PFS? |
| SSH | depends on configuration |
| Off the Record Messaging | yes |
| Double Ratchet (Signal’s messaging protocol & encrypted Matrix 1-1 chat) | yes |
| Megolm Group Ratchet (encrypted Matrix group chats) | not – but partial forward secrecy |
| TLS 1.2 (and older) | depends on configuration |
| TLS 1.3 | yes |
| WPA 2 & 3 Enterprise | depends on configuration |
| WPA 3 Personal | yes |
| IPSec / IKE | depends on configuration |
| PGP | no |
| S/MIME | no |
| KIM (EMails within the german health system) | no (due to use of S/MIME) |
| TIM (Messenger within the german health system) | yes for 1-1 chats (due to Olm/Megolm) |
E-Mail protocols seem to be behind on this technology. This is due to tough challenges in asynchronous communication with PFS. Signal has solved those rather well for 1-1* chats, using its ratcheting mechanism. Notably, Threema also just recently started supporting PFS (it’s a mildly popular messaging app from Switzerland).
* I’m not sure if Signal group chats have PFS.
The problem is with all the protocols where it “depends on configuration”. A close look reveals that these protocols are the ones most often used in large organizations. This is no accident and there are mainly two reasons:
- backwards compatibility with older clients
- current algorithms with PFS are more costly
The cost argument, in my opinion, is not as strong anymore as it used to be, because of today’s noise generators. It is also vastly outweighed by the security gain. This opinion is also reflected in TLS 1.3 dropping support for the non ephemeral DH modes (more on that below).
All these protocols get the PFS property due to usage of some key exchange algorithm. Let’s have a look at key exchange algorithms:
| Algorithm | Has PFS? |
| Asymmetric Encryption | no |
| DH (Diffie Hellman Key Exchange) | no |
| ECDH (Elliptic Curve Diffie Hellman Key Exchange) | no |
| DHE (Diffie Hellman Ephemeral Key Exchange) | yes |
| ECDHE (Elliptic Curve Diffie Hellman Ephemeral Key Exchange) | yes |
| QKD (Quantum Key Distribution) | yes |
| OPAQUE | yes |
| SPEKE | yes |
| Dragonfly* | yes |
Asymmetric encryption as used in hybrid encryption is the traditional “problem” case, along with pre-shared session keys (which are problematic due to being persistent).
The Diffie-Hellman key exchange revolutionised the way we communicate. But it only has PFS when you use ephemeral secrets, meaning you generate a new secret every single session. This is very important. Just as in the TLS standard, I have listed the use of ephemeral secrets as separate algorithms here. DHE and ECDHE are the most well known key exchange algorithms with PFS.
SPEKE and Dragonfly* are worth mentioning due to their use in WPA3.
OPAQUE is interesting because it can safely use a password for mutual authentication. This authentication comes without the heavy weight of a PKI.
Last, but not least, the quantum key exchange, while currently not as widespread due to the required infrastructure and additional hardware, is still an interesting contender.
* It is noteworthy here that Dragonfly is at least controversial, if not insecure. I would recommend not using it, whenever you have the choice.
Practical Recommendations
When using any cryptographic protocol, have a short look at if and how it performs key exchange. Have a look at the configuration and the defaults. DHE, for example, is susceptible to the logjam attack which needs countering by using a large group (2048bit a least). That group should be a group not used by others (i.e. you need to generate it yourself). But generally DHE is weak, when compared to good ECDHE groups, because of logjam.
With TLS, make sure to drop support for all non-ECDHE/DHE cipher suites as much as you can. Or just drop support for versions older than version 1.3 if you can.
For SSH I have yet to see a version that supports a non-PFS algorithm, but I think in theory it is or used to be possible to break PFS by using a bad algorithm. You can check which algorithms are available on your system by running “ssh -Q kex” (note that there may be many different ECDHE curves* available).
One last thing, which I will not go deeper into in this post, but want to mention now: Correct configuration of (EC)DHE is also important. By choosing a weak underlying group, breaking it can become easy (the above mentioned logjam attack is such an example). And since you may not trust certain organizations specifying these groups, both SSH and TLS support a variety of groups*, so you can select one that you trust. The most notable curves are the Curves suggested by the US american NIST in the DSS standard. The German IT security bureau “BSI” (alongside others) suggests the Brainpool Curves of RFC5639, but software support varies for these curves.
* Elliptic Curves are also groups. Groups is the more general term. In case of non-elliptic-curve cryptography, the group is usually defined by the Diffie-Hellman parameters.