5.4.1 Problem You need to use a low-level interface to encryption. You have chosen a block cipher and need to select the mode in which to use that cipher. 5.4.2 Solution There are various tradeoffs. For general-purpose use, we recommend CWC mode in conjunction with AES, as we discuss in the following section. If you wish to do your own message authentication, we recommend CTR mode, as long as you're careful with it. 5.4.3 Discussion First, we should emphasize that you should use a low-level mode only if it is absolutely necessary, because of the ease with which accidental security vulnerabilities can arise. For general-purpose use, we recommend a high-level abstraction, such as that discussed in Recipe 5.16. With that out of the way, we'll note that each cipher mode has its advantages and drawbacks. Certain drawbacks are common to all of the popular cipher modes and should usually be solved at another layer. In particular: If a network attack destroys or modifies data in transit, any cipher mode that does not perform integrity checking will, if the attacker does his job properly, fail to detect an error. The modes we discuss that provide built-in integrity checking are CWC, CCM, and OCB. When an attacker does tamper with a data stream by adding or truncating, most modes will be completely unable to recover. In some limited circumstances, CFB mode can recover, but this problem is nonetheless better solved at the protocol layer. Especially when padding is not necessary, the ciphertext length gives away information about the length of the original message, which can occasionally be useful to an attacker. This is a covert channel, but one that most people choose to ignore. If you wish to eliminate risks with regard to this problem, pad to a large length, even if padding is not needed. To get rid of the risk completely, send fixed-size messages at regular intervals, whether or not there is "real" data to send. Bogus messages to eliminate covert channels are called cover traffic. Block ciphers leak information about the key as they get used. Some block cipher modes leak a lot more information than others. In particular, CBC mode leaks a lot more information than something like CTR mode.
 | If you do not use a cipher mode that provides built-in integrity checking, be sure to use a MAC (message authentication code) whenever encrypting. |
|
In the following sections, we'll go over the important properties of each of the most popular modes, pointing out the tradeoffs involved with each (we'll avoid discussing the details of the modes here; we'll do that in later recipes). Note that if a problem is listed for only a single cipher mode and goes unmentioned elsewhere, it is not a problem for those other modes. For each of the modes we discuss, speed is not a significant concern; the only thing that has a significant impact on performance is the underlying block cipher.[9] [9] Integrity-aware modes will necessarily be slower than raw encryption modes, but CWC and OCB are faster than combining an integrity primitive with a standard mode, and CCM is just as fast as doing so.
5.4.3.1 Electronic Code Book (ECB) mode This mode simply breaks up a message into blocks and directly encrypts each block with the raw encryption operation. It does not have any desirable security properties and should not be used under any circumstances. We cover raw encryption as a building block for building other modes, but we don't cover ECB itself because of its poor security properties. ECB has been standardized by NIST (the U.S. National Institute for Standards and Technology). The primary disadvantages of ECB mode are: Encrypting a block of a fixed value always yields the same result, making ECB mode particularly susceptible to dictionary attacks. When encrypting more than one block and sending the results over an untrusted medium, it is particularly easy to add or remove blocks without detection (that is, ECB is susceptible to tampering, capture replay, and other problems). All other cipher modes that lack integrity checking have similar problems, but ECB is particularly bad. The inputs to the block cipher are never randomized because they are always exactly equal to the corresponding block of plaintext. Offline precomputation is feasible.
The mode does have certain advantages, but do note that other modes share these advantages: Multiblock messages can be broken up, and the pieces encrypted in parallel. Random access of messages is possible; the 1,024th block can be decrypted without decrypting other data blocks.
However, the advantages of ECB do not warrant its use. We do discuss how to use ECB to encrypt a block at a time in Recipe 5.5, when it is necessary in implementing other cryptographic primitives. 5.4.3.2 Cipher Block Chaining (CBC) mode CBC mode is a simple extension to ECB mode that adds a significant amount of security. CBC works by breaking the message up into blocks, then using XOR to combine the ciphertext of the previous block with the plaintext of the current block. The result is then encrypted in ECB mode. The very first block of plaintext is XOR'd with an initialization vector (IV). The IV can be publicly known, and it must be randomly selected for maximum security. Many people use sequential IVs or even fixed IVs, but that is not at all recommended. For example, SSL has had security problems in the past when using CBC without random IVs. Also note that if there are common initial strings, CBC mode can remain susceptible to dictionary attacks if no IV or similar mechanism is used. As with ECB, padding is required, unless messages are always block-aligned. CBC has been standardized by NIST. The primary disadvantages of CBC mode are: Encryption cannot be parallelized (though decryption can be, and there are encryption workarounds that break interoperability; see Recipe 5.14). There is no possibility of offline precomputation. Capture replay of entire or partial messages can be possible without additional consideration. The mode requires an initial input that must be random. It is not sufficient to use a unique but predictable value. The mode leaks more information than is optimal. We wouldn't use it to output more than 240 blocks. The primary advantage of CBC mode is that it captures the desirable properties of ECB mode, while removing most of the drawbacks.
We discuss CBC mode in Recipe 5.6. 5.4.3.3 Counter (CTR) mode Whereas ECB and CBC are block-based modes, counter (CTR) mode and the rest of the modes described in this section simulate a stream cipher. That is, they use block-based encryption as an underlying primitive to produce a pseudo-random stream of data, known as a keystream. The plaintext is turned into ciphertext by XOR'ing it with the keystream. CTR mode generates a block's worth of keystream by encrypting a counter using ECB mode. The result of the encryption is a block of keystream. The counter is then incremented. Generally, the counter being publicly known is acceptable, though it's always better to keep it a secret if possible. The counter can start at a particular value, such as zero, or something chosen at random, and increment by one every time. (The initial counter value is a nonce, which is subtly different from an initialization vector; see Recipe 4.9.) Alternatively, the counter can be modified every time using a deterministic pseudo-random number generator that doesn't repeat until all possible values are generated. The only significant requirements are that the counter value never be repeated and that both sides of an encryption channel know the order in which to use counters. In practice, part of the counter is usually chosen randomly at keying time, and part is sequential. Both parts help thwart particular kinds of risks. Despite being over 20 years old, CTR mode has only recently been standardized by NIST as part of the AES standardization process. The primary disadvantages of CTR mode are: Flipping bits in the plaintext is very easy because flipping a ciphertext bit flips the corresponding plaintext bit (this problem is shared with all stream cipher modes). As with other encryption algorithms, message integrity checks are absolutely necessary for adequate security. Reusing {key, counter} pairs is disastrous. Generally, if there is any significant risk of reusing a {key, nonce} pair (e.g., across reboot), it is best to avoid ever reusing a single key across multiple messages (or data streams). (See Recipe 4.11 for advice if you wish to use one base secret and derive multiple secrets from it.) CTR mode has inadequate security when using ciphers with 64-bit blocks, unless you use a large random nonce and a small counter, which drastically limits the number of messages that can be sent. For this reason, OCB is probably still preferable for such ciphers, but CTR is clearly better for 128-bit block ciphers.
The primary advantages of CTR mode are: The keystream can be precomputed. The keystream computation can be done in parallel. Random access into the keystream is possible. (The 1,024th byte can be decrypted with only a single raw encryption operation.) For ciphers where raw encryption and decryption require separate algorithms (particularly AES), only a single algorithm is necessary. In such a case, the faster of the two algorithms can be used (though you will get incompatible results if you use decryption where someone else uses encryption). CTR mode leaks incredibly little information about the key. After 264 encryptions, an attacker would learn about a bit's worth of information on a 128-bit key.
CTR mode is old and simple, and its security properties are well understood. It has recently gained a lot of favor in the cryptographic community over other solutions for using block ciphers in streaming modes, particularly as the world moves to AES with its 128-bit blocks. Many of the "better" modes that provide built-in integrity checking, such as CWC and CCM mode, use CTR mode as a component because of its desirable properties. We discuss CTR mode in Recipe 5.9. 5.4.3.4 Output Feedback (OFB) mode OFB mode is another streaming mode, much like CTR mode. The keystream is generated by continually encrypting the last block of keystream to produce the next block. The first block of keystream is generated by encrypting a nonce. OFB mode shares many properties with CTR mode, although CTR mode has additional benefits. Therefore, OFB mode is seeing less and less use these days. OFB mode has been standardized by NIST. The primary disadvantages of OFB mode are: Bit-flipping attacks are easy, as with any streaming mode. Again, integrity checks are a must. Reusing a {key, none} pair is disastrous (but is easy to avoid). Generally, if there is any significant risk of reusing a {key, nonce} pair (e..g., across reboot), it is best to avoid reusing a single key across multiple messages or data streams. (See Recipe 4.11 for advice if you wish to use one base secret, and derive multiple secrets from it.) Keystream computation cannot be done in parallel.
The primary advantages of OFB mode are: Keystreams can be precomputed. For ciphers where raw encryption and decryption operations require separate algorithms (particularly AES), only a single algorithm is necessary. In such a case, the faster of the two algorithms can be used (though you will get incompatible results if you use decryption where someone else uses encryption). It does not have nonce-size problems when used with 64-bit block ciphers. When used properly, it leaks information at the same (slow) rate that CTR mode does.
We discuss OFB mode in Recipe 5.8. 5.4.3.5 Cipher Feedback (CFB) mode CFB mode generally works similarly to OFB mode, except that in its most common configuration, it produces keystream by always encrypting the last block of ciphertext, instead of the last block of keystream. CFB mode has been standardized by NIST. The primary disadvantages of CFB mode are: Bit-flipping attacks are easy, as with any streaming mode. Again, integrity checks are a must. Reusing a {key, nonce} pair is disastrous (but is easy to avoid). Generally, if there is any significant risk of reusing a {key, nonce} pair (e.g., across reboot), it is best to avoid reusing a single key across multiple messages or data streams. Encryption cannot be parallelized (though decryption can be).
The primary advantages of CFB mode are: For ciphers where raw encryption and decryption operations require separate algorithms (particularly AES), only a single algorithm is necessary. In such a case, the faster of the two algorithms can be used. A minor bit of precomputational work can be done in advance of receiving a block-sized element of data, but this is not very significant compared to CTR mode or OFB mode. It does not have nonce-size problems when used with 64-bit block ciphers.
These days, CFB mode is rarely used because CTR mode and OFB mode provide more advantages with no additional drawbacks. We discuss CFB mode in Recipe 5.7. 5.4.3.6 Carter-Wegman + CTR (CWC) mode CWC mode is a high-level encryption mode that provides both encryption and built-in message integrity, similar to CCM and OCB modes (discussed later). CWC is a new mode, introduced by Tadayoshi Kohno, John Viega, and Doug Whiting. NIST is currently considering CWC mode for standardization. The primary disadvantages of CWC are: The required nonce must never be reused (this is easy to avoid). It isn't well suited for use with 64-bit block ciphers. It does work well with AES, of course.
The primary advantages of CWC mode are: CWC ensures message integrity in addition to performing encryption. The additional functionality requires minimal message expansion. (You would need to send the same amount of data to perform integrity checking with any of the cipher modes described earlier.) CWC is parallelizable (hardware implementations can achieve speeds above 10 gigabits per second). CWC has provable security properties while using only a single block cipher key. This means that under reasonable assumptions on the underlying block cipher, the mode provides excellent secrecy and message integrity if the nonce is always unique. CWC leverages all the good properties of CTR mode, such as being able to handle messages without padding and being slow to leak information. For ciphers where raw encryption and decryption operations require separate algorithms (particularly AES), only a single algorithm is necessary. In such a case, the faster of the two algorithms can be used (though you will get incompatible results if you use decryption where someone else uses encryption).
We believe that the advantages of CWC mode make it more appealing for general-purpose use than all other modes. However, the problem of repeating nonces is a serious one that developers often get wrong. See Recipe 5.10, where we provide a high-level wrapper to CWC mode that is designed to circumvent such problems. 5.4.3.7 Offset Codebook (OCB) mode OCB mode is a patented encryption mode that you must license to use.[10] CWC offers similar properties and is not restricted by patents. [10] At least one other patent also needs to be licensed to use this mode legally.
OCB is reasonably new. It was introduced by Phil Rogaway and is based on earlier work at IBM. Both parties have patents covering this work, and a patent held by the University of Maryland also may apply. OCB is not under consideration by any standards movements. The primary disadvantages of OCB mode are: It is restricted by patents. The required nonce must never be reused (this is easy to avoid). It isn't well suited for use with 64-bit block ciphers. It does work well with AES, of course.
The primary advantages of OCB mode are: OCB ensures message integrity in addition to performing encryption. The additional functionality requires minimal message expansion (you would need to send the same amount of data to perform integrity checking with any of the previously mentioned cipher modes). OCB is fully parallelizable (hardware implementations can achieve speeds above 10 gigabits per second). OCB has provable security properties while using only a single block cipher key. This means that under reasonable assumptions on the underlying block cipher, the mode provides excellent secrecy and message integrity if the nonce is always unique. Messages can be of arbitrary length (there is no need for block alignment). For ciphers where raw encryption and decryption operations require separate algorithms (particularly AES), only a single algorithm is necessary. In such a case, the faster of the two algorithms can be used (though you will get incompatible results if you use decryption where someone else uses encryption).
Because of its patent status and the availability of free alternatives with essentially identical properties (particularly CWC mode), we recommend against using OCB mode. If you're interested in using it anyway, see Phil Rogaway's OCB page at http://www.cs.ucdavis.edu/~rogaway/ocb/. 5.4.3.8 CTR plus CBC-MAC (CCM) mode While OCB mode has appealing properties, its patent status makes it all but useless for most applications. CCM is another alternative that provides many of the same properties, without any patent encumbrance. There are some disadvantages of CCM mode, however: While encryption and decryption can be parallelized, the message integrity check cannot be. OCB and CWC both avoid this limitation. In some applications, CCM can be nonoptimal because the length of the message must be known before processing can begin. The required nonce must never be reused (this is easy to avoid). It isn't well suited to 64-bit block ciphers. It does work well with AES, of course.
CCM is also fairly new (more recent than OCB, but a bit older than CWC). It was introduced by Doug Whiting, Russ Housley, and Niels Fergusen. NIST is currently considering it for standardization. The primary advantages of CCM mode are: CCM ensures message integrity in addition to performing encryption. The message integrity functionality requires minimal message expansion (you would need to send the same amount of data to perform integrity checking with any of the previously mentioned cipher modes). CCM has provable security properties while using only a single key. This means that under reasonable assumptions on the underlying block cipher, the mode provides near-optimal secrecy and message integrity if the required nonce is always unique. CCM leverages most of the good properties of CTR mode, such as being able to handle messages without padding and being slow to leak information. For ciphers where raw encryption and decryption operations require separate algorithms (particularly AES), only a single algorithm is necessary. In such a case, the faster of the two algorithms can be used (though you will get incompatible results if you use decryption where someone else uses encryption).
In this book, we focus on CWC mode instead of CCM mode because CWC mode offers additional advantages, even though in many environments those advantages are minor. However, if you wish to use CCM mode, we recommend that you grab an off-the-shelf implementation of it because the mode is somewhat complex in comparison to standard modes. As of this writing, there are three free, publicly available implementations of CCM mode: The reference implementation: http://hifn.com/support/ccm.htm The implementation from Secure Software: http://www.securesoftware.com/ccm.php The implementation from Brian Gladman: http://fp.gladman.plus.com/AES/ccm.zip
5.4.4 See Also CCM reference implementation: http://hifn.com/support/ccm.htm CCM implementation from Secure Software: http://www.securesoftware.com/ccm.php CCM implementation from Brian Gladman: http://fp.gladman.plus.com/AES/ccm.zip CWC home page: http://www.zork.org/cwc/ OCB home page: http://www.cs.ucdavis.edu/~rogaway/ocb/ Recipe 4.9, Recipe 4.11, Recipe 5.5-Recipe 5.10, Recipe 5.14, Recipe 5.16
|
