Forward secrecy is a confusing term that should be abandoned, especially the meaningless but value-loaded variant ‘perfect forward secrecy’. It is especially confusing because it is often associated with any protocol that does ephemeral DH key agreement, like TLS—even if, as in TLS<1.3 session resumption, the keys capable of decrypting transcripts of past sessions are deliberately kept around for long periods of time. Instead, you should ask: Who has the data, who has the decryption keys, and when can the decryption keys be erased?
Suppose Alice decides she wants to send a message to Bob, and types it into her laptop.
Let's look at the flow of data in email.
- Alice's laptop sends the message to Alice's MTA outgoing.oohay.com over the internet, encrypted.
- The decryption keys between Alice's laptop and Alice's MTA outgoing.oohay.com can be erased after this step, but now outgoing.oohay.com necessarily has a plaintext copy of the message.
- outgoing.oohay.com sends the message to Bob's MTA incoming.oogleborg.com over the internet, encrypted.
- The decryption keys between outgoing.oohay.com and incoming.oogleborg.com can be erased after this step, but now incoming.oogleborg.com necessarily has a plaintext copy of the message.
- A couple days later, after Bob gets back from vacation, he logs into his workstation and downloads the message from incoming.oogleborg.com over the internet, encrypted.
- The decryption keys between Bob's workstation and incoming.oogleborg.com can be erased after this step, but erasing the keys for the TLS sessions doesn't help with the plaintext copies that were left on Oohay and Oogleborg's servers!
If Alice's message is an OpenPGP-encrypted message, then you also need to answer: When does Bob erase all copies of his decryption key? If it's not before Bob's laptop is compromised, then even if Bob has deleted old email messages, an adversary can use Bob's decryption key to decrypt ciphertexts of old email messages.
In contrast, here's the flow in Signal.
- Alice's laptop encrypts the message and some ratcheting administrivia using her current key for Bob, and sends it to the Google mothership for distribution.
- The Google mothership necessarily has a ciphertext copy of the message, and needs no keys.
- Alice can now turn her ratchet and erase the key that would allow decryption of the ciphertext stored on the Google mothership.
- After this point, if Alice has followed the protocol, only Bob has the key to decrypt the ciphertext or any way to derive it.
- A couple days later, after Bob gets back from vacation, he logs into his workstation and downloads the ciphertext from the Google mothership.
- If the ratcheting administrivia shows the messages are in order, Bob can now turn his ratchet and erase the key that would allow decryption of the ciphertext stored on the Google mothership. (If the messages were delivered out of order, Bob has to hang onto the decryption key for a little longer.)
- After this point, if Alice and Bob have followed the protocol, nobody has the key to decrypt the ciphertext or any way to derive it.
If Bob decides to delete old Signal messages (e.g., with ‘disappearing messages’, which are, of course, voluntary requests for the peer to respect, and which it is good etiquette to respect), then future compromise of Bob's workstation still isn't enough to decrypt ciphertexts of old Signal messages.
Could Bob rapidly rotate his OpenPGP encryption key pairs to achieve a similar effect? Yes—if he erases them that's enough to prevent decryption of past ciphertexts. But there's no OpenPGP tooling to do this automatically, and OpenPGP is enough of a pain to deal with without rolling keys over every Thursday that approximately nobody wants to deal with it, and there's certainly nothing in the protocol to automatically roll keys over after every message while also handling reasonable out-of-order delivery.
That's because OpenPGP was—from a modern perspective with the benefit of hindsight—designed as a toy for early '90s crypto nerds to spend all their time reconfiguring their email clients to handle, mashing ‘signature’ and ‘encryption’ together like LEGO bricks, rather than a protocol to facilitate human interaction like Signal with security goals studied in the cryptography literature.
To be fair to the early PGP designers, a good deal of crucial cryptography literature was evolving concurrently with the development of PGP during the '90s—but even when confronted with basic cryptographic problems in the protocol for humans, the designers abdicated responsibility for addressing them in 2001. Despite contemporary literature on exactly how to address it, to this day OpenPGP doesn't support public-key authenticated encryption. OpenPGP didn't even achieve what has for two decades been the cryptographic standard security notion of public-key encryption until 2018 when EFAIL persuaded the OpenPGP world to begrudgingly make the MDC mandatory—a decade and a half after being alerted to problems with the MDC in 2002.