Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.78 MB, 385 trang )
communicating with. Analyzing these sorts of external information is called
Also recall that the encryption modes in this chapter are only designed to
provide conﬁdentiality against eavesdroppers; they do not stop the attacker
from changing the data. We will come back to protecting both conﬁdentiality
and authenticity in Chapter 7.
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 ﬁrst 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 speciﬁcations
decrypt both sides
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.
analysis can provide very useful information to an attacker. Preventing trafﬁc analysis is
possible, but generally too expensive in terms of bandwidth for anyone but the military.
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.
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 ﬁrst 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 ﬁnding one is small, he has to repeat
this whole job for about 248 different keys. The total amount of work before he
actual number of blocks you can encrypt before you expect the ﬁrst 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.
ﬁnds 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 insigniﬁcant 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.
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 difﬁcult. It is a
complication, but a justiﬁable one.
About Our Math
Readers with a mathematical background may be horriﬁed 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 ﬁgure out the exact results for themselves, but
we prefer the rougher approximations for their simplicity.
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 satisﬁes 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 ﬁxed 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.
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 ?
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.
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 .
A hash function is a function that takes as input an arbitrarily long string of bits
(or bytes) and produces a ﬁxed-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 ﬁngerprint. 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
speciﬁc 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
you have a variable-sized value, you can use a hash function to map it to a
ﬁxed-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.
Security of Hash Functions
As we mentioned above, a hash function maps an input m to a ﬁxed-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 ﬁnd 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
inﬁnite number of these collisions. (There are an inﬁnite number of possible
input values, and only a ﬁnite 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 deﬁnition 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 deﬁnitions
globally throughout this book.)
Deﬁnition 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 deﬁnition of the ideal block cipher (Section 3.3), this is an incomplete
deﬁnition. 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 deﬁnition is good enough.
We can now deﬁne what an attack on a hash function is.
Deﬁnition 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 ﬁnd a pre-image (given
x, ﬁnd an m with h(m) = x), or to ﬁnd 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 efﬁcient than a generic attack that yields
similar results. We know this is not an exact deﬁnition, but—as with block
ciphers—we don’t have an exact deﬁnition. 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 speciﬁcs 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 speciﬁed. We
can imagine a 512-bit hash function that speciﬁes a security level of 128 bits.
In that case, distinguishers are limited to 2128 steps.
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