5.5: Message Confidentiality

Some applications may require message confidentiality in addition to message authentication. Two principals may want to communicate privately without adversaries having access to the communicated information. If the principals are running on a shared physical computer, this goal is easily accomplished using the kernel. For example, when sending a message to a port, it is safe to ask the kernel to copy the message to the recipient's address space, since the kernel is already trusted; the kernel can read the sender's and receiver's address space anyway.

If the principals are on different physical processors, and can communicate with each other only over an untrusted network, ensuring confidentiality of messages is more challenging. By definition, we cannot trust the untrusted network to not disclose the bits that are being communicated. The solution to this problem is to introduce encryption and decryption to allow two parties to communicate without anyone else being able to tell what is being communicated.

Message Confidentiality Using Encryption

Figure \(\PageIndex{1}\): Providing confidentiality using ENCRYPT and DECRYPT over untrusted networks.

The setup for providing confidentiality over untrusted networks is shown in Figure \(\PageIndex{1}\). Two secure areas are separated by an insecure communication path. Our goal is to provide a secure channel between the two secure areas that provides confidentiality.

Encryption transforms a plaintext message into ciphertext in such a way that an observer cannot construct the original message from the ciphertext version, yet the intended receiver can. Decryption transforms the received ciphertext into plaintext. Thus, one challenge in the implementation of channels that provide confidentiality is to use an encrypting scheme that is difficult to reverse for an adversary. That is, even if an observer could copy a message that is in transit and has an enormous amount of time and computing power available, the observer should not be able to transform the encrypted message into the plaintext message. (As with "signing", we use the term "messages" conceptually; one can also encrypt and decrypt files, email attachments, streams, or other data objects.)

The ENCRYPT and DECRYPT primitives can be implemented using cryptographic transformations. ENCRYPT and DECRYPT can use either shared-secret cryptography or public-key cryptography. We refer to the keys used for encryption as encryption keys.

With shared-secret cryptography, Alice and Bob share a key K that only they know. To keep a message M confidential, Alice computes ENCRYPT (M, K) and sends the resulting ciphertext C to Bob. If the encrypting box is good, an adversary will not to be able to get any use out of the ciphertext. Bob computes DECRYPT (C, K), which will recover the plaintext form of M . Bob can send a reply to Alice using exactly the same system with the same key. (Of course, Bob could also send the reply with a different key, as long as that different key is also shared with Alice.)

With public-key cryptography, Alice and Bob do not have to share a secret to achieve confidentiality for communication. Suppose Bob has a private and public key pair (KBpriv, KBpub), where KBpriv is Bob’s private key and KBpub is Bob’s public key. Bob gives his public key to Alice through an existing channel; this channel does not have to be secure, but it does have to provide authentication: Alice needs to know for sure that this key is really Bob’s key.

Given Bob’s public key (KBpub), Alice can compute ENCRYPT (M, KBpub) and send the encrypted message over an insecure network. Only Bob can read this message, since he is the only person who has the secret key that can decrypt her ciphertext message. Thus, using encryption, Alice can ensure that her communication with Bob stays confidential. To achieve confidential communication in the opposite direction (from Bob to Alice), we need an additional set of keys, a KApub and KApriv for Alice, and Bob needs to learn Alice's public key.

 

Properties of ENCRYPT and DECRYPT

For both the shared-key and public-key encryption systems, the procedures ENCRYPT and DECRYPT should have the following properties. It should be easy to compute:

• C ← ENCRYPT (M, K1)
• M' ← DECRYPT (C, K2)

and the result should be that M = M'.

The implementation of ENCRYPT and DECRYPT should withstand the following attacks:

1. Ciphertext-only attack. In this attack, the primary information available to the adversary is examples of ciphertext and the algorithms for ENCRYPT and DECRYPT. Redundancy or repeated patterns in the original message may show through even in the ciphertext, allowing an adversary to reconstruct the plaintext. In an open design the adversary knows the algorithms for ENCRYPT and DECRYPT , and thus the adversary may also be able to mount a brute-force attack by trying all possible keys.
   
   More precisely, when using shared-secret cryptography, the following property must hold:
       •  Given ENCRYPT and DECRYPT , and some examples of C , it should be difficult for an adversary to reconstruct K or compute M .
   
   When using public-key cryptography, the corresponding property holds:
       •  Given ENCRYPT and DECRYPT , some examples of C , and assuming an adversary knows K1(which is public), it should be difficult for the adversary to compute either the secret key K2or M .
    
2. Known-plaintext attack. The adversary has access to the ciphertext C and also to the plaintext M corresponding to at least some of the ciphertext C . For instance, a message may contain standard headers or a piece of predictable plaintext, which may help an adversary figure out the key and then recover the rest of the plaintext.
    
3. Chosen-plaintext attack. The adversary has access to ciphertext C that corresponds to plaintext M that the adversary has chosen. For instance, the adversary may convince you to send an encrypted message containing some data chosen by the adversary, with the goal of learning information about your transforming system, which may allow the adversary to more easily discover the key. As a special case, the adversary may be able in real time to choose the plaintext M based on ciphertext C just transmitted. This variant is known as an adaptive attack.
   
   A common design mistake is to unintentionally admit an adaptive attack by providing a service that happily encrypts any input it receives. This service is known as an oracle, and it may greatly simplify the effort required by an adversary to crack the cryptographic transformation. For example, consider the following adaptive chosen-plaintext attack on the encryption of packets in WiFi wireless networks. The adversary sends a carefully-crafted packet from the Internet addressed to some node on the WiFi network. The network will encrypt and broadcast that packet over the air, where the adversary can intercept the ciphertext, study it, and immediately choose more plaintext to send in another packet. Researchers used this attack as one way of breaking the design of the security of WiFi Wired Equivalent Privacy (WEP)\(^*\).
    
4. Chosen-ciphertext attack. The adversary might be able to select a ciphertext C and then observe the M' that results when the recipient decrypts C . Again, an adversary may be able to mount an adaptive chosen-ciphertext attack.

Section 5.9 describes cryptographic implementations of ENCRYPT and DECRYPT that provide protection against these attacks. A designer can increase the work factor for an adversary by increasing the key length. A typical key length used in the field is 1,024 bits. 

The window of validity of ENCRYPT and DECRYPT is the minimum of the time to compromise of the underlying cryptographic transformation, the time to try all keys, and the time to compromise the key itself. When considering what implementation of ENCRYPT and DECRYPT to use, it is important to understand the required window of validity. It is likely that the window of validity required for encrypting protocol messages between a client and a server is smaller than the window of validity required for encrypting long-term file storage. A protocol message that must be private just for the duration of a conversation might be adequately protected by an cryptographic transformation that can be compromised with, say, one year of effort. On the other hand, if the period of time for which a file must be protected is greater than the window of validity of a particular cryptographic system, the designer may have to consider additional mechanisms, such as multiple encryptions with different keys.

---

\(^*\) N. Borisov, I. Goldberg, and D. Wagner, Intercepting mobile communications: the insecurity of 802.11, MOBICOM ‘01, Rome, Italy, July 2001.

 

Achieving both Confidentiality and Authentication

Confidentiality and message authentication can be combined in several ways:

• For confidentiality only, Alice just encrypts the message.
• For authentication only, Alice just signs the message. 
• For both confidentiality and authentication, Alice first encrypts and then signs the encrypted message (i.e., SIGN (ENCRYPT (M, Kencrypt), Ksign)), or, the other way around. (If good implementations of SIGN and VERIFY are used, it doesn't matter for correctness in which order the operations are applied.)

The first option, confidentiality without authentication, is unusual. After all, what is the purpose of keeping information confidential if the receiver cannot tell if the message has been changed? Therefore, if confidentiality is required, one also provides authentication.

The second option is common. Much data is public (e.g., routing updates, stock updates, etc.), but it is important to know its origin and integrity. In fact, it is easy to argue the default should be that all messages are at least authenticated.

For the third option, the keys used for authentication and confidentiality are typically different. The sender authenticates with an authentication key, and encrypts with a encryption key. The receiver would use the appropriate corresponding keys to decrypt and to verify the received message. The reason to use different keys is that the key is a bit pattern, and using the same bit pattern as input to two cryptographic operations on the same message is risky because a clever cryptanalyst may be able to discover a way of exploiting the repetition. Section 5.9 gives an example of exploitation of repetition in an otherwise unbreakable encryption system known as the one-time pad. Problem sets 44 and 46 also explore one-time pads to setup a secure communication channel.

In addition to using the appropriate keys, there are other security hazards. For example, M should have identified explicitly the communicating parties. When Alice sends a message to Bob, she should include in the message the names of Alice and Bob to avoid impersonation attacks. Failure to follow this explicitness principle can create security problems, as we will see in Section 5.6.

 

Can Encryption be Used for Authentication?

As specified, ENCRYPT and DECRYPT don’t protect against an adversary modifying M and one must SIGN and VERIFY for integrity. With some implementations, however, a recipient of an encrypted message can be confident not only of its confidentiality, but also of its authenticity. From this observation arose the misleading intuition that decrypting a message and finding something recognizable inside is an effective way of establishing the authenticity of that message. The intuition is based on the claim that if only the sender is able to encrypt the message, and the message contains at least one component that the recipient expected the sender to include, then the sender must have been the source of the message.

The problem with this intuition is that as a general rule, the claim is wrong. It depends on using a cryptographic system that links all of the ciphertext of the message in such a way that it cannot be sliced apart and re-spliced, perhaps with components from other messages between the same two parties and using the same cryptographic key. As a result, it is non-trivial to establish that a system based on the claim is secure even in the cases in which it is. Many protocols that have been published and later found to be defective were designed using that incorrect intuition. Those protocols using this approach that are secure require much effort to establish the necessary conditions, and it is remarkably hard to make a compelling argument that they are secure; the argument typically depends on the exact order of fields in messages, combined with some particular properties of the underlying cryptographic operations.

Therefore, in this book we treat message confidentiality and authenticity as two separate goals that are implemented independently of each other. Although both confidentiality and authenticity rely in their implementation on cryptography, they use the cryptographic operations in different ways. As explained in Section 5.9, the shared-secret AES cryptographic transformation, for example, isn't by itself suitable for either signing or encrypting; it needs to be surrounded by various cipher-feedback mechanisms, and the mechanisms that are good for encrypting are generally somewhat different from those that are good for signing. Similarly, when RSA, a public-key cryptographic transformation, is used for signing, it is usually preceded by hashing the message to be signed, rather than applying RSA directly to the message; a failure to hash can lead to a security blunder.

A relatively recent paper\(^*\) on the topic on the order of authentication and encrypting suggests that first encrypting and then computing an authentication tag may cover up certain weaknesses in some implementations of the encrypting primitives. Also, cryptographic transformations have been proposed that perform the transformation for encrypting and computing an authentication tag in a single pass over the message, saving time compared to first encrypting and then computing an authentication tag. Cryptography is a developing area, and the last word on this topic has not been said; interested readers should check out the proceedings of the conferences on cryptography. For the rest of the book, however, the reader can think of message authentication and confidentiality as two separate, orthogonal concepts.

---

\(^*\) Hugo Krawczyk, The Order of Encryption and Authentication for Protecting Communications (or: How Secure is SSL?), Advances in Cryptology (Springer LNCS 2139), 2001, pages 310–331.