7: Which Mode Should I Use?

72



Part II



■



Message Security



communicating with. Analyzing these sorts of external information is called

traffic analysis.1

Also recall that the encryption modes in this chapter are only designed to

provide confidentiality against eavesdroppers; they do not stop the attacker

from changing the data. We will come back to protecting both confidentiality

and authenticity in Chapter 7.



4.8



Information Leakage



We now come to the dark secret of block cipher modes. All block cipher modes

leak some information.

For this discussion, we will assume that we have a perfect block cipher. But

even with a perfect block cipher, the ciphertexts that the encryption modes

produce reveal information about the plaintexts. This has to do with equalities

and inequalities of ciphertext and plaintext blocks.

Let’s start with ECB. If two plaintext blocks are equal (Pi = Pj ), then the

two ciphertext blocks are equal, too (Ci = Cj ). For random plaintexts, this will

happen very rarely, but most plaintext is not random but highly structured.

Thus, equal plaintext blocks occur far more frequently than random, and the

equal ciphertext blocks reveal this structure. That is why we dismissed ECB.

What about CBC mode? Equal plaintext blocks do not lead to equal

ciphertext blocks, as each plaintext block is first xored with the previous

ciphertext block before it is encrypted. Think of all the ciphertext blocks as

random values; after all, they were produced by a block cipher that produces

a random output for any given input. But what if we have two ciphertext

blocks that are equal? We have

Ci = Cj

E(K, Pi ⊕ Ci−1 ) = E(K, Pj ⊕ Cj−1 )

Pi ⊕ Ci−1 = Pj ⊕ Cj−1

Pi ⊕ Pj = Ci−1 ⊕ Cj−1



from the CBC specifications

decrypt both sides

basic algebra



The last equation gives the difference between two plaintext blocks as the xor

of two ciphertext blocks, which we assume the attacker knows. This is certainly

not something you would expect from a perfect message encryption system.

And if the plaintext is something with a lot of redundancy, such as plain English

text, it probably contains enough information to recover both plaintext blocks.

A similar situation occurs when two ciphertexts are unequal. Knowing that

Ci = Cj implies that Pi ⊕ Pj = Ci−1 ⊕ Cj−1 , so each unequal pair of ciphertexts

leads to an inequality formula between the plaintext blocks.

1 Traffic



analysis can provide very useful information to an attacker. Preventing traffic analysis is

possible, but generally too expensive in terms of bandwidth for anyone but the military.



Chapter 4



■



Block Cipher Modes



CTR has similar properties. With this encryption mode we know that

the Ki blocks are all different, because they are encryptions of a nonce and

counter value. All the plaintext values of the encryption are different, so all

the ciphertext values (which form the key blocks) are different. Given two

ciphertexts Ci and Cj , you know that Pi ⊕ Pj = Ci ⊕ Cj because otherwise the

two key stream blocks would have had to be equal. In other words, CTR mode

provides a plaintext inequality for each pair of ciphertext blocks.

There are no problems with collisions in CTR. Two key blocks are never

equal, and equal plaintext blocks or equal ciphertext blocks lead to nothing.

The only thing that makes CTR deviate from the absolute ideal stream cipher

is the absence of key block collisions.

OFB is worse than either CBC or CTR. As long as there are no collisions on

the key stream blocks, OFB leaks the same amount of information as CTR. But

if there is ever a collision of two key stream blocks, then all subsequent key

stream blocks also produce a collision. This is a disaster from a security point

of view, and one reason why CTR is preferable to OFB.



4.8.1



Chances of a Collision



So what are the chances that two ciphertext blocks are equal? Let’s say we

encrypt M blocks in total. It doesn’t matter whether this is done in a few large

messages, or in a large number of small messages. All that counts is the total

number of blocks. A good rough estimate is that there are M(M − 1)/2 pairs of

blocks, and each pair has a chance of 2−n of being equal, where n is the block

size of the block cipher. So the expected number of equal ciphertext blocks is

M(M − 1)/2n+1 , which gets close to unity when M ≈ 2n/2 . In other words, when

you encrypt about 2n/2 blocks, you can expect to get two ciphertext blocks that

are equal.2 With a block size of n = 128 bits, we can expect the first duplicate

ciphertext block value after about 264 blocks. This is the birthday paradox we

explained in Section 2.7.1. Now, 264 blocks is a lot of data, but don’t forget that

we are designing systems with a lifetime of 30 years. Maybe people will want

to process something close to 264 blocks of data in the future.

Smaller data sets are also at risk. If we process 240 blocks (about 16 TB of

data) then there is a 2−48 chance of having a ciphertext block collision. That

is a really small probability. But look at it from the attacker’s point of view.

For a particular key that is being used, he collects 240 blocks and checks for

duplicate blocks. Because the chance of finding one is small, he has to repeat

this whole job for about 248 different keys. The total amount of work before he

2 The



actual number of blocks you can encrypt before you expect the first duplicate is closer to

√

π 2n−1 = 2n/2 π/2, but the theory behind the analysis is much harder and we don’t need that

level of precision here.

√



73



74



Part II



■



Message Security



finds a collision is 240 · 248 = 288 , which is much less than our design strength

of 128 bits.

Let’s concentrate on CBC and CTR. In CTR you get a plaintext inequality

for every pair of blocks. In CBC you get an inequality if the two ciphertext

blocks are unequal, and an equality if the blocks are equal. Obviously an

equality provides much more information about the plaintext to the attacker

than an inequality does, so CTR leaks less information.



4.8.2 How to Deal With Leakage

So how do we achieve our goal of a 128-bit security level? Basically, we don’t,

but we get as close as we can. There is no easy way of achieving a 128-bit

security level with a block cipher whose block size is 128 bits. This is why we

want to have block ciphers with 256-bit blocks, but there are no widely studied

proposals of such a block cipher out there, so that is a dead end. What we can

do is get close to our design security level, and limit the damage.

CTR leaks very little data. Suppose we encrypt 264 blocks of data and

produce a ciphertext C. For any possible plaintext P that is 264 blocks long, the

attacker can compute the key stream that would have to be used for this P to

be encrypted to C. There is roughly a 50% chance that the resulting key stream

will contain a collision. We know that CTR mode never produces collisions,

so if a collision occurs, that particular plaintext P can be ruled out. This means

that the attacker can rule out approximately half of all possible plaintexts.

This corresponds to leaking a single bit of information to the attacker. Even

revealing a single bit of information can sometimes be problematic. But leaking

a single bit of information for 264 blocks is not much. If we restrict ourselves to

encrypting only 248 blocks, then the attacker can rule out approximately 2−32 of

all plaintexts, which is even less information. In a practical setting, such a small

leakage is insignificant when taken in the context of the attack requirements.

So although CTR encryption is not perfect, we can limit the damage to an

extremely small leak by not encrypting too much information with a single

key. It would be reasonable to limit the cipher mode to 260 blocks, which allows

you to encrypt 264 bytes but restricts the leakage to a small fraction of a bit.

When using CBC mode you should be a bit more restrictive. If a collision

occurs in CBC mode, you leak 128 bits of information about the plaintext. It

is a good policy to keep the probability of such a collision low. We suggest

limiting CBC encryption to 232 blocks or so. That leaves a residual risk of 2−64

that you will leak 128 bits, which is probably harmless for most applications,

but certainly far from our desired security level.

Just a reminder; these limits are on the total amount of information encrypted

using a single key. It does not matter whether the data is encrypted in one

very large message, or as a large number of smaller messages.



Chapter 4



■



Block Cipher Modes



This is not a satisfactory state of affairs, but it is the situation we face.

The best you can do at this point is use CTR or CBC and limit the amount of

data you process with any one key. We will talk later about key negotiation

protocols. It is quite easy to set up a fresh key when the old key is nearing its

usage limit. Assuming you already use a key negotiation protocol to set up

the encryption key, having to refresh a key is not particularly difficult. It is a

complication, but a justifiable one.



4.8.3



About Our Math



Readers with a mathematical background may be horrified at our blithe use

of probabilities without checking whether the probabilities are independent.

They are right, of course, when arguing from a purely mathematical standpoint.

But just like physicists, cryptographers use math in a way that they have

found useful. Cryptographic values typically behave very randomly. After all,

cryptographers go to great length to absolutely destroy all patterns, as any

pattern leads to an attack. Experience shows that this style of dealing with

probabilities leads to quite accurate results. Mathematicians are welcome to

work through the details and figure out the exact results for themselves, but

we prefer the rougher approximations for their simplicity.



4.9



Exercises



Exercise 4.1 Let P be a plaintext and let (P) be the length of P in bytes. Let b

be the block size of the block cipher in bytes. Explain why the following is not

a good padding scheme: Determine the minimum number of padding bytes

necessary in order to pad the plaintext to a block boundary. This is a number n

which satisfies 0 ≤ n ≤ b − 1 and n + (P) is a multiple of b. Pad the plaintext

by appending n bytes, each with value n.

Exercise 4.2 Compare the security and performance advantages and disadvantages of each variant of CBC mode covered in this chapter: a fixed IV, a

counter IV, a random IV, and a nonce-generated IV.

Exercise 4.3 Suppose you, as an attacker, observe the following 32-byte

ciphertext C (in hex)

46 64 DC 06 97 BB FE 69 33 07 15 07 9B A6 C2 3D

2B 84 DE 4F 90 8D 7D 34 AA CE 96 8B 64 F3 DF 75



and the following 32-byte ciphertext C (also in hex)

51 7E CC 05 C3 BD EA 3B 33 57 0E 1B D8 97 D5 30

7B D0 91 6B 8D 82 6B 35 B7 8B BB 8D 74 E2 C7 3B.



75



76



Part II



■



Message Security



Suppose you know these ciphertexts were generated using CTR mode with

the same nonce. The nonce is implicit, so it is not included in the ciphertext.

You also know that the plaintext P corresponding to C is

43 72 79 70 74 6F 67 72 61 70 68 79 20 43 72 79

70 74 6F 67 72 61 70 68 79 20 43 72 79 70 74 6F.



What information, if any, can you infer about the plaintext P corresponding

to C ?

Exercise 4.4



The ciphertext (in hex)

87 F3 48 FF 79 B8 11 AF 38 57 D6 71 8E 5F 0F 91

7C 3D 26 F7 73 77 63 5A 5E 43 E9 B5 CC 5D 05 92

6E 26 FF C5 22 0D C7 D4 05 F1 70 86 70 E6 E0 17



was generated with the 256-bit AES key (also in hex)

80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01



using CBC mode with a random IV. The IV is included at the beginning of

the ciphertext. Decrypt this ciphertext. You may use an existing cryptography

library for this exercise.

Exercise 4.5



Encrypt the plaintext

62 6C 6F 63 6B 20 63 69 70 68 65 72 73 20 20 20

68 61 73 68 20 66 75 6E 63 74 69 6F 6E 73 20 78

62 6C 6F 63 6B 20 63 69 70 68 65 72 73 20 20 20



using AES in ECB mode and the key

80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01.



You may use an existing cryptography library for this exercise.

Exercise 4.6 Let P1 , P2 be a message that is two blocks long, and let P1 be

a message that is one block long. Let C0 , C1 , C2 be the encryption of P1 , P2

using CBC mode with a random IV and a random key, and let C0 , C1 be the

encryption of P1 using CBC mode with a random IV and the same key. Suppose

an attacker knows P1 , P2 and suppose the attacker intercepted and thus know

C0 , C1 , C2 and C0 , C1 . Further suppose that, by random chance, C1 = C2 . Show

that the attacker can compute P1 .



CHAPTER



5



Hash Functions



A hash function is a function that takes as input an arbitrarily long string of bits

(or bytes) and produces a fixed-size result. A typical use of a hash function

is digital signatures. Given a message m, you could sign the message itself.

However, the public-key operations of most digital signature schemes are

fairly expensive in computational terms. So instead of signing m itself, you

apply a hash function h and sign h(m) instead. The result of h is typically

between 128 and 1024 bits, compared to multiple thousands or millions of bits

for the message m itself. Signing h(m) is therefore much faster than signing m

directly. For this construction to be secure, it must be infeasible to construct

two messages m1 and m2 that hash to the same value. We’ll discuss the details

of the security properties of hash functions below.

Hash functions are sometimes called message digest functions, and the hash

result is also known as the digest, or the fingerprint. We prefer the more common

name hash function, as hash functions have many other uses besides digesting

messages. We must warn you about one possible confusion: the term ‘‘hash

function’’ is also used for the mapping function used in accessing hash tables,

a data structure used in many algorithms. These so-called hash functions

have similar properties to cryptographic hash functions, but there is a huge

difference between the two. The hash functions we use in cryptography have

specific security properties. The hash-table mapping-function has far weaker

requirements. Be careful not to confuse the two. When we talk about hash

functions in this book, we always mean cryptographic hash functions.

Hash functions have many applications in cryptography. They make a great

glue between different parts of a cryptographic system. Many times when

77



78



Part II



■



Message Security



you have a variable-sized value, you can use a hash function to map it to a

fixed-size value. Hash functions can be used in cryptographic pseudorandom

number generators to generate several keys from a single shared secret. And

they have a one-way property that isolates different parts of a system, ensuring

that even if an attacker learns one value, she doesn’t learn the others.

Even though hash functions are used in almost every system, we as a

community currently know less about hash functions than we do about block

ciphers. Until recently, much less research had been done on hash functions

than block ciphers, and there were not very many practical proposals to choose

from. This situation is changing. NIST is now in the process of selecting a new

hash function standard, to be called SHA-3. The SHA-3 hash function selection

process is proving to be very similar to the process that selected the AES as

the new block cipher standard.



5.1



Security of Hash Functions



As we mentioned above, a hash function maps an input m to a fixed-size

output h(m). Typical output sizes are 128–1024 bits. There might be a limit

on the input length, but for all practical purposes the input can be arbitrarily

long. There are several requirements for a hash function. The simplest one is

that it must be a one-way function: given a message m it is easy to compute

h(m), but given a value x it is not possible to find an m such that h(m) = x. In

other words, a one-way function is a function that can be computed but that

cannot be inverted—hence its name.

Of the many properties that a good hash function should have, the one that

is mentioned most often is collision resistance. A collision is two different inputs

m1 and m2 for which h(m1 ) = h(m2 ). Of course, every hash function has an

infinite number of these collisions. (There are an infinite number of possible

input values, and only a finite number of possible output values.) Thus, a hash

function is never collision-free. The collision-resistance requirement merely

states that, although collisions exist, they cannot be found.

Collision resistance is the property that makes hash functions suitable for

use in signature schemes. However, there are collision-resistant hash functions

that are utterly unsuitable for many other applications, such as key derivation,

one-way functions, etc. In practice, cryptographic designers expect a hash

function to be a random mapping. Therefore, we require that a hash function

be indistinguishable from a random mapping. Any other definition leads to

a situation in which the designer can no longer treat the hash function as

an idealized black box, but instead has to consider how the hash function

properties interact with the system around it. (We number our definitions

globally throughout this book.)



Chapter 5



■



Hash Functions



Definition 4 The ideal hash function behaves like a random mapping from all

possible input values to the set of all possible output values.

Like our definition of the ideal block cipher (Section 3.3), this is an incomplete

definition. Strictly speaking, there is no such thing as a random mapping; you

can only talk about a probability distribution over all possible mappings.

However, for our purposes this definition is good enough.

We can now define what an attack on a hash function is.

Definition 5 An attack on a hash function is a non-generic method of distinguishing

the hash function from an ideal hash function.

Here the ideal hash function must obviously have the same output size as the

hash function we are attacking. As with the block ciphers, the ‘‘non-generic’’

requirement takes care of all the generic attacks. Our remarks about generic

attacks on block ciphers carry over to this situation. For example, if an attack

could be used to distinguish between two ideal hash functions, then it doesn’t

exploit any property of the hash function itself and it is a generic attack.

The one remaining question is how much work the distinguisher is allowed

to perform. Unlike the block cipher, the hash function has no key, and there is

no generic attack like the exhaustive key search. The one interesting parameter

is the size of the output. One generic attack on a hash function is the birthday

attack, which generates collisions. For a hash function with an n-bit output,

this requires about 2n/2 steps. But collisions are only relevant for certain uses

of hash functions. In other situations, the goal is to find a pre-image (given

x, find an m with h(m) = x), or to find some kind of structure in the hash

outputs. The generic pre-image attack requires about 2n steps. We’re not going

to discuss at length here which attacks are relevant and how much work would

be reasonable for the distinguisher to use for a particular style of attack. To be

sensible, a distinguisher has to be more efficient than a generic attack that yields

similar results. We know this is not an exact definition, but—as with block

ciphers—we don’t have an exact definition. If somebody claims an attack,

simply ask yourself if you could get a similar or better result from a generic

attack that does not rely on the specifics of the hash function. If the answer is

yes, the distinguisher is useless. If the answer is no, the distinguisher is real.

As with block ciphers, we allow a reduced security level if it is specified. We

can imagine a 512-bit hash function that specifies a security level of 128 bits.

In that case, distinguishers are limited to 2128 steps.



5.2



Real Hash Functions



There are very few good hash functions out there. At this moment, you are

pretty much stuck with the existing SHA family: SHA-1, SHA-224, SHA256, SHA-384, and SHA-512. There are other published proposals, including



79