Rolf Oppliger's eSECURITY Blog

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.

After the development and deployment of OpenPGP and S/MIME, it was commonly agreed that the secure messaging problem was solved, and that public key cryptography provides a viable solution: Digital signatures for authentication (and nonrepudiation) and digital envelopes for confidentiality protection. It was argued that the slow deployment of OpenPGP and S/MIME in the field was only due to poor usability, rather than technical inadequacy. This changed in 2004, when Nikita Borisov, Ian Goldberg, and Eric Brewer published a research paper, in which they challenged common wisdom and questioned the adequacy of existing technologies for secure messaging. In particular, they stressed the fact that these technologies do neither provide forward secrecy nor deniable authentication, and that these shortcomings limit their usefulness in the field. Note what happens if a long-term private key gets compromised. In this case, all messages that have been or will ever be enveloped with this key are compromised, as well. The respective damage in terms of confidentiality loss is as large as possible. Furthermore, many of these messages will be digitally signed, and hence carry a cryptographic proof of their origin. This, in turn, means that the originator of such a message cannot meaningfully deny having sent it. There are certainly cases, in which this undeniability does not pose any problem. But there are also cases, in which it may pose a huge problem to the originator of such a message. Think about whistle-blowers, dissidents, and political activists.

Against this background, the above-mentioned paper argued that people sometimes want to hold a casual conversation that is private, informal, and unofficial. It is like a conversation held in a backyard without witnesses. In real life, we attribute the term “off-the-record” to this type of conversation; it does neither leave traces nor records that may prove that the conversation ever took place. The term “off-the-record” can also be used in the realm of secure messaging, and hence OTR messaging refers to this type of message exchange. It is as private as possible, and it provides repudiation, meaning that it can be denied by all participants. For the reasons mentioned above, OTR messaging cannot be implemented with digital envelopes and digital signatures. Instead, technologies are needed that provide forward secrecy and deniability – or even plausible deniability. Forward secrecy is usually achieved by using ephemeral Diffie-Hellman key exchangesand it can be even further improved by restricting the lifetime of the keys in use. OTR messaging uses a Diffie-Hellman ratcheting mechanism to refresh the key as often as possible. Plausible deniability, in turn, is achieved by using MACs instead of digital signatures. Note that a MAC is symmetric in nature, meaning that a MAC can be generated and verified by either side of a communication, i.e., the sender and the recipient of a message. This, in turn, allows the originator of a message to deny having sent it. There are even some complementary techniques that can be used to further strengthen deniability.

From today’s perspective, OTR messaging has paved the way to end-to-end encrypted (E2EE) messengers that use similar techniques. Most importantly, the Signal protocol (that is also used in WhatsApp and the Facebook Messenger) combines the Diffie-Hellman ratchet with some other technologies that can be used in an asynchronous setting. Keep in mind that OTR messaging has been developed for instant messaging, where the participants need to be online. This need not be the case in an asynchronous setting, like the one used for e-mail. This complicates things a little bit, but OTR messaging is still a milestone in the development of contemporary secure and E2EE messaging solutions. It will be explained in detail in a new and upcoming book on E2EE messaging on the Internet that is scheduled for 2020.

David Wong has created an animated TLS 1.3 specification that is more readable and accessible than the purely text-based RFC 8446.

If you want to delve more deeply into the technical specificities and details of the TLS 1.2 and TLS 1.3 protocols, then you may consider downloading and analyzing two log files that have been captured with Wireshark (TLS12Handshake.pcapng for TLS 1.2 and TLS13Handshake.pcapng for TLS 1.3). You can use the files for self-study or for educational purposes.