5.4 Selecting a Cipher Mode
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.
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. CWC offers similar properties and is not restricted by
patents.
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:
5.4.4 See Also
 |
