A topic that is ultimatively important to understand the current discussions about secure and E2EE messaging is related to the different notions of secrecy. Assume some long-term keying material being compromised. What is the impact on the secrecy of the cryptographically protected (i.e., encrypted) data? Is the secrecy of the data still protected? Is there a difference for data sent in the past and data to be sent in the future? Questions like these have led to different notions of secrecy that are sometimes referred to using different (and sometimes confusing) terms.
Since the early 1990s, people have been using the term perfect forward secrecy (PFS) to refer to the property of a cryptographic system using a particular key agreement protocol that ensures that session keys don’t get compromised even if a long-term (typically private) key gets compromised. This definition is informal and not mathematically precise, but it is still intuitively clear what it means and what it is standing for. Because the word “perfect” misleads people to believe that the notion of PFS is somehow related to Claude Shannon’s notion of “perfect secrecy,” people sometimes leave aside the word “perfect” and use the term forward secrecy instead, i.e., synonynmously and interchangeably with PFS.
From a practical viewpoint, the provision of PFS or forward secrecy typically requires an ephemeral Diffie-Hellman key exchange for every session key that is required, and the long-term private key to be used only to authenticate the respective key exchange. If this (authentication) key gets compromised, then there is still no way to recompute the session key. Such a key can only get compromised while it (or any of the Diffie-Hellman parameters that have been used to generate it) is stored in memory or is in actual use. Once it is deleted, there is no way to recompute it – this, in turn, ensures PFS or forward secrecy.
Things get more involved, if one considers alternative approaches to achieve PFS or forward secrecy (than always performing an ephemeral Diffie-Hellman key exchange). Look, for example, what happens if one generates a new session key simply by hashing the old one. In this case, if a session key gets compromised, it is not possible to compute any previously used session key (because this would require to compute the inverse of the hash function in use), but it is still perfectly feasible to compute all subsequently used session keys (because the session key can simply be subjected to the hash function). Hence, this simple key update mechanism provides some sort of PFS or forward secrecy, namely the one that is backward-oriented in time: Any previously used session key remains secret, but any session key to be used in the future gets compromised trivially.
This insight has led to a more subtle use of the terms PFS and forward secrecy. In fact, the terms are still used, but they are used in the sense that the respctive key agreement protocol protects data secrecy against a key compromise that may occur in the future. In contrast, if the key agreement protocol protects data secrecy against a key compromise that may have occured in the past, then people often use the complementary terms post-compromise security (PCS) or future secrecy. The above-mentioned scheme to generate a new session key by hashing the old one provides PFS and forward secrecy in the new and narrow sense, but it does not provide PCS or future secrecy. So when discussing the level of secrecy a key agreement protocol provides, one usually has to discuss the two cases. The question to ask is what happens if some keying material gets compromised? Is the secrecy of past data still protected or not, and vice-versa, is the secrecy of future data protected or not? The first question leads to the notions of PFS and forward secrecy, whereas the second question leads to the notions of PCS and future secrecy. In the ideal case, both notions of secrecy apply.
The terminology used to refer to the notions of secrecy is summarized in Figure 1. It is confusing, because the two notions of secrecy could also be referred to as pre-compromise security and PCS (but in this case, both acronyms would be the same) or backward secrecy and future secrecy (but in this case, we would have to use the term “backward secrecy” as a synonym to “forward secrecy,” and this is not very intuitive). For lack of better terminology, we (as a sommunity) use the terms forward secrecy and PCS in most cases (these are the terms that are written in bold face in Figure 1). This terminology is neither elegant nor intuitive, but it is in line with the literature. Forward secrecy and PCS are important criteria when it comes to discussing secure and E2EE messaging on the Internet. While OpenPGP and S/MIME provide neither of the two properties, modern approaches and solutions, like OTR and Signal, typically do. In fact, the provision of forward secrecy and PCS is one of the distinguishing features of a modern and state of the art E2EE messaging protocol.