2 Introduction to

Cryptography

2.1 Introduction

The word cryptography comes from

the Greek words κρυπτο (hidden or se-
cret) and γραϕη (writing). So, cryptog-
raphy is the art of secret writing. More
generally, people think of cryptogra-
phy as the art of mangling informa-
tion into apparent unintelligibility in a
manner allowing a secret method of
unmangling. The basic service pro-
vided by cryptography is the ability to
send information between partici-
pants in a way that prevents others
from reading it. In this book, we will
concentrate on the kind of cryptogra-
phy that is based on representing in-
formation as numbers and mathemat-
ically manipulating those numbers.
This kind of cryptography can provide
other services, such as

integrity checking—reassuring the

recipient of a message that the
message has not been altered since
it was generated by a legitimate
source,
authentication—verifying
someone’s (or something’s)
identity.
There are three basic kinds of crypto-
graphic functions: hash functions, se-
cret key functions, and public key
functions. In this chapter, we’ll intro-
duce what each kind is and what it’s
useful for. In later chapters we will go
into more detail. Public key cryptogra-
phy (see §2.3 Public Key
Cryptography) involves the use of
two keys. Secret key cryptography (see
§2.2 Secret Key Cryptography) in-
volves the use of one key. Hash func-
tions (see §2.4 Hash Algorithms) in-
volve the use of zero keys! The hash
algorithms are not secret, don’t in-
volve keys, and yet they are vital to
cryptographic systems.

But back to the traditional use of cryp-

tography. A message in its original
form is known as plaintext or cleart-
ext. The mangled information is
known as ciphertext. The process for
producing ciphertext from plaintext is
known as encryption. The reverse of
encryption is called decryption.

While cryptographers invent clever

secret codes, cryptanalysts attempt to
break these codes. These two disci-
plines constantly try to keep ahead of
each other.
2.1.1 The Fundamental Tenet of
Cryptography

Ultimately, the security of cryptogra-

phy depends on what we call the

Fundamental Tenet of Cryptography

If lots of smart people have failed to

solve a problem, then it probably won’t
be solved (soon).

2.1.2 Keys

Cryptographic systems tend to involve

both an algorithm and secret informa-
tion. The secret is known as the key.
The reason for having a key in addi-
tion to an algorithm is that it is diffi-
cult to keep devising new algorithms
that will allow reversible scrambling
of information, and it is difficult to
quickly explain a newly devised algo-
rithm to the person with whom you’d
like to start communicating securely.
With a good cryptographic scheme, it
is perfectly okay to have everyone, in-
cluding the bad guys (and the cryptan-
alysts), know the algorithm, because
knowledge of the algorithm without
the key does not help unmangle the
information.

The concept of a key is analogous to

the combination of a combination
lock. Although the concept of a combi-
nation lock is well known (you dial in
the secret numbers in the correct se-
quence and the lock opens), you can’t
open a combination lock easily with-
out knowing the combination.

2.1.3 Computational Difficulty

It is important for cryptographic algo-

rithms to be reasonably efficient for
the good guys to compute. The good
guys are the ones with knowledge of
the keys.* Cryptographic algorithms
are not impossible to break without
the key. A bad guy can simply try all
possible keys until one works (this as-
sumes the bad guy will be able to rec-
ognize plausible plaintext). The secu-
rity of a cryptographic scheme de-
pends on how much work it is for the
bad guy to break it. If the best possible
scheme will take ten million years to
break using all the computers in the
world, then it can be considered rea-
sonably secure.

*We’re using the terms good guys for

the cryptographers and bad guys for
the cryptanalysts. This is a convenient
shorthand and not a moral judgment
—in any given situation, which side
you consider good or bad depends on
your point of view.

Going back to the combination lock

example, a typical combination might
consist of three numbers, each a num-
ber between 1 and 40. Let’s say it takes
ten seconds to dial in a combination.
That’s reasonably convenient for the
good guy. How much work is it for the
bad guy? There are 403 possible com-
binations, which is 64000. At ten sec-
onds per try, it would take a week to
try all combinations, though on aver-
age it would only take half that long
(even though the right number is al-
ways the last one you try!).

Often a scheme can be made more se-

cure by making the key longer. In the
combination lock analogy, making the
key longer would consist of requiring
four numbers to be dialed in. This
would make a little more work for the
good guy. It might now take thirteen
seconds to dial in the combination.
But the bad guy has forty times as
many combinations to try, at thirteen
seconds each, so it would take a year
to try all combinations. And if it took
that long, he might want to stop to eat
or sleep.

With cryptography, computers can be

used to exhaustively try keys.
Computers are a lot faster than peo-
ple, and they don’t get tired, so mil-
lions of keys can be tried per second
in software on a single computer, and
dramatically more with specialized
hardware. Also, lots of keys can be
tried in parallel if you have multiple
computers, so time can be saved by
spending money on more computers.

The cryptographic strength of a cryp-

tographic algorithm is often referred
to as the work factor required to
break it, defined as the number of op-
erations required on classical comput-
ers. People are usually vague about
what an “operation” is. An ideal en-
cryption algorithm with n-bit keys
should require a work factor of 2n to
break it. It can’t get better than that,
because a brute-force attack (where
an attacker tries all possible keys)
would be 2n. Another way of express-
ing work factor is security strength,
usually expressed as the size of key in
an ideal secret key encryption algo-
rithm (one in which there is no better
attack than brute force).

Sometimes a cryptographic algorithm

has a variable-length key. It can be
made more secure by increasing the
length of the key. Increasing the length
of the key by one bit makes the good
guy’s job just a little bit harder but
makes the bad guy’s job up to twice as
hard (because the number of possible
keys doubles). Some cryptographic al-
gorithms have a fixed-length key, but
a similar algorithm with a longer key
can be devised if necessary.

Assume a perfect algorithm, meaning

that the work for the good guys is pro-
portional to the length of the key (say
n bits), and the work for the bad guys
is exponential in the length of the key
(e.g., work factor 2n). Let’s say you
were using 128-bit keys. If computers
got twice as fast, the good guys can
use a 256-bit key and have the same
performance as before, but the bad
guys now have 2128 times as many
keys to try, and the fact that their com-
puter is also twice as fast as before
doesn’t help them much. So faster
computers mean that the computation
gap between good guys and bad guys
can be made much bigger, while
maintaining the same performance
for the good guys.

Keep in mind that breaking the cryp-

tographic scheme is often only one
way of getting what you want. For in-
stance, a bolt cutter works no matter
how many digits are in the combina-
tion. For another example, see
xkcd.com/538.

You can get further with a kind word

and a gun than you can with a kind
word alone.

—Willy Sutton, bank robber

2.1.4 To Publish or Not to Publish

It might seem as though keeping a

cryptographic algorithm secret will
enhance its security. Cryptanalysts
would not only need to break the algo-
rithm, but first figure out what the al-
gorithm is.

These days the consensus is that pub-

lishing the algorithm and having it get
as much scrutiny as possible makes it
more secure. Bad guys will probably
find out what the algorithm is eventu-
ally (through reverse engineering
whatever implementation is distrib-
uted), so it’s better to tell a lot of non-
malicious people about the algorithm
so that in case there are weaknesses, a
good guy will discover them rather
than a bad guy. A good guy who dis-
covers a weakness will want to gain
fame by letting the world know they
have found a weakness (after first
warning the developers of the system
so they can fix the problem). Making
your cryptographic algorithm publicly
known provides free consulting from
the academic community as cryptana-
lysts look for weaknesses so they can
publish papers about them. A bad guy
who discovers a weakness will exploit
it for doing bad-guy things like embez-
zling money or stealing trade secrets.

2.1.5 Earliest Encryption

We use the terms secret code and ci-

pher interchangeably to mean any
method of encrypting data. The earli-
est documented cipher is attributed to
Julius Caesar. The way the Caesar ci-
pher would work if the message were
in English is as follows. Substitute for
each letter of the message the letter
that is 3 letters later in the alphabet
(and wrap around to A from Z). Thus
an A would become a D, and so forth.
For instance, DOZEN would become
GRCHQ. Once you figure out what’s
going on, it’s very easy to read mes-
sages encrypted this way (unless, of
course, the original message was in
Latin).
A slight enhancement to the Caesar ci-
pher was distributed as a premium
with Ovaltine in the 1940s as Captain
Midnight secret decoder rings. (There
were times when this might have been
a violation of export controls for dis-
tributing cryptographic hardware!)
The variant is to pick a secret number
n between 1 and 25, instead of always
using 3. Substitute for each letter of
the message the letter that is n later
(and wrap around to A from Z, of
course). Thus, if the secret number
was 1, an A would become a B, and so
forth. For instance, HAL would be-
come IBM. If the secret number was
25, then IBM would become HAL.
Regardless of the value of n, since
there are only 26 possible values of n
to try, it is still very easy to break this
cipher if you know it’s being used and
you can recognize a message once it’s
decrypted.

The next type of cryptographic system

developed is known as a monoalpha-
betic cipher, which consists of an ar-
bitrary mapping of one letter to an-
other letter. There are 26! possible
pairings of letters, which is approxi-
mately 4×1026. [Remember, n!, which
reads “n factorial”, means n×(n–1)×(n–
2)×…×1.] This might seem secure, be-
cause to try all possibilities, if it took a
microsecond to try each one, would
take about ten trillion years. However,
by statistical analysis of language
(knowing that certain letters and let-
ter combinations are more common
than others), it turns out to be fairly
easy to break. For instance, many
daily newspapers have a daily crypto-
gram, which is a monoalphabetic ci-
pher, and can be broken by people
who enjoy that sort of thing during
their subway ride to work. An exam-
ple is

Cf lqr’xs xsnyctm n eqxxqgsy iqul qf

wdcp eqqh, erl lqrx qgt iqul!

Computers have made much more

complex cryptographic schemes both
necessary and possible. Necessary be-
cause computers can try keys at a rate
that would exhaust an army of clerks,
and possible because computers can
execute the complex algorithms
quickly and without errors.

2.1.6 One-Time Pad (OTP)

There is an easy-to-understand, fast-

to-execute, and perfectly secure en-
cryption scheme called a one-time
pad. While it is rarely practical to im-
plement, other more practical but less
secure schemes are often compared to
it. A one-time pad consists of a long
stream of random bits known to the
communicating parties but not to any-
one else. We’ll use the symbol ⊕ for
the operation XOR (bitwise exclusive
or). Encryption consists of ⊕ing the
plaintext with the random bits of a
one-time pad, and decryption consists
of ⊕ing the ciphertext with those
same random bits.

An eavesdropper who only sees the ci-

phertext sees something that is indis-
tinguishable from random numbers.
One can think of the one-time pad as
being the secret key, and while an
eavesdropper could go through all
possible keys to learn the message,
they would also see all other possible
messages of the same length and have
no way to tell which one was actually
sent. Because no amount of computa-
tion would allow an eavesdropper to
do better than guessing, the scheme is
called information-theoretically
secure.

One-time pads are generally impracti-

cal because they require the two par-
ties to agree in advance on a random
bitstream that is as long as all the mes-
sages they will ever want to send to
one another. One-time pads are inse-
cure if the same random numbers are
used to encrypt two different mes-
sages. That’s because an eavesdropper
who knows the communicating par-
ties are doing that can learn the ⊕ of
the two messages. This might not
seem like a big deal, but in practice it
can leak a lot of information. For ex-
ample, assume two images encrypted
by ⊕ing with the same one-time pad.
If the two encrypted images are ⊕’d,
you’ll get the ⊕ of the two images.
Even a human can often see what
both images are if the result is dis-
played. The more times a one-time
pad is reused, the easier it becomes to
determine what the one-time pad is.
This is why cryptographers call this
method a one-time pad, to remind peo-
ple not to use it more than once (see
Homework Problem 11).

Because it tends to be impractical for

Alice and Bob to agree upon a truly
random one-time pad with as many
bits as the total amount of information
they might want to send to each other,
some cryptographic schemes use a
fixed-length secret number as a seed
to generate a pseudorandom bit-
stream. The pseudorandom stream
generated from the seed is ⊕’d with
plaintext as a means of encrypting the
plaintext (and the same stream is ⊕’d
by the receiver to decrypt). This sort of
scheme, usually referred to as a
stream cipher, looks like a one-time
pad scheme. However, if the stream is
generated from a seed, it doesn’t have
information-theoretic security be-
cause an attacker could go through all
possible seeds to find the one that re-
sults in an intelligible message. Some
stream ciphers we discuss in the book
include RC4 (§3.8), and CTR mode
(§4.2.3).

2.2 Secret Key Cryptography

Secret key cryptography involves the

use of a single key. Given a message
(the plaintext) and the key, encryption
produces unintelligible data (called an
IRS Publication—no! no! that was just
a finger slip, we meant to say cipher-
text), which is about the same length
as the plaintext was. Decryption is the
reverse of encryption, and uses the
same key as encryption.

Secret key cryptography is sometimes

referred to as conventional cryptog-
raphy or symmetric cryptography.
The Captain Midnight code and the
monoalphabetic cipher are both ex-
amples of secret key algorithms,
though both are easy to break. In this
chapter we describe the functionality
of cryptographic algorithms, but not
the details of particular algorithms. In
Chapter 3 we describe the details of
some popular secret key crypto-
graphic algorithms. The next few sec-
tions describe the types of things one
might do with secret key
cryptography.

2.2.1 Transmitting Over an Insecure

Channel

It is often impossible to prevent eaves-

dropping when transmitting informa-
tion. For instance, a telephone conver-
sation can be tapped, a letter can be
intercepted, and a message transmit-
ted on the Internet can be observed by
routers along the path.
If you and I agree on a shared secret
(a key), then by using secret key cryp-
tography we can send messages to one
another on a medium that can be
tapped, without worrying about
eavesdroppers. All we need to do is
have the sender encrypt the messages
and the receiver decrypt them using
the shared secret. An eavesdropper
will only see unintelligible data. This
is the classic use of secret key
cryptography.

2.2.2 Secure Storage on Insecure

Media

Since it is difficult to assume any

stored data can be kept from prying
eyes, it is best to store it encrypted.
This must be done carefully, because
forgetting the key makes the data
irretrievable.

2.2.3 Authentication

In spy movies, when two agents who

don’t know each other must ren-
dezvous, they are each given a pass-
word or pass phrase that they can use
to recognize one another. For exam-
ple, Alice’s secret phrase might be
“The moon is bright tonight.” Bob’s re-
sponse might be “Not as bright as the
sun.” If Alice were not talking to the
real Bob, she will have divulged the
secret phrase to the imposter. Even if
she is talking to Bob, she may have
also divulged the secret phrase to an
eavesdropper.
The term strong authentication
means that someone can prove knowl-
edge of a secret without revealing it.
Strong authentication is possible with
cryptography. Strong authentication is
particularly useful when two comput-
ers are trying to communicate over an
insecure network (since few people
can execute cryptographic algorithms
in their heads). Suppose Alice wants to
make sure she is talking to Bob, and
they share a key KAB. Alice picks a ran-
dom number rA, encrypts it with KAB,
and sends that to Bob. The quantity
{rA}KAB is known as a challenge. Bob
decrypts the challenge and sends rA to
Alice. This is known as Bob’s response
to the challenge {rA}KAB. Alice knows
that she is speaking to someone who
knows KAB because the response
matches rA. See Figure 2-1.

Figure 2-1. Challenge–Response Authentication

with Shared Secret

If someone, say, Fred, were imperson-

ating Alice, he could get Bob to de-
crypt a value for him (though Fred
wouldn’t be able to tell if the person
he was talking to was really Bob be-
cause Fred doesn’t know KAB), but
Bob’s response to Fred’s challenge
would not be useful later in imperson-
ating Bob to the real Alice because the
real Alice would pick a different
challenge.
Note that in this particular protocol,
there is the opportunity for Fred to ob-
tain some ⟨chosen ciphertext, plain-
text⟩ pairs, since he can claim to be
Alice and ask Bob to decrypt a chal-
lenge for him. For this reason, it is es-
sential that challenges be chosen from
a large enough space, say 264 values,
so that there is no significant chance
of using the same challenge twice. We
discuss all sorts of authentication
tricks and pitfalls in Chapter 11
Communication Session
Establishment.

2.2.4 Integrity Check

Another use of secret key cryptogra-

phy is to generate a fixed-length cryp-
tographic checksum associated with a
message.

What is a checksum? An ordinary

(noncryptographic) checksum protects
against accidental corruption of a
message. The original derivation of
the term checksum comes from the op-
eration of breaking a message into
fixed-length blocks (for instance, 32-
bit words) and adding them up. The
sum is sent along with the message.
The receiver similarly breaks up the
message, repeats the addition, and
checks the sum. If the message had
been garbled en route, the sum will
hopefully not match the sum sent and
the message will be rejected.
Unfortunately, if there were two or
more errors in the transmission that
canceled each other, the error would
not be detected. It turns out this is not
terribly unlikely, given that if flaky
hardware flips a bit somewhere, it is
likely to flip another somewhere else.
To protect against such “regular”
flaws in hardware, more complex
checksums called cyclic redundancy
checks (CRCs) were devised. But these
still only protect against faulty hard-
ware and not an intelligent attacker.
Since CRC algorithms are published,
an attacker who wanted to change a
message could do so, compute the CRC
on the new message, and send that
along.

To provide protection against mali-

cious changes to a message, a secret
integrity check algorithm is required,
i.e., an attacker that does not know the
algorithm should not be able to com-
pute the correct integrity check for a
message. As with encryption algo-
rithms, it’s better to have a common
(known) algorithm and a secret key.
This is what a cryptographic check-
sum does. Given a key and a message,
the algorithm produces a fixed-length
message authentication code (MAC)
that can be sent with the message.
MACs used to be called MICs (mes-
sage integrity codes) in some older
standards, but the term MAC seems to
have become more popular.

If anyone were to modify the message

without knowing the key, they would
have to guess a MAC, and the chance
of picking a correct MAC depends on
the length of the MAC. A typical MAC
is at least 48 bits long, so the chance of
getting away with a forged message is
only one in 280 trillion.

Such message authentication codes

have been in use to protect the integ-
rity of large interbank electronic
funds transfers for quite some time.
The messages are not kept secret from
an eavesdropper, but the integrity
check assures that only someone with
knowledge of the key could have cre-
ated or modified the message.

2.3 Public Key Cryptography

Public key cryptography is sometimes

also referred to as asymmetric cryp-
tography. The first publication to
present the concept of public key
cryptography was in 1975 [DIFF76b],
though it is now known that scientists
from GCHQ, the British equivalent to
the U.S. NSA, had discovered this tech-
nology a few years earlier. Clifford
Cocks is now known to have invented
the RSA technology in 1973, and
Malcom J. Williamson invented the
Diffie-Hellman technology in 1974.

Unlike secret key cryptography, each

individual has two keys: a private key
that should only be known to the key
owner, and a public key that can
safely be told to the entire world. The
keys are related to each other, in that
Alice’s public key could be used so that
anyone with knowledge of her public
key can encrypt something for Alice,
and only Alice, knowing her private
key, will be able to decrypt it. There
are other uses as we will describe.

Note that we call the private key a pri-

vate key and not a secret key. This con-
vention is an attempt to make it clear
in any context whether public key
cryptography or secret key cryptogra-
phy is being used. Some people use
the term secret key for the private key
in public key cryptography or use the
term private key for the secret key in
secret key technology. We hope to con-
vince people to use the term secret key
only as the single secret number used
in secret key cryptography. The term
private key should refer to the key in
public key cryptography that must not
be made public.

Unfortunately, both words public and

private begin with p. We will some-
times want a single letter to refer to
one of the keys. The letter p won’t do.
We will use the letter e to refer to the
public key, since the public key is used
when encrypting a message. We’ll use
the letter d to refer to the private key,
because the private key is used to de-
crypt a message.

There is an additional thing one can

do with public key technology, which
is to generate a digital signature on a
message. A digital signature is a
number associated with a message,
like a checksum or the MAC described
in §2.2.4 Integrity Check. However,
unlike a checksum, which can be gen-
erated by anyone, a digital signature
can only be generated by someone
knowing the private key. A public key
signature differs from a secret key
MAC because verification of a MAC re-
quires knowledge of the same secret
as was used to create it. Therefore,
anyone who can verify a MAC can also
generate one, and so be able to substi-
tute a different message and corre-
sponding MAC.

In contrast, verification of the signa-

ture only requires knowledge of the
public key. So Alice can sign a message
by generating a signature that only
she can generate (using her private
key). Other people can verify that it is
Alice’s signature (because they know
her public key) but cannot forge her
signature. This is called a signature
because it shares with handwritten
signatures the property that it is possi-
ble to recognize a signature as authen-
tic without being able to forge it.

Public key cryptography can do any-

thing secret key cryptography can do,
but to give the same security level, the
known public key cryptographic algo-
rithms are orders of magnitude
slower than the best known secret key
cryptographic algorithms. So public
key algorithms are usually used in
combination with secret key algo-
rithms. Public key cryptography is
very useful because network security
based on public key technology tends
to be more easily configurable. Public
key cryptography might be used in the
beginning of communication for au-
thentication and to establish a tempo-
rary shared secret key, then the secret
key is used to encrypt the remainder
of the conversation using secret key
technology.

For instance, suppose Alice wants to

talk to Bob. A typical technique is that
Alice uses Bob’s public key to encrypt
a secret key, then uses that secret key
to encrypt whatever else she wants to
send to Bob. Since the secret key is
much smaller than the message, using
the slow public key cryptography to
encrypt the secret key is not that
much of a performance hit. Notice
that given this protocol, Bob does not
know that it was Alice who sent the
message. This could be fixed by hav-
ing Alice digitally sign the encrypted
secret key using her private key.

Now we’ll describe the types of things

one might do with public key
cryptography.
2.3.1 Transmitting Over an Insecure
Channel

Suppose Alice’s ⟨public key, private

key⟩ pair is ⟨eA, dA⟩. Suppose Bob’s key
pair is ⟨eB, dB⟩. Assume Alice knows
Bob’s public key, and Bob knows
Alice’s public key, and they each know
their own private key. Actually, accu-
rately learning other people’s public
keys is one of the biggest challenges in
using public key cryptography and
will be discussed in detail in §10.4
PKI. But for now, don’t worry about it.

2.3.2 Secure Storage on Insecure

Media

For performance reasons, you would

encrypt the data with a secret key, but
then you can encrypt the secret key
with the public key of whoever is au-
thorized to read the data, and include
that with the encrypted data. An ad-
vantage of public key cryptography is
that Alice can encrypt something for
Bob without knowing his decryption
key. If there are multiple authorized
readers, Alice can encrypt the secret
key with each of the authorized read-
ers, and include those encrypted
quantities as well, with the encrypted
data.

2.3.3 Authentication

With secret key cryptography, if Alice

and Bob want to communicate, they
have to share a secret. If Bob wants to
be able to prove his identity to lots of
entities, then with secret key technol-
ogy he will need to remember lots of
secret keys, one for each entity to
which he would like to prove his iden-
tity. Possibly he could use the same
shared secret with Alice as with Carol,
but that has the disadvantage that
then Carol and Alice could imperson-
ate Bob to each other.

Public key technology is much more

convenient. Bob only needs to remem-
ber a single secret, his own private
key. It is true that if Bob wants to be
able to verify the identity of thou-
sands of entities, then he will need to
know (or be able to obtain when nec-
essary) thousands of public keys. In
§10.4 PKI we discuss how this might
be done.

Here’s an example of how Alice can

use public key cryptography for veri-
fying Bob’s identity (assuming Alice
knows Bob’s public key). Alice chooses
a random number r, encrypts it using
Bob’s public key eB, and sends the re-
sult to Bob. Bob proves he knows dB
by decrypting the message and send-
ing r back to Alice.

2.3.4 Digital Signatures

Forged in USA

engraved on a screwdriver claiming to

be of brand Craftsman™

It is often useful to prove that a mes-

sage was generated by a particular in-
dividual. This is easy with public key
technology. Bob’s signature for a mes-
sage m can only be generated by
someone with knowledge of Bob’s pri-
vate key. And the signature depends
on the contents of m. If m is modified
in any way, the signature no longer
matches. So digital signatures provide
two important functions. They prove
who generated the information (in
this case, Bob), and they prove that the
information has not been modified (by
anyone other than Bob) since the mes-
sage and matching signature were
generated.

Digital signatures offer an important

advantage over secret key–based cryp-
tographic MACs—non-repudiation.
Suppose Bob sells widgets and Alice
routinely buys them. Alice and Bob
might agree that, rather than placing
orders through the mail with signed
purchase orders, Alice will send elec-
tronic mail messages to order widgets.
To protect against someone forging or-
ders and causing Bob to manufacture
more widgets than Alice actually
needs, Alice will include an integrity
check on her messages. This could be
either a secret key–based MAC or a
public key–based signature. But sup-
pose sometime after Alice places a big
order, she changes her mind (the bot-
tom fell out of the widget market).
Since there’s a big penalty for cancel-
ing an order, she doesn’t confess that
she’s canceling, but instead denies
that she ever placed the order. Bob
sues. If Alice authenticated the mes-
sage by computing a MAC based on a
key she shares with Bob, then Bob
knows Alice did place the order. That
is because nobody other than Bob and
Alice knows that key, so if Bob knows
he didn’t create the message, he
knows it must have been Alice. But he
can’t prove it to anyone! Since he
knows the same secret key that Alice
used to sign the order, he could have
forged the signature on the message
himself, and he can’t prove to the
judge that he didn’t! If it were a public
key signature, he could show the
signed message to the judge and the
judge could verify that it was signed
with Alice’s key. Alice could still claim,
of course, that someone had stolen
and misused her key (it might even be
true!), but the contract between Alice
and Bob could reasonably hold her re-
sponsible for damages caused by her
inadequately protecting her key.
Unlike secret key cryptography, where
the keys are shared, you can always
tell who’s responsible for a signature
generated with a private key.

2.4 Hash Algorithms

Hash algorithms are also known as

message digest algorithms. A crypto-
graphic hash function is a mathemati-
cal transformation that inputs a mes-
sage of arbitrary length (transformed
into a string of bits) and outputs a
fixed-length (short) number. We’ll call
the hash of a message m, hash(m). It
has the following properties:

For any message m, it is relatively

easy to compute hash(m). This just
means that in order to be practical
it can’t take a lot of processing time
to compute the hash.
Given a hash value h, it is computa-
tionally infeasible to find an m that
hashes to h.
Even though many different values
of m will hash to the same value
(because m is of arbitrary length,
and hash(m) is fixed length), it is
computationally infeasible to find
two messages that hash to the
same thing.

We’ll give examples of secure hash

functions in Chapter 5 Cryptographic
Hashes.
2.4.1 Password Hashing

When a user types a password, the

system has to be able to determine
whether the user got it right. If the
system stores the passwords unen-
crypted, then anyone with access to
the system storage or backup tapes
can steal the passwords. Luckily, it is
not necessary for the system to know
a password in order to verify its cor-
rectness. Instead of storing the pass-
word, the system can store a hash of
the password. When a password is
supplied, the system computes the
password’s hash and compares it with
the stored value. If they match, the
password is deemed correct. If the
hashed password file is obtained by
an attacker, it is not immediately use-
ful because the passwords can’t be de-
rived from the hashes.

Historically, some systems made the

password file publicly readable, an ex-
pression of confidence in the security
of the hash. Even if there are no cryp-
tographic flaws in the hash, it is possi-
ble to guess passwords and hash them
to see if they match. If a user is care-
less and chooses a password that is
guessable (say, a word that would ap-
pear in a 50000-word dictionary of po-
tential passwords), an exhaustive
search would “crack” the password
even if the encryption were sound.
For this reason, many systems hide
the hashed password list (and those
that don’t, should).
2.4.2 Message Integrity

Cryptographic hash functions can be

used to generate a MAC to protect the
integrity of messages transmitted over
insecure media in much the same way
as secret key cryptography.

If we merely sent the message and

used the hash of the message as a
MAC, this would not be secure, since
the hash function is well-known. The
bad guy can modify the message, com-
pute a new hash for the new message,
and transmit that.

However, if Alice and Bob have

agreed on a secret, Alice can use a
hash to generate a MAC for a message
to Bob by taking the message, concate-
nating the secret, and computing the
hash of message|secret. This is called
a keyed hash. Alice then sends the
hash and the message (without the se-
cret) to Bob. Bob concatenates the se-
cret to the received message and com-
putes the hash of the result. If that
matches the received hash, Bob can
have confidence the message was sent
by someone knowing the secret. (Note:
There are some cryptographic sub-
tleties to making this actually secure.
See §5.4.10 Computing a MAC with a
Hash.)
2.4.3 Message Fingerprint

If you want to know whether some

large data structure (e.g., a program)
has been modified from one day to the
next, you could keep a copy of the
data on some tamper-proof backup
store and periodically compare it to
the active version. With a hash func-
tion, you can save storage. You simply
save the hash of the data on the tam-
per-proof backup store (which, be-
cause the hash is small, could be a
piece of paper in a filing cabinet). If
the hash value hasn’t changed, you
can be confident none of the data has.

A note to would-be users—if it hasn’t

already occurred to you, it has oc-
curred to the bad guys—the program
that computes the hash must also be
independently protected for this to be
secure. Otherwise, the bad guys can
change the file but also change the
hashing program to report the hash as
though the file were unchanged!

2.4.4 Efficient Digital Signatures

Public key algorithms are much

slower than hash algorithms.
Therefore, to sign a message, which
might be arbitrarily large, Alice does
not usually sign the actual message.
Instead, she computes a hash of the
message and uses her private key to
sign the hash of the message.

2.5 Breaking an Encryption

Scheme

What do we mean when we speak of a

bad guy Fred breaking an encryption
scheme? Examples are Fred being
able to decrypt something without
knowing the key, or figuring out what
the key is. Various attacks are classi-
fied as ciphertext only, known plain-
text, chosen plaintext, chosen ci-
phertext and side-channel attacks.

Note that cryptographers are well

aware of all these attacks, so most
modern systems are designed to be re-
silient against these attacks.

2.5.1 Ciphertext Only

In a ciphertext-only attack, Fred has

seen (and presumably stored) some ci-
phertext that he can analyze at
leisure. Typically, it is not difficult for
a bad guy to obtain ciphertext. (If a
bad guy can’t access the encrypted
data, then there would have been no
need to encrypt the data in the first
place!)

How can Fred figure out the plaintext

if all he can see is the ciphertext? One
possible strategy is to search through
all the keys. Fred tries the decrypt op-
eration with each key in turn. It is es-
sential for this attack that Fred be able
to recognize when he has succeeded.
For instance, if the message was
English text, then it is highly unlikely
that a decryption operation with an
incorrect key could produce some-
thing that looked like intelligible text.
Because it is important for Fred to be
able to differentiate plaintext from
gibberish, this attack might be better
called a recognizable-plaintext
attack.

It is also essential that Fred have

enough ciphertext. For instance, using
the example of a monoalphabetic ci-
pher, if the only ciphertext available
to Fred were XYZ, then there is not
enough information. There are many
possible letter substitutions that
would lead to a legal three-letter
English word. There is no way for
Fred to know whether the plaintext
corresponding to XYZ is THE or CAT
or HAT. As a matter of fact, in the fol-
lowing sentence, any of the words
could be the plaintext for XYZ:

The hot cat was sad but you may now

sit and use her big red pen.

[Don’t worry—we’ve found a lovely

sanatorium for the coauthor who
wrote that.

—the other coauthors]

Often it isn’t necessary to search
through a lot of keys. For instance, the
authentication scheme Kerberos (see
§10.3 Kerberos) assigns to user Alice
a secret key derived from Alice’s pass-
word according to a straightforward,
published algorithm. The secret key
Kerberos uses today is typically 256
bits. If Alice chooses her password un-
wisely (e.g., a word in the dictionary),
then Fred does not need to search
through all 2256 possible keys—instead
he only needs to try the derived keys
of the 50000 or so passwords in a dic-
tionary of potential passwords.

Another form of information leakage

from ciphertext alone is known as
traffic analysis, in which information
is inferred based on seeing transmit-
ted ciphertext. For instance, it might
be useful to know that a lot of traffic is
suddenly being transmitted between
two companies, because it might sig-
nal a potential merger. To avoid leak-
ing information based on which par-
ties are communicating, traffic can be
sent through an intermediary, which
could send lots of dummy traffic to all
its customers at all times, and just re-
place dummy traffic with real traffic
when there is real traffic to send. See
§14.18 Message Flow Confidentiality.

The length of a message might leak in-

formation. For instance, when a
teenager gets a letter from a college
they applied to, they know before
opening the envelope (based on
whether it is thick or thin), whether
the letter is a rejection or an accep-
tance. To avoid leaking information
based on how long a message is, mes-
sages can be padded with extra bits so
they are all the same size.

A cryptographic algorithm has to be

secure against a ciphertext-only attack
because of the accessibility of the ci-
phertext to cryptanalysts. But, in
many cases, cryptanalysts can obtain
additional information, so it is impor-
tant to design cryptographic systems
to withstand the next two attacks as
well.

2.5.2 Known Plaintext

Sometimes life is easier for the at-

tacker. Suppose Fred has somehow
obtained some ⟨plaintext, ciphertext⟩
pairs. How might he have obtained
these? One possibility is that secret
data might not remain secret forever.
For instance, the data might consist of
specifying the next city to be attacked.
Once the attack occurs, the plaintext
to the previous day’s ciphertext is now
known. Another example is where all
messages start with the same plain-
text, for instance, the date.

With a monoalphabetic cipher, a small

amount of known plaintext would be
a bonanza. From it, the attacker would
learn the mappings of a substantial
fraction of the most common letters
(every letter that was used in the
plaintext Fred obtained). Some crypto-
graphic schemes might be good
enough to be secure against cipher-
text-only attacks but not good enough
against known plaintext attacks. In
these cases, it becomes important to
design the systems that use such a
cryptographic algorithm to minimize
the possibility that a bad guy will ever
be able to obtain ⟨plaintext, cipher-
text⟩ pairs.

2.5.3 Chosen Plaintext

Sometimes, life may be easier still for

the attacker. In a chosen plaintext at-
tack, Fred can choose any plaintext he
wants and get the system to tell him
what the corresponding ciphertext is.
How could such a thing be possible?

Suppose a telegraph company offered

a service in which they encrypt and
transmit messages for you. Suppose
Fred had eavesdropped on Alice’s en-
crypted message. Now he’d like to
break the telegraph company’s en-
cryption scheme so that he can de-
crypt Alice’s message.

He can obtain the corresponding ci-

phertext to any message he chooses by
paying the telegraph company to send
the message for him, encrypted. For
instance, if Fred knew they were using
a monoalphabetic cipher, he might
send the message
The quick brown fox jumps over the
lazy dog.

knowing that he would thereby get all

the letters of the alphabet encrypted
and then be able to decrypt with cer-
tainty any encrypted message. Even if
the telegraph company is using a
strong cipher, if the same message
sent twice encrypts to the same ci-
phertext, then if the attacker can
guess the plaintext, he can verify his
guess by sending that message and
seeing whether the ciphertext
matches. As we will see in Chapter 4
Modes of Operation, modern crypto-
graphic systems encrypt in a way that
encrypting the same plaintext twice
will result in two different ciphertexts.

2.5.4 Chosen Ciphertext

If an attacker (Trudy) makes up a mes-

sage or modifies a real message from
Alice to Bob, and sends it to Bob,
claiming to be Alice, Trudy might
learn something by observing how
Bob reacts. Even if Bob detects that
the message is not formatted as a mes-
sage from Alice should be, Trudy
might learn something based on the
particular error message Bob sends
when rejecting the message, or even
based on how long it takes Bob to re-
spond with an error.

One example of a chosen ciphertext

attack was a vulnerability in a widely
deployed system (SSL), found by
Bleichenbacher [BLEI98]. The attack
works as follows: First, Trudy eaves-
drops and records a session between
Alice and Bob. In particular, Trudy
will find the part of the session where
Alice sent a secret key encrypted with
Bob’s public key. That secret key was
then used to cryptographically protect
the rest of the session. Trudy can then
pretend to try to initiate a connection
to Bob sending modified versions of
the encrypted secret key that Alice
sent. These connections will fail, be-
cause Trudy doesn’t know the secret
key Alice used, but this attack takes
advantage of the fact that in this im-
plementation, Bob was super helpful
in letting Trudy know what was
specifically wrong with each modified
message. With this attack, Trudy
would eventually (e.g., after on the or-
der of million connection attempts)
discover the session key for the
recorded Alice-Bob session, and,
therefore, Trudy would be able to de-
crypt that entire Alice-Bob conversa-
tion. These sorts of attacks can gener-
ally be protected against by simple
precautions, such as always protecting
data with both encryption and integ-
rity protection, and by giving the least
information possible about why com-
munication attempts fail.

There are more subtle chosen cipher-

text attacks and defenses, which we
discuss in (§8.1.3 Defense Against
Dishonest Ciphertext). These gener-
ally force the attacker to prove they
have generated their ciphertext in a
way that does not deviate from the
specification, for example, by includ-
ing in the ciphertext an encryption of
the random seed used to create the
ciphertext.

2.5.5 Side-Channel Attacks

A side-channel attack, introduced by

Paul Kocher [KOCH96], isn’t an attack
on an algorithm itself, but rather on
an implementation of an algorithm in
a particular environment. By observ-
ing side effects of an implementation
while it is executing, an attacker might
discover information such as some or
all the bits of the plaintext or the key
being used. Usually, what’s observed is
how long it takes something to exe-
cute, though some side channels are
based on careful measurement of
power consumption or even the sound
the computer makes. The most power-
ful attacks are possible when Trudy,
the attacker, can run a program on a
system very close to the implementa-
tion she would like to observe. For ex-
ample, she might run a process on the
same computer. Trudy can measure
how long her own operations take
while the victim process is running on
another thread. By carefully measur-
ing instruction times as it accesses
memory, Trudy can get information
about which cache lines the victim
process is using. Another example
where Trudy might powerfully gain
information is if she installs malicious
software or hardware on a smart card
reader. Again, she is close to the im-
plementation running on the smart
card and can observe how much
power it uses, and other information.
Even an attacker with only network
access may be able to determine
things by carefully measuring how
long it takes a server to respond to
messages.

One way of defending against side-

channel attacks is for an implementa-
tion to make sure that it always be-
haves the same way, no matter what
its inputs are. For instance, it could
perform extra computation so that
timing always matches that of the
worst-case input. Another type of miti-
gation is to randomize the inputs us-
ing a random function of the inputs
and then convert the result to what it
would be if the implementation com-
puted based on the actual input.

2.6 Random Numbers

The generation of random numbers is

too important to be left to chance.

—Robert Coveyou, Oak Ridge National

Laboratory

In this section, we will discuss some of

the considerations that go into the
generation and use of random num-
bers. For more reading on the subject
of random number generators, see
NIST SP800-90 parts A, B, and C.
You can have perfect cryptographic al-
gorithms, and perfectly designed pro-
tocols, but if you can’t select good ran-
dom numbers, your system can be re-
markably insecure. Random numbers
may be required in choosing crypto-
graphic keys, challenges, or other in-
puts to a cryptographic system.

Although I3’d love to rigorously define

“random”, I2 won’t let me3 because a
really rigorous definition is beyond
the scope and spirit of the book. For
instance, in [KNUT69], fifteen pages
are devoted to coming up with a defi-
nition of a random sequence. For
those readers who are not intimidated
by notions such as (m,k)-distributed,
serial correlation coefficients, and
Riemann-integrability (don’t try to
find those terms in our glossary), the
discussion of randomness in
[KNUT69] is actually very interesting
(though, honestly, not to me2).

In the context of cryptography, we

measure the quality of random num-
bers by how much work it would be
for an attacker to guess the chosen
value. If that’s more than the work re-
quired to break the cryptographic sys-
tem in some other way, then the quan-
tity is random enough. Ideally, it
would require testing about 2n strings
to find a specific n-bit random string
(actually, 2n–1 tests on average, assum-
ing average luck on the part of the at-
tacker). Random number generators
used in cryptographic systems usually
involve three steps:

Gathering entropy
Computing a random seed
Compute a pseudorandom number
stream from the seed

Each of these steps is perilous in its

own way, in terms of bugs that could
make a system insecure in ways that
are hard to detect.

2.6.1 Gathering Entropy

The concept of entropy comes from

physics, but in this context entropy is
a measure of the difficulty of guessing
the value of something. Something
with 2n equally likely values has n bits
of entropy. If the values are not
equally likely, there is less entropy. A
perfectly random stream of bits would
have one bit of entropy per bit of data,
but even data that is easier than that
to guess has value. Timing user key-
strokes using a high-resolution clock
may be fairly predictable but still give
a few bits of entropy per keystroke.
Measuring the seek time of disks is
similarly predictable but not in the
low order bits. If the device has a mi-
crophone or camera, a large number
of bits can be read containing a rea-
sonably high amount of entropy.

One of the problems with mechanical

sources is that their quality can de-
grade over time. User keystroke tim-
ing may contain a lot of entropy until
the user is replaced with an auto-
mated agent that feeds the keystrokes
from a script. Disk seek times may be-
come highly predictable when the
disk hardware is replaced with a
solid-state drive. A conservative de-
sign will combine lots of entropy
sources in such a way that the system
will be secure if any of them is good.

Most modern CPUs have a built-in ran-

dom number generator from which
random bits can be harvested, but it is
dangerous to rely on that single
source. That’s because subverting the
design of the random number source
on a CPU chip would be a high-value
target for intelligence agencies or
well-funded criminal organizations. It
would be very difficult to detect that
the output of the chip’s random num-
ber function was not based on truly
random input, but instead, guessable
by someone who knows the seed and
algorithm that they secretly embed-
ded in the chip design.

Some systems go to extreme lengths to

build hardware that gathers provably
good sources of entropy like counting
events of radioactive decay with a
Geiger counter or measuring the po-
larization of photons. There is no rea-
son to believe that these sources of
randomness are any better than more
conventional ones, and like a random
number source built into a CPU, it
would be difficult to know whether
the high-priced device is really count-
ing Geigers :-) or generating numbers
that are guessable by the agency that
secretly embedded an algorithm.

2.6.2 Generating Random Seeds

The second step is to turn a lot of

sources of unguessable quantities into
a random seed. The best way to do
that is to perform a cryptographic
hash of the data. Some people recom-
mend ⊕ing the different sources to-
gether, which is just as good if the dif-
ferent sources are uncorrelated. But if
two sources turned out to be identical,
⊕ing them together would entirely re-
move their benefit (see Homework
Problem 6), while hashing their con-
catenation would keep almost all the
entropy they contain so long as the
hash fuinction output is large enough
to hold it.

2.6.3 Calculating a Pseudorandom

Stream from the Seed

A pseudorandom number generator

(PRNG) takes the random seed and
produces a long stream of crypto-
graphically random data. Since the
PRNG generates a stream deterministi-
cally from a seed, the entropy in the
stream will not be greater than the
size of the seed. Also, if someone were
to capture the state of the PRNG, they
would be able to calculate all the sub-
sequent output. Sometimes parts of
the stream will not be secret, such as
when the stream is used for choosing
a random initialization vector (IV) [see
§4.2.2 CBC (Cipher Block Chaining)].
It is essential, then, that seeing part of
the pseudorandom stream not allow
an attacker to compute the rest of the
stream. It is also desirable for an im-
plementation to throw away state so
that previous output of the stream will
not be able to be calculated based on
the current state. For example, if the
implementation always kept the initial
seed, someone who stole that seed
would be able to calculate the entire
stream, past and future. If an imple-
mentation were to crash, the system
might dump the entire state.

There are many secure ways to con-

struct a pseudorandom number gen-
erator using secret key encryption and
hash functions, but it is best to use one
of the standardized ones from
[NIST15a]. There are two reasons for
that—first, it is required for some se-
curity compliance regimes, but just as
important is that those algorithms
come with sample data that allow you
to test whether your implementation
is correct. Bugs in random number
generators will produce output that al-
most certainly looks random to any
tester but may be trivially attackable
by someone who discovers the bug
and sees some of the output.

Sometimes, Alice and Bob need to

agree on a lot of different keys or
other secret values. It is often conve-
nient to derive all of them from a seed
so that Alice need only send the seed
to Bob and the other secret informa-
tion can be derived from that seed.
The deterministic function for deriv-
ing information from a seed is either
known as a pseudorandom function
(PRF) or a key-derivation function
(KDF). This function will generally
take two inputs: the seed, and an addi-
tional input called a data variable
which identifies which of the possible
keys or secret values are being gener-
ated from the seed.

2.6.4 Periodic Reseeding

It is good security practice to periodi-

cally add randomness to the PRNG.
This involves gathering entropy as the
program runs, and when there is
enough, mixing it in with the state.
The reason to do this is so that if an at-
tacker learns the seed you are using,
they will only be able to predict the
random stream for a limited amount
of time.

It is better to wait until a reasonable

amount of entropy has been built up,
and mix it all in at once, rather than
mixing in new entropy bit-by-bit as it
is gathered. Adding 128 bits of entropy
once is worth a lot more than adding
eight bits of entropy a thousand times
(see Homework Problem 9).
2.6.5 Types of Random Numbers

Applications that use random num-

bers have different requirements. For
most applications, for instance one
that generates test cases for debugging
a computer program, all that might be
required is that the numbers are
spread around with no obvious pat-
tern. For such applications it might be
perfectly reasonable to use something
like the digits of π. However, for cryp-
tographic applications such as choos-
ing a cryptographic key, it is essential
that the numbers be unguessable.
Consider the following pseudorandom
number generator. It starts with a
truly random seed, say by timing a
human’s keystrokes. Then it computes
a hash of the seed, then at each step it
computes a hash of the output of the
previous step. Assuming a good hash
function, the output will pass any sort
of statistical tests for randomness, but
an intruder that captures one of the
intermediate quantities will be able to
compute the rest.

In general, the functions provided in

programming languages for random
numbers are not designed to be
unguessable in the cryptographic
sense. They are designed merely to
pass statistical tests. Calling one of
these to generate cryptographic keys
is an invitation to disaster.
2.6.6 Noteworthy Mistakes

Random number implementations

have made some amusing mistakes.
Typical mistakes are:

Seeding the generator with a seed

that is from too small a space.
Suppose each time a cryptographic
key needed to be chosen, the appli-
cation obtained sixteen bits of true
randomness from special purpose
hardware and used those sixteen
bits to seed a pseudorandom num-
ber generator. The problem is that
there would be only 65536 possible
keys it would ever choose, and that
is a very small space for an adver-
sary (equipped with a computer) to
search. Jeff Schiller found an im-
plementation in a product that
computed RSA key pairs randomly,
but from an 8-bit seed! Jeff at-
tempted to report the bug to one of
the lead developers of the product
(let’s call that person Bob, though
that was not his name). Bob did not
believe Jeff. So Jeff wrote a pro-
gram to compute all 256 possible
key pairs the product could gener-
ate, found Bob’s key, and sent Bob
an email signed with Bob’s private
key.
Using a hash of the current time
when an application needs a ran-
dom value. The problem is that
some clocks do not have fine gran-
ularity, so an intruder that knew
approximately when the program
 was run would not need to search
a very large space to find the exact
clock value for the seed. For in-
stance, if a clock has granularity of
1/60 second, and the intruder knew
the program chose the user’s key
somewhere within a particular
hour, there would only be
60×60×60 = 216000 possible values.
A widely deployed product used a
microsecond granularity concate-
nated with some other values that
were not very secret. Ian Goldberg
and David Wagner discovered this
bug and demonstrated breaking
keys in 25 seconds on a slow ma-
chine [GOLD96].
Divulging the seed value. An imple-
mentation, again discovered by Jeff
Schiller (who warned the company
so that the implementation has
been fixed), used the time of day to
choose a per-message encryption
key. The time of day in this case
may have had sufficient granular-
ity, but the problem was that the
application included the time of
day in the unencrypted header of
the message!

One event too important to leave out

involves an intelligence agency that
may have tricked the world into de-
ploying a pseudorandom number gen-
erator with a back door that allowed
them to predict the output (assuming
they could see parts of the output). It
was called Dual_EC_DBRG, and in spite
of warnings from industry experts
and much lower performance than
competing algorithms, they managed
to convince NIST to standardize it, and
RSA Data Security to make it the de-
fault in their widely used software. It
was only after evidence of a back door
was revealed in the Edward Snowden
papers that the algorithm was discred-
ited and removed from service.

2.7 Numbers

Cryptographic algorithms manipulate

messages and keys, both of which are
defined in terms of bit strings. The al-
gorithms are usually defined in terms
of arithmetic operations on numbers,
where the numbers come from some
interpretation of groups of bits.
Mathematics has been studied for
thousands of years, and mathematical
properties are well understood, mak-
ing analysis of algorithms based on
mathematical principles more
reliable.

Mathematics deals with many kinds of

numbers: integers, rational numbers,
real numbers, complex numbers, etc.
There are infinitely many of each of
these kinds of numbers, which makes
them not representable in any finite
number of bits. Cryptographic algo-
rithms manipulate numbers with
thousands of bits, and require exact,
rather than approximate, representa-
tions of the quantities they
manipulate.
Let’s call the things in the set that a
mathematical system operates on ele-
ments. Elements might be integers,
real numbers, rational numbers, com-
plex numbers, polynomials, matrices,
or other objects. Various crypto-
graphic algorithms require a mathe-
matical system to have certain proper-
ties. Familiar properties of numbers in
ordinary math are that there are two
operations, + and × (called plus and
times, or addition and multiplication),
and:

commutativity: For any x and y,

x+y = y+x and x×y = y×x
associativity: For any x, y, and z,
(x+y)+z = x+(y+z). Also, (x×y)×z =
x×(y×z)
distributivity: For any x, y, and z,
x×(y+z) = (x×y)+(x×z)
additive identity: There is a num-
ber 0 such that for any x, 0+x=x and
x+0=x
multiplicative identity: There is a
number 1 such that for any x,
1×x=x and x×1=x
additive inverse: For any x, there
is a number –x such that x+(–x)=0
multiplicative inverse: For any x
other than 0. there is a number x–1
such that x×x–1=1

A system that satisfies all these prop-

erties is called a field. A system that
has these properties except that some
elements might not have multiplica-
tive inverses, and multiplication might
not be commutative, is called a ring. A
system that only has one operation,
and for which every element has an
inverse, is called a group.

Some cryptographic systems require a

system with some or all the above
properties and also require being able
to exactly represent each element in a
fixed number of bits. Will integers
work? Integers have an additive iden-
tity, namely 0. And they have a multi-
plicative identity, namely 1. However,
most integers do not have multiplica-
tive inverses. (For example, ½ is the
multiplicative inverse of 2 in real
numbers, but ½ is not an integer.)
Also, integers can get arbitrarily large,
and we want to be able to represent
each element exactly in a fixed num-
ber of bits.

2.7.1 Finite Fields

Luckily, there is a mathematical struc-

ture that will do everything we want.
It is called a finite field. A finite field
of size n has n different elements and
has all the properties we need. One
form of finite field is the integers mod-
ulo p, where p is a prime. Arithmetic
mod p uses integers between 0 and p–
1. Addition and multiplication are
done just like with regular arithmetic,
but if the answer is not between 0 and
p–1, the answer is divided by the mod-
ulus p, and the answer is the remain-
der. For example, with mod 7 arith-
metic, the elements are {0, 1, 2, 3, 4, 5,
6}. If you add 2 and 4, you get 6, which
is one of the elements. However, if
you add 5 and 6, the answer is 11, so
you need to divide by the modulus, 7,
and take the remainder, which is 4.
We will talk more about modular
arithmetic in Chapter 6 First-
Generation Public Key Algorithms,
when we talk about the RSA algo-
rithm, which is only secure if the mod-
ulus is not prime.

Évariste Galois founded the theory of

finite fields. For each prime p, there is
exactly one finite field with p ele-
ments, and it will be equivalent to the
integers mod p. There is also exactly
one finite field for each higher power
of p, for instance, pk. The field with pk
elements is usually denoted by GF(pk),
where GF stands for Galois field, in
honor of Galois. Arithmetic mod
prime p would be denoted GF(p), al-
though it is sometimes denoted as Zp.

Note that if we use modular arith-

metic, say mod 11, it will require four
bits to represent each element, but
there will be five values of the bits
that will not be elements in the field
{11, 12, 13, 14, 15}. This causes some
problems, and it wastes space since
we are using four bits to specify only
11 values. For that reason, crypto-
graphic algorithms often use GF(2n)
arithmetic, because each element cor-
responds to a unique n-bit value and
vice versa.
Arithmetic in GF(2n) is very efficient.
Addition is ⊕, which computers love
to do. GF(2n) multiplication is also effi-
cient (for computers). Multiplication
in GF(2n) can be thought of as modu-
lar arithmetic of polynomials with co-
efficients mod 2. For instance, the bit
string 110001 would represent the
polynomial x5+x4+1. Given that we
need to represent GF(2n) elements in n
bits, it is necessary after a multiplica-
tion of two n-bit polynomials to re-
duce the answer (which might be 2n–1
bits) modulo a degree-n polynomial.
The polynomial modulus needs to be
irreducible, which in this case means
only divisible by itself and 1.

There are also finite rings and finite

groups, and these are also commonly
used in cryptography. For instance,
RSA, which uses modular arithmetic
with a non-prime modulus, does not
use a finite field, but it does use a fi-
nite ring.

2.7.2 Exponentiation

We talked about + and × as two opera-

tions on the elements in our set. But
cryptographic algorithms often re-
quire exponentiation. Exponentiation
is not another operation on two ele-
ments in the set like + and × are.
Instead, exponentiation takes as input
an element a and an integer x and
multiplies x as together. This is writ-
ten ax.
That’s fine if x is small, but what if the
exponent x is a number with thou-
sands of digits? It would take several
universe lifetimes, even for a super-
computer, to do that many multiplica-
tions. The trick that makes exponenti-
ation by a very large number practical
is repeated squaring. That means start-
ing with a, squaring it (meaning multi-
plying it by itself) to get a2, and squar-
ing a2 to get a4, squaring a4 to get a8,
and so on. So, as long as the exponent
x is a power of two, e.g., 2k, we can
compute ax with only k multiplies
(rather than 2k–1 multiplies). If the ex-
ponent x is not a power of two, we can
still use the trick of repeated squaring.
If x is a power of two, it will look, in
binary, like 1 followed by a bunch of
zeroes. If x is not a power of two, the
binary representation of x will consist
of some 0s and some 1s. To raise a
number a to the exponent x, do the
following. Use a pointer that points to
a bit in x and initially points to the
leftmost (most significant) bit of x.
Have a second value that we will refer
to as the intermediate value, which is
initialized to 1. For each bit in x, do
the following:

1. If the bit in x pointed to by the

pointer is 1, multiply the interme-
diate value by a.
2. If the pointer is at the rightmost bit
of x, you are done; otherwise, move
the pointer to the right one bit
position.
 3. Square the intermediate value.

Using this algorithm, the number of

multiplies to raise something to the
power x depends on the number of 1s
in the binary representation of x. In
the worst case, it will take twice the
number of bits in x (if all the bits in x
are 1). In the best case, it will take the
number of bits in x (if x is a power of
two).

We will go deeper into these concepts

as they are required for specific
algorithms.

2.7.3 Avoiding a Side-Channel Attack

A straightforward implementation of
the algorithm in §2.7.2
Exponentiation is an opportunity for
a side-channel attack, because the im-
plementation would behave differ-
ently on each bit of the exponent, de-
pending on whether the bit was a 0 or
a 1. An implementation can avoid pro-
viding a side-channel by behaving the
same way on each bit. For instance, it
could always implement step 2 (multi-
plying the intermediate value by a),
saving both the result of step 1 and of
step 2, and then discard the result of
step 1 if the bit was a 1 or discard the
result of step 2 if the bit was a 0.

Even this remediation might still al-

low a side-channel attack because
anything that contains conditional
branches might cause observable be-
havior differences, such as which
memory locations are read and writ-
ten. So, an implementation might exe-
cute the exponentiation algorithm by
computing both the result of squaring
alone (let’s call that the IF0 value) and
of squaring and multiplying by a (let’s
call that the IF1 value). Then the im-
plementation can take the relevant bit
in the exponent (which will be 0 or 1),
and ⊕ the bit times the IF1 value with
the complement of the bit times the
IF0 value.

Even this might not be enough. To

truly eliminate side channels, you
need to know the details of the partic-
ular platform.

2.7.4 Types of Elements used in

Cryptography

Sometimes cryptographic systems use

mod p arithmetic, where p is a prime.
RSA, as we will see, uses mod n arith-
metic, where n is definitely not a
prime. Other cryptographic systems,
especially some of the post-quantum
algorithms, use polynomials or matri-
ces, but with coefficients that use ei-
ther modular arithmetic or GF(2n).
When modular arithmetic is used in
post-quantum cryptography, the mod-
ulus is either prime or a power of two.
Note that numbers modulo a power of
two do not form a finite field (because
powers of two other than 21 are not
prime).
2.7.5 Euclidean Algorithm

The Euclidean algorithm is an effi-

cient method of finding the greatest
common divisor (gcd) of two numbers
a and b. The gcd of a and b is written
as gcd(a,b). It is the largest number
that evenly divides both a and b.

The Euclidean algorithm can also be

used to find the multiplicative inverse
of b mod a, and this is what the
Euclidean algorithm is mostly used for
in cryptography. Sometimes, using the
Euclidean algorithm for finding multi-
plicative inverses is called the ex-
tended Euclidean algorithm.

The insight into efficiently finding

gcds is that if a number d is a divisor
of both a and b, it is also a divisor of
a–b. It is also a divisor of a minus any
multiple of b. Therefore, if you divide
a by b, the remainder is also divisible
by d. The Euclidean algorithm starts
with a and b, and at each step, calcu-
lates smaller numbers that are divisi-
ble by d, until the last step when the
remainder is 0.

At each step, there will be two num-

bers A and B, initialized to a and b.
Divide A by B to get the remainder R,
which will be smaller than B. At the
next step, set A equal to B, and B equal
to R, and keep iterating until R is 0.
The final value of B will be the gcd of
a and b. For example, consider finding
the gcd of 420 and 308.
420÷308 = 1 remainder 112

308÷112 = 2 remainder 84

112÷84 = 1 remainder 28

84÷28 = 3 remainder 0

Therefore, 28 is the gcd of 420 and

308.

When we want to find the multiplica-

tive inverse of b mod a, the goal is to
find integers u and v such that
u×a+v×b=1. Then v will be the multi-
plicative inverse of b mod a, because
v×b will be 1 more than a multiple of
a. The integer b will only have an in-
verse mod a if gcd(a,b) is 1. So let’s use
two numbers a and b such that
gcd(a,b)=1. We’ll use 109 and 25. First,
let’s apply the Euclidean algorithm to
find gcd(109,25).

109÷25 = 4 remainder 9

25÷9 = 2 remainder 7

9÷7 = 1 remainder 2

7÷2 = 3 remainder 1

2÷1 = 2 remainder 0

So, gcd(109,25)=1. We want to repre-

sent each of the remainders as some
multiple of a (109) plus some multiple
of b (25). We know that a=1×a+0×b and
that b=0×a+1×b. After the first step, we
know that a÷b = 4 remainder 9, or
rewriting, we get

9=1×a–4×b.

The second line tells us that 25÷9=2 re-

mainder 7. That means 7=25–2×9.
Well, 25=b. And 9 is 1×a–4×b.
Substituting for 9, we get 7=25–
2×(1×a–4×b), Since 25=b, this simplifies
to

7=–2×a+9×b.

The third line tells us that 9÷7=1 re-

mainder 2. That means that 2=9–1×7.
Substituting for 9 (1×a–4×b) and 7 (–
2×a+9×b), we get

2=3×a–13×b.

The next line tells us that 7÷2=3 re-

mainder 1. That means that 1=7–3×2.
Substituting for 7 (–2×a+9×b) and 2
(3×a–13×b), we get 1=(–2×a+9×b)–
3×(3×a–13×b), which simplifies to

1=–11×a+48×b.

This tells us that 48 times b is one

more than a multiple of a. In other
words, 48 is b’s inverse mod a. Going
back to the values we chose for a and
b (109 and 25), we have calculated that
25’s inverse mod 109 is 48. And in-
deed, 25×48=1200 and 1200÷109=11
remainder 1.
2.7.6 Chinese Remainder Theorem

The Chinese Remainder Theorem will

be useful for making certain RSA oper-
ations more efficient. We’ll give a spe-
cial case definition, since that’s all that
we need. As we will see, a typical RSA
modulus n is the product of two
primes p and q. The Chinese
Remainder Theorem states that if you
know what a number, say x, equals
mod n, then you can easily calculate
what x is mod p and what x is mod q.
And likewise, if you know what x is
mod p, and what x is mod q, then you
can easily calculate what x is mod n.

It’s pretty easy to see how knowing

what x is mod n enables you to calcu-
late what x is mod p, and what x is
mod q. To find out what x is mod p,
just divide x mod n by p and the re-
mainder will be what x is mod p.
Likewise for calculating what x mod n
is mod q.

The other direction is a bit trickier.

Suppose you know that a number
equals a mod p and b mod q, and you
want to know what it is mod pq.

The first thing you need to do is calcu-

late p’s multiplicative inverse mod q
and q’s multiplicative inverse mod p.
You can do that with the extended
Euclidean algorithm.

Now you know p–1 mod q. And you

know q–1 mod p. Note
p×(p–1 mod q)=1 mod q and it is equal
to 0 mod p.

q×(q–1 mod p)=1 mod p and 0 mod q.

You are looking for a number that is a

mod p and b mod q. Multiply q×(q–1
mod p) by a, but don’t reduce mod p.
You’ll get something that is a mod p
and also 0 mod q. (When you started,
you knew that a was equal to a mod p,
but a is probably not equal to 0 mod
q.)

Likewise, multiply p×(p–1 mod q) by b,

but don’t reduce mod q. You now have
a number that is equal to 0 mod p and
b mod q.

Add these two quantities together.

You’ll get a×(q×(q–1 mod p))+b×(p×(p–1
mod q)). Now you can reduce mod n,
and the result will be the number,
mod n, that is also equal to a mod p
and b mod q.

Why is the Chinese Remainder

Theorem useful? As we will see in
§6.3.4.5 Optimizing RSA Private Key
Operations, instead of doing calcula-
tions mod n, the numbers can be con-
verted into their representations mod
p and mod q, and the operations can
be performed mod p and mod q, and
knowing the answer mod p, and
knowing the answer mod q, the an-
swer can be converted into the an-
swer mod n. Since p and q are roughly
half the size of n, this will be more ef-
ficient than doing the operations mod
n.

Note the Chinese Remainder Theorem

holds even if the smaller moduli are
not themselves prime, as long as they
are relatively prime (no factors in
common). Since people think of p and
q as primes, we’ll use j and k and re-
state the Chinese Remainder Theorem
as “If j and k are relatively prime and
you know a mod j and a mod k, you
can compute a mod jk, and vice
versa.”

2.8 Homework

1. What is the dedication to this book?

2. Random J. Protocol-Designer has
been told to design a scheme to
prevent messages from being mod-
ified by an intruder. Random J. de-
cides to append to each message a
hash of that message. Why doesn’t
this solve the problem?
3. Suppose Alice, Bob, and Carol want
to use secret key technology to au-
thenticate each other. If they all
used the same secret key K, then
Bob could impersonate Carol to
Alice (actually any of the three can
impersonate the other to the third).
Suppose instead that each had
their own secret key, so Alice uses
KA, Bob uses KB, and Carol uses KC.
This means that each of Alice, Bob,
and Carol, to prove his or her iden-
tity, responds to a challenge with a
function of his or her secret key
 and the challenge. Is this more se-
cure than having them all use the
same secret key K? (Hint: What
does Alice need to know in order to
verify Carol’s answer to Alice’s
challenge?)
4. As described in §2.4.4 Efficient
Digital Signatures, it is common,
for performance reasons, to sign a
hash of a message rather than the
message itself. Why is it so impor-
tant that it be difficult to find two
messages with the same hash?
5. Assume a cryptographic algorithm
in which the performance for the
good guys (the ones that know the
key) grows linearly with the length
of the key, and for which the only
way to break it is a brute-force at-
tack of trying all possible keys.
Suppose the performance at a cer-
tain key-size is adequate for the
good guys (e.g., encryption and de-
cryption can be done as fast as the
bits can be transmitted over the
wire). Then suppose advances in
computer technology make com-
puters twice as fast. Given that
both the good guys and the bad
guys get faster computers, does this
advance in computer speed work
to the advantage of the good guys,
the bad guys, or does it not make
any difference?
6. Suppose you had a source of really
good randomness, and you copied
the random output into two places
and ⊕’d these. How random would
 the result be? What if you concate-
nated the two quantities and
hashed the result? Would that be
random?
7. Suppose the seed for a PRNG (see
§2.6.3 Calculating a
Pseudorandom Stream from the
Seed) is n bits long. How many bits
of output of the PRNG would you
need to see in order to verify a
guess of a seed that it is using (with
high probability)?
8. Suppose you could see some, but
not all, of the output of a PRNG.
Assuming you know the algorithm
the PRNG is using, would you be
able to verify a guess of a seed
based solely on seeing every tenth
bit? Would this require trying
more potential seeds than if you
were able to see all the bits of the
PRNG output (assuming you were
able to see enough output bits)?
9. Suppose you could see 400 bits of
output of a PRNG every second,
and you knew that it started with
eight bits of randomness and
mixed in eight bits of new random-
ness every second. How difficult
would it be, after sixteen seconds,
to calculate what the state of the
PRNG is, compared to a PRNG that
mixed in 128 bits of randomness
every sixteen seconds?
10. Suppose a process generates about
eight bits of randomness every sec-
ond, and suppose a PRNG used the
8-bit random output every second,
 and suppose you could see the out-
put of the PRNG. Why is it better to
wait until you have, say, 128 bits of
randomness, before using the ran-
domness to reseed your PRNG? In
other words, if the random seed
were a function of sixteen 8-bit
random chunks, how many possi-
ble seeds would there be? What if
you waited until there were 128
bits of randomness?
11. Suppose Alice wants to send a se-
cret message M to Bob, but has not
agreed upon a secret with Bob.
Furthermore, assume that Alice
can be assured that when she
sends something to Bob, it will ar-
rive at Bob without anyone having
tampered with the message. So the
only threat is someone reading the
transmissions between Alice and
Bob. Alice chooses a random secret
SA, and sends SA⊕M to Bob.
Nobody (including Bob) can read
this message. Bob now creates his
own secret SB, ⊕s what he received
from Alice with SB, and transmits
SA⊕M⊕SB to Alice. Alice now re-
moves her secret by ⊕ing with SA
and returns M⊕SB to Bob. Bob can
now ⊕ with his secret (SB) in order
to read the message. Is this secure?

12. Use the Euclidean algorithm to

compute gcd (1953,210).
13. Use the Euclidean algorithm to
compute the multiplicative inverse
of 9 mod 31.
14. A number is 11 mod 36 and also 7
mod 49. What is the number mod
1764? How about if a number is 11
mod 36 and also 11 mod 49—what
would that number be mod 1764?