Cryptograpny

HX. Mel ¢ Doris Baker

 fe
a

“moet

vt
i ba

i
CRYPTOGRAPHY
DECRYPTED
 CRYPTOGRAPHY
DECRYPTED

H. X. Mel
Doris Baker

Math Appendix by Steve Burnett

Foreword by John Kinyon

A
vv
Addison-Wesley

Boston ® San Francisco ® New York *® Toronto ® Montreal

London * Munich ¢ Paris * Madrid
Capetown * Sydney ® ‘Iokyo * Singapore * Mexico City
Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in this book, and we were aware of
a trademark claim, the designations have been printed in initial capital letters or in all capitals.

Screen shots reprinted by permission from Microsoft Corporation.

The authors and publisher have taken care in the preparation of this book, but make no
expressed or implied warranty of any kind and assume no responsibility for errors or
omissions. No liability is assumed for incidental or consequential damages in connection with
or arising out of the use of the information or programs contained herein.

The publisher offers discounts on this book when ordered in quantity forDSP eet sales. For
more information, please contact:

Pearson Education Corporate Sales Division

One Lake Street
Upper Saddle River, NJ 07458
(800) 382-3419
corpsales @ pearsontechgroup.com

Visit AW on the Web: www.awl.com/cseng/

Library of Congress Cataloging-in-Publication Data

Mel, H.X., 1948-
Cryptography decrypted / H. X. Mel, Doris M. Baker; math appendix by Steve Burnett;
foreword by John Kinyon.
p. cm.
Includes bibliographical references and index.
ISBN 0-201-61647-5
1. Computer security. 2. Cryptography. I. Baker, Doris M. II. Title.

QA76.9.A25 M44 2000

005.8'2—dc21 00-046878

Copyright © 2001 by Cary Meltzer and Doris Baker

All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior consent of the publisher. Printed in the United States
of America. Published simultaneously in Canada.

ISBN 0-201-61647-5
Text printed on recycled paper
123456789 10—MA—S50403020100
First printing, December 2000
 For Max Samuel—

who showed us that a good hiding place is hard to find

 Digitized by the Internet Archive
in 2023 with funding from
Kahle/Austin Foundation

https://archive.org/details/cryptographydecrO00Omelh
 CONTENTS

Foreword
Preface
Introduction

Parti Secret Key Cryptography

Chapter 1. Locks and Keys
Locks and Combinations
Defining Cryptographic Terms
Making and Solving Puzzles
Review

Chapter 2 Substitution and Caesar’s Cipher

Cryptanalysis of Caesar’s Cipher
Empowering the Masses
The Importance of Separating the Method and the Key
Adding Keys
A Weakness of Caesar’s Ciphers: The Failure to
Hide Linguistic Patterns
More Complex Substitution: Vigenére’s Cipher
Review

Chapter 3 Transposition Ciphers: Moving Around

Patterns and Cryptanalysis
Adding Complexity
Computer ‘Transposition
Combining Substitution and Transposition
Review
Viii CONTENTS

Chapter 4 Diffuse and Confuse: How Cryptographers

Win the End Game
Diffusion
The Polybius Cipher
The Principle of Confusion
Cryptographic Locks and Keys
Review

Chapter 5 DES Isn’t Strong Anymore

The Historical Need for an Encryption Standard
Cycling Through Computer Keys
Double and Triple DES
DES (and Other Block Cipher) Modes
The Avalanche Effect
Supplement: Binary Numbers and Computer Letters
Review

Chapter 6 Evolution of Cryptography: Going Global

Early Cryptography
Commercial and Military Needs
Entering the Computer Age
Review

Chapter 7 Secret Key Assurances

Confidentiality
Authentication
An Authentication Attack
Not Really Random Numbers
Integrity
Using the MAC for Message Integrity Assurance
Why Bother Using a Message Authentication Code?
File and MAC Compression
Nonrepudiation: Secret Keys Can’t Do It
Review

Chapter8 Problems with Secret Key Exchange

The Problem and the Traditional Solution
Using a Trusted Third Party
Key Distribution Center and Key Recovery
 CONTENTS ix

Problems with Using a Trusted Third Party

Growth in the Number of Secret Keys
Trust and Lifetime
Review

Part Il Public Key Cryptography

Chapter 9 Pioneering Public Key: Public Exchange
of Secret Keys
The Search for an Innovative Key Delivery Solution
Developing an Innovative Secret Key Delivery Solution
First Attempt: A Database of Key/Serial Number Pairs
Second Attempt: An Encrypted Database of
Key/Serial Number Pairs
Merkle’s Insight: Individually Encrypted
Key/Serial Number Pairs
Black Hat’s Frustrating Problem
The Key to Public Key Technology
A New Solution: Diffie-Hellman-Merkle Key Agreement
Alice and Bob Openly Agree on a Secret Key
Problems with the Diffie-Hellman Method
Separate Encryption and Decryption Keys
Review

Chapter 10 Confidentiality Using Public Keys

New ‘Twists on Old Security Issues
Confidentiality Assurances
Distribution of Public Keys
Two-Way Confidentiality
Review

Chapter 11 Making Public Keys: Math Tricks

Alice’s Easy Problem
Grade School Math Tricks
More Grade School Math
Division and Remainders: Modular Math
Modular Inverses
Using Modular Inverses to Make a Public Key
Putting It All Together
Giving BlackHat a Difficult, Time-Consuming Problem
Trapdoor to the Easy Problem
x CONTENTS

Knapsack Cryptography 112

Modulo Calculations Lig
Mxercise: Vind Which Numbers Sum to 103 i bs
Review 113

Chapter 12 Creating Digital Signatures Using

the Private Key Vo
Written and Digital Signature Assurances 116
Reviewing and Comparing Authentication Li
Secret Key Authentication Lay:
Private Key Authentication 117
Authentication and Integrity Using Private and Secret Keys 119
Private Key Authentication Methods 120
RSA 120
DSA 121
Signing ‘lerminology 122
Nonrepudiation 122
Assurances in Both Directions 123
Summary of Public Key Assurances 123
Public Key Means Public/ Private Key 124
Assurance Initiated 124
Compressing before Signing 124
Review 125

Chapter 13 Hashes: Non-keyed Message Digests 127

Detecting Unintentional Modifications 129
Detecting Intentional Modifications 13]
Signing the Message Digest 133
Detecting BlackHat’s Forgery 135
Replay Attacks 136
Supplement: Unsuccessfully Imitating a Message Digest 137
Review 13%

Chapter 14 Message Digest Assurances 141

‘Two Message Digest Flavors 141
Non-keyed Message Digest Assurances 143
One-wayness 143
Collision Resistance 143
Weak Collision Resistance 144
Examples of One-way and Weak Collision Resistance 145
Strong Collision Resistance 147
 CONTENTS xi

Non-keyed Digest Implementations 150

Keyed Message Digest Assurances 151
A MAC Made with DES 151
DES-MAC Security ers
Message Digest Compression 154
Digest Speed Comparisons 155
Hashed MAC 15
Review 156

Chapter 15 Comparing Secret Key, Public Key,

and Message Digests 17,
Encryption Speed iol)
Key Length 158
Ease of Key Distribution 158
Cryptographic Assurances 159
Symmetric (Secret) Key 159
Asymmetric (Public) Key 159
Review 161

Part Ill Distribution of Public Keys 163

Chapter 16 Digital Certificates 165
Verifying a Digital Certificate 167
Attacking Digital Certificates 167
Attacking the Creator of the Digital Certificate 168
Malicious Certificate Creator 168
Attacking the Digital Certificate User 168
The Most Devastating Attack 168
Understanding Digital Certificates: A Familiar Comparison 169
Issuer and Subject 169
Issuer Authentication 169
Transfer of Trust from the Issuer to the Subject 170
Issuer’s Limited Liability 171
Time Limits 171
Revoking ‘Trust 171
More than One Certificate 172
Fees for Use 172
The Needs of Digital Certificate Users wees
Getting Your First Public Key 173
Certificates Included in Your Browser 174
Review We
xii CONTENTS

Chapter 17 X.509 Public Key Infrastructure 177

Why Use X.509 Certificate Management? 178
What Is a Certificate Authority? L79
Application, Certification, and Issuance 179
Certificate Revocation 181
Polling and Pushing: Two CRL Delivery Models 182
Building X.509 Trust Networks 182
Root Certificates 183
More Risks and Precautions 187
Distinguished Names 188
Certification Practice Statement 189
X.509 Certificate Data 189
Challenge Response Protocol 190
Review 190

Chapter 18 Pretty Good Privacy and the

Web of Trust 193
The History of PGP 193
Comparing X.509 and PGP Certificates 194
Building Trust Networks 196
Bob Validates Alice’s Key 196
Casey Validates Alice’s Key Sent by Bob 197
Dawn Validates Alice’s Key Sent by Casey via Bob 198
Web of ‘Trust 200
PGP Certificate Repositories and Revocation 200
Compatibility of X.509 and PGP 201
Review 201

Part IV Real-World Systems 203

E-mail Cryptographic Parameters 204
Negotiation of SSL and [Psec Cryptographic Parameters 204
User Initiation of Cryptographic E-mail, SSL, and IPsec 205

Chapter 19 Secure E-mail 207

Generic Cryptographic E-mail Messages 207
Invoking Cryptographic Services 209
Confidentiality and Authentication eA
_Choosing Services 7a
Positioning Services 2
Deterring E-mail Viruses 218
Review PAN)
 CONTENTS

Chapter 20 Secure Socket Layer and Transport

Layer Security
History of SSL
Overview of an SSL Session
An SSL Session in Detail
Hello and Negotiate Parameters
Key Agreement (Exchange)
Authentication
Confidentiality and Integrity
TLS Variations
Anonymous Diffie-Hellman
Fixed and Ephemeral Diffie-Hellman
Comparing TLS, SSL v3, and SSL v2
A Big Problem with SSL v2
A Possible Problem with TLS and SSL
Generating Shared Secrets
Bob Authenticates Himself to Alice DotComStocks
Review

Chapter 21 IPsec Overview

Enhanced Security
Key Management
Manual Distribution
Automated Distribution
IPsec Part 1: User Authentication and Key Exchange
Using IKE
SSL/TLS and IPsec Key Agreement
Security Association
Phases
IKE Nomenclature
Benefits of Two-Phase Key Exchange
IPsec Part 2: Bulk Data Confidentiality and Integrity for
Message or File Transport
Protocol and Mode
ESP Examples
AH Examples
Management Control
Implementation Incompatibilities and Complications
Review

Chapter 22 Cryptographic Gotchas

Replay Attack
xiv CONTENTS

Man-in-the-Middle Attack 24/7

Finding Your Keys in Memory
Does Confidentiality Imply Integrity?
Example 1
Example 2: Cut-and-Paste Attack
Public Key as a Cryptanalysis Tool
Example 1: The Chosen Plaintext Attack
Public Key Cryptographic Standards
Example 2: The Bleichenbacher Attack
BlackHat Uses Bob’s RSA Private Key
Review

Chapter 23. Protecting Your Keys

Smart Cards
Types of Smart Cards
What’s Inside a Smart Card
Protections and Limitations
Smart Card Attacks
Review

Epilogue

Appendix A_ Public Key Mathematics (and Some

Words on Random Numbers)

Appendix B_ (A Few) IPsec Details

Bibliography oor

Index 345
 FOREWORD

e-Everything
Every January for the past 10 years, members of a cult from all over the world
have headed to Silicon Valley for a summit. In the early years, only a few cryp-
tographers, mathematicians, and forward thinkers in the relatively new field of
computer security showed up for this then-obscure event, known as the RSA
Security Conference. Imagine, if you will, a group of distinguished eggheads
and computer nerds getting together to talk about cryptographic algorithms and
how they might one day be used to solve security problems.
In Internet years, that first event was a very long time ago. A decade for
everyday people, it was an Internet generation for those of us involved with
computer technology. The problems were small and often theoretical then. We
couldn’t imagine the looming frenzied pace of change, the way the World Wide
Web (World Wide what?—it wouldn’t be invented for another year) would
explode, and the e-izing of everything and anything. With those changes came
what those original visionaries predicted: e-fraud, e-theft, e-vandalism, e-scams,
e-viruses, and e-everything-else bad along with e-everything good.
Nowadays, there are dozens of computer security conferences and exhib-
its. Even so, our understanding of cryptography is weak, often only abstract.
Practical applications of cryptography are just beginning to become common-
place. These solutions are still young. It is a struggle for an information tech-
nology professional, and often an information protection professional, to
understand how security technology works and how to apply cryptography
appropriately to solve real business problems.
The RSA Security Conference is bigger than ever. Hidden among the prod-
uct demos, sales pitches, and seminars, interesting technical papers are still pre-
sented. It was at RSA 2000 that I met the joyful and energetic H. X. Mel. Like
many others, he and Doris Baker had a vision of how to improve security. Their
vision, however, was not product implementation, but education—to make
cryptography understandable to the people who need it. Their book, this book,
is more than “Alice and Bob” diagrams and yet less than a tome full of math.
xvi FOREWORD

Instead, it is filled with examples of the principles behind today’s solutions, ex-
plained with an interesting historical perspective.
Even after 10 years as an IT architect in the field of information protection
for a major electronics manufacturing company, I learned a lot from this book.
I think you will, too.

—John Kinyon
 PREFACE

A Tool for Everyone

In the past, cryptography was used mainly to secure the communications of the
powerful and influential, the military and royalty. But the widespread use of
computers, and the attacks to which they are vulnerable, has expanded the need
for secure communications around the globe. This book describes the protec-
tion afforded by modern computer cryptographic systems and explains how the
pace of modern technology requires continuing attention to the security of
those systems.
The advent of computers changed a great many things, but not the funda-
mentals of cryptography. Through stories and pictures, Cryptography Decrypted
presents cryptography’s evolution into a modern-day science, laying out patterns
from the past that are applicable today. It also gives you a thorough understand-
ing of terms that are destined to become as much a pait of our language and life
as megabyte and Internet. As you begin to think about controlling various aspects
of your life using wired or wireless communication, on line all the time, your
understanding of cryptography—its benefits and its pitfalls—will make you feel
a little more in control of a rapidly changing world.
Because rapid advances in the speed of hardware will continue to threaten
the security of current cryptographic methods, it’s essential that you choose
appropriate techniques and perform ongoing assessment if you want to main-
tain your digital security. You can make such choices and assessments only if you
know the basic concepts of cryptography. Cryptography Decrypted offers you that
knowledge through visual representation of difficult concepts, an easy-to-use
reference for reviewing key cryptographic terminology, and instructive histori-
cal information.
You need little or no background in cryptography to read this book. Nei-
ther does it require technical or math genius. It’s designed so that anyone from
CIOs to self-taught computer enthusiasts—and everyone in between—can pick
up this book without any knowledge of encryption and find it fascinating, un-
derstandable, and instructive.

xvii
PREFACE

If you have some understanding of computer cryptography, Cryptography

Decrypted is systematic and comprehensive enough to solidify your knowledge.
It provides a simple description of the component parts of secret key and pub-
lic key cryptography. (Those who already understand and don’t wish to cover
any more material about secret key cryptography may choose to read only Parts
II through IV, bypassing Part I.)
Throughout the book, we use images to clarify cryptographic terms. After
explaining the basic cryptographic components, we describe real-world crypto-
graphic systems, some possible attacks on those systems, and ways to protect
your keys.
The book provides a historical framework on which to build your under-
standing of how and why computer cryptography works. After a discussion of
how cryptography has evolved into an essential Internet tool, we analyze secret
key exchange problems and then explain the evolution of public key cryptog-
raphy, with its solution to the key exchange problem. Along the way we explain
some simple background on the math tricks that make public key cryptography
secure.
Traditionally, those who have thoroughly understood cryptography have
been trained as mathematicians or scientists. Our goal here is to explain com-
puter cryptography with rather little discussion of math. If the esoteric details
aren’t of immediate concern to you, you can skip Chapter 11 (“Making Public
Keys: Math Tricks”), Chapter 14 (“Message Digest Assurances”), and the appen-
dixes without diminishing your understanding of the basic concepts.
Appendix A describes some aspects of public key mathematics, including
inverses, primes, the Fermat test, Diffie-Hellman, DSA, elliptic curve, and
pseudo-random number generation. Appendix B provides details of IPsec, a
security system introduced in Chapter 21.

Acknowledgments
It was no small task to wade through and distill the technical and historical
material to write a cryptography book that would be understandable to a broad
audience. We could not have done it without the considerable help we received
from conscientious reviewers who left no stone unturned. They included Paul
Brown, Sheila Frankel, Peter Honeyman, Russ Housley, Doug Hughes, John
Kinyon, Marcus Leech, Greg Rose, Ben Rosengart, Anton Stiglic, David Youd,
and Neal Ziring.
Of course, we might never have gotten through the many months of cre-
ation and rewrite without our editors, Tyrrell Albaugh, Karen Gettman, Betsy
Hardinger, Mary Hart, and Lisa Hernandez, who helped us stay focused on the
light at the end of the tunnel.
Our heartfelt thanks to them all.
 INTRODUCTION

Welcome to the Front Line

If your computer is connected to or transmits over an electronic network, your
data is on the front line. Attackers are getting more competent by the month,
and their attacks more intrusive, virulent, and widespread—from Melissa to the
Love Bug to the unknown virus that ate your hard drive.
Although few of us leave our valuables unlocked, few of us know how to use
cryptographic locks to secure our digital possessions. By the time you finish
reading this book, you will.
Most governments, including those of Canada, China, France, Saudi
Arabia, and the United States, consider cryptographic tools to be munitions of
war, so it’s reasonable to think ofpotential attacks on your data as a kind of war.
Your opponent is anyone who wants to read, modify, or destroy your private
documents.
In large part, this is a book about the cryptographic keys and methods you
use to safeguard your digital possessions. Figure I-1 shows cryptographic keys
and the symbols we use to portray them. Part I of this book explains secret keys

A Devastating Opponent
In World War Il the German Observation Service Beobachtuncs Dienst,
or B-Dienst—was a small group of codebreakers who played a powerful
role in the Battle of the Atlantic. B-Dienst uncovered the positions of
Allied convoys that German submarines then destroyed, devastating the
Allied Atlantic forces from 1941 to 1943. For example, during three days
in March 1943, the Germans sank 21 Allied vessels while losing only one
submarine. Better communications security and new technologies such
as sonar helped the Allies turn the tide.

xix
XX INTRODUCTION

Oran 4
Secret Key Public Key Private Key

Figure I-1 Cryptographic keys used in this book.

and secret key methods. Part II describes public and private keys and public
key methods. Part II explains how keys are distributed, and Part TV shows how
three real-world systems—secure mail, Secure Socket Layer (SSL), and Internet
Protocol Security ([Psec)—use cryptographic keys and methods.

Need a Quick Read?

Section Chapter(s) Major Points Covered

Part I: Secret Key 1-4 The difference between cryptographic methods and cryptographic
keys. The security of modern cryptographic methods. Best
feasible attack against a modern method: trying each key
5 Effect of technology in weakening DES
6 Historical insights into cryptography
i Secret key assurances: confidentiality, authentication, and integrity
8 Maintenance and management problems in sharing secret keys
Part II: Public Key Y) Foundation of public key cryptography: easy and hard problems
10 Public key encryption and public key assurances
i Simple cryptographic mathematics
Ws Private key encryption and private key assurances
13 Detecting message modification with nonkeyed message digests
and hashes
ia Message digest assurances
15 Comparing secret key, public key, and message digests
Part IL: Distribution 16 Digital certificates: digitally signed public keys
of Public Keys 7 x.509 digital certificates, certificate authorities, and certificate
revocation
18 Pretty Good Privacy (PGP) compared to x.509
Part IV: Real-World 19-21 Examples of real-world systems (secure e-mail, SSL, IPsec)
Systems jp Some cryptographic attacks
Oe Protecting your keys with smartcards
Appendixes A Mathematics underlying public key technology
B IPsec details
 PART |

SECRET KEY
CRYPTOGRAPHY
I: 1977, two innovations in computer cryptography forever changed 3,500
years of message disguise engineering and brought cryptography closer to be-
ing a tool everyone would need and use. Part I, “Secret Key,” explains the con-
cepts used to develop one of these innovations—Data Encryption Standard
(DES)—and leads into the second innovation, public key cryptography, dis-
cussed in Part II.
Part I describes the current state of secret key computer cryptography. The
first five chapters explain two important concepts:

¢ Secret key cryptography offers secure ways to store secrets.

e¢ The attacker’s most feasible attack against these secure methods is to
try each possible key.

‘To prove these two concepts, Chapters | through 5 quickly proceed from
ancient to modern cryptographic methods. If you’re familiar with these two
concepts, you may choose to skip to Chapter 6. That said, we believe the first
five chapters offer a quick and instructive overview that will help you understand
secret key cryptographic protective devices.
Chapter 6 shows how cryptography evolved into a mathematical science.
Chapter 7 describes protections and assurances available with secret key
cryptography.
Chapter 8 explains why secret key cryptography, by itself, is not sufficient
to protect communications on the Internet. The bulk of the book and appen-
dixes explain public key cryptography and demonstrate why the Internet
needs it.
 ive teeta en ag . wee (ws oammritycry -
7e>
ia »ShaDrvwet ling
Fara paces ere Park: arnt igs Puma
. Gt F09 re hot. : re Aan if ~~ ete leurei yu

De it. ae sieges i) 0 siv-epaiairets (hd °AAPA) ary

ied agen May win Ss am woth a

: a A
ae 604 ye Pye) Ser Ri oie a ete - ——————
a \ ot a a ig) mane «ety Ie te Lena
aE =i 5+ 6" pale. lium
Sale REAMOD 1) 10 Fd PEA ier neler) yp ne! | @ ote ch bay —
De PPalggarss « or eer oe gt be >. (pee 2 eg wf * :
7 — (eu ¢ . © eon — :
; m4 ’ Be aye | A

‘iy ny ly (erwet | aoa karl Pema elrrvtaah@ Grell): spas oT in eres dy

aie * Ian aire th vines ‘Seatesl TVS ar rw 8! ont byt
Jif) ( JG: ul AD cana Tina Wires =
eS etsiivnveg, © etna > Seba ofRP rsrqucky rth ae
en a) ern ap Rhli py eas here a ;
Aggertigt nats fet |’ sty ee | Sie. tee rl Owrah A veajer DP - _
Call Tei ire © RiP re werte 6.4 ‘jee
: Arh : by Sag zu =
rim Al Bor ve Friap tte —~ oto qatl + ¥ :
nl wth s5itsalte Paieae iW pian ehuteires — ;
1 i : olan! Vets 40 ee ately Ae nn se 7

5 ~~ e1 aw ~~ -
/ see a SUES 1 iia, | oe
i

a hoe
 Chapter 1

Locks AND Keys

WwW: begin our explanation of cryptographic concepts with the help of two
people you'll get to know well in this book: Alice and Bob, a fictitious pair
often used for illustration in cryptography books. Alice and Bob’s first task is to
illustrate the difference between method and key.

Locks and Combinations

Imagine that a master locksmith has designed a combination lock and published
the entire inner workings—the nuts and bolts of every mechanism in the lock.
Alice buys a lock and changes the combination. The design is so secure that no
one, not even the locksmith, can figure out the new combination. Of course, this
means that if Alice forgets the combination, no one can open the lock without
trying every combination or breaking the lock.
One lock design _ Further imagine that this one lock design is used to make many locks. Sup-
used to make many pose Bob also buys a lock and changes the combination. Just like the locksmith
locks who designed the lock, Alice has no clue how to figure out the combination on
Bob’s or anyone else’s lock. So Alice can’t open Bob’s lock, and Bob can’t open
Alice’s lock (see Figure 1-1).

12 Right, 18 Left... 34 Right, 28 Left...

Figure 1-1 Alice’s and Bob’s individual locks are only two of many instances of the
identical lock design.
A CHAPTER 1 Locks AND Keys

Alice checks that her lock is secure against the force she believes an oppo-
nent might use to open it and checks that the lock can’t be opened by merely
pulling on the handle. She also wants to have confidence that it would take an
intruder a long time to try all the possible combinations. How long Alice wants
someone to have to try different combinations determines the kind of lock she
buys. If Alice’s only concern is to protect her luggage against a nosy baggage
attendant, she needs a lock to stop someone for only a few minutes. She might
buy a lock with only a few possible combinations. On the other hand, if Bob
wants to protect his valuables at an athletic club, he needs a lock with more
possible combinations (see Figure 1-2).
Let’s use the lock and key analogy to see how Alice could protect her elec-
tronic possessions. Imagine that Alice has an envelope containing a secret mes-
sage and that her lock seals the envelope to keep others from opening it. The
message inside the envelope is readable if the correct combination opens the
lock. The message is unreadable if the lock is opened any other way, such as
breaking it with a hammer or a crowbar.
Cryptography is both the lock and the combination (or key). Just as there
are a variety of locks, there are a variety of cryptographic methods and keys (see
Figure 1-3). The joining of the method and the key determines how secure
Alice’s secret message is from an opponent who doesn’t know the combination.
Strength of lock Bob can use a lock with the same design as Alice’s lock; many people know
and number of that the method is to turn right to number 1, left to number 2, and finally right
possible again to number 3. But it’s Bob’s individual lock combination (his personal num-
combinations bers 1, 2, and 3) that enables his lock to secure his personal belongings and keeps
(keys) Alice, or anyone else without the lock combination, out. What matters most in
securing Bob’s personal belongings is the strength of the lock and the number
of possible combinations or keys.
In the same way, the lock strength and the number of possible keys are criti-
cal to securing Bob’s and Alice’s electronic communications. Alice and Bob can
use a cryptographic method or lock with the same design (as long as it’s a strong
method) and still securely hide their personal messages from a savvy opponent,

Few Possible Many Possible

Combinations Combinations

Figure 1-2 Some locks have very few possible combinations; others have many pos-
sible combinations.
 DEFINING CryPTOGRAPHIC TERMS 5

z= Secret a

Figure 1-3 Cryptography is both a lock and a key.

or each other, because their individual cryptographic keys are different. As long as
there are enough possible keys to keep an opponent busy trying them for a long
time, Bob and Alice can feel somewhat secure that the secrets in their messages
wont fall into the wrong hands.
Why is the number of possible secret keys one of the most important fac-
tors about a secret key cryptographic method? It’s obvious that a physical lock
with 10,000 possible combinations is much more secure than a lock with only
10 possible combinations. In cryptography, this has not always been true. In the
following chapters, you'll learn why.

Defining Cryptographic Terms

Definitions: Cryptography is both the lock and the combination (key) that protects a secret
cryptography, message from anyone who doesn’t know the key. Cryptographers are the people
cryptographer, who create a disguise to hide the meaning. A key that will reclaim the meaning
cryptanalyst, is given only to those for whom the message is intended.
cryptology Cryptanalysts are mathematical and linguistic analysts who remove the dis-
guise created by cryptographers. Because they haven’t been given a key, they
attempt to pick the lock to meaning using statistical analysis. Cryptology is the
study of both cryptography and cryptanalysis.

Hiding Writing
Cryptography is like building a crypt, where people have traditionally
buried valuables for safekeeping on the way to the afterlife. It comes
from the Greek word kryptos, meaning “hidden” or “covered,” the Old
Norse hreysar, meaning “heap of stones,” and the Lithuanian krauti,
meaning “to pile up.” It’s a way to hide writing (“-graphy”) but retain a
way to find it again, like piling stones on a gravesite to which you want
to return.
6 CHAPTER 1 Locks AND Keys

Making and Solving Puzzles

For as long as people have been communicating, the Bobs and Alices of the
world have looked for secure ways to share and hide meaning. When people
began using written language to reveal meaning, fields such as cryptography and
cryptanalysis were created by the clever mathematical and linguistic minds
among us. These people like to make and solve puzzles and often spend lifetimes
doing it. Some make a living at it, whereas others only dabble; many contrib-
ute to the field. Over time, many good ideas and systems have been created but
not fully understood, recognized, or used until much later.
To stay one step ahead of cryptanalysts, cryptographers have invented vari-
ous ingenious ways to hide meaning. Although computers have made many
older methods obsolete, technology has put cryptographic minds to work in new
ways.
If you want to lay a good foundation for looking at computerized disguis-
ing techniques, the first step is to understand how complexity affects a crypto-
eraphic system. So before we clarify how today’s computer methods work, let’s
take a brief look at the history of the cryptographic craft, starting with simple
methods and leading up to the more complex. In the next two chapters we'll
discuss the two major components of ancient and modern secret key cryptog-
raphy: substitution and transposition.

The Father of American Cryptography

Thomas Jefferson earned the title “Father of American Cryptography” for
a device he called a wheel cipher. It remained undiscovered for nearly
a century until two others—a Frenchman and an American—indepen-
dently created the same device. Although the wheel cipher was a good
method for its time, Jefferson put it aside and apparently forgot about
it. In 1922, the year the device was discovered in the Library of Con-
gress among Jefferson’s papers, the U.S. Army adopted an almost iden-
tical cipher mechanism others had developed.

Review
If you’re connected to or transmit data over an electronic network, your data is
vulnerable to attack by anyone else who is connected to that network.
Cryptography is both the lock and the combination (or key) that can be
used to help protect your data. There are a variety of cryptographic methods
and keys. ‘Iogether, the method and the key determine cryptographic security.
 Chapter2

SUBSTITUTION AND
CAESAR’S CIPHER

f your mission is to win a war, maintaining secrecy is mission-critical. Ancient

warrior Julius Caesar was extremely eager to disguise written messages, and
he came up with Caesar’s cipher, a simple system that is not particularly secure
once the method is known.
Caesar's cipher Here’s a slightly simplified version of how it works. Say Caesar wants to
example: FIVE send a written message, FIVE AM, to his generals, instructing them to attack
AM encrypts to at that time. In the emperor’s system, each letter in the message FIVE AM is
GJWF BN advanced one place in the alphabet. F becomes G, I becomes J, V becomes W,
and so on. The generals receive GJWF BN, and, knowing that the procedure to
reclaim the message meaning is “subtract 1,” they convert G back to F, J to I,
and so on until the message makes sense.
To aid decoding, Caesar may have given his generals the helpful chart
shown in Figure 2-1.
‘To encrypt (disguise) a message, you convert each letter of the message to
the letter directly underneath it in the chart. A is converted to B and so on.
Mathematically, this method can be described as follows: message letter + 1
place = encrypted (disguised) letter. Z, the last letter, is converted to A.
Definitions: cipher, A cipher is a method that encrypts or disguises text. The undisguised text is
plaintext, ciphertext, called plaintext, and the disguised text is called ciphertext. The process of trans-
encryption, forming plaintext to ciphertext is called encryption. The reverse is called
decryption, decryption. Encipher and encrypt mean the same thing: to confuse or hide mean-
encipher, encrypt, ing. Similarly, decipher and decrypt both mean to remove disguise and reclaim
decipher, decrypt meaning. See Figure 2-2 for some helpful pictures.

Plain IN SRG, ID) WB I Gaal ah I) eI ME INE PO RR SGP AW AY WEE NEL

Cipnered BC.) Eek 2G el ake be NIN Oia? Ol Ropoe Ue Wi XY. Ze A

Figure 2-1 This chart helps in decoding Caesar's messages.

8 CHAPTER 2 SUBSTITUTION AND CAESAR’S CIPHER

ENCRYPTION

Five —
AM 1F >

Plaintext Encryption Ciphertext

Method & Key

also known also Known as also Known as

as cleartext cipher method/key encrypted text
diguised text

DECRYPTION

— Five
= AM

Ciphertext Decryption Plaintext

Method & Key

also known as
decipher method/key

Figure 2-2. Encryption and decryption.

Note that even though it’s called “plaintext,” it could as well be “plain pic-
tures” or “plain audio” or “plain video.”
Definition: In Figure 2-1 we used the labels “Plain” and “Ciphered” because Caesar’s
substitution cipher cipher transforms a plain alphabet into a ciphered alphabet. Each letter of
ciphertext substitutes for a letter of plaintext. This is called a substitution cipher.
Caesar’s cipher combines a method—called, in mathematics, an a/gorithm—
and a key. The method is “add,” and the key (how many times to do it) is 1.
Julius Caesar’s cipher was actually slightly more complex; he rotated the cipher
alphabet three places. If you understand “F + 1 = G,” it follows that “F + 2 = H”
and “F + 3 =I,” assuming that your cipher alphabet is in alphabetical order. The
F in FIVE becomes I, so FIVE AM translates to ILYH DP (see Figure 2-3).

1. Purists prefer to categorize this as a shift cipher or rotational cipher, a special kind of
substitution.
 SUBSTITUTION AND CAESAR’S CIPHER 9

eee pee Ce aie eke lav Ne Ose PaO Roms MUMS. WW Kn YZ,

Drs Gal Glee hile Tn OM ON OQ. PP Om, Esta T BW VW ak AY? 2 AB IC

Figure 2-3 Caesar’s cipher variation: rotating each letter three places.

Advancing three letters, instead of one, shows what happens when you add
levels of complexity to a key. An adversary trying to understand your disguised
message must work a little harder to reclaim plaintext from an enciphered mes-
sage that rotates the alphabetic code by three letters (Figure 2-3) than with a
ciphered message that rotates the alphabetic code by one letter (Figure 2-1).
Julius Caesar used the ciphered alphabet in Figure 2-3. His nephew,
eae Augustus Caesar, said to be less able than his uncle, used the ciphered alphabet
dictates number of | 1n Figure 2-1. Figures 2-1 and 2-3 show the results of using two Caesar’s cipher
possible keys—l1 and 3, respectively—of 25 possible keys; that is, there are 25 different
encryptions ways to disguise letters of the alphabet using a Caesar cipher method.
The concentric alphabet circles in Figure 2-4 can be used to picture any
possible key. The outer ring is fixed and does not rotate. It’s the plaintext alpha-
bet that is used to write the message. The inner, or cipher, circle is the cipher
alphabet used to create the disguised text. Each movement of the inner cipher
circle creates a new cipher alphabet. The diamond shapes in key | point to the
letters FIVE AM.
In Figure 2-4, one of the four keys—1, 2, 24, or 25—1s displayed inside each
circle. The inner wheel rotates the “key” number of positions: 1, 2, 24, or 25.
After 25, the cipher alphabet has turned full circle and the key returns to 0. In
other words, at “key” 0 the message and ciphertext are the same—oops, not a
disguise!
The key tells how far to move the inner circle alphabet from the initial
position where the A’s in both alphabet circles match—remember, that’s key 0.

The Origin of Cipher

The Arabic sifr is the root from which we get our words cipher and
zero. After the thirteenth century, Europeans began using Arabic nu-
merals rather than Roman numerals because decimals and zeroes made
European medieval mathematicians very happy. But the concept of zero
confused common people in the Middle Ages; so when they referred
to something that wasn’t quite clear, they compared it to something
they considered a mystery: the cipher. Eventually the word cipher
evolved to describe concealment of clear meaning.
10 CHAPTER2 °@ SUBSTITUTION AND CAESAR’S CIPHER

“<eGu? eG My
DP
Seok
& ¢ eae ec
2 504« otllky we&
9 ¢ @ « L

mS Bap 72 ica Clecmre i=ae

Ps)
? o © 7 is
eae hes ® we oe
a TAN ©) DT 4 RN
fairs nN 1%
GJWF BN HKXG CO

$Guy oF Gy
SII ae
oe rs) “ €
agp NE i $

4 See > Se
Nx : a e
pice 2 © ane 0 ©
©
Se 4m4s 1%pier
aes o 05; Hy
ea.
4qa¢ ©
DGTC YK EHUD ZL

Figure 2-4 Four Caesar cipher keys—1, 2, 24, and 25—encrypting FIVE AM.

The four different cipher combinations for the plaintext message FIVE AM are
shown below each cipher circle. Because all the inner cipher circles are in alpha-
betical order, the differing ciphertext is due only to the key, which tells how many
places to rotate the cipher alphabet in relation to the message alphabet.

Cryptanalysis of Caesar’s Cipher

Caesar's cipher:
Caesar’s cipher is a little bit confusing if you’ve never seen it, but the confusion
only 25 possible is easy to overcome. ‘lo cryptanalyze a message using this cipher, you simply put
keys. Much too the encrypted text on the top row and repeatedly increase each letter one alpha-
few. betic position (see Figure 2-5). For example, you replace J with 7, then K, then
L, and so on. Most trials produce gibberish. When you are successful, the En-
glish plaintext jumps out upon inspection.
It’s important to understand that Caesar’s cipher has only 25 possible keys.
Next, you'll see other methods with many more possible keys.
More keys means Throughout this book the “key” concept is the same. Like Caesar and his
more work for your generals, you and your confidant share a key. The object is to make your adver-
adversary. sary work a long time trying many, many keys. Hopefully, by the time an
 EMPOWERING THE MASSES 11

zl J M Z. I E Q
+2 K N A J F R
+3 i8 O B K G S
+4 M P C i H av
117 Z D Pp Y U G
+18 A E Q Wh W H
+19 B F R A Ww I
+20 G H S B x j
+21 D G “ib G Y K
+22 E H U D Z is
+23 F I V E A M
+24 Grea Ww F B N
425 H kK x G € e)
+26 I iL Y H D P

Figure 2-5 Caesar’s cipher cryptanalysis: Meaningful text appears after 23 tries.

adversary finds the correct decrypting key, the encrypted message has little
value. At 5:01, the value of a FIVE AM attack message is greatly reduced. We'll
see cryptographic methods that put your adversary to work for thousands of
years, just in case unforeseen technological advances permit your adversary to
do in hours what used to take years.

Empowering the Masses

After Gutenberg invented the printing press, more people learned to read. With
more people knowing the reading code, encryption systems such as Caesar’s
cipher were subjected to increasingly educated scrutiny. Secure hiding de-
manded increasingly elaborate encrypting.
Anyone who can read can quickly try all 25 keys. Also, if you figure out just
one letter of ciphertext that corresponds to plaintext, you’ve got the key. For
example, knowing that E is encrypted as K (see Figure 2-6) lets you determine
all the letters in the inside cipher circle by simply filling in the remaining alphabet
in alphabetical order. Well, what to do, what to do? Don’t teach them to read!
Although it may not be ethical or particularly democratic, this approach worked
for quite a long time. Major institutions supported it for centuries (and based on
the reading scores of many American children, perhaps some of them still do).
If you want to keep important secrets hidden from the reading masses, us-
ing 25 alphabetically ordered alphabets does not provide enough complexity. It’s
like using a combination lock that has only 26 numbers on the face—and a one-
number combination key (say, turn to 3) opens the lock.
12 CHAPTER 2 SUBSTITUTION AND CAESAR’S CIPHER

GH Gq
o* 12 Sera
& % (a & . PES

< Cie 2 2S
<o ites a
a Re 7 o, ae
i ? a *Vznt" ©

44% 4a 4

Figure 2-6 Cryptanalysis of one letter determines the entire cipher alphabet.

Messages Inside and Out ©

Even though ideography, the written form of Chinese, is very old, cryp-
tography wasn’t used in China in ancient times. The ancient Chinese
didn’t have a great need to disguise their writing because few people
knew how to read. Also, ideographic writing doesn’t lend itself to cryp-
tography as well as an alphabetic language does, so the Chinese found
other ways to hide meaning. Diplomatic and military messages were
memorized or hidden on or in the messenger.

Using cipher circles, the key is the number of positions to move the inner
cipher circle. Caesar’s generals simply moved the inner cipher circle to the po-
sition indicated by the key number. Based on probability, Caesar’s adversaries
must try about half the keys (about 12), on average, until they stumble on the
correct key and decrypt the message.

The Importance of Separating the Method

and the Key
Review: method
Before we add a huge number of keys to befuddle hound-dog cryptanalysts, let’s
and key reinforce the concepts of method and key. The method in a Caesar cipher type
of encryption system is to rotate the alphabetic ordering of the ciphertext 1 to
25 places in relation to the plaintext. Caesar’s adversaries, as well as generals, can
know the method, but they need the key to quickly decrypt the message.
The method Is not
The important concept is that anyone can have the cryptographic method.
secret. The key is The method “shift the letters in the alphabet” can be written on the walls of the
secret. Roman Coliseum, published on the front page of The New York Times, or posted
 AppinG Keys 13

to an Internet site. You may share many secrets, but all your secrets are built on
the fact that you and your confidant share a secret key. Your secrets are only as
secure as your secret key. Even though an adversary may know your encryption
method, it is the joining of the encryption method with your unique secret key
that confuses messages for anyone who doesn’t have the secret key.

Adding Keys
There are ways to make an adversary try many more keys than discussed so far
to find the correct decrypted message. Suppose Alice gives Bob two different
cipher circles (see Figure 2-7).
Both cipher circles have an outer, alphabetically ordered plaintext ring, but
each cipher circle has a different inner ring. Cipher circle 1 is Caesar’s cipher,
but the inner ring of the cipher circle 2 is different: We’ve altered the normal
ordered sequence of the alphabet.
This system allows Alice to increase complexity by doubling the number of
possible cipher alphabets. Now Bob will need a two-part secret key. Part 1 of
the secret key identifies which cipher circle—the first or the second—to use;
part 2 of the secret key is just like Caesar’s cipher key: the number of positions
to rotate the chosen ring.
Now Alice has 50 possible encrypted alphabets: 25 from each cipher circle.
Cipher circle 2 disguises plaintext better than cipher circle 1 because the inner
cipher alphabet ring is not in alphabetic order. This means that knowing a single
letter on the inner ring does not immediately allow an adversary to fill in the rest
of the cipher letters.

Gay, GH,
o° Wear sues @* eae 2
Geos ‘4 © Con Y ae
ee. * a
eo Ua 2 —. Saw oe
NY : poe te d 4
ie ae ne: a
txin R* XO 4y Worist*
Anus 4qn¢°*
Cipher circle 1 Cipher circle 2

Figure 2-7 Two cipher circles with different inner cipher alphabets.
14 CHAPTER 2 © SUBSTITUTION AND CAESAR’S CIPHER

Cipher circle 2’s inner ring is just one of about 40 billion billion billion
possible inner rings. This is much more than 49 billion + 40 billion + 40 billion.
It is 40 billion times a billion times a billion—much too large a number for
anyone to imagine.

A Weakness of Caesar’s Ciphers: The Failure to Hide

Linguistic Patterns
Given the high number of possible inner rings, you might think that every Alice
could simply make some unordered rings and thereby ensure safe encrypted
messages forever. Not so—it’s still easy to break or cryptanalyze.
Let’s see why. Suppose the plaintext message is EVERYONE MUST ATTACK
BEFORE FIVE AM. It doesn’t matter which cipher ring or key Caesar uses to
encrypt the message. To illustrate our point, let’s use the cipher alphabet shown
in Figure 2-8.
Merely using a large
The encrypted message certainly looks like gibberish—but not to a
cryptanalyst, who would instantly see that there are six Hs and three Cs. Because
fal eS is E is the most used letter in English, the cryptanalyst would substitute E for all
not a secure the Hs and then substitute T, the second most used letter, for all the Cs. The
method. decryption is well under way even though the cryptanalyst isn’t using the secret
cipher circles and doesn’t know the key.
The billions and billions of possible keys don’t necessarily slow a
cryptanalyst very much. That’s because the Caesar’s cipher method does not
disguise the linguistic patterns of letter and word frequency in the encrypted
message. In this type of encryption, those patterns are the same as in the
plaintext message. This aspect of the Caesar cipher method gives a good
cryptanalyst enough information to very quickly recover plaintext.
ne So far we’ve looked at one-alphabet, or monoalphabetic, ciphers, and we’ve
monoalphabetic seen how using alphabetic and nonalphabetic order affects complexity. In Fig-
ure 2-8, every plaintext A is replaced by ciphertext Z, every plaintext B is re-
placed by ciphertext P, and so on. Using a single alphabet to substitute letters
in a Message is not secure enough to stop a cryptanalyst.

A 1B © ly We eS el I fe A aM INE OY) i @) IR SS AP IW Ww Ay Oe Ne

ae kVA I Ne SR? Ou Us Yo ORV AWe CIR S Siler Gas kek letG= pr &
EVERYONE MUST ATTACK BEFORE FIVE AM

HEHSDVOH YKJC ZCCZXF PHMVSH MREH ZY

Figure 2.8 A substitution cipher. The plaintext (normal) alphabet is on the top row; the cipher alphabet
is on the bottom row.
 More Comptex SUBSTITUTION: VIGENERE’S CIPHER 15

Letter and Word Frequency

Facts about letter and word usage in languages have helped cryptolo-
gists encrypt and decrypt messages ever since Arab linguists started
doing statistical analysis on Arabic languages more than a thousand
years ago. Here’s a look at letter and word frequency and letter com-
bination statistics from the English language.
e Eis the letter used most often, followed by t, 0, a, and n.
e Tis the most common letter at the beginning of a word, Eis the most
common letter at the end of a word.
e Aand /are the only single-letter words in English. The words of, to,
and in are the most frequent two-letter words; the and and, the
most frequent three-letter words; that, the most frequent four-let-
ter word.
e The most common double letters are /I, ee, oo, tt, ff, rr, nn, pp, and
cc. Th, he, an, re, er, and in are the most frequent two-letter com-
binations. The, ing, and, ion, and ent are the most frequent three-
letter combinations.
e Nis the consonant that most often follows a vowel.

More Work, More Money

Edgar Allan Poe amazed nineteenth-century readers with his amateur
facility in solving monoalphabetic ciphers. But he decided to focus on
his more lucrative writing after winning a $100 prize for “The Gold-Bug,”
a story based on cryptography. Poe wrote to a friend that cracking ci-
phers took too much of his time.
Unlike Poe, the best cryptanalysts found cipher cracking lucrative.
France’s Antoine Rossignol and England’s John Wallis, seventeenth-cen-
tury cryptanalysts, could spend months cracking ciphers; but for such
pros the time was well spent because those in power paid them well.

More Complex Substitution:

Vigenére’s Cipher
Confusing the Now let’s look at a way to make the cryptanalyst do a lot more work. Cryptog-
cryptanalyst: a raphers added complexity to Caesar’s cipher, naming the method Vigenére’s
more complex cipher for Blaise de Vigenére, a French cryptographer of the 1500s.
encryption method
and longer keys
16 CHAPTER 2 © SUBSTITUTION AND CAESAR’S CIPHER

Everything’s a Cipher
In 1586, Vigenére published a book in which he seemed to lump cryp-
tography with everything. He wrote, “All nature is merely a cipher and
a secret writing. The great name and essence of God and his wonders,
the very deeds, projects, words, actions, and demeanor of mankind—
what are they for the most part but a cipher?”

Like Caesar’s cipher, Vigenére’s method can be compared to a combination

lock (see Figure 2-9). Caesar’s cipher is like the lock on the left. The combina-
tion is a single number: Turn left to 3, and the lock opens. It was a breakthrough
in security—2,500 years ago. Vigenére’s cipher, on the other hand, is like the
lock on the right; the combination is more complex. It was a breakthrough in
security 400 years ago. (It’s instructive to see how Vigenére confuses the
cryptanalyst, but don’t get bogged down trying to understand the details. In-
stead, focus on how Vigenére enhanced Caesar’s method, as explained in a
moment. Although substitution is a key tool in modern cryptographic methods,
both Caesar’s and Vigenére’s ciphers are obsolete and insecure.)
Figure 2-10 shows how Vigenére used a longer key and many alphabets to
confuse the relationship between plaintext and the secret key. In our example,
the secret key first transforms an E to an F, and then it transforms an E to an M!
Definition: The Vigenére cipher looks like Caesar’s cipher, but instead of one cipher
polyalohabetic alphabet, there are 26—a polyalphabetic cipher. This kind of cipher adds a twist
to Caesar’s cipher, and that makes the disguise more effective. The key length,
combined with all the cipher alphabets, makes this system much better at hid-
ing meaning than Caesar’s cipher.

Locks and Caesar’s Cipher— Locks and Vigenére’s Cipher—

A Simple Key A More Complex Key

Left to ‘3’ Left to ‘3’

Right to ‘27’
Left to ‘12’

Caesar Cipher Key = 3 Vigenére’s Cipher Key = 3, 27, 12

1st Letter Turn Left to 3 ‘ 1st Letter Turn Left to 3
2nd Letter i 2nd Letter Turn Right to 27
3rd Letter : 3rd Letter Turn Left to 12
Ath Letter... . Ath Letter... Wepeat sy 271k.

Figure 2-9 Comparing the Caesar and Vigenére methods.

 More CompLex SusstiTUTION: VIGENERE’S CIPHER 7

Ciphertext

VW
X bee Zz

M oe tS) V eWe X Y Bae A

MN > > x
M UNO y Z AgeeC

L M N O U yow
x y
Me ONE Or P:Q 1) D

Ge

10 KE M N O

1225s
Ni ©

135
N © —_d

eo oe FG. oH

15 VW X MN O

16 Q yveWX MONS OP.

17 Me ae sOmiPa@

18 M N O

19 P
QE RES

2 1) MN O

21 M N O

22 WE MN O

23 M N O

24 Mr Nao

Vib Lek MN O VON EXSY

Figure 2-10 The Vigenére cipher is a polyalphabetic cipher.

18 CHAPTER 2 SUBSTITUTION AND CAESAR’S CIPHER

At the top of the Vigenére table is the plaintext alphabet in alphabetical

order. Along the side are numbers, and any combination of those numbers could
be the key. For our example, we’ve picked 1-5-8-11-14 as the key.
Suppose an early seventeenth-century Alice wants to send Bob the en-
crypted message EVERY ONE UP AT FIVE AM. Let’s encrypt plaintext EV-
ERY to ciphertext FAMCM. Notice that the first alphabet at key 0 in the Vigenére
table in Figure 2-10 is the same as the plaintext alphabet at the top of the table.
So just as in Caesar’s cipher, key 0 does not disguise the message.
Confuse the Using 1, the first number in the key 1-5-8-11-14, plaintext E encrypts to
relationship ciphertext F. If you follow E along the top of the table to its intersection with
between plaintext row | along the side of the table, you’ll find the cipher letter F.
and secret key. The next number in the key is 5, and the next letter to encrypt is V. Plaintext
V encrypts to ciphertext A—the intersection of V along the top of the table with
row 5 along the side.
The word EVERY in our message now contains a second E. Here’s where
this system is much better than Caesar’s cipher. Can you see that this more com-
plex key combined with multiple alphabets allows the second E in our message
to be encrypted differently from the first E? This is an important advance be-
cause it makes the encrypted message resistant to statistical analysis (e.g., iden-
tifying the most commonly used letters such as E and T).
Following this pattern, you should be able to look at the table now and
easily understand how R and Y must be encrypted. Because the key contains only
five numbers, 1-5-8-11-14 is used again and again to encrypt each five-letter
chunk of plaintext.
The entire message, EVERY ONE UP AT FIVE AM, encrypts to FAMCM
PSK FD BY NTJF FU—if we got it right. It’s easy for humans to make
enciphering errors, even using an encryption table. Although cryptanalysis of
a Vigenére’s cipher is a tough problem for most people, it’s easy for a well-de-
signed computer program.
Adding key lensih In public key cryptography, key lengths grow to 200 or more digits. How
causes a little more big a number is that? Try picturing all the atoms in the known universe. Well,
work encrypting that’s not enough because there are many fewer atoms in the universe than “1
plaintext, but it followed by 100 zeroes.” If you can’t imagine how big a 200-digit number is,
makes the imagine how such a number complicates the task of determined cryptanalysts.
cryptanalyst do
That’s the idea behind long keys.
much more work.
Vigenére’s cipher is just like Caesar’s cipher in that the method is public
knowledge but the key is secret. Vigenére’s method was a major conceptual
breakthrough because identical plaintext letters seldom encrypt to the identi-
cal ciphertext letters. Although your adversary can have a copy of the table you
and your confidant use to encrypt and decrypt messages, it still takes a long time
to decrypt the ciphertext without the secret key. Vigenére’s cipher disguises
simple linguistic patterns.
 REVIEW 19

Methods, Keys, and Error

Look what happens when the method is not secure and there are not
enough keys. For hundreds of years, the Vigenére cipher created in the
1500s was mistakenly thought by some people to be invincible. During
the U.S. Civil War in the 1860s , the Confederate Army was among those
that invested too much trust in this legend. Confederate cryptographers
used a Vigenére cipher, usually combined with three keys. Mistakes
were frequent, and having to turn the cipher into Morse code added
to the difficulty. As a result, telegraph transmission sometimes was so
troublesome that Southern soldiers would gallop over to the sender to
get the message firsthand.
Dutch cryptologist Auguste Kerckhoffs—the first to distinguish be-
tween the cryptographic method and the specific key used with it—
would not have approved of the South’s method and keys. In 1883
Kerckhoffs wrote that wartime cryptography needed to be efficient,
portable, and easy to understand. It should also have a key that was
easy to change and should lend itself to telegraphic transmission,
Kerckhoffs argued.

Review
Caesar’s cipher uses a simple cryptographic method (lock): Substitute each letter
in the message with a letter from a ciphered alphabet. The key determines
which ciphered alphabet to use for this monoalphabetic substitution.
Cryptanalysis of this centuries-old substitution method is simple and can be
done more than one way. For example, because there are only 25 possible keys,
an adversary can try each one until something emerges that looks like a message.
Another approach, frequency analysis, is to look for the most frequently appear-
ing letter; in English, that letter is e.
Other substitution ciphers, such as the Vigenére cipher, are polyalphabetic
and use a similar lock and key. The lock is the Vigenére cipher table. Even as-
suming that an adversary has the same Vigenére table used to encrypt the mes-
sage, the message’s key provides secrecy—if it is not discovered. The use of
many possible keys forces the cryptanalyst to work much longer and makes sta-
tistical frequency analysis more difficult. This approach is like a lock that re-
quires the user to correctly turn to three numbers in a certain order, making it
more difficult than a combination of only one number.
Statistical analysis is a snap for a computer-toting cryptanalyst. By the same
token, however, the computer also allows cryptographers to deeply bury the
linguistic patterns that help cryptanalysts uncover meaning.
 aayu”®
a a —<= o—=?.>
hE ie

- Pd hl “—
a ;
ee ae

e 6 ~—~sta) . =?
"Re ai: e?. me 7
ree = oF) ra :

5 ae. ae rer a
iL Wy > rea’?
‘o "4 -3->
aS Ds, ode
ee ee gp
niet rg \ amy
AT : 7. 7 7 +
a) Bog 7 - et im bs 7
sre 7 , >
aa = ® MW
- 4] ‘il, ee m4 op

- : a

ar a
é pat : ff
J nips a? ? A j ’ é
SV re .
Pai 6 7 \ 4
hy i bey he
7 td VPlease al
i) 4 pet veld iba ¢
Aveo, it's yar’ igv Law tA
Mae ; ry e6,
2 ls j 4 “yal
4 Ipiaped od
eu 1h i"
amr
pew « JO
on
. Mi, ee e mee ial
fia , (hit (
rT ae:
. y : le
LES) ier ahi (oo gy & q i a Nw _
san
le Gah wer
linet ie
~~ i sere

bi “ae rate!
1. sf :

‘££ zs a
 Chapter3

TRANSPOSITION CIPHERS?
MoviING AROUND

Definition: Ss: far, all the ciphers we’ve discussed are substitution ciphers, in which
transposition plaintext letters are replaced by ciphertext letters. Changing the positions of
ciphers plaintext letters is another enciphering technique. It’s called transposition, as in
transferring position. Many newspapers have transposition puzzles called
“Fumbles.”
Substitution = A simple transposition of FIVE AM moves each letter one position to the
replacement® left. FIVE AM is encrypted to IVEA MF. Although the letters have been moved
Transposition = around, all the ciphertext letters are the same as the plaintext letters. There’s no
relocation replacement or substitution of letters.
To illustrate this ciphering technique, let’s look at a more complex transpo-
sition: the simple love note LAST NITE WAS HEAVEN PLEASE MARRY ME.!
The table in Figure 3-1 encrypts

LACS Nel TEA W ASS EE AVE IN P To ACS eM ALR Rey ME

to
Ee AACE AE Rese AN ATR 1A S YeNeS UN: EVEL EL PoE

Figure 3-1 A transposition table. The letters are read down the columns.

1. Notice the spelling of “nite.” Cryptographers often use nonstandard spelling.

21
22 CHAPTER 3 © TRANSPOSITION CIPHERS: MOVING AROUND

Each plaintext letter Figure 3-1 is like a six-column word processor equipped with word wrap-
transfers to a new ping. It’s a 5 x 6 grid. The method used to read letters from the grid is the ci-
position. pher. This particular cipher reads letters down the first column, then letters
down the second column, and so on. The ciphered letters are the same as the
plaintext letters except that they are positioned to form a new pattern. The in-
tended receiver must know two things: the length and width of the grid and the
way letters are read from the grid.

Patterns and Cryptanalysis

Like substitution ciphers, transposition ciphers can be analyzed for patterns. We
choose to show some patterns to others; for example, we might show that we are
married by wearing a wedding band. If we want to disguise our marital status,
however, we might remove the ring. But a telltale white mark on the ring fin-
ger exposes a meaningful pattern to an observant eye.
Looking for patterns The observant cryptanalyst looks for telltale patterns in substitution and
transposition ciphers. The cryptanalyst uses persistence and best guesses, look-
ing for any clue to ferret out patterns.
In Chapter 2, we show how a cryptanalyst uses letter frequency patterns.
Just as there are known frequencies of single letters (such as e and f), there are
also known frequencies of two-letter combinations (such as ofand zm) and three-
letter combinations (such as the and and). Because transposition ciphers only
rearrange plaintext letters, you can try rearranging ciphertext that produces
combinations such as the and and. Also, if you can make guesses about some

Telltale Patterns
Giovanni Battista Porta, a sixteenth-century Italian cryptologist, was one
of the earliest cryptographers to divide ciphers into transposition and
substitution. His book on cryptography, De Furtivis Literarum Notis, is
instructive reading even today.
Unlike many people involved in cryptography during the Renais-
sance, Porta refused to consider polyalphabetic ciphers (such as the
Vigenére cipher) invincible. Instead, he proposed some methods of
attack. He also offered techniques to improve message disguise, such
as using synonyms in plaintext and deliberately misspelling words to
avoid the kind of word repetitions and spelling patterns that are used
to recover meaning (a modern example: pa$$word for password).
Porta wrote that knowing the subject matter of the message can
speed decryption because the cryptanalyst can look for key words. To
keep his readers attentive, he used risqué plaintext examples in his
book.
 ADDING COMPLEXITY 23

words that might appear in the message, it provides a gateway into decrypting
the entire ciphertext.
For example, our plaintext and ciphertext love note,

LASTNITEWASHEAVENPLEASEMARRYME
encryptsto
i 1h eASASEe EV ReseVvew Ace l AES Y NSN EOMODH Pals

Probe for key This may look like mish-mash, but a small clue could give away the secret.
words. If your beloved has a parent who objects to your romance and has an eye peeled
for key words? such as marry or elope, your mish-mash could rapidly become
meaningful text.
Searching for MARRY, we see that the ciphertext has two Ms and many As.
Not much help here. But wait, there are only two Rs, and only one Y. Gotcha.
Let’s bold those letters and see what emerges.

LTELAAEAERSWVARTAESYNSNEMIHPME
4. 4--____- « ——

Beginning at the Y and going backward five letters is an R; five more letters
back is another R, and five letters before that is an A. Six letters before the A
(wrapping around) is an M.
Using the pattern Now let’s try the pattern to see whether it reclaims more plaintext. Begin
on ciphertext below at the first letter L and then skip five, skip five, skip five, skip five, and so
on until you reach the end of ciphertext line. Then skip six and wrap around:
L, skip to an A, skip to an S, skip to a T, skip to an N, and so on.

LTELAAEAERSWVARTAESYNSNEMIHPME

If our suspicious parent is a cryptanalyst, he or she may even try skipping

letters first—skip one letter, skip two letters—to look for a pattern before look-
ing for key words such as elope or marry.

Adding Complexity
The following minutia is interesting but not essential to understanding the rest
of this text.
You might wonder why transposition ciphers are used if they’re so easy to
crack. It’s because transposition ciphers can be more difficult to crack if they are

2. A guess about key words is often referred to as a crib.

24 CHAPTER 3 TRANSPOSITION CIPHERS: MOVING AROUND

repeatedly used on the same plaintext. Figure 3-2 repeats the transposition ci-
pher in Figure 3-1, and Figure 3-3 uses transposition to encipher the output of
Figure 3-2. After two transposition cycles the cryptanalyst has a more difficult
job unmasking the disguise and reclaiming the original plaintext.

LAST NITE WAS HEAVEN PLEASE MARRY ME

Here’s the first transposition:

LTELA AEAER SWVAR TAESY NSNEM IHPME

Here’s the second transposition:

LEVSM TAAYI EERNH LRTSP ASANM AWEE

Remember that after the first transposition cycle the last four letters of
MARRY (ARRY) were five spaces apart. Two transposition rounds make a better
disguise. The original plaintext letter ordering has been reversed; the Y in
MARRY has been transposed to a new position before the Rs. Although there’s
still a pattern, it’s more difficult to find. Figure 3-2 and Figure 3-3 show the two
transpositions of plaintext.
Computerized secret key cryptographic methods use many transposition
cycles. The secret key cryptographic method most used currently, the Data
Encryption Standard (DES), applies 16 cycles of transposition (and substitution)
to each group of about eight letters (see Chapter 5, “DES Isn’t Strong
Anymore”). .
Complex Before computers were invented, cryptographers often used manual tech-
transpositions niques to add complexity to their transposition methods. For example, Figure
3-4 shows another, more complex way of reading text from a grid. Instead of
using a transposition method of reading down each column, a diagonal pattern
is used. The plaintext message ABCDEFGHIJKL is transposed to
AEBICETUGDAKL,

LAST NITE WAS HEAVEN LTELA AEAER SWVAR

PLEASE MARRY ME TAESY NSNEM IHPME
1b, AN Soe I pe eS Ne ek
ene VW A Ss: eH EY #a~ i R See
Pe Age EB IN. SP VO cAG Ree aeemeeA. oi
L EA S EM » S Yo SNe 3S. ee
Ahapeers XN. ivi. Mie Fite Pe aN 2B

Figure 3-2 The transposition cipher from Figure 3-3 The output of Figure 3-2,
Figure 3-1. enciphered,
 ComPUTER TRANSPOSITION 25

Figure 3-4 An example of diagonal transposition.

Computer Transposition
‘Transposition ciphers can also be looked at as a set of instructions, one instruc-
tion for each letter. Let’s quickly review a simple 2 x 3 transposition, shown in
Figure 3-5. The message FIVE AM is transposed to FEIAVM by reading down
column 1, then column 2, and then column 3.
Instead of building a transposition table with rows and columns, it’s faster
to “tell” each letter its new, transposed location. Figure 3-6 enciphers the FIVE
AM message without building a transposition table. The first letter, F, moves to
the first position, that is, from location | to location 1. The second letter, I,
moves to the third position, that is, from location 2 to location 3. The third
letter, V, moves to the fifth position, that is, from location 3 to location 5, and
so forth. Computers do this kind of relocation very fast—millions every second.
Computer Even a complex transposition cipher, such as the diagonal transposition
programs use cipher, has an easy set of instructions, or transposition map. Figure 3-7 is a map
transposition maps. _ of the diagonal cipher displayed in Figure 3-4. Row | is the beginning position
of each letter. Row 2 is the ending position.

1 2 3 4 5 6

vNise ee oa
FIVEAM if 4 2 5 3 6

Example:

F I V E A M

PRIAVM | Sts ae
PE I A V M

Figure 3-5 Asimple 2 x 3 transposition. Figure 3-6 This method enciphers FIVE AM
without the need to build a transposition
table.
26 CHAPTER 3. ® TRANSPOSITION CIPHERS:? MOVING AROUND

Figure 3-7 Diagonal transposition map for the cipher in Figure 3-4.

That is, the top row is the initial position of each letter in the message. In
our message, in Figure 3-4,A, B, C, andD are inthe first, second, third, and
fourth positions respectively. The bottom row in Figure 3-7 shows their new
positions: A is moved to the first position, B to the third position, C to the fourth
position, and D to the ninth position. Computer programs use this kind of table
to rapidly move (encipher) individual bits of the plaintext.

Complex Versus Simple Transposition Ciphers

A transposition cipher that helped the North maintain telegraphic se-
crecy during the U.S. Civil War was made more complex with the use of
key words, code names for important names, and nulls, or meaningless
letters, symbols, or numbers designed to confuse cryptanalysts. Al-
though the North developed a complex ciphering system, the South
was using such a simple cipher that it need not have bothered encrypt-
ing messages at all.
In the 1876 U. S. presidential election between Samuel Tilden (D)
and Rutherford B. Hayes (R), Democrats communicated the information
needed to buy votes using a transposition cipher similar to the one
used in the Civil War. But the cipher was simpler, and, when it was bro-
ken, the scandal was revealed by the press.

Combining Substitution and Transposition

As cryptographers dug into the mazelike patterns of substitution and transpo-
sition cipher methods, they found that using the two types together created
much better concealment than either method alone. In fact, using substitution
and transposition cipher methods repeatedly on ciphertext does such a good job
of disguising patterns that the encoded message is harder to decipher unless the
adversary has other kinds of clues, such as those acquired through espionage.
Such a cipher combination nearly defeated the Allied forces in World
War I, had it not been for the dogged persistence of Georges Painvin, a French
army cryptanalyst whose cutting-edge mind reclaimed meaning from a message
 ComBINING SUBSTITUTION AND TRANSPOSITION Q7

How to Lose 33 Pounds in a Seated Position

French cryptanalyst Georges Painvin lost 33 pounds in his efforts—
essential to Allied victory—that cracked ADFGVX, a German cipher used
in World War |. Painvin’s educated guess was that the cryptographic
method used both substitution and transposition. His frequency counts
showed that the substitution key changed daily, and he assumed that
the same was true of the transposition key. Painvin had to wait for
enough messages to be sent on the same day so that he could compare
two messages of about the same length that used the same keys. His
cipher know-how led him to compare word endings, find repetitions,
and make frequency counts to crack the cipher for that day only.

that pinpointed where the Germans planned to attack the French. He broke
ADFGVxX, one of the toughest field ciphers in cryptographic history.
ADFGV<X was so difficult that the Allies never developed a general solu-
tion to it during the war. Cracking it nearly always depended on finding, on the
same day, two messages of about the same length with similar endings or begin-
nings. The strength of this cipher lies in its ability to break up plaintext and
scatter the text’s normal characteristics, which cryptanalysts typically use in re-
constructing a transposition cipher.
By itself, simple substitution or simple transposition is not secure, but com-
bining substitution and transposition makes a very secure encryption method.
Modern computer cryptography has made the most of combining transpo-
sition and substitution to befuddle even the most brilliant of the brilliant
cryptologic minds. How? By doing what computers do well without any mis-
takes—perform simple operations numerous times. It’s just what a computer is
good for, and it’s also what humans find tedious and error-prone.
As you'll see in Chapter 4, a correctly constructed computer encryption
program so completely hides any concealed pattern that cryptanalysts are forced
to find new ways to uncover meaning.

Brain Cracking
Sixteenth-century Italian cryptologist Giovanni Battista Porta wrote
tellingly of the results of prolonged cryptanalysis, calling it “brain fag”
(toil) and advising that such efforts “should not go on uninterrupted.”
Seventeenth-century English cryptanalyst John Wallis, while in his sev-
enties, complained about “cracking his brains” spending eight to ten
hours a day for seven weeks trying to solve ciphers for England’s rulers,
William and Mary. Wallis described it as “hard service for one of my
years.”
28 CHAPTER 3 TRANSPOSITION CiPHERS: MOVING AROUND

Review
Secret key cryptography uses a combination of transposition and substitution
to create strong encryption methods. In transposition ciphers, letters or bits are
moved from their initial plaintext position to create ciphertext.
A method that uses repeated transpositions makes a cipher more difficult
to crack because it obscures the plaintext patterns more effectively. The Data
Encryption Standard and Rijndael use multiple combinations of transposition
and substitution.
Even before computer cryptography, combinations of transposition and
substitution ciphers coupled with frequently changed keys could be very diffi-
cult to crack, as illustrated by the ADFGVX cipher used in World War I.
 Chapter4

DIFFUSE AND CONFUSE?

How CryPTOGRAPHERS
WIN THE END GAME
ie istorian James Burke, creator of the PBS television series Connections, has
repeatedly shown that great inventions are the result of the efforts of a
number of people coming together to form a single powerful, useful tool. The
same thing happened as a result of the centuries-long focus by many sharp-
edged minds on cryptography. Although substitution and transposition ciphers
became more complex, they could be attacked using statistical methods.
Substitution % The statistical weakness in substitution ciphers is that they don’t change the
cryptanalysis frequency of alphabetic letters. For example, a cryptanalyst might count the
number of times each letter appears in ciphertext. Looking at the letter count
of ciphertext CFGPSF GJWF (see Figure 4-1), a cryptanalyst typically guesses
that the most frequent ciphertext letter (F) is really a disguised E. If that guess
is correct, the cryptanalyst is on the road to cracking the ciphertext. But if the
F is not an E, the cryptanalyst may guess it’s a T. Given a somewhat longer
ciphertext message, the cryptanalyst may guess the most frequent two-letter
pattern is TH; and so forth.
Computers do Eventually the cryptanalyst will discover clues that uncover what’s disguised
Statistical analysis by the substitution cipher. With the help of computers, that eventuality happens
very quickly. much sooner than the cryptographer would like.

CFGPSF GJWF

Letter Counts of Ciphertext

GEal Pam Fees Sigal Gre Wart a4

Figure 4-1 Counting ciphertext letters.

Diffusion
Diffusion = Ideally, ciphertext should look as if
it’s a random string of letters keystroked by
substitution + a chimpanzee. The cryptographer wants to eliminate any clues in the ciphertext
transposition that help the cryptanalyst to reclaim plaintext. Mathematically speaking, this

29
30 CHAPTER 4 Dirrus—E AND Confuse: How CrypTOGRAPHERS WIN THE END GAME

means eliminating statistical relationships between the ciphertext and the un-
derlying plaintext.
Combining transposition and substitution diffuses (distributes or disperses)
the statistical structure of plaintext over the ciphertext. Not surprisingly, this
method is referred to as diffusion.
With much of science and technology, little of what we think of as “new
discovery” is ever really new; rather, our current understanding is built on the
musings of previous generations. Even Sir Isaac Newton gave credit to others.
“Tf Ihave seen further than you,” he wrote, “it is by standing upon the shoul-
ders of giants.” Similarly, diffusion—a technique that current computer cryp-
tography depends on to create a method so unbeatable it can be made public
without compromising security—had its beginnings in Greece more than 2,000
years ago.

The Polybius Cipher

Polyboius Polybius (203-120 be), a citizen of ancient Greece, is credited with inventing
(checkerboard) an encoding scheme that converts letters to numbers. Figure 4-2 shows an ex-
cipher ample of a Polybius square—more commonly known as a checkerboard cipher—
using the English alphabet. The Polybius square converts plaintext letters to
numbers. The numbers are the ciphertext.
The first digit in the ciphertext letter is found in the letter row, and the
second digit is in the letter column. For example, A is converted to 11; B is con-
verted to 12; Mis converted to 32. Ina 5 x 5 square, two letters must share the
same cell; in Figure 4-2 those letters are I and J, so they are inferred from the

Figure 4-2 A Polybius square.

1. Diffusion is actually transposition along with an additional function. The

function can
be a substitution method or something more elaborate.
 DIFFUSION 31

Knuckles and Ears

Prisoners made good use of the Polybius square by using their knuck-
les, or some other hard object, and ears. Russian prisoners developed
an audible system, called a knock cipher, to turn taps and pauses into
letters based on the Polybius square. Later, in World War Il, a form of the
Polybius square called the quadratic code was used to disguise sensi-
tive information in telephone communications about development of
the atomic bomb.

context of the encoded message. Other versions of the Polybius square may have
different letters share the same cell.
Polybius hoped to use his square to send messages great distances by means
of torches and hilltops. The sender holds a torch in each hand, raising the torch
in the right hand the number of times to signal the row and the torch in the left
hand the number of times to signal the column. Although one account says
there is no known instance of his square being used this way, it was used to turn
letters into digits and then into sounds.
A Polybius secret
In Figure 4-2, letters in the Polybius square are laid out in alphabetical
key square order. But a non-alphabetical grid is more difficult to cryptanlayze. For instance,
a non-alphabetical grid could be made with an easily remembered secret key
F
phase, known only to H. X. Mel and Doris Baker—“If we had more time, we
would have written a shorter book”. The first line of the grid would contain the
ez
ae
@a letters I F W E H insteadofA B C D E, the second line would contain
—
>
una
(Ge Omi
ee <
rosta te
©!
<a)=< N the letters A D M O R insteadofF G H I J, andsoon. By the third line
letters start to repeat; they’re skipped and not used again. So the third line would
contain the letters T U L V N. Note the secret key phrase does not contain
all the letters in the alphabet; specifically, it does not include C, G, J, P,
QO, x, VY; of Z. These lettersare placed at the end’ot-the grid.
Let’s look at Figures 4-2 and 4-3 to see how letter patterns can be diffused
using this method. Figure 4-2 shows a Polybius square that is used in Figure 4-3
to encrypt JESTER to 24 15 43 44 15 42 by substituting two numbers for
each plaintext letter.

Figure 4-3 The Polybius square in Figure 4-2 is used here to encrypt JESTER.
32 CHAPTER 4 © Dirruse AND CONFUSE: How CryptoGrAPHERS WIN THE END GAME

A Useful Cipher Never Used

Almost 2,000 years after Polybius came up with his useful square, Pliny
Earl Chase, a Harvard-trained child prodigy and professor of natural
science and philosophy, proposed the idea of manipulating the num-
bered ciphertext from Polybius’s square. In 1859 Chase wrote a three-
page paper for Mathematical Monthly in which he described how he
split the numbers in the resulting ciphertext (called fractionating) and
subjected them to other mathematica! operations to further disguise
them. Cryptographic historian David Kahn reports that although Chase’s
techniques were better than many methods, no one has ever used
them.

Can you see that the Es are showing through the ciphertext? After inter-
Two numbers for
one letter
cepting a few messages and seeing all these 15s (Es), a savvy cryptanalyst will
identify this statistical pattern very quickly and crack the cipher. A more secure
method will hide all those 15s and other number patterns.
Because each plaintext letter is represented by two numbers, you can eas-
ily scatter Es by combining a Polybius substitution with a transposition method
to transpose some of the numbers. Figure 4-4 rearranges 24 15 43 44 15
42 (JESTER) by splitting apart each number; 24 is separated vertically into a
2 and a 4; 15 is separated into a 1 and a 5; and so on.
Now read the numbers along the first and second row: 21 44 14 45 34
52. The 15s (Es) seem to have vanished. Of course, they’re still there. But re-
arranging the number pairs scatters the ciphertext representation ofE.The top
halves of each number are grouped, as are the bottom halves, forming new num-
ber combinations.
We have effectively cut each letter in half and shared its parts with the ad-
jacent ciphertext letter. For example, in Figure 4-5 visualize the first E in
JESTER being split into two halves. The top part of the E, represented as a 1,
is attached to the top part of the J, represented as a 2; and the bottom half of
the E (5) is attached to the bottom half of the J (4).
Transposition Is a Diffusion dissipates or disperses parts of letters throughout the ciphertext.
component of Our simple Polybius square represented E as two numbers: 1 and 5. Because
diftusion. computers represent each letter as seven (or eight) 0’s and 1's, diffusion can dis-
sipate the frequency patterns so well that they cannot be used in the
cryptanalysis. The JESTER is still there, so to speak, but he has effectively van-
ished—except to those who share the secret key.
 THE PRINCIPLE OF CONFUSION 33

24 15 43 44 15 42’

°21 44 14 45 34 52’

Figure 4-4 Transposing some Polybius square numbers from Figure 4-3.

Split up:
J(24); E(15); S(43); 1(44); E(15); R(42)

To: 21 44 14 45 34 52

Figure 4-5 In this simple example of diffusion, note how the J and E are mixed
together. Diffusion disperses parts of letters throughout the ciphertext.

The Principle of Confusion

Definition: The cryptographer assumes that the cryptanalyst has ciphertext and knows the
confusion cipher (encryption) method. Diffusion frustrates the cryptanalyst’s attempt to
use ciphertext patterns to recover plaintext. Because the cryptanalyst doesn’t
Diffusion hides the have plaintext, he or she uses ciphertext and the cipher method to try to figure
relationship out the encryption key. The principle of confusion prevents the cryptanalyst from
between using ciphertext to figure out the secret encryption key.
ciphertext and
In Caesar’s cipher, the cryptanalyst can figure out the secret encryption key
plaintext.
with very little ciphertext. Even ciphers such as Vigenére’s (Chapter 2) aren’t
Confusion hides strong enough to stop the cryptanalyst from figuring out the secret encryption
the relationship key.
between Confusion usually means that the cryptographer has invented a complex
ciphertext and substitution method. Even if the cryptanalyst can figure out some ciphertext
secret key. patterns, he can’t use the cipher method and patterns to figure out the secret key.
DES, discussed in Chapter 5, was successful for many years because it uses a
complex (nonlinear) substitution method.
34 CuHapter 4 © Dirruse AND Conruse: How CrypTOGRAPHERS WIN THE END GAME

Cryptographic Locks and Keys

Definitions: Ciphers that use confusion and diffusion are called product ciphers. Each appli-
product cipher, cation of confusion and diffusion is called a round. Product ciphers that use many
round, iterated rounds, such as DES, are called iterated product ciphers. Historically, effective
product ciphers cryptanalysis tools don’t work against correctly designed iterated product
ciphers.
A correctly designed iterated product cipher encrypts a message that no
one—even the cryptographer who designed the method—can easily decrypt
without knowing the secret key.
De nitioneonute In other words, with an iterated product cipher, statistical analysis of
force attack, strong ciphertext letters is no longer the most practical way to recover the original
method message. Now the cryptanalyst’s best attack is to try each possible secret key, a
brute force attack. A cryptographic method requiring a brute force attack that also
has so many keys that a brute force attack is not feasible is referred to as a strong
method.

This is much too nard to break

(because the encryption
method is secure).

I'll have to try each Combination Key

Welle Wyler WASP oon Wale WOR OSE oo.
El eget Ape ao 8221 NOH OO) he.

10,1,1; 10,1,2; 10,1,3; ... 10,2,1; 10,2,2; 10,2,3; .../

This is taking too long; this is too strong!

Figure 4-6 A cryptanalyst’s most practical attack is to try each possible key.
 REVIEW 35

Modern secure cryptographic methods are strong; the cryptographer can

(and arguably should) publish the method for everyone to see and attack (see
Figure 4-6). For example, the National Institute of Standards and Technology
(NIST)—the U.S. government agency overseeing the next approved secret key
encryption standard—mandated that the encryption method of each candidate
be openly published.
Always use a Practically, this means that Alice uses a published secret key method, which
published secret has many potential secret keys. If she keeps her secret key secret, her secrets will
key method. stay secret, too. But with the rapid pace of technological change, Alice must
make sure that she keeps up with the times and periodically assesses whether the
method she chose years ago is still secure today.
Chapter 5 discusses the Data Encryption Standard, a previously strong
cryptographic secret key method that was published more than 20 years ago.
DES has about 70 quadrillion potential keys and is secure against traditional
cryptanalysis. But even though DES is less than 30 years old, it’s no longer se-
cure (strong) because its 70 quadrillion potential keys aren’t enough to stop
today’s attacks.

Review
Diffusion is a technique that combines transposition and substitution to disperse
the statistical structure of plaintext over the ciphertext. A cryptographer uses
diffusing techniques to eliminate all clues in the ciphertext that might help an
adversary figure out the plaintext of a message. Whereas diffusion hides the
relationship between ciphertext and plaintext, confusion hides the relationship
between ciphertext and the secret key.
Secret key cipher methods that use diffusion and confusion are called prod-
uct ciphers. Correctly implemented product ciphers that have great quantities
of potential secret keys are called strong. This means that an adversary’s best
attack is to try each possible secret key, called a brute force attack. But strong
cryptographic methods also have enough possible secret keys that a brute force
attack is infeasible.
Strong methods are made more secure by being published because they can
be scrutinized and tested by cryptanalysts.
 =
- ee di =o
eS Ses oe — cain

2. AG °
pie reelair Me erieliy ape i ene veoly-
ita ny rh UE ms i "set i 0 T Fal i ma peg hige

We ee lk ee ee ee ee So,
phy) Oe» cine as > sae Tel
iprermmener (neha “fin 1 ae
A¥ mi: jl iy eat oe : 7
a ala Mod orip acre I roe ’ a aparny
en A igi lay atu) Lay ri pw 7 sia i-y a
ot athea Ky we 2 0 @ j L~¢ oF ~~ , -
can 7 ani “4 Pigs ce UT EP DTT) lat
herald’ arfthie' hg maar
ime H lite yy } Te ee ee a S
: viii » ba Sie “ake ij 1 mL
WW) aunt fi ! PPriey i : =
rs. Wa), Ol aree yearnt iu ee
mr hong? = er i .
bine es |

| woivall
igri ive ction Viorel Piinety 4 eayeru ones =
a
; itso TiLD > '@ ein tg T ray svt oe *, :
‘Aldea hue ae ab 1 ee he 04. x abit ia ae Te :
) cpterri oge arty fn rigs I A : iy Taae ee
Firaseik JOS iio fi paar i i! ip we Cr 7
GAG gt pee | pit, dis i if :
intoneloten). Lite tye y 9Ayhe = ee iy rie ;
or capal paddy Meck itis itp! be5 ? VA: bie es Oe = _
-_ Gp pee BE ee Bie wee! a, ee TN 4 ge ig reer | 7 -
; ato rth reat +) ehh) “fe OR Sli thi yi “A Pagstut (ia 2
POPPE Eye! 1 eel | NitES ee Repieh ee RRA Oy: Se gan fe HT
; mt NAR nd ee doi 7
Tes Wi aye ;
Tye? ex, MyFaces laure ie a AS i
-
 Chapter 5

DES Isn’t
STRONG ANYMORE

DES Is one of two I: Chapter | we point out that during 1977 there were two innovations in
innovations that computer cryptography that forever changed 3,500 years of message disguise
brought engineering. The introduction of the Data Encryption Standard was one of
cryptography into these changes; the invention of public key cryptography was the other.
the computer age. DES uses 16 rounds of confusion and diffusion (iterated product cipher) on
each group of about eight plaintext letters. Statistical analysis of letter fre-
quency—the mainstay of cryptanalysts for thousands of years—is no help in
attacking a well-designed method such as DES. The DES method is so secure
that the cryptanalyst has no choice except to attack the keys.!
Review: With a So why is DES no longer strong if the best attack is to try all possible keys
strong method, the and there are an enormous number of potential DES keys? Simply stated, tech-
best attack is to try nology has made brute force attacks much faster.
each key, but a On average, without knowing the right key, the computer cryptanalyst must
strong method has cycle through half of all possible keys before stumbling on the correct one. And
too many keys to because there are trillions and trillions of possible keys, modern cryptanalysis
try.
requires super computer power—so much computer power that, until recently,
computer cryptanalysis has been prohibitively expensive for all but the most
well-endowed governments. With increasing amounts of computing power in
increasing numbers of hands, searching through all those keys is no longer the
chore it used to be for many people.

The Historical Need for an

Encryption Standard
The new era in cryptography began in the late 1960s, when companies began
needing secure ways to send files. Although there were many security

1. DES is susceptible to advanced cryptographic attacks, such as differential and linear

cryptanalysis. Compared with trying all the keys, these attacks can be successful with
less effort, but they are still impractical. ‘These attacks are complex and beyond the
scope of this book.

37
38 CHapTER 5 DES Isn’t STRONG ANYMORE

companies that claimed to have cryptographic computer programs, there was

no industry standard—no widely accepted encryption method that had a uni-
versal seal of approval.
Financial institutions in particular wanted a standard encryption method
that they could have confidence in and could use for secure data exchange. They
needed something that was tested by someone they could trust. Whom to trust?
How about someone whose reputation was built on keeping secrets?
Because U.S. national security depended on secure cryptography, govern-
ment agencies involved in cryptography, such as the National Security Agency
(NSA), had not been open with their expertise. Secrets have always been the
mainstay of the NSA. According to one quip, the NSA was so secret in its be-
ginning that its acronym stood for No Such Agency. Its budget is still secret. But
the needs of private enterprise were beginning to pressure computer cryptog-
raphy to come out in the open.’
NIST chooses DES, Finally, in 1972 the National Institute of Standards and Technology
a cipher (NIST), then known as the National Bureau of Standards, decided to assist in
developed by IBM. the development of a secure cryptographic method (algorithm). In 1974 it
settled on DES, a cryptographic method submitted by IBM. It is also known as
the Data Encryption Algorithm (DEA).
Much of the underlying DES cipher research is credited to an IBM re-
searcher, Horst Feistel, who in 1967 began experimenting with a combination
of substitution and transposition ciphers. Before computers, transposition was
difficult to mechanize and too complex to do by hand. Increases in the size of
computer memory made it possible for Feistel to use transposition in his sys-
tem. Feistel blocks are still used in many (if not most) secret key ciphers.
NSA assists In DES did not evolve into the standard without significant discussion and
development. even suspicion by some participants. NIST requested and received assistance
from NSA on DES development. Some people have said that NSA modified
DES so that the agency could easily reclaim plaintext without using a brute
force attack, installing what is commonly known as a trapdoor function. NSA
shortened the secret key originally proposed by IBM to 56 bits from 128 bits.
Some people believe that NSA altered IBM’s algorithm to ensure that IBM
had not secretly included its own trapdoor function. Some people also believe

What’s in a Name?
Feistel wanted to call his system Dataseal. IBM shortened the term dem-
onstration cipher to Demon. Later, Demon morphed to Lucifer, which
phonetically contains the word cipher. In the end, the name evolved
to DES.

es.
de Its interesting to note that the Internet israe
driving the development of today’s cryp-
tographic tools.
 THE HistoricAt NEED FOR AN ENCRYPTION STANDARD 39

that NSA wanted to control the use of DES and expected DES to be imple-
mented only in hardware, which can be controlled more easily than a software
implementation. A hardware-only implementation of DES would have been
harder to copy, and thus the method would have been less easily scrutinized.
Because software implementations of DES became widely available, people have
been able to study a method that NSA claimed was secure.
NSA didn’t publicly respond to the criticisms about DES during the 1970s,
but a heated debate ensued nevertheless. For example, people complained about
the reduction of the key size to 56 bits; but because the DES method was in-
tended to last fewer than 10 years, NSA could have easily justified its decision
in that a 56-bit key was considered more than secure for that time period. There
were also complaints that NSA changed some of the method’s inner workings,
perhaps to prevent cryptographic attacks NSA knew about but did not want to
disclose.
Despite the controversy, DES was adopted as the federal standard for un-
classified documents in 1977 and is the most widely used cryptographic method
in history.
NIST made the DES design public, and the advent of computer chips per-
mitted faster processing, making software implementation of DES feasible.
Cryptographic Because any program that can be implemented in hardware can be implemented
methods in software, DES software implementations began to appear. Disclosing cryp-
implemented in tographic design criteria can give adversaries ideas they wouldn’t otherwise have
software thought of, but the best way to ensure a method’s security is to publish it and
let it withstand attack over time.
The 1977 DES standard mandated a review every five years. In 1983, DES
was approved for five more years. In 1987, the expected end of DES'’s life span,
Like a certain DES was approved for another five years, with the provision that it would ex-
battery, DES goes pire before 1992. Then in 1993, DES was again approved for yet another five
on and on and on years. In 1997, NIST solicited candidates for a new secret key encryption stan-
aNGhes « dard, Advanced Encryption Standard (AES).
NIST announced the candidates for AES, successor to DES, in 1999, and
in October 2000, NIST selected Rijndael. See Epilogue and www.nist.gov/AES.

Machines That Cipher

Computers make it easier to mechanize a secret key method that com-
bines substitution and transposition. Because of a basic difference be-
tween substitution and transposition, patent offices prior to the
computer age were swamped with applications for mechanical cipher
disks based primarily on substitution. That’s because transposition re-
quires that the plaintext letters be jumbled in a certain pattern, and the

(Continued)
40 Cuapter 5 e DES Isn’t STRONG ANYMORE

exact process can depend on the length of the message. Mechanizing

this process isn’t easy. With substitution, the message length doesn’t
matter, and it’s much easier to mechanize the typical one-to-one cor-
respondence of plaintext to ciphertext.

Cycling Through Computer Keys

DES has withstood Although DES has probably been subjected to more cryptanalysis than any
all practical attacks other encryption method in history, no useful practical holes have yet been
against its method. found. As we mentioned, the best attack on DES is to try each possible key.
In 1977, a 56-bit key was considered a good defense. A cryptanalyst with-
out the key trying all the combinations of 56 1’s and 0’s (more than a quadril-
lion possible keys) at one million keys per second would have to work for more
than 1,000 years to try all of them.
But even though the number of possible DES keys confounds most hu-
mans, it’s just a bunch of memory cells (transistors) to a computer. And the rea-
son DES is no longer strong enough has a lot to do with those memory cells.
Only 30 years ago, human technology put a man on the moon, at the time
the pinnacle of technology. Still, the computer that was used had less than one
megabyte of memory (at a time when even most of the tech-savvy world didn’t
know what computer memory was). The NASA computer filled a small room
and was tended to by people in white coats with engineering degrees. As re-
cently as 10 years ago, most tech-savvy people didn’t know what a megabyte was.
Now megabyte is in most computer users’ vocabularies, and most home comput-
ers have at least 64 MB of memory.
Moore’s Law More remarkable than the ability of DES to withstand statistical attack was
an observation made by Gordon Moore around 1970. Moore, who co-founded
Intel, said that the number of transistors on a silicon chip would double every
18 months without increasing the price of the chip. Widely known as Moore’s
Law, this dictum is often interpreted as doubling a computer’s power every 18
months for the same cost.
Moore’s Law makes What does all this have to do with DES? A 1975 computer could try about
DES obsolete. half of all possible DES keys in about 100,000 days (300 years). That’s a respect-
ably secure secret. But during the past quarter-century, Moore’s Law has turned
out to be correct: Computers have become about 100,000 times more power-
ful, while their cost has remained the same. So a computer made in 2000 can do
in one day what a 1975 computer would have been able to do in 100,000 days
for the same price. This means that DES is no longer the bastion of security it
was created to be. Although it’s difficult to estimate, those with cryptographic
expertise claim that a $10,000,000 machine could find the DES key by brute
force in a few minutes or even less!
 DousLe AND Tripte DES 41

DES Crackers
RSA Data Security Inc., named after the inventors of the RSA public key
encryption algorithm (see Chapter 12), issued its first “DES Challenge”
in January 1997. The first-prize winner, Rocke Verser, cracked DES by
recovering the secret key in 96 days. Less than one year later, in Feb-
ruary 1998, a team from Distributed.net cracked DES in 41 days.
Four months later, in July 1998, a team from the Electronic Frontier
Foundation (EFF) and Distributed.net, using a machine valued at less
than $250,000, cracked DES in 56 hours. Half a year later, in January
1999, the same team accomplished the feat in less than 24 hours.

The pattern is clear. If you need a strong cryptographic method, DES

doesn’t (or soon won’t) do it anymore.
Probably no one is going to spend the time and effort to crack your 2001
holiday gift list. But if your livelihood depends on e-commerce or you make
your living negotiating million-dollar deals, DES may not be strong enough. In
January 1999, NIST reiterated a statement (in FIPS 46-3) it made in 1988: “Or-
ganizations needing security beyond that provided by the DES could use Triple
DES”

Double and Triple DES

Until a new encryption standard is agreed upon, the de facto interim solution
is Double or Triple DES. Double DES refers to the use of two DES encryptions
with two separate keys, effectively doubling the DES key from 56 bits to 112
bits. This dramatic increase in key size much more than doubles the strength
of the cipher. Each increase of a single bit doubles the number of keys. This
means that a 57-bit key is twice as big as a 56-bit key; a 58-bit key is four times
as big as a 56-bit key, and so on. It seems that this should stop an ambitious high
schooler, or nearly anyone else, from completing a successful brute force attack.
But wait.
Double DES: There’s an attack on Double DES that reduces its effective number ofkeys
Probably not what to about double the number in DES (in math lingo, 2°” = 2 x 2°°). Known as the
you want meet-in-the-middle attack, this approach was discovered by Whitfield Diffie and
Martin Hellman, the same folks who invented public key cryptography. So al-
though Double DES is an improvement over DES, ‘Triple DES is better.
With Triple DES, you use three DES encryptions with three separate keys.
Managing three keys is more difficult, so Walter Tuchman, another member of
IBM’s DES development team, proposed the current popular ‘Triple DES
implementation using just two keys.
42 CHapTER 5 DES Isn’t STRONG ANYMORE

DES (and Other Block Cipher) Modes

DES is a block cipher.’ A block cipher takes a certain number of letters (actually
bits) and encrypts them all at once. DES encrypts 64 bits (about eight letters)
at a time. Each chunk of 64 bits is called a block.
DES (and other block ciphers) also employs a mode method when a message
is longer than one block. When DES is used in its simplest mode, called elec-
tronic codebook (ECB), it gives an adversary too many patterns. Why? It’s be-
cause each block (chunk) of equivalent plaintext characters always encrypts to
the same value. For example, suppose a message contains many blocks of the
plaintext phrase Your CIO. Using DES (or any block cipher) in ECB mode will
always encrypt the block Your CIO to the same ciphertext value, and that’s
often too many clues to give to a cryptanalyst. A short message without repeat-
ing plaintext can use ECB. But longer messages that have repeating phrases
need to ensure against plaintext-ciphertext repetition.
The three other common modes ensure that repeated phrases are
enciphered differently each time they are encrypted. The modes are cipher
block chaining (CBC), cipher feedback (CFB), and output feedback (OFB).
CBC is probably used most often, followed by CFB. OFB is a more complex
variant of CFB.

The Avalanche Effect

DES and other secret key block ciphers also add something called the avalanche
effect. Essentially, this means that each small change in plaintext implies that
about half the ciphertext changes.
For example, suppose that two plaintext messages (message | and message
2) are almost identical; they differ by only a single bit (a single binary 0 or 1).
DES (and other block ciphers) promise that although the underlying plaintext
is almost identical, the ciphertext is very different.

Plaintext message 1: 100000000001 000101010001

Plaintext message 2: 100001000001 000101010001
Ciphertext of message 1: 100100001111 010111000001
Ciphertext of message 2: 101001111001 011111011000

3. As opposed to stream ciphers, such as Caesar’s cipher or Vigenére’s cipher, which

encrypt a single character or bit at a time. Much more network encryption is done
with block ciphers.
4. For a review of binary numbers, see the section “Supplement: Binary Numbers and
Computer Letters” at end of this chapter.
 SupPLeMENT: BINARY NUMBERS AND Computer LETTERS 43

DES illustrates that with every new cryptographic system comes new prob-
lems to be solved and that the problems are moving targets over time. Today’s
cryptography cloaks the electronically interconnected fishbowl in which we now
live. Yesterday’s cryptography is a good way to see how we got here. In Chap-
ter 6 we'll take a look back with an overview of cryptography’s evolution before
we rush head-on into the field’s current twists.

Supplement: Binary Numbers and

Computer Letters
If you’re already comfortable with binary numbers, you can skip this section.
Otherwise, here’s a brief explanation.
In a nutshell, letters(a, b, c, . . . zZ)are represented in the com-
puter as binary numbers. At their core, computers work only with 0’s and 1’s.
Computer memory is analogous to billions of tiny light bulbs; some are off, and
others are on. The electronic circuit is either open or closed.
Of course, this isn’t new; Morse code does almost the same thing. A tele-
gram specialist transforms each plaintext letter to dots and dashes. ‘Think of the
dot as 0, or off, and the dash as 1, or on. For example, Morse code represents
B as dash, dot, dot, dot (1,0,0,0) and C as dash, dot, dash, dot (1,0,1,0). At the
destination, each group of dashes and dots is converted back to plaintext.
Morse code uses as many as four dashes and dots to represent each letter.
Most computers use American Standard Code for Information Interchange
(ASCID code characters (see Figure 5-1). ASCII represents each letter with
some combination of eight 0’s and 1’s. Each 0 or 1 is called a dit. Eight bits is
called a byte.

erie peal
Byte= | letter (character) Byte = 1 letter (character)

Figure 5-1 Two letter characters represented as binary data.

44 CHapTer 5 DES Isn’t STRONG ANYMORE

Review
Openly publishing a cryptographic method is a good way to ensure its security.
DES, the published cryptographic standard since 1977, has withstood attack
over the years. The DES algorithm was strong, so cryptanalysts had no choice
except to attack the keys. This means trying, on average, half of all possible
keys—some number of trillion keys.
However, advances in computer hardware have compromised the strength
and security of DES. That’s because it’s easier to search through all those keys
now than in 1977.
The candidates for AES, DES’s successor, were announced by NIST in
1999, and the new standard is scheduled for selection. If you believe your ad-
versary has sophisticated knowledge of cryptography and if your secret is valu-
able, don’t use DES. Until the new encryption standard is anointed, it’s safer to
use a DES variant called Triple DES.
Rijndael was selected to replace DES in October 2000. See our Epilogue
and NIST"s site www.nist.gov/AES for additional information.
 Chapter 6

EVOLUTION OF CRYPTOGRAPHY:
GOING GLOBAL

n the beginning, information was local. Neanderthal Alice and Bob shared
meaning eyeball to eyeball, ear to ear, gesture to gesture. Adversaries were lo-
cal, too. They had to be physically present and privy to the purpose of the ges-
ture, the image, the spoken language in order to gain access to meaning and
grab secrets not intended for them.
Suppose that, one Monday morning, cavewoman Alice leads caveman Bob
through some fields to a berry patch. Because Bob understands the meaning of
the event through gestures and being led to the location, he is able to find the
berry patch again the next day. The Monday morning experience leaves pictures
in his mind of Alice walking in front and helps him retrieve the meaning later.
But now our story takes a tragic turn. Bob eats some berries from a certain bush
in the corner of the patch and gets sick. Alice watches him convulse and die. Her
response is an anguished howl of despair.'
The meaning of those particular berries is now firmly lodged in Alice’s
cavewoman brain. When Alice takes her kids, Casey and Dawn, to eat berries
there again, she howls if they go near the poisonous bush. Casey and Dawn ei-
ther understand her meaning, or they follow dear old Dad to the caveperson
afterlife.
And so meaning came to be stored in and was transferred from one brain
to the next.
The use of sound to convey meaning increased in complexity and precision
as people envisioned more precise tools. Those grunts and gestures had to be
polished into words.
When iceman Bob gave his son, Casey, instruction in flint manufacture, he
needed a precise code to convey meaning for each step. Probably Bob also in-
structed Casey not to offer the information to strangers or other people who
didn’t need to share their secret. The shared code between father and son locked
others out of their personal keys to meaning.

1. Unless, of course, she intended the foul deed, a strategic maneuver beyond the scope
of this text.

45
46 CHAPTER 6 EVOLUTION OF CryPTOGRAPHY: GOING GLOBAL

Now let’s skip ahead a few millennia. During both world wars, the United
States military devised something similar to the Bob-and-Casey code. They
used the languages of Native Americans from various tribes, particularly the
Navaho, to conceal voice messages from the enemy. These languages were a
secure encryption method since few people had the key to their meaning. The
American Indians were isolated from other cultures, and their language was
local, not widespread. The Germans and Japanese were not likely to figure out
its underlying meaning, and without the assistance ofa local insider they were
locked out.
But this method of securing and sharing meaning is less secure when infor-
mation sharing technology goes from local to global. No longer do you have to
be present or nearby in a particular time or place to capture information as it’s
presented. Having graduated from grunts to speech to writing, Alice can record
and preserve the information about which berries are poisonous and where
they’re located so that her great-great grandchildren don’t have to find out the
hard way. Recorded information is much more easily shared across time and
space, affording adversaries more opportunity to capture your secrets.

Early Cryptography
Oddly enough, some of the earliest cryptographers weren’t really trying to hide
anything. Rather, they were drawing attention to their subject and showing off
their language skills by playing with words.
When the knowledge of written language was not widespread, as in Caesar’s
time, ciphers didn’t need to be very complex. That’s because written language,
like early spoken language, is a pretty good secret keeper when very few people
can read or speak it. Caesar's cipher, simple as it was, was good enough for a
while. Even so, ingenious ways of hiding communications—later used during

Crypt from the Crypt

Nearly 4,000 years ago, a scribe deliberately changed the hieroglyph-
ics symbols in an Egyptian tomb, thereby creating the oldest crypto-
graphic writing. According to cryptographic historian David Kahn, the
scribe’s intention in carving the symbols into stone in a different way
was not to hide the message, but perhaps to dignify it—or maybe the
scribe was just showing off his knowledge.
As tombs proliferated, so did the instances of Egyptian scribes tak-
ing poetic license. For example, sometimes the new hieroglyph had the
same first sound as the one replaced, or the scribe might use a play on
words. It was done as a game or a decoration to catch the reader's eye.
 Earty CRYPTOGRAPHY 47

both world wars—were first written about by Aeneas the Tactician more than
2,000 years ago. In On the Defense of Fortified Places, Aeneas explained methods
of steganography, a form of communications security that used hidden compart-
ments and invisible inks. In one system, Aeneas suggested pricking holes above
or below a document’s letters to indicate a secret message. German spies used
this method in World War I and used a modified version in World War II,
marking letters in newspapers with invisible ink.
Nomenclators were As history unfolded and more people were able to read and write, some-
a way to add thing had to be done to better deal with the growing number of potential ad-
complexity to versaries. The Renaissance birthed combination cipher and code systems,
methods of termed nomenclators, that were designed to mask communications of popes,
concealment. royalty, and Renaissance commerce. Mixing codes and ciphers was a way to add
complexity to methods of concealment. Codes are words, numbers, letters, or
symbols used to replace words, letters, and phrases; an example is 007 for James
Bond. Nomenclators can consist of thousands of code words or code numbers.
Ciphers, as you’ve seen in previous chapters, replace the message letters with
other letters, numbers, or symbols, as in substitution, or they rearrange the
individual letters of the plaintext, as in transposition—or a combination of both.
It was also during the Renaissance that cryptanalysis became a profession,
with the rise of so-called Black Chambers: groups of people who intercepted and
read letters as well-paid employees of governments such as England, France,
and Austria in the 1700s. These fledgling cryptanalysts learned through expe-
rience how to crack the various cryptographic systems then in use. The best of
these early cryptanalysts began to recognize patterns, and over time they un-
masked keys and ciphers used by unsuspecting diplomats.

Snoops and Eavesdroppers of Yore

A 10-man team of well-paid snoops was key to Austrian diplomatic
strategy in the eighteenth century. Because Vienna was a crossroads city
between eastern and western Europe, the Austrian Black Chamber had
access to mail from several important embassies. Such mail was secretly
brought from the post office to the chamber, where the staff melted
seals after forging their designs for later use. Letters were copied and
envelopes resealed without disrupting regular postal schedules. Mail in
transit from other places was also intercepted.
Handling 80 to 100 letters a day, the team worked one week on,
one week off (except in emergencies) to minimize stress. These
cryptanalysts won bonuses for solving difficult ciphers and even re-
ceived unemployment bonuses when keys were stolen instead of hav-
ing to be cryptanalyzed. Foreign diplomats knew what was happening
to the mail but couldn’t stop it.
(Continued)
48 CHAPTER 6 EVOLUTION oF CryPTOGRAPHY: GOING GLOBAL

Like the men of the Austrian Black Chamber, America’s On the Roof
- Gang of the late 1920s, a group of radio operators, underwent vigor-
ous training to track the communications of Japan. Part of the group’s
mission was to understand how to interpret kata kana, the Japanese
version of Morse code. Those who passed the difficult four-month
course, held in a classroom on top of the Navy department building in
Washington, D.C., were placed in exotic locations to listen for Japanese
dots and dashes.

Commercial and Military Needs

Over time, nomenclators began to be unwieldy. Then, in the mid-1850s, the
telegraph brought in Morse code as well as nonsecret codes to shorten commer-
cial communications and make them more cost-efficient. Business executives
didn’t have time for convoluted encryption with all its unwieldy keys, but the
military had a different agenda. The military needed secure ways to communi-
cate quickly and accurately over long distances.
Invention of the The telegraph, much used during the U.S. Civil War in the 1860s, made
telegraoh messages easier to send and intercept, increasing the need for secure ciphers.
increased the need But the military didn’t always make good choices. As pointed out in Chapter 2,
for secure ciphers Vigenére’s table, although easy to attack by knowledgeable cryptanalysts, was
during wartime. mistakenly thought secure by many people for generations. So when the Con-
federate Army entrusted its military secrets to such a system, the Union Army
had the advantage and exploited it. Even so, in 1914 the U.S. Army based its
Larrabee cipher on Vigenére’s table.
Other types of systems used for military encryption also proved to be in-
effective. After 1931, the Japanese beefed up their cryptographic know-how
following the publication of The American Black Chamber by American

The Need for Speed

Before Samuel F. B. Morse assigned dots and dashes to the alphabet to
create Morse code, he counted the letters in a Philadelphia
newspaper's type case. Armed with this information about the most
frequently used letters, he chose the shorter dot-and-dash symbols for
them, increasing the transmission speed of telegraph messages. Cryp-
tography has a similar need for speed. If cryptography is to be widely
used to protect the data of millions of people who are traveling the
Internet highway, its execution must not slow us down.
 ENTERING THE COMPUTER AGE 49

From Red to Purple

In the late 1930s, the Japanese came up with a mechanized crypto-
graphic system they thought was unbreakable. Called Alphabetical
Typewriter 97 and code-named Purple, it replaced a machine called
Red that the Japanese didn’t know the United States had broken. Be-
cause the messages in Purple were similar to those in Red, the Ameri-
cans were able to cryptanalyze the new cipher. An analog of the Purple
machine built from telephone selector switches assisted the U.S.
cryptanalysts of the Signal Intelligence Service (SIS) in breaking the
code. Through most of the 1930s the SIS had an average annual bud-
get of $17,000, spending only $685 on hardware for the Purple analog.

cryptographer Herbert Yardley. This book contained indiscreet disclosures of

U.S. knowledge of Japanese codes.
Military history has confirmed that the tide of war can turn on who knows
what about whom and when. Perhaps the best advantage comes when you can
grab the keys to your opponent’s system without the opponent realizing you’ve
got them.

Entering the Computer Age

Making sure that you use a strong method or algorithm and keeping keys secure
are ongoing concerns. Math and computers are the means we use today to pro-
vide that security. The work of two American men and one American husband-
and-wife team during this century significantly contributed to elevating
cryptology to a mathematical science. They were geneticist-turned-cryptanalyst
William Friedman and his wife, Elizabeth Friedman, who had a college degree
in English; mathematics professor Lester Hill; and expert tightrope walker,
unicycle rider, and brilliant engineer-mathematician Claude Elwood Shannon.
During the 1920s William Friedman, who began solving ciphers for the
American government before WWI and developed cryptanalysis training pro-
grams for the federal government, published a paper that linked cryptography
and mathematics. He presented the distribution of letters as a curve having
characteristics that could be quantified with statistics. Later he developed a well-
defined mathematical test, the kappa test, that allowed him to apply probabil-
ity studies that would correlate plaintext and ciphertext letters. In the 1960s he
lived to see computers apply his test to cryptanalyze ciphertext very rapidly.
Along with her husband, Elizabeth Friedman worked for the U.S. Army as
well as doing cryptanalysis for the Navy and the State Department. During
50 CHAPTER 6 ¢ EVOLUTION of CryPTOGRAPHY: GOING GLOBAL

Prohibition in the 1920s she helped the Coast Guard decrypt messages from
bootleggers. The Friedmans became a team before World War [ at an Illinois
think tank called Riverbank, where they began working with cryptography by
investigating the authorship of the works attributed to William Shakespeare.
In 1929 Lester Hill, while assistant professor of mathematics at New York
City’s Hunter College, published a paper showing how to use algebraic equa-
tions in cryptography. Although his system was too complex for widespread use,
Hill’s work broke ground that led more mathematicians to investigate
cryptography.
iat 1940s Shannon—trained at MIT and honed at Bell Labs—described
cryptology in terms ofinformation theory, a field he gave birth to. Math-dense
information theory explains that languages use more symbols than are needed
to transmit meaning, a phenomenon called redundancy. Shannon wrote that in
most ciphers “it is only the existence of redundancy in the original messages that
makes a solution possible.” Shannon also coined the terms diffusion and confusion.
Such mathematical analysis of cryptography has allowed computers to take
over much of the brain-cracking work of cryptanalysis and has spread cryptog-
raphy everywhere that there’s a computer. For that we can thank the British
mathematical genius Alan Turing, whom cryptographic historian David Kahn
calls “the intellectual father of the computer.” Turing’s mathematical brainchild
was the blueprint for the Colossus, the codebreaking device built by the Brit-
ish to crack Germany’s advanced enciphered teletype transmissions during
World War II. Turing’s ideas were also vital to the building of the Bombe, a
machine that rapidly found the keys for German communications enciphered
with the Enigma machine.
Computers have Computers have made adding complexity to cryptography a snap. They
made it a snap to have also made solving complexity more of a snap. Because of rapidly advanc-
add complexity to ing technology, secure systems must constantly be assessed for the possibility of
cryptography. new attacks if security is to be maintained. Secret sharing and hiding is still a tug
of war between clever cryptographers and ingenious cryptanalysts with new
tools in their belts. If the algorithm is so secure that it can be made public, is
there less to worry about?
Alice and Bob and Casey and Dawn must still be vigilant in their commu-
nications. No longer can they judge strangers, eyeball to eyeball, to assess the
person they’re sharing secrets with, as in their caveman days. They need an elec-
tronic method to feel assured that their secrets are being shared only with a
trusted few, that their messages aren’t being tampered with, and that they always
know the person with whom they are communicating. Chapter 7, “Secret Key
Assurances,” shows how secret key cryptography can provide the assurances we
seek. The limitations of secret key cryptography are then shown in Chapter 8,
“Problems with Secret Key Exchange.” The rest of the book shows how you can
use public key cryptography to solve the problems of secret key cryptography.
 REVIEW 51

Review
From the beginning of humankind, language was a way to both convey and hide
meaning. [he invention of writing gave people a way to hide meaning that was
effective until increasing numbers of people learned how to read and write.
Widespread understanding of written and spoken language made cryptography
essential if one was to conceal meaning.
The Renaissance gave birth to combinations of ciphers and codes to help
make cryptography more complex. However, complexity has never been an
automatic guarantee of security.
Cryptography was elevated to a mathematical science through the work of
several Americans in this century. But the work of one Briton, Alan Turing, the
intellectual father of the computer, is what makes computer cryptography pos-
sible. Despite technological advances, however, the need to be vigilant in choos-
ing the methods and keys still applies.
 ’

i ’
_ ¥ a
a — rs a amg ant

: v wypeag phyay
mae
a oo Pyabliage tin ign, Rea hohe laiye 4
bari iP wits) Woe i a TY “ Fir :
meme vt_

nay “ig th OM) ) Seine ty) 43) 7 ae se Sr : = ne)

ae tim, 4 AG) jeanne wiley C4 needa r al wie

PIA oth bar = 4 oh pall Yea aT of 4 - 7
y ATi Te ot i sort iF
i : Five ; ‘|
ait iva: PSs iiethe J 7) a P 7) ‘ i = ~ ;
oy - - - 7 2 - to S22 4) =
= > Al a i ’ ~
= 7 7 - aa or be eee =
’ ueF _
hei jesth)
te pas ec ce
oy v2
‘
“ecl
a - bas -_ Pare” © Ab é . mee Uae eh

| b r if : ' Lait
shia ee: : i: mm iL“ev, to" A : J 7 se ate ‘pat 3 " af

’ crane: Pi Pi ot Ps ’ prettier 1 a bai 3 : “lo Hts ,

iT: Naas. n te on W
rp tame
« wy bitiyNeg ae
7 Hr : ¢ Henieies.
si nmiaehn:
: » a chiht.
; Ade °-
: a Oe aa OF

alae
h + astheret

¥ . : >A Sunred ,
; wil
4tout
Srey " ie?
ak parvlig, |

ot

Ww

"
»
ra
ae
‘a
 Chapter 7

Secret Key ASSURANCES

G ood cryptographic methods assure us that we can keep our secrets from
others. That is, Alice and Bob’s encrypted files remain private between
them as long as their secret key stays secret.
Definitions: Modern-day cryptographers use the term confidentiality to mean that your
confidentiality, encrypted secrets aren’t available to unauthorized users.' Let’s review that con-
authentication, cept briefly and examine three other necessary electronic data assurances—au-
integrity, thentication, integrity, and nonrepudiation—defined in Figure 7-1.
nonrepudiatiory

Confidentiality is assurance that only owners of a

shared secret key can decrypt a computer file that
has been encrypted with the shared secret key.

Authentication is assurance of the identity of the

* ————— person at the other end of the line. Authentication
<_< stops masquerading imposters.

Integrity is assurance that a file was not changed

during transit and is also called message
Qo authentication.

Nonrepudiation is assurance that the sender cannot

deny a file was sent. This cannot be done with the
secret key alone.

Figure 7-1 Terms of assurance.

1. In Chapters 7 and 8 we represent confidentiality with an image of a safe with an en-

crypted plaintext symbol. We’re using a safe to reinforce the concept that encrypted
text ensures privacy. After Chapter 8, confidentiality will be shown using only the
encrypted plaintext symbol (without the safe).

53
54 CHAPTER 7 Secret Key ASSURANCES

In this chapter we explain how secret key cryptography implements these

assurances. Later chapters examine how modern cryptography uses public keys
more than secret keys for this purpose. The concepts are the same, although
more involved, when public key methods are used. So we look first at the sim-
pler case.

Confidentiality
Suppose Alice and Bob have a West Coast real estate business. While Bob is on
the road, Alice and Bob exchange financial and love notes encrypted with their
secret key. Strong cryptography helps Alice and Bob feel assured their confiden-
tiality (privacy) is being maintained because only someone who has their secret
key can make sense of their shared electronic messages (see Figure 7-2).
Strong cryptography also ensures the confidentiality of encrypted files
stored on computer disks; only those with whom we’ve shared the secret en-
crypting key can decrypt and understand the content.
Why you want But confidentiality (privacy) is not enough assurance to give you the warm
authentication, fuzzies you crave about the security of your communications (see Figure 7-3).
integrity, Even before you send or receive encrypted data to or from another computer,
nonrepudiation. you need to know that the person on the other end of the line is the person he

Internet

Figure 7-2 Confidentiality is like sending your secret in a safe; only the owner of the
shared secret key can decrypt the message (open the safe).
 AUTHENTICATION 55

ly, Himodel Aice

a normal person.

j (CMM
cca
———,, ae

Figure 7-3 Cryptography offers a way to detect masquerading impostors and ensure
the identity of the person on the other end of the line.

or she claims to be (authentication). You also need to know that the software you
downloaded hasn’t been tampered with during its journey to you (integrity).
And you'd probably also like to be assured that your stockbroker brother-in-law
can’t deny that he received your sell order before the bottom dropped out of the
market. Similarly, he wants the same assurance if you deny that you instructed
him to buy a falling-star dot-com (nonrepudiation).

Authentication
Shared secret keys can also be used to authenticate credentials. Cryptographic
A
¢———= authentication assures Alice that her electronic contact is the genuine Bob and
not someone masquerading as Bob—unless the masquerader has stolen a copy
of Alice and Bob’s shared secret key. Here’s how Alice is assured it’s the authentic
Bob.
If Bob wants to send Alice information via computer, all Alice knows is that
Enter BlackHat
her phone rings, the modem picks up, and some computer requests access to her
computer. Is it Bob? Or is it our book’s bad guy, the nefarious BlackHat? How
can Alice feel somewhat secure that it’s Bob without seeing his face, hearing his
voice, or asking for his mother’s maiden name? She needs a genuine electronic
ID from Bob.
Challenge and If the computer requesting access to Alice’s computer can verify that it
response: Alice knows Alice and Bob’s shared secret key, Alice will feel more secure that it’s Bob.
authenticates Bob. But it would be foolish to ask Bob to send the secret key to prove it’s his com-
puter calling. BlackHat might be listening in and make a copy. Alice needs to
know that the person on the other end of the line knows their secret key with-
out either of them divulging it. A way to know whether the caller is the genu-
ine, authentic Bob is called challenge and response. It’s shown in Figure 7-4.
e Secret Key ASSURANCES

Authentication by
CHALLENGE AND RESPONSE
Challenge Response

Alice sends a challenge.

She picks a number between 1 and
100, say 34, and challenges the Challenge
computer requesting access to
correctly encrypt 34. Only the
secret key Alice shares with Bob will
correctly encrypt 34.

Bob responds.
He encrypts 34. Say 34 encrypts to
“%9.” He sends %2 back to Alice.

mo-—-rep> Response

Alice finishes authenticating Bob.

She also encrypts 34 to %2 and is
assured it’s Bob. Only their shared
secret key encrypts 34 to %2.

34 encrypted = %2
Completes
Authentication

Figure 7-4 Alice authenticates Bob with a challenge and response protocol.

When the challenge and response protocol is completed, Alice is assured

that the caller is Bob’s computer. But note that Bob is not assured that the com-
puter on the other end is Alice’s because he has only responded to a challenge
from someone he hopes is Alice. Bob must authenticate Alice, as shown in Fig-
ure 7-5,

Bob authenticates Alice.

A 76
Bob should challenge Alice in a similar L B
way. Except Bob should challenge | ce)
with any number other than 34. C a3 B
BlackHat may have listened in. E

Figure 7-5 Bob authenticates Alice.

 Not REALLY RANDOM Numeers 57

A [34.1 BL. >

An Authentication Attack
L A

\ z 6| Now suppose that BlackHat has listened in and recorded the challenge and re-
u 8} sponse. Later, if Alice challenged with 34 again, BlackHat could impersonate
|" res Bob because he knows that Alice and Bob’s shared secret key encrypts 34 to 32.
That is, BlackHat intercepts Alice’s challenge (e.g., 34) before it gets to Bob.
He uses the previously recorded response (e.g., %2) and correctly responds to
Alice.
Because Alice wants to ensure that she never again challenges Bob with the
same number, she picks a random number from a very big group of numbers.
A good cryptographic system chooses a challenge between | and a very, very big
number. How big is big enough? Imagine all the sand on earth in a pile. Choose
a grain of sand, put the grain back in the pile, mix up the pile, and choose a grain
again. It’s unlikely the same grain will be chosen twice. In fact, it’s unlikely you
could find the same grain again.
Good random numbers draw from a set of even bigger numbers so that
you're even more unlikely to choose the same number again. We look at ran-
domness next. You’ll find more detail about randomness in Appendix A.’

Not Really Random Numbers

Do these numbers between | and 3 trillion seem random to you?

1414213562373
1732050807569
2236067977499

A good cryptographic system uses randomization with as little detectable

pattern as possible. The lack of pattern is crucial for many reasons. Here’s one.
Say BlackHat records Alice’s challenges to Bob. On Monday, Alice sends Bob
the challenge 1,,414,.213,,562,8/37 0m. luesday, 1/82 7050, 807,569;
and on Wednesday, 2, 236,067,977,499. Bob correctly responds and is au-
thenticated by Alice. The challenges may, at first glance, look like random num-
bers; but they actually follow a simple sequence. As shown in Figure 7-6, they

2. Although it’s not shown here, passwords (and random values) should be long to pro-
hibit BlackHat from successfully guessing them.
58 CHAPTER 7 e Secret Key ASSURANCES

1.414213562373 * — 1.414213562373

1.732050807569 * 1.732050807569

2.236067977499 * —9.936067977499

Figure 7-6 The square roots of 2, 3, and 5.

are the square roots of2, 3, and 5, respectively (with decimal points removed).
Although they look random, they’re not because it’s easy to figure out the next
number in the sequence.’
If BlackHat figures out Alice’s sequence, he can impersonate Bob. BlackHat
BlackHat
successfully guesses that Alice’s next challenge will be the square root of 6 (2.449489742783)
masquerades as with the decimal point removed. BlackHat knows he can’t correctly respond to
Bob to Alice. Alice’s challenge of 2,449,489,742,783 because he doesn’t have the cor-
rect secret key. But he may be able to trick Bob into doing the work for him.
BlackHat intercepts Bob’s next call to Alice’s computer. Bob thinks he’s con-
nected to Alice. BlackHat challenges Bob with 2,449, 489,742,783. Bob
encrypts the challenge and responds to BlackHat. BlackHat now knows how to
respond to Alice’s challenge of 2,449, 489,742,783. He puts Bob on hold
while he calls Alice’s computer. BlackHat logs on to Alice’s computer and drops
Bob’s connection. When Bob tries Alice’s computer again, he gets a busy signal.
Computer cryptography crucially relies on random numbers. But almost
the most difficult task you can give a computer is to make something random.
Even though computers are made to behave in the same identical way over and
over again, many, if not most, people think computer work is already frustrat-
ing enough. Imagine if acomputer behaved differently on different days (ugh).

One-time pad ; Making Good Use of Randomization

One cryptographic system that absolutely cannot be cryptanalyzed
wasn’t conceived of until the twentieth century. In this system—termed
the one-time pad—a randomly generated, nonrepeating key (the
length of the key is at least as great as the length of the message) is used
only once. The one-time use ensures that ciphertext can’t be
cryptanalyzed through an examination of patterns in different messages.
Perfect secrecy is ensured only by a truly random number. Quantum -
events, such as those measured by a Geiger counter, are believed to be
the only source of truly random information.
(Continued)

3. See Appendix A for more on pseudo-random numbers.

 INTEGRITY 59

The one-time pad got its name from Germany’s use of this system
around the 1920s. The Germans typed a sequence of supposedly ran-
dom numbers on two separate pads—one for the receiver and one for
the sender—to be used only once. The German system had a mechani-
cal precursor, called the one-time system, that was developed indepen-
dently. It was created by AT&T engineer Gilbert Vernam, who was
studying security problems with the teletypewriter. It was improved on
by U.S. Army Major Joseph Mauborgne, who proposed modifying
Vernam’s system by using a nonrepeating random key.

Definition: pseudo- In fact, computer programs can’t make random numbers. They may come
random close, but not close enough to be called random. Instead, “random” numbers
made by computer programs are actually pseudo-random. To you and me, a
pseudo-random number may look like a random number, and we can use it as
though it were a random number. Economists, statisticians, scientists, and oth-
ers use pseudo-random numbers all the time. Nevertheless, if a cryptographer
isn’t very careful in using pseudo-randomness, a hound-dog cryptanalyst might
. spot it and use it to launch a successful attack.

Integrity
Did you just download the latest version of your favorite browser, or maybe a
virus update program, from Microsoft or Netscape? You may have logged on
Cer through your network or dialed into an Internet service provider (ISP). Then
you downloaded the file. The file passed from the vendor’s disk to its Internet
server to the Internet cloud to your ISP and finally to your machine (see Fig-
ure 7-7).

Internet Server Local Provider

(e.g., www.HxMel.com) (e.g., WWW.AOL.com)

Figure 7-7 When you send or receive a message over the Internet, it’s important to
ensure its integrity.
60 CHAPTER 7 Secret Key ASSURANCES

You hope you received what you ordered; you hope that during each stop
and forward along the way no one changed the contents. No one wants
BlackHat to modify a virus checker program so that it will fail to check for par-
ticular viruses.
Integrity is often Authentication assures Alice that no one is masquerading as Bob. The prin-
referred to as ciple of integrity assures Alice that no one can change Bob’s messages without
message being detected. Authentication and integrity are very closely linked; integrity is
authentication. often referred to as message authentication.
Alice and Bob obtain integrity assurance by using their secret key and the
message to make a message fingerprint, known as a message authentication code
Definition: MAC
(MAC). The message and message fingerprint are a closely tied, matched pair.
No one can easily find another message that makes the identical matched mes-
sage fingerprint. As with secret key encryption, the secret key Alice shares with
Bob ensures that the message fingerprint is secure from forgeries. Even search-
ing for an identical fingerprint is frustrating because the message fingerprint
formula is designed so that a change in a single message letter (actually a single
bit) changes about one-half the message fingerprint (see Figure 7-8).
Any change in the message clianges the fingerprint. If $10 . 00 is changed
to $10.01, it makes a completely different message authentication code. As dis-
cussed in Chapter 5, this is called the avalanche effect and means that
cryptanalysts have a difficult time knowing when they’re close to producing a
successful forgery.
Like a secret key encryption method, the MAC formula is publicly available
and known, it’s not secret. Chapters 13 and 14 cover this topic in greater depth.

Using the MAC for Message Integrity Assurance

In Figure 7-9, Alice creates the MAC from the secret key and the message
$10.00 is cost of game and sends both the message and the MAC to
Bob.

is cost of is cost of MAC formula

1 ‘ Z)

Figure 7-8 A slight difference between two messages results in greatly differing
message authentication codes.
 INTEGRITY 61

$10.00 $10.00
is cost of
game

Figure 7-9 Alice makes a message and a MAC and sends both to Bob.

In Figure 7-10, Bob uses the message and his copy of their shared secret key
to independently calculate another message fingerprint. If Bob’s independently
calculated message fingerprint is exactly equal to the message fingerprint he
received from Alice, he is assured that the message has not been changed in
transit.
MAC formula and Bob can feel secure because no one else can duplicate the message finger-
shared secret key print without knowing the secret key he shares with Alice. Note that in our
ensure that no one example, the message $10.00 is cost of game is sent as plaintext; that
else can duplicate is, the message is not confidential. In Part IV, “Real World Systems,” we’ll see
the (MAC) message how to get confidentiality, authentication, and integrity assurances together.
fingerprint.

3. If both
MACs are
identical the
ns aE message has
2. Bob checks his “c==- not been
MAC vs. MAC sent changed in
by Alice. transit.

Figure 7-10 Bob verifies that Alice’s message arrived unaltered.

62 CHAPTER 7 Secret Key ASSURANCES

Why Bother Using a Message Authentication Code?

A MAC is small. Why bother computing a MAC if you’re going to send the message in the clear
anyway? First, software updates can be many megabytes and don’t need to be
secret. Encryption and decryption take computer time. A MAC is very small
compared with tlie size of most messages.
Confidentiality, by Second, it’s a common but mistaken notion that secret key confidentiality
itself, does not alone assures message integrity. Encryption doesn’t stop BlackHat from alter-
ensure integrity. ing messages (see Chapter 22). That is, message fingerprints are as important
as confidentiality and should always be sent with the messages.

File and MAC Compression

By the way, MAC math compresses large files to a very few bytes (characters),
but you shouldn’t confuse MAC compression with popular compression pro-
grams such as PKZip, WinZip, or Stufflt. MAC compression is one-way; there’s
no way to decompress a MAC to reclaim the original underlying text (see Fig-
tine 7 = 11!)
In fact, if BlackHat could recover or figure out any part of the original text
from a MAC, the MAC program would be flawed and insecure (see Chapter 14).

Internet
Browser

50
MegaBytes

Figure 7-11 MAC compression is one-way. The MAC cannot be decompressed to

recover the original file (message).
 NONREPUDIATION: SeEcRET Keys CAN’T Do It 63

Nonrepudiation: Secret Keys Can't Do It

In a world of marital harmony and perfect people, Alice would never deny or
forget that she received a message from Bob, and vice versa. But suppose Alice
and Bob share a secret key with their stockbroker. Alice or Bob encrypts a buy
order, specifies a price, and sends it to Untrusty the stockbroker. Untrusty thinks
the price will go down and decides not to buy Alice and Bob’s stock until the
next day; Untrusty figures he can pocket the difference.
But the next day the price goes up, and Untrusty claims he never received
the order from Alice or Bob. Untrusty denies, or repudiates, the buy order. Bob
and Alice would be out of luck except that cryptography provides a way to make
Untrusty confess the truth.
Alice makes Untrusty agree to encrypt a message stating that he, Untrusty,
received their buy order. Then if Untrusty denies or repudiates the buy order,
Alice could show the message to an impartial judge. Alice could say, “Here is the
encrypted message and the decrypted message that Untrusty sent us; here is the
secret key Untrusty used to make the encrypted message. Only the secret key,
which is shared by Untrusty and us, can make this exact encrypted message from
the plaintext. It’s proof that Untrusty sent us the message that he received our
buy order.”
Untrusty’s lawyer slowly gets up, slowly straightens his tie, and very slowly
touches his finger to his lip. He’s getting paid by the hour. Untrusty’s lawyer asks
Alice whether she has a copy of the secret key she shares with Untrusty. Alice,
of course, has a copy. How else could she decrypt the encrypted confirmation
she received from Untrusty? The lawyer then asks Alice whether she could also
make exactly the same message and encrypt it so that it looks exactly like what
she says was sent to her by Untrusty. She can. Alas—this means that she has no
case.
Secret keys alone aren’t enough to ensure that someone else can’t repudi-
ate or deny receiving your message. Io implement nonrepudiation, you must
either use secret keys with a trusted third party (a process reviewed in Chapter
8) or use public key cryptography.
Alice and Bob—along with their offspring, Casey and Dawn—will encoun-
ter another difficulty with secret key cryptography, a problem resolved by public
key cryptography. They are computer-sawvy and know to encrypt their messages
with Triple DES or the new AES standard, Rijndael. If they are to communi-
cate securely with one another and the diverse others they meet at the four
corners of the Internet world, they’ll need to exchange and keep track of many
secret keys. Although they are all keyed up to share secrets globally, Chapter 8
shows the problems of a secret-key-only system.
64 CHAPTER 7 Secret Key ASSURANCES

Review
Cryptography and shared secret keys can be used to secure electronic files and
communications. Cryptographic assurances are categorized as follows.

* Confidentiality is assurance that only owners of a shared secret key can de-
crypt a computer file that has been encrypted with the identical shared se-
cret key.
e Authentication is assurance of the identity of the person at the other end of
the line. Because Bob can’t send the shared secret, Alice challenges Bob to
correctly encrypt a previously unused random number with their shared se-
cret key. Only the shared secret key will correctly encrypt the random
number.
e Integrity, or message authentication, is assurance that a file has not been
changed during transit. A message and a shared secret key make a unique
message authentication code (MAC), or message fingerprint. Only some-
one with a copy of the shared secret key can correctly reproduce the
fingerprint.
¢ Nonrepudiation is assurance that the sender cannot deny that a file was
sent. This cannot be done using a secret key alone; it requires a mutually
trusted third party or public key technology.
 Chapter8

PROBLEMS WITH
Secret Key EXCHANGE

haring and exchanging secret keys is fraught with problems, so much so that
it’s one of two reasons that public key cryptography was invented. The other,
the need for digital signatures, is discussed in Chapter 12.
Let’s reintroduce Alice and Bob and their offspring, Casey and Dawn, to
help us look at conventional ways to distribute secret keys as well as typical
problems with secret key distribution. Now Alice and Bob are retired and liv-
ing in the upper Midwest. Their son, Casey, has taken over the California busi-
ness. Their daughter, Dawn, is a well-connected bond trader in New York City.
In 1977, the year DES was released as a standard, Alice and Bob made their
personal DES secret key. Bob uses DES to send Alice love notes and investment
advice. They still keep their encrypted love notes.
Casey doesn’t spend much time visiting his parents, but he does send them
investment advice about secret deals. Because he doesn’t trust the telephone
(and especially electronic mail), he asks Bob for his secret key. Bob, an accom-
modating dad, immediately agrees, but then he remembers the encrypted ro-
mantic notes. So he makes another DES secret key to share with Casey. Figure
8-1 shows Casey sending Alice and Bob a confidential message.

Alice & Bob \

o | aa
a| )
Figure 8-1 Casey wants to send Alice and Bob a confidential message.

65
66 CHAPTER 8 PROBLEMS WITH Secret Key EXCHANGE

The Problem and the Traditional Solution

How do Alice and Bob share the secret key with Casey? That is, how is it deliv-
ered to him? They can’t send the secret key via mail (e-mail or postal mail or voice
mail) because they can’t be certain of the key’s security in transit (see Figure 8-2).
Alice and Bob could personally deliver the secret key to Casey, or they could
hire a trusted courier. This method, or something similar, was used for thou-
sands ofyears and brings to mind a picture of aman carrying a briefcase hand-
cuffed to his wrist. Let’s assume that Casey somehow gets a secret key and that
only Alice, Bob, and Casey know it.

Ancient Advice of Sun-Tzu

“A hundred ounces of silver spent for information may save ten. thou-
sand spent on war,” wrote early fourth century B.C. Chinese general
Sun-Tzu. Attuned to the value of intelligence gathering, he would have
insisted upon the careful delivery and storage of secret keys. Because
he believed “to subdue the enemy without fighting is the supreme ex-
cellence,” he also would have endorsed clandestinely stealing your
opponent's secret keys. His advice in Ping-fa (The Art of War), the ear-
liest known text on war and espionage, is still studied by modern mili-
tary strategists who take to heart that “nothing should be as confidential
as the art of intelligence.”

Soon after Alice and Bob begin exchanging secret messages with Casey,
Dawn wants a secret key, too. For personal family reasons, she does not want
to use the secret key her parents share with Casey and wants her parents to make
a new secret key. So Alice (or Bob) must travel to New York City and deliver a
secret key to Dawn.
Alice and Bob now have three secret keys': one for their love notes, a sec-
ond one they share with Casey, and a third one they share with Dawn.

a 4
Alice & Bob

Figure 8-2 Delivering a secret key can be problematic. (Dawn now telecommutes
from North Carolina.)

1. This assumes that they’re using DES or the new AES standard, Rijndael. If they are
using Triple DES, they have nine (or six) keys.
 THE PROBLEM AND THE TRADITIONAL SOLUTION 67

Alice and Bob use their shared secret key to ensure the confidentiality of
their romantic letters. They use the secret keys they share with Casey and Dawn
to ensure authentication, message integrity, and confidentiality with their chil-
dren. Figure 8-3 shows the current arrangement. Although it includes only
three people, it’s already getting complicated.

The Ecstasy of the Agony

In the mid- to late 1800s, lovers used cryptography to communicate
clandestinely in a very public place: the newspaper. But their amateur
efforts were often the playground for budding cryptanalysts, who de-
lighted in uncovering their lovelarn messages, which were printed in
what was termed the “agony columns.”
Charles Babbage, who expressed the principles behind today’s com-
puters back in the 1800s but could never make them work, was one
who liked to cryptanalyze the agony columns. In school Babbage often
suffered for his cleverness in decrypting others’ notes. Cryptographic
historian David Kahn quotes Babbage’s remembrances: “The bigger boys
made ciphers, but if | got hold of a few words, | usually found out the
key. The consequence of this ingenuity was occasionally painful: The
owners of the detected ciphers sometimes thrashed me, though the
fault lay in their own stupidity.”

Keys Bob Holds

Romantic Letters Share with Casey Share with Dawn

Authentication
by Challenge-Response |

QO—-+ Message Integrity

Figure 8-3 Secret keys and their uses.

68 Cuapter 8 © PROBLEMS WITH SEcrET Key ExcHANGE

Using a Trusted Third Party

The situation gets more complicated when Casey and Dawn decide to exchange
secret messages through Bob. Figure 8-4 shows how it’s done. First, Casey en-
crypts a message using the secret key he shares with Bob. Next, Bob decrypts
the message and then encrypts it with the secret key he shares with Dawn. Then
Dawn decrypts the message using the key she shares with Bob. Note that in
Figure 8-4 the encrypted text Casey sends to Bob is different from the encrypted
text Bob sends to Dawn. This is because there are two different encryption keys.
Definition: trusted In effect, the children want their parents to be a conduit for messages. Bob
third party (or Alice) is the conduit, or trusted third party (TTP). That may sound like a nice
title, but remember that the TTP must decrypt and encrypt each message, re-
sulting in twice the work of either Casey or Dawn. Some cryptographic

Alice & Bob

: ee.

3. Dawn decrypts

Casey to Bob to Dawn

Figure 8-4 Bob becomes a trusted third party for Casey and Dawn.
 UsinG A TrusTED THIRD PARTY 69

literature calls this the military model because the troops, Casey and Dawn,
must communicate through a superior ranking solider, Bob or Alice.
After Bob spends a few hours decrypting and encrypting messages, he re-
alizes that it would be better if Casey and Dawn were able to communicate di-
rectly. Bob makes another secret key. But Alice, Bob, Casey, and Dawn don’t
want to travel to deliver or pick up the key. They don’t trust couriers because
keys can be lost, stolen, or even sold (or copied) by an untrustworthy courier.
Cryptographers But because Alice and Bob are a TTP, no one has to travel. That’s because
often use secret secret keys can encrypt secret keys in the same way that secret keys encrypt love
keys to encrypt notes or financial text. A cryptographic key is just like a text message except that
other secret keys. it contains only a long, random number. In fact, cryptographic keys are often
used to encrypt secret keys, as shown in Figure 8-5. Cryptographers often re-
fer to encrypting a secret key as wrapping it.? One more, perhaps obvious, point:
the cipher and key wrapping (encrypting) another key should be at least as
strong as the key being wrapped. It’s silly to wrap (encrypt) a 168-bit Triple DES
key or a Rijndael key with a weaker 56-bit DES key.

Trusted Third Parties Aren’t Always So Trustworthy

Marie Antoinette and Louis XVI trusted a good-looking Swede, 6ount’
Axel Fersen, to help them escape their fate in the French Revolution.
Fersen handled enciphering and deciphering the heavy traffic of cryp-
tographic correspondence to and from the co-conspirators during the
two months before the planned escape. It wasn’t Fersen’s fault that the
king and queen were causht in their disguise as servants. After all, he’d
had extensive experience encrypting and decrypting his own love notes
to and from Marie before this assignment. If King Louis had known, he
might not have considered this trusted third party so trustworthy!

(a) Encrypting Messages (6) Encrypting a Secret Key

Figure 8-5 Secret keys are used to encrypt (a) messages and (6) other secret keys.

2. For a real-world example, see Part IV.

70 CuHaPTeR 8 © PROBLEMS WITH SECRET Key EXCHANGE

Key Distribution Center and Key Recovery

Ker’ At the top of Figure 8-6, Bob sends Casey and Dawn the new secret key en-
ie ee crypted with the respective secret keys they share with Bob. Bob and Alice are
authentication now a key distribution center (KDC) (Figure 8-7). Other names for this setup
system, acts as a include key exchange authority and key exchange center.
KDC. At the bottom of Figure 8-6, Casey and Dawn use the new secret key and
exchange encrypted messages. The messages need not be passed through Bob.
Casey and Dawn trust that Bob will not intercept messages and decrypt their
message using the secret key he made. In fact, Bob can (and arguably should)
destroy his original copy of Casey and Dawn’s secret key.
Alice & Bob’s
Key Distribution Center

Figure 8-6 Alice and Bob assume the role of a key distribution center.

3. Kerberos, used extensively in Microsoft Windows 2000, is modeled

on a KDC.
 PROBLEMS WITH USING A TRUSTED THIRD PARTY 71

Key escrow But Casey and Dawn may ask Bob to keep a copy in case one of them loses
the secret key. Bob is now a key recovery (or key escrow) agent. Bob should hold
Casey and Dawn’s key in an encrypted form so that it cannot be used even if lost
or stolen. In the larger world, there is heated debate about who should have
access to secret keys and how they should be recoverable.
Storing secret keys For extremely important keys, Bob may choose to split up Casey and
Dawn’s key into two or more parts, keeping the parts separate. In this way, all
the parts must be lost or stolen before the key is compromised. Key splitting and
key recovery are interesting topics, but they are beyond the scope of this book.

Problems with Using a Trusted Third Party

Although it’s convenient to have a trusted third party to create a common se-
cret key, this approach has a number of problems. Let’s take a look.

Growth in the Number of Secret Keys

Secret key sharing Although secret key delivery isn’t difficult if you have only a few users, it’s al-
and distribution is most impossible to deliver secret keys to a large network of users. For example,
a big, big problem. if Casey has offices in all three West Coast states, each office wants a secret key
with every other office. Bob must make and send three new secret key pairs, as
shown in Figure 8-7.
Opening an office in each of the 50 states greatly expands the number of
different keys. Each state office must have 50 different secret keys (one key for
each of the states and one key for Bob). This means that there are more than
1,200 secret keys.

Key Distribution Center

Figure 8-7 As the business grows, so does the number of shared secret keys.
72 CHapTER 8 © ProsLems witH Secret Key EXCHANGE

In general, a key distribution center supporting X sites, where each site

needs a secret key with every other site, must make almost (X * X)/2 keys.* This
means that a KDC supporting 1,000 sites must m ake almost (1,000 * 1,000) /2
= 500,000 keys, an unmanageable number of keys.

Trust and Lifetime

Of course, Casey and Dawn totally trust their parents, but they must also im-
plicitly trust everyone who has access to Bob’s computer. If Bob’s computer
holds many secret keys, it is a worthwhile target. Once Casey and Dawn’s shared
secret key is compromised, any encrypted message they ever sent that was pre-
viously intercepted and saved can also be decrypted. Old encrypted messages
may still have value to an adversary.
The best Secret keys are not secure forever. They can be stolen, lost, forgotten, de-
encryption stroyed, stored in insecure ways, or copied without authorization. A secret key
algorithm is useless that has been used many times probably hides more secrets than a secret key that
if you don’t protect has been used only once. An adversary is more likely to go after the secret key
your secret key. that has been used many times. In Part IV, “Real-World Systems,” we’ll see how
new secret keys are easily shared.
A better way to handle key management is available through public key
cryptography. In Chapter 9 we examine a clever technique for exchanging se-
cret keys over public channels that sets the framework for methods being used
today.

Review
Secret communications with secret keys implies that on/y trusted parties should
have copies of the secret key. Although secret keys can assure us of confidenti-
ality, authentication of users, and message integrity, in a global world we must
be able to securely distribute keys at a distance in a timely manner. If security
is to be maintained, key distribution must be as solid as the cryptographic
method and must be able to ensure that only trusted parties have copies of the
keys. Obviously, key distribution is a significant problem.
‘Traditional methods of key distribution use trusted couriers to place the
initial secret key. If the key is shared with a trusted third party (TTP), additional
keys can be shared because secret keys can encrypt secret keys for distribution
in the same way that secret keys encrypt love notes and financial statements.
When the TTP encrypts any additional keys with the shared secret key, the
TTP is often referred to as a key distribution center (KDC).

Beexactly- X= (X=1)i/2.
 REVIEW 73

The KDC is often burdened with extensive key management and can be-
come a bottleneck. Additionally, if the KDC also acts as a key escrow agent, the
KDC itself is an attractive target.
Public key encryption makes (secret) key distribution much easier.
 7 7 oe
a

Sy
i : -

i ism et at ee Wat
ye es
6 mgt-
We j, 00), 48 ;
= 7 - : Ry i> F = f Ty.

ies
a Niea ies
Tsee >) cine ho r a yar
= .
 PART Il

PUBLIC KEY
CRYPTOGRAPHY
f all you need is to encrypt your disk, you don’t need anything more than se-
cret key cryptography. Unlike secret key cryptography, public key cryptogra-
phy provides a feasible way to distribute encryption keys publicly while
keeping decryption keys secret.
The chapters in Part II explain public/private key cryptography—often
referred to simply as “public key”—the most important advance in cryptogra-
phy in several thousand years. Although public key solves the secret key deliv-
ery problem for our global digital marketplace, it creates others that must be
considered, such as how Bob can be certain he is using Alice’s authentic public
key, a problem we discuss in Part III, “Distribution of Public Keys.”
From the beginning of human history to about 20 years ago, secret key
cryptography satisfied all our needs for secure communications. That’s because
most people didn’t need cryptographic communications, and those who did
need it spent money and time to distribute and maintain secret keys. As illus-
trated in Chapter 8, setting up and maintaining a system of thousands of secret
keys is all but impossible. Key distribution centers (KDCs) worked well with
secret keys because, with few exceptions, KDCs were never required to main-
tain thousands of keys.
Chapter 9 introduces the concepts behind public key systems with an early
innovation by Ralph Merkle, one of the pioneers of public key cryptography. In
the 1970s, Merkle demonstrated a clever method to exchange secret keys over
a public line without a KDC. Merkle’s ideas capture the benefits that a public
key system provides its users and the problems it forces on potential adversaries.
Chapter 10 explains how encrypting with a public key ensures
confidentiality.
Chapter 11 shows a simple example ofamath trick used in public key cryp-
tography that is the basis for confidentiality. If you’d rather eat liver than do
math,! rest assured that understanding the rest of the book is not contingent on
understanding the math tricks in this chapter.

1. We wish we’d come up with this analogy, but the full quote is from Bill Neugent:
“The protection provided by encryption is based on the fact that most people would
rather eat liver than do mathematics.”

75
76 Part Il Pustic Key CryptoGRAPHy

Chapter 12 explains how encrypting with a private key provides assurances

other than confidentiality: authentication, integrity, and nonrepudiation.
Nonrepudiation, which ensures that Alice and Bob cannot deny sending any
messages they transmit, is an added benefit of public key that secret key can’t
provide.
Chapters 13 shows how message digests speed the encryption process and
provide even more security.
Chapter 14 describes technicalities that cryptographers have built into
message digests to defeat attacks. These details are not essential to understand-
ing how public key cryptography operates, so if you’re interested only in the big
picture, you can safely skip this chapter.
Chapter 15 compares secret key, public key, and message digests to help you
better understand why all three cryptographic tools are used in the real-world
systems discussed in Part IV.
 Chapter 9

PIONEERING Pus.ic Key:

Pusiic EXCHANGE OF SEcrET Keys

Lc recap and lay the groundwork to see how a new twist on secret key dis-
tribution empowers a new form of cryptography.
Alice and Bob have developed secure secret keys. Alice encrypts her com-
puter files and feels secure that no one can decrypt the files without her indi-
vidual secret key. Alice and Bob’s digital conversations use their shared secret key
to authenticate each other, confidentially exchange files, and validate the integ-
rity of the files (ensure that the files have not been altered during transit).
Review: Sharing But as you saw in Chapter 8, sharing secret keys is difficult and expensive.
and distributing Alice must either personally deliver the shared secret key to Bob or unequivo-
secret keys is cally trust a courier. Trustworthy couriers are expensive. And if Bob forgets their
cumbersome. shared secret key, Alice must repeat the same key delivery process.

The Search for an Innovative Key

Delivery Solution
The secret key delivery problem has plagued cryptographers, governments, and
kings for thousands of years. How do you securely deliver a secret key to a con-
fidant using insecure public lines of communication? Although the key may pass
through BlackHat’s hands, BlackHat must not be able to ascertain the secret key.
It’s a tough problem. What advantage does Bob have over BlackHat that Bob
can exploit?

Developing an Innovative Secret Key

Delivery Solution
While a graduate student at Berkeley in the early 1970s, Ralph Merkle devised
a system that enabled people like Alice and Bob to exchange secret keys over a
public line, marking the beginning of public key cryptography. Even though

77
78 CHAPTER 9 PIONEERING Pustic Key: Pustic EXCHANGE OF SEcRET Keys

BlackHat is assumed to be listening to Alice and Bob’s communications, Merkle

envisioned a way to create a difficult, time-consuming problem for BlackHat.
At the same time, Merkle’s approach makes it easier for Alice and Bob to estab-
lish their shared secret key.
The goal was to create a problem that would take BlackHat a long time to
solve even with the aid of a computer. Here’s what Merkle devised.

First Attempt: A Database of Key/Serial

Number Pairs
Suppose that Alice makes 1,000,000 new secret keys and stamps a unique serial
number on each one (see Figure 9-1). Note that there’s no reason to order the
serial numbers. Alice keeps a database of each secret key and serial number.
If Alice then sends Bob a plaintext electronic copy of that database, he can
easily pick a serial number (say, serial number 500,121) and its paired secret key
(lyt8a42x35); then he calls Alice to tell her to use the secret key associated with
serial number 500,121. But as Figure 9-2 shows, what’s easy for Alice is also easy
for the eavesdropping BlackHat. BlackHat has copied the database Alice sent to
Bob—remember that it was sent over public lines—and quickly figures out the
secret key. So this secret key exchange doesn’t work for Alice and Bob.

Secret Key Serial #

aiet187£45 1,287,341

9dsyh3701 T Ig 834902

lyt8a42x35 500,121

43879d323 10,100,001 |

L25s42fds70 | 95,428,385

Figure 9-1 Alice makes 1,000,000 secret keys.

 DEVELOPING AN INNOVATIVE Secret Key Detivery SOLUTION 719

Figure 9-2 Alice sends Bob a file of secret keys and serial numbers, but BlackHat
copies it and learns their secrets.

Second Attempt: An Encrypted Database of

Key/Serial Number Pairs
New and Now suppose that Alice encrypts her serial number/secret key database and then
improved: Encrypt ships the encrypted database to Bob. Alice tells Bob the encryption method she
the entire database used but not the encryption key. Because Bob doesn’t know Alice’s encryption
of serial number/ key, he must try all possible keys. Say it takes Bob about one hour, using his
secret key pairs. desktop computer, to find Alice’s encryption key.' After decrypting the entire
database, Bob selects a secret key and tells Alice the matching serial number—
say, serial number 500,121. As before, Alice knows to use secret key lyt8a42x35
(see Figure 9-3). But, like Bob, BlackHat can also spend about an hour decrypt-
ing Alice’s database, so BlackHat can also figure out that serial number 500,121
matches secret key lyt8a42x35. We still need a method that will make
BlackHat’s job much tougher than Alice and Bob’s job.

1. Obviously, Alice does not choose a “strong” cryptographic method to encrypt her
database. Recall from Chapter 4 that a strong encryption method is one in which the
most practical attack is to try each possible key and there are so many possible keys
that it’s infeasible to try even half of them.
80 CHapter 9 © PIONEERING Pustic Key: Pustic EXCHANGE OF SecreT Keys

Figure 9-3 Alice sends an encrypted file of secret key and key pairs, but BlackHat
isn’t intimidated.

Merkle’s Insight: Individually Encrypted Key/Serial

Number Pairs
Third approach: This brings us to Merkle’s creative insight. As the result of this innovation, Bob’s
Encrypt each work doesn’t change, but BlackHat’s work increases dramatically. Let’s see how.
individual serial Previously, Alice encrypted the entire database with one secret key. But that
number Isecretkey didn’t make BlackHat work longer than Bob. Now Alice sends 1,000,000 en-
Selle crypted secret key/serial number pairs (see Figure 9-4).

Ciphertext3

= iphertex
Ciphertext 2
x
Ciphertext 1

Figure 9-4 Alice sends Bob 1,000,000 encrypted secret key/serial number pairs.
BlackHat eavesdrops and copies the key pairs sent to Bob.
 DEVELOPING AN INNOVATIVE Secret Key DeLivery SOLUTION 81

Each secret key/serial number pair (second column, Table 9-1) is encrypted
with a unique secret key (third column, Table 9-1) to make the encrypted pair
(final column, Table 9-1). Alice uses a million different secret keys to encrypt the
1,000,000 individual secret key/serial number pairs. Table 9-1 shows each secret
key/serial number pair encrypted with a separate key.
Bob gets 1,000,000 encrypted secret key/serial number pairs and picks one
encrypted pair—say, Pair3. He spends an hour deciphering it and learns that
Pair3 means secret key lyt8a42x35 and serial number 500,121 (see Figure 9-5).
As before, he tells Alice that he will encrypt with the secret key matching the
serial number 500,121. Alice quickly matches the serial number to the corre-
sponding secret key in her database.
As before, Alice and Bob assume that BlackHat is listening, has copied all
1,000,000 encrypted pairs Alice sent to Bob, and has heard Bob tell Alice to use
the secret key associated with serial number 500,121.

Black Hat’s Frustrating Problem

BlackHat must How does BlackHat figure out the secret key Alice and Bob agreed to share?
decrypt many more BlackHat doesn’t know that Bob selected Pair 3; he knows only that one of the
serial number/ * encrypted pairs Alice sent to Bob contains serial number 500,121. But here’s the
secret key pairs rub: BlackHat doesn’t know which pair. It must be one of the million pairs, but
than does Bob. he has no clue which one (see Figure 9-6).

Table 9-1 Alice’s database of secret keys and serial numbers, encryption key, and encryption message sent
to Bob (and snooped by BlackHat).

Alice Makes and Keeps Alice Sends to Bob

Plaintext 1,000,000 Different

of Secret Key / Secret Keys— Encrypted Text of Secret
Serial Number One for Each Key/Serial Number
(reproduced from Figure 9-1) Pair Number

Cipher
7
aiet187£45 / # 1,287,341

Qdsyh3701 / # 77,183,902 __ Ciphertext 2

Lyt8a42x35 / # 500,121 Ciphertext 3 -

900,000 438794323 / # 10,100,001 900,000 Ciphertext 900,000 _-

1,000,000 25s42fds70 / # 95,428,385 | 1,000,000 | | Ciphertext 1,000,0

82 CHAPTER 9 © PIONEERING Pustic Key: Pusiic EXCHANGE OF SecreT Keys

Figure 9-5 Bob picks one encrypted pair and decrypts it to learn the secret key and
serial number.

Recall that Bob tells Alice only the serial number he learned. BlackHat has
a much bigger problem than Bob: He must decrypt about half the encrypted
pairs Alice sent to Bob until he stumbles onto the one pair that decrypts to
lyt8a42x35 / 500,121.
With this twist, Merkle turned a relatively simple problem for Bob into a
time-consuming problem for BlackHat. If deciphering one encrypted pair takes
about one hour and if BlackHat must try, on average, about 500,000 of them,
BlackHat has a 500,000-hour problem. Bob has only a one-hour problem.
Asa result, Alice and Bob can communicate confidentially with their shared
secret key while BlackHat is busy trying to figure out which secret key they are
using.

The Key to Public Key Technology

Easy and difficult All public key cryptography works in the same way. You and your confidant
puzzles share a quickly solved problem. Let’s call it an easy puzzle. But if you withhold
a critical puzzle piece from your adversary, the easy puzzle is transformed into

fal
(a Fal fren ? 2? /#500,121

[eal (al [al

Figure 9-6 BlackHat has a big problem. He knows that one of the 1,000,000 pairs
he copied contains the pair Alice and Bob are using; but because he doesn’t know
which one, he must try them one by one. According to probability theory, he’ll have
to try about half of them before he stumbles onto Bob’s choice.
 DEVELOPING AN INNOVATIVE Secret Key DELIVERY SOLUTION 83

a difficult, time-consuming puzzle. In Merkle’s innovative implementation, Bob

solves one encrypted pair and finds a secret key to share with Alice. BlackHat
doesn’t know and isn’t told which encrypted pair Bob solved. That critically
withheld puzzle information forces BlackHat to solve, on average, 500,000 en-
crypted pairs—a much more time-consuming puzzle.
Technology A ratio of 500,000 to 1 may seem impressive, and certainly after 500,000
reduces the hours (or about 50 years) Alice and Bob’s secrets have much less value. A delay
perceived of 50 years may seem sufficient to protect secrets, but more powerful computer
advantage. hardware and more efficient software can dramatically reduce that number.
Bob may use a $1,000 computer to solve a puzzle sent to him by Alice, but
an adversary—wanting to learn about, let’s say, the next major West Coast land
deal, might use a $10,000,000 computer. A computer 10,000 times more expen-
sive and 10,000 times faster than Bob’s desktop might solve the 50-year prob-
lem in 50 hours. With better software, it might take even less time.
Cryptographic history is replete with stories of technological advances
eliminating cryptographic advantages. As a result, cryptographers prefer a much

Hiding in
i Plain
Sight

had never diecty obsened

6 the exact location. _ _
His instructions were to go toa particular foyer near the number 98 _
_ telephone. Across the hallway was a dark green radiator held to.the
wall by a single metal hook. Between the wall and the radiator was a
space 2 to 3 centimeters wide that was to be used as the drop. The
selected hiding place made it easy for both parties to deposit and re-
trieve materials while in a standing position. In this way, someone ob-
serving the scene would be less likely to notice the drop.
Merkle envisioned his public distribution of secret keys in a similar
way: Make it hard for BlackHat to find your secret key bygiving him a
much bigger search space than Bob’s.
84 CHAPTER 9 PIONEERING PusLic Key: Pustic EXCHANGE OF SECRET Keys

larger advantage: at least 500,000,000 to 1, which is about 1,000 years compared

with | minute. One way to accomplish that is to give BlackHat a much bigger
search space. For example, Alice could send a greater number of encrypted pairs,
but that’s an inefficient use of bandwidth. Only one of the 1,000,000 encrypted
pairs is used; the other encrypted 999,999 pairs just cloak the selected one and
are thrown away.

A New Solution: Diffie-Hellman-Merkle

Key Agreement
Unlike Merkle’s initial idea to solve the problem of key delivery, the first pat-
ented public key cryptographic system used math to achieve the overwhelming
ratio needed to ensure that BlackHat would stay busy for a long time. During
the 1970s, Merkle took his ideas to Martin Hellman of Stanford, where Merkle
found a more sympathetic training ground for public key cryptography.’
Hellman was joined by another cryptographic kindred spirit, Whitfield Diffie,
who drove across the United States to meet him.
Like Thomas Edison, who tried thousands of materials before arriving at
the combinations that made the light bulb possible, the Diffie-Hellman-Merkle
trio tried all sorts of ways to solve the problem. Their persistence paid off. Af-
ter two years of focusing on modular arithmetic and one-way functions’—prob-
lems that were harder to work one way than the other way—the men developed
an open (that is, public) secret key agreement solution.
The first workable public key cryptographic system, the patented Diffie-
Hellman-Merkle key agreement scheme (more commonly known as Diffie-
Hellman, or DH), is still widely used in Internet browsers such as Secure Socket
Layer (see Chapter 20) and Internet Protocol Security (see Chapter 21). Like
Merkle’s original approach, Diffie-Hellman confidants use insecure public com-
munication lines to agree on a shared secret key.

Alice and Bob Openly Agree on a Secret Key

In Merkle’s original approach, Alice sent Bob 1,000,000 potential secret keys
and Bob randomly selected one. In Diffie-Hellman, as incredible as it sounds,
Alice and Bob make the shared secret key, online, together, in full view of
BlackHat—or any other eavesdropper. (The math, not important for this dis-
cussion, is shown in Appendix A.)

2. As the story goes, Merkle’s Berkeley professor couldn’t understand Merkle’s ideas and
Merkle dropped the course.
3. Modular math and one-way functions are discussed in Chapters 11 and 14, respec-
tively.
 A New Sotution: Dirrig-HELLMAN-MERKLE Key AGREEMENT 85

The Diffie-Hellman What's important is the breakthrough that allows Alice and Bob to openly
method of secret exchange some Diffie-Hellman numbers. Then, in private, they use each other’s
key agreement DH numbers, their secret random numbers, and the DH method to agree on
makes secret key the same secret key.
distribution much Although BlackHat knows the DH method and copies Alice and Bob’s con-
easier. versation, he cannot figure out Alice and Bob’s agreed-on secret key. Figure 9-7
shows how Alice and Bob create and exchange a secret key over a public line.
BlackHat listens to every communication between Alice and Bob.

* Bob, let’s use Diffie-Hellman ve a

and make a secret key 4 x OK, Alice. I'll use yours.
together. Here are my / public DH values and my 5
public DH values! made iq private number and
“with my private number. .” \ calculate an agreed-
~, rae ‘upon secret key.

“ OK, Bob. I'll use your public “

: DH value and my private
_ number and calculate the
“identical secret key.”

/ lil record everything and : ” Rats! Even though | know’

use the Dime Hellman) ~ DH, I can’t figure out the
formulae explained in ‘secret key they’re using.”
Appendix A. ee

Figure 9-7 Alice and Bob using the Diffie-Hellman (-Merkle) secret key agreement.
BlackHat records their conversation but cannot reproduce their shared secret key.
86 CHAPTER 9 PIONEERING Pusiic Key: PuBtic EXCHANGE OF SEcRET Keys

Problems with the Diffie-Hellman Method

But the DH method has two weaknesses. The first is the lack of authentication.
DH, by itself, doesn’t give Alice assurance that the person with whom she’s
agreeing on a secret key is Bob. Rather, it assures Alice that the secret key she
calculates is known only to her and to the computer at the other end of the
connection. It doesn’t stop BlackHat from masquerading as Bob to Alice or
masquerading as Alice to Bob.
Second, the DH method fails to provide a versatile means for secret key
exchange. Recall that to agree on secret keys, Alice and Bob must exchange
some DH values. Although their DH values can be openly exchanged, for some
applications, such as e-mail, an online exchange is inconvenient.

Separate Encryption and Decryption Keys

Definitions: So far in our discussion, Alice and Bob share the same key, and both of them use
symmetric cipher, the identical secret key to encrypt and decrypt. Systems that use shared secret
asymmetric cipher keys are called symmetric cipher methods. Diffie, Hellman, and Merkle also
envisioned systems, called asymmetric ciphers, that have separate encryption and
decryption keys. One key encrypts, and the other one, a different key, decrypts.
Diffie’s 1976 paper about this system marked the first time in 3,000 years of
cryptographic study that anyone outside government institutions knew that such
an idea had been conceived.
Diffie’s paper ended up in the hands of Ronald Rivest at MIT. Rivest per-
suaded Adi Shamir and Leonard Adleman, also at MIT, to help him search for
the math that would make this idea a reality.

Public Key: A Top Secret Discovery

In 1969, the British military asked Britis

dick a daunting problem,on went to work tying

dilemma. _
The proble
was
m gi James Ellis, one ofBritain’sp
ernment cryptograp own by the GCHQ.as some
 SEPARATE ENCRYPTION AND DecryPTION Keys 87

_ But Ellis was also known for his brilliance, which led him to read and col-
lect a broad range of scientific materials. In those materials he found the
seed of the idea that was proposed by the Stanford trio: an asymmet-
ric cipher, in which one key encrypted and the other key decrypted.
Ellis’s brainstorm came after he read a Bell Telephone report written
during WWII. To ensure the security of telephone speech, the report's
unknown author proposed that the recipient mask the sender's mes-
sage by adding noise to the line. B ause the recipient had added the
noise, theoretically the recipient i d be able to remove it. It didn’t
work that way in reality because of ifficulty of removing noise from
speech communications. But Ell applied the noise principle to
enciphering text. He suggested that it could be a way of achieving se- _
curity without exchanging any secrets. Unfortunately, Ellis was not a
mathematician. Although he knew he needed a special one-way func-
tion that only the receiver could reverse, he didn’t have the mathemat-
ics background to implement his idea.
Ellis made his idea known to the higher-ups, and for several years
GCHQ's brightest minds worked on a practical solution to the problem.
aL lution came to a novice cryptographer, Clifford Cocks, just six
“s after he joined GCHQ in 1973. Although Cocks knew very little
a
about cryptography, he’d specialized in number theory at
University before joining British Intelligence. _
According to cryptographic historian Simon Singh in The Codeoe _
Cocks claimed that it took him half an hour to solve the mathematical
puzzle with prime numbers and factoring, the same solution that has
become known as RSA (after Rivest, Shamir, and Adleman). At the time
Cocks solved the problem, he had no idea that GCHQ had been work-
ing on its solution for years or that he’d discovered one of the most
important cryptographic methods ever conceived. At that time, GCHQ
couldn’t put Cock’s discovery into’ oes because there wasn’t yet
enough computing power available
NSA claimed It had In 1974 Malcolm Williamson, a me eneucen and
a long-time friend of
public key Cocks, joined GCHQ. When Williamson heard about Cocks’s discovery,
technology before he set out to disprove it. Instead, he discovered what the world would
Diffie-Hellman. soon know as Diffie-Hellman key exchange at about the same time it
was being developed across the Atlantic.
By 1975, the British had discovered all the essential components of
public key cryptography, but no one was talking. It was top secret. The
credit went to the Americans, who commercialized and patented these
ideas, which are key to the advancement of the digital revolution.
88 CHAPTER 9 PIONEERING Pustic Key: Puatic EXCHANGE OF SECRET Keys

The RSA method solved the authentication and key exchange problems and
thus enabled the assurances needed in our burgeoning digital age. Saf
This powerful system can seem complex if you look at all its capabilities at
once. Chapter 10 shows how public/private key pairs provide easy key exchange
and confidentiality. Chapter 11 briefly examines the major math trick behind
public key cryptography. After that, we look at how public key cryptography
(and RSA in particular) goes beyond confidentiality to give us digital signatures
needed for e-commerce.

Review
Ralph Merkle helped create the framework for public key cryptography. Despite
the drawbacks to his key distribution approach, Merkle designed an ingenious
way to securely distribute secret keys over an insecure public communication
channel. Although Merkle’s initial idea didn’t give people the desired competi-
tive advantage over their adversaries, he worked with Martin Hellman and
Whitfield Diffie to create a mathematically feasible system. It’s now accepted
that British cryptographers developed public key cryptography before Diffie,
Hellman, and Merkle, even though the Stanford trio were the first to patent a
public key system.
The Diffie-Hellman-Merkle public key system (commonly referred to as
Diffie-Hellman, or DH), implements the strategy of making a problem that has
at least two solution paths: an easy one and a very difficult one. The idea is to
give your friends the easy, less time-consuming path and force your adversar-
ies to solve the difficult, more time-consuming version of the same problem. All
public key cryptography uses this principle.
The Diffie-Hellman-Merkle key agreement method didn’t provide all the
versatility and assurances needed to fuel the digital age. Authentication was still
a problem. The idea of asymmetric ciphers, in which one key is used to encrypt
and another is used to decrypt, solves the problem of authentication. Rivest,
Shamir, and Adleman built on the public key foundation built by Diffie,
Hellman, and Merkle to create an asymmetric cipher known as RSA.
 Chapter10
@ Public Key Assurance

Tr Wl
Confidentiality i
CONFIDENTIALITY USING
Pustic Keys

lectronic commerce introduces new twists on old security issues. But the
move from hard copy to electronic communications means that we need a
new way to ensure the security of the communications we send and receive.
Public key cryptography can provide all the digital assurances we need, but
for simplicity this chapter shows only how public and private mechanics offer
Internet users confidential communications and easier key delivery. To explain
in more detail how confidentiality is ensured, Chapter 11 examines one of the
math tricks used to create pairs of public and private keys. Chapter 12 discusses
how cryptography offers users the additional assurances of authentication, in-
tegrity, and nonrepudiation.
To illustrate confidentiality, let’s pay another visit to Alice, who is now
working as an Internet stockbroker. The transactions between Alice and her
customers also show how public key cryptography provides a manageable so-
lution to the problem of key distribution.

New Twists on Old Security Issues

Figure 10-1 shows Alice’s interactions as an Internet stockbroker with her cus-
tomers. Both broker and customer know that their communications pass
through many computers and want assurances that their messages are
confidential.
Let’s examine only how Bob (the customer) delivers confidential messages
(e.g., BUY 100 shares WigitCo. @ 14) to Alice. For the moment, we’re not
concerned about how Alice communicates confidential messages to the cus-
tomer or how both parties get other assurances. The one-way arrow in Figure
10-1 symbolizes confidential messages being delivered to Alice. In Chapters 19,
20, and 21 you'll learn how real-world systems offer confidential messages to
Bob as well as Alice.
Confidentiality Figure 10-2 is a simple illustration of confidentiality before the electronic
before the digital age. The envelope represents confidentiality. Each of Alice’s customers person-
age ally delivers the envelope to Alice or uses a trusted courier service such as the

89
90 Cuapter 10 © ~ConrIDENTIALITy UsinG Pustic Keys

Internet Stock
BUY 100
shares f
WigitCo
@|
14/share

Internet Stock }

Other Internet
User

Internet Service
Provider

Figure 10-1 Internet business: A customer sends a buy order to a stockbroker.

U.S. Postal Service. Because Alice’s customers trust that no one opens the en-
velope before it is put into Alice’s mail slot, they trust the confidentiality of their
messages.
Figure 10-2 provides an analogy that helps explain what happens with pub-
lic key cryptography. Anyone who puts a message in Alice’s secure mailbox is
assured that only Alice can read the contents. The picture doesn’t imply that
Alice can securely deliver a message to a particular customer that no one else can
read. Figure 10-3 shows something Alice would never do. Alice would never put
an envelope addressed to one of her customers on the other side of the brick
wall; she can’t be sure that someone else won’t open and read, destroy, or even
alter the contents of the letter.
(Alice’s)
Customers
Confidential

Alice’s Stock f| a\<

Le

Figure 10-2 Alice receives confidential orders from Bob and others.
 New Twists ON Otp Security Issues 91

Not Confidential

Figure 10-3 Alice can’t send confidential messages to her customers in the same
way they send them to her.

Pulolic key The public key cryptographic system we’re about to describe works in the
cryptography is same way. Alice’s customers can deliver confidential messages to her, but this
asymmetric. The doesn’t mean that she can deliver confidential messages to any of her custom-
public key encrypts ers. Recall that secret key cryptography is a symmetric relationship: The sender
(disguises). The and the receiver use the same key to encrypt and decrypt. Public key cryptog-
private key raphy, on the other hand, is an asymmetric relationship: Public key methods
decrypts (removes
create two different but mathematically related keys. What is encrypted with
the disguise).
one key can be decrypted only with the other key. Alice’s customers use the
public (encryption) key, and Alice uses the private (decryption) key. This means
that a message encrypted with Alice’s public key is a confidential transmission
between the customer and Alice. Figure 10-4 shows how we illustrate the three
different kinds of keys in this book.
Another analogy can help clarify this confidentiality scenario: Public key
cryptography is like a postal mailbox. Anyone can drop a letter into a mailbox,
but only the person with the key (the postal employee) can open the mailbox and
retrieve the mail. Similarly, anyone can use Alice’s public key to encrypt a mes-
sage, but only Alice (or another person who has her private key) can decrypt the
message.
A message encrypted with a public key cannot be decrypted with the pub-
lic key; similarly, a letter put in the top of a mailbox cannot be retrieved through
the top.

Qo
Secret Key Public Key Private Key

Figure 10-4 Secret keys, public keys, and private keys as represented in this book.
92 Cuapter 10 @ COonFIDENTIALITyY UsiNG Pustic Keys

Confidentiality Assurances
Figure 10-5 shows Bob using Alice’s public key to encrypt a message to Alice.
Even though BlackHat intercepts and copies the message, he cannot decrypt the
message without Alice’s private key. If BlackHat tries to decrypt the message
using Alice’s public key, he gets gibberish. Public key cryptography gives
BlackHat a tough problem while providing a trapdoor to an easy problem for
Alice.
Even Bob can’t decrypt a message he encrypts with Alice’s public key. This
means that if Bob needs to keep a readable record, he should save a plaintext
copy of each message he encrypts with Alice’s (or anyone’s) public key.
Knowing Alice’s public key doesn’t give BlackHat any practical help figur-
ing out her private key. Strong public key methods ensure that figuring out the
private key is as close to impossible as cryptographers can make it. Chapter 11
shows a simple example of the principles used, and Appendix A delves deeper
into some of the mathematical intricacies.

Distribution of Public Keys

It doesn’t matter if Public key cryptography is designed so that it doesn’t matter who knows or has
anyone knows your Alice’s public (encryption) key. As a result, it’s easier to deliver public keys than
public key. secret keys.

Private Key Decrypts Public Key Encrypts

Encrypting
Key

Public Key
Encrypted
Message
Decrypting :
Key :

Figure 10-5 Bob sends a public key encrypted message to Alice. BlackHat copies the
message but can‘t decrypt what the public key has encrypted.
 DistRIBUTION OF PusBLic Keys 93

Alice shares her In our brick wall and envelope analogy, all of Alice’s customers use the same
public key. mail slot—that is, Alice’s public key—to encrypt messages. This means that
Alice need create only a single public key and share the identical public key with
all her customers. This arrangement is much easier than sharing a different
secret key with each customer.
Figure 10-6 shows customers encrypting their messages using Alice’s public
key. Although the customers’ encrypted messages pass through many comput-
ers before reaching Alice, the customers are confident that their messages are
confidential because only Alice has the matching private decryption key.
Alice can send Bob the encrypting (public) key over an insecure (public)
communication line, such as unencrypted e-mail, telephone conversation, and
so on. Many people even put their public keys on their business card. Alice can
advertise her public key in The New York Times or on her Internet Web site (see
Figure 10-7). In fact, as we’ll see in Chapters 16 and 17, some companies want
as many people as possible to know and trust their public key. See authors’ pub-
lic keys in Epilogue.

Private

Figure 10-6 A public/private key pair. The senders have the encryption key, and the
receiver has the decryption key.

Figure 10-7 Alice announces her public key and even pays a third party to adver-
tise it.
94 Cuapter 10 © ConFIDENTIALITY UsinG Pustic Keys

If BlackHat intercepts Alice’s public key distribution to her customers and

substitutes his own public key for Alice’s, he can masquerade on the Internet as
Alice. This subterfuge is known as a man-in-the-middle attack (see Chapter 22).
Alice uses digital certificates (discussed in Chapter 16) to prevent man-in-the-
middle and other attacks.

Two-Way Confidentiality
Alice can’t use her private key to send confidential messages to her customers.
As you have seen, she can’t be sure that someone else won’t pick up and read the
message (see Figure 10-8).
If Alice wants to send confidential messages to a customer, she must have
that customer’s public key or must exchange a secret key with that customer.
Two cryptographic security systems—Secure Socket Layer (Chapter 20) and
IPsec (Chapter 21)—offer Alice and her customers two-way confidentiality and
even more.
Alice can and does use her RSA private key to authenticate herself and her
messages to her customers, and you'll see how that happens in Chapter 12. But
before we jump into our public key cryptographic sportscar and drive it full
speed ahead, let’s look under the hood at some simple math tricks.

No Confidentiality Public

Qua Public

Private

Public

oa 10-8 Alice can’t send her customers confidential messages using only her pri-
vate key.
 REVIEW 95

Review
A public key is used to encrypt a message that can be decrypted only by the
coon
matching private key. Knowledge of the public key doesn’t help BlackHat to
quickly decipher a public key encrypted message or figure out the private key.
Because the public key doesn’t need to be concealed and is widely distributed,
key distribution is much easier than in secret key cryptography.
Anyone can use Alice’s public key to encrypt messages. Only Alice, the
holder of the matching private key, can quickly decrypt messages encrypted with
her public key. If Alice wants to send confidential messages to her customers,
she needs a separate public key for each of them.
 j —

et hy!
Me Vieds a Lisl One| Saas
7H! ‘ tg ii ae! Cgant
a> |i ‘ Pe rr) =F “ea i yy 7 q AUP ' idk!
Li i -
vi Le) iene
é
a
if eur Thi
@EMF) ARS
of JLT PE Vic ac etl ai bys?
7 ek i.
- i a 7 7)
win @ Te) ee,
Nts faaeat) rn Ny | - ell. ring a) tif te! TL

eG) Pea ry ite 2 is 5 OS, |’ Ded UN itien Oa a

a : - =
Riis i,
(ei ij.
1 Pi
ad = 7 "
PPD 7 eel hed

-_
=
—-

rang
i
ct Abi”
 Chapter 11

MAKING Pustic Keys:

MarTH TRICKS

» AlLesson
in Inverses

he simple math trick used in most commercial public key cryptography is

called a modular inverse. Cryptographers use modular inverses to manufac-
ture public/private key pairs, such as those shown in Chapter 10. Here, you’ll
see how modular inverses force BlackHat to solve a difficult, time-consuming
problem but give Alice a trapdoor to an easy, quick solution.
First, let’s briefly review what led us here. Chapter 9 describes a system that
enables Alice and Bob to exchange secret keys over a public line. Alice sends
1,000,000 secret keys, and Bob selects one of them. It frustrates BlackHat be-
cause he must try about 500,000 keys before stumbling onto the one Bob se-
lected (see Figure 11-1).
Chapter 10 examines a major goal of public key cryptography: confidenti-
ality. Alice openly (that is, publicly) distributes her public key to her clients so
that each client can use the public key to encrypt a message to Alice. The mes-
sage is confidential because only Alice’s private key can decrypt a message en-
crypted with her matching public key (see Figure 11-2).
Compared with the Merkle puzzles in Chapter 9, this chapter shows a more
math-based public key system. Now, instead of distributing 1,000,000 potential
secret keys, Alice distributes a list of numbers. Her customers encode messages
by choosing and adding numbers from the list. It’s easy to choose numbers from
the list and calculate their sum, but after they’re totaled, it’s far more difficult
to figure out which numbers were added.
Easy and hard Many math problems are easy to solve one way and far more time-consum-
problems ing to solve another way. For example, without a calculator, squaring 1.234

97
98 CHAPTER 11. © MAKING Pustic Keys: MATH TRICKS

Figure 11-1 Alice sends 1,000,000 potential secret keys to Bob. BlackHat listens but
doesn’t know which one Bob selected.

Venere”) Public

Figure 11-2 In a public/private key pair, senders have the encryption key. The re-
ceiver has the decryption key.

(1.234 x 1.234 = 1.522756 ) may take a little time. But it’s easy compared with
finding the square root of 1.522756. That is a far more time-consuming
problem.

Alice’s Easy Problem

Alice publishes a newsletter, and each issue contains stock reports requested by
her clients. But her clients want only Alice to know which stocks they want to
read about. So Alice sends them a list of stock names and stock numbers (shown
in Figure 11-3) and gives them a way to communicate with her publicly so that
only she can decipher the information they send over the Internet.
 Atice’s EAsy PROBLEM 99

ALICE’S HOT PICKS

Select and Sum Stock Numbers

Name Number
Amazon.com 1
Barnes & Noble 3
Ford Motor 5
General Motors 10
IBM 20
Microsoft 40

Figure 11-3 Alice sends her clients a list of stocks with special numbers that they can
use to encipher the information.

Summing specially Each stock number identifies a particular stock. Alice’s clients sum the stock
created stock numbers and send the total to Alice. The stock numbers are designed so that
numbers every possible sum is unique. For example, if Bob sends 9, Alice knows that Bob
must have added 1 (Amazon.com), 3 (Barnes & Noble), and 5 (Ford). Only one
group of the stock numbers sums to 9. Similarly, only one combination sums to
4, one combination sums to 29, one combination sums to 41, and so on; each
combination of stock numbers makes a unique sum.
Definition: super- The uniqueness of each sum is guaranteed because Alice’s choice of stock
increasing numbers—l1, 3, 5, 10, 20, and 40—ensures it. It’s a math trick. Here’s how it
sequence works. Note that each stock number is greater than the sum of all the preced-
ing numbers. That is, 5 is greater than | + 3, 10 is greater than 1 + 3 + 5, 20 is
greater than 1 + 3 + 5 + 10, and 40 is greater than 1 + 3 +5 + 10+ 20. Any such
sequence of numbers is called a super-increasing sequence.
Alice chose a super-increasing sequence because it’s easy and quick to fig-
ure out the individual numbers that make a sum. For example, it’s easy to fig-
ure out that 53 is the sum of40 + 10 + 3 or that 33 is the sum of 20 + 10 + 3. The
math trick is to start with the biggest number in the sequence that is also less
than the sum. That is, any sum must contain the greatest stock number that’s
less than the sum. Here’s the math trick in action.

1. Bob sends Alice 53; 53 must be made with 40. 53 — 40 = 13. 13 must be
made with 10. 13 —-10 =3. So 53 = 40+ 10+3 or 53 =M+G+B:!
2. Casey sends Alice 33. 33 must be made with 20. 33 - 20 = 13. 13 must be
made with 10. 13 - 10 = 3. So 33 = 20+ 1043.

But because Alice’s list in Figure 11-3 is public, BlackHat can intercept the
transmission and figure out Bob’s request, as shown in Figure 11-4.

1. We refer to each stock by the first letter of its name.

100 CHAPTER 11 © MakinG Pustic Keys: MATH TRICKS

53= 40 +10 dee} |

M +G + B j

CIs

Alice

53=40 +10 + 3
M+G +

BlackHat

Figure 11-4 BlackHat intercepts Bob’s message and figures out his stock requests.

Alice’s problem is just like those that plague Merkle’s puzzles in Chapter 9.
Alice wants to solve quick and easy problems but needs to transform them into
time-consuming and difficult problems for BlackHat. To do that, Alice uses
modular inverses.
Although the simple cryptographic transformation technique we show in
the remainder of this chapter is no longer used, it’s instructive because almost
all public key cryptography depends on modular inverse transformations.’ If you
don’t need or want to know how these transformations work, feel free to skip
the rest of this chapter. The rest of the book is not contingent on material in this
chapter.
Before we turn to modular inverses, let’s review some simple math you may
not have used for many years.

Grade Schoo! Math Tricks

Unless you’re a mathematician (or of that nature), you may not be familiar with
the math tricks used in public key cryptography, but almost everyone who stud-
ies math learns a few math tricks.
Multiplying by 10, 100, 1,000, and so on is an easy trick we’ve all learned
(see Figure 11-5). How about multiplying a number by 11—say, 24 x 11 (see

2. More precisely, most schemes depend on the discrete logarithm problem. For our
discussion, understanding that difference is not important. For more details, see
Appendix A.
 More Grave SCHOOL MATH 101

Figure 11-6)? If you don’t know the trick, you must do traditional multiplica-
tion. But there’s a trick to use when multiplying a number by 11. First, you put
11 on top. (Most people put 11 on the bottom because it’s easier when you’re
multiplying by 11 the conventional way.) For this math trick, instead of multi-
plying by 11 you add the digits in 24, 2 + 4, to get the middle number, 6. Mul-
tiplying by 11 is much faster and easier if you know this trick.’
There are thousands of creative math tricks, and public key cryptography
uses some of them. No one wants to hide secrets with tricks (it doesn’t sound
very secure, does it?), so cryptographers call some of these math tricks by their
formal mathematical name, number theory. Number theory can sound intimidat-
ing if you’ve never studied it; but if you think “math tricks” instead, it’s more like
figuring out a puzzle than getting a Ph.D.

Figure 11-6 Here’s a simple math trick for multiplying by 11.

More Grade School Math

All public key cryptographic systems depend on something we all learned in
grade school math: the identity property.
Simple In grade school we all learned that multiplying any number by | equals that
multiplicative number. It’s called the multiplicative identity property: 6 x 1 = 6; 20 x 1 = 20;
inverses 1,234,567 x 1 = 1,234,567; and so forth. There’s also an additive identity

3. 36x11 = 396, 71x11 =781, and so on.

102 CHAPTER 11 @ MakinG Pustic Keys: MATH TRICKS

property: A number plus 0 equals that number. We focus here on multiplicative

identity because public key cryptographers use it extensively,
We learned some tricks with the identity property. For example, because
8 x 1/8 equals 1, any number multiplied by 8 and then multiplied by 1/8 must
be the same as multiplying that number by 1. For example, 2 x 8 = 16, and
16 x 1/8 = 2. We are back where we started, at 2. Simple math trick! We call 1/8
and 8 inverses because when we multiply them together they equal | (see Fig-
ures 11-7 and 11-8.)
Although our example is not complex enough for them, cryptographers like
the math trick with inverses. Here’s why. They reason, “If I can multiply the
message by 1, the multiplicative identity property guarantees that the answer
will equal the original message. And if I can separate that multiplication into two
parts—such as 8 and 1/8—then I can disguise the original number (message)
after multiplying by one part and comie back to the original number (message)
after multiplying by the second part.”

Multiplicative Inverses:

Sx 17/3 =

3/2 29/3 =

Figure 11-7 A couple of multiplicative inverses.

Multiplicative Inverses and the

Identity Property:

2x8
x 1/8 = 2

98,766 x 3/2 x 2/3 = 98,766 |

Figure 11-8 Multiplicative inverses and the identity property.

 DIVISION AND REMAINDERS: MODULAR MATH 103

Simple public/ For example, if Alice were the only person on Earth who knew that 1/8 is
private key pair: 8 the multiplicative inverse of 8, she could securely proclaim her public key to be
and 1/8 “multiply by 8” (see Table 11-1, first key pair). If Bob wants to send her the
message 5,000, he encrypts it to 40,000 (5,000 x 8). Only Alice knows to
multiply the ciphertext 40,000 by 1/8, so only she can quickly recover the
plaintext. A slightly more complex key pair (3/2, 2/3) is also shown in
Table 11-1.

Table 11-1 Two too-simple key pairs.

Key Pair Message Key Encrypted Key Decrypted

8, 1/8 5,000 8 40,000 1/8 5,000

Sind, OY 98,766 3/2 148,149 2/3 98,766

Obviously, this encryption/decryption pattern is too simplistic to be secure

in the real world of Internet- and math-savvy grade schoolers. Cryptographers
° needed something more complex, and sure enough, they pored over the prob-
lem until they found a way.

Division and Remainders: Modular Math

Because most public key cryptographic systems (including RSA, the most widely
used) draw on modular math and modular math uses division, let’s review some
basics.
In grade school division, the answer is the quotient plus the remainder (see
Figure 11-9); in modular math, the answer is the remainder only. Note that
modular math uses only the whole number remainder and never fractions or
negative numbers.

Quotient + Remainder

Divisor |Dividend

Figure 11-9 The terminology of division.

104 CHAPTER 11 © MAKING Pustic Keys: MATH TRICKS

Clock math is People actually do modulo operations every day. For example, a typical
modular math. (nonmilitary) clock is modulo 12; 10 o’clock plus 4 hours is 2 0’cloc. Because
Example: you’ve worked with clock math since grade school, you automatically perform
10+4=2 a modular calculation: 10 + 2 gets you back to 0 (12 o’clock), and then you add
2 more. In modular math terms, it’s (10 + 4) mod 12 = 2 (see Figure 11-10).
Here’s another clock math, or modulo, example: 3 o’clock + 25 hours = 4
o'clock, or (3 + 25) mod 12 = 4.
Figure 11-11 shows the similarities between grade school division and
modular math. The chart illustrates how modular math uses division to calcu-
late the remainder. The quotient, or the number of times the divisor goes into
the dividend, isn’t a part of the answer in modular math.
Modulo is usually abbreviated mod, as in 21 mod 10 = 1 (recall that 21 di-
vided by 10 leaves a remainder of 1). The divisor is called the modulus, and the
remainder is called the residue. We'll use the word modulus instead of divisor.
Because the words residue and remainder are so close, we’ll continué to refer to
the residue as the remainder.
If you need additional modular math examples to solidify your understand-
ing, see Figure 11-12. There’s also an additional modulo lesson in Appendix A.
Because the last step in any modular math problem always finds the remain-
der, the multiplication table, shown in Figure 11-13, doesn’t have a product
greater than 10; after multiplication, the modulo operation reduces the prod-
uct (see Figure 11-13). For example, in both grade school and modular math,
3 x 3 = 9. But grade school math and modulo have different answers for 3 x 4
because modulo 10 reduces 12 to 2. Modular math also reduces 3 x 5, 3 x 6, and
so on.
This table also shows the kinds of modular multiplicative inverses that cryp-
tographers use to build public and private keys; for example, 7 x 3 mod 10 = 1.

10 o’clock + 4 hours = 2 o’clock

(10 + 4) mod 12 = 2

Figure 11-10 Clock math uses modulo.

 DivisiON AND REMAINDERS: MODULAR MATH 105

Quotient + Remainder
(residue)
Divisor [Dividend
(modulus)

Grade School Division

Dividend / divisor = quotient + remainder
Answer
Dividend / Divisor = Quotient + Remainder
13 f Sore 1 + 3
23 / 10 = Q + 3
33 / 10 = 3} + 3
43 Tt Mele 4 + 8

Modular Arithmetic
Dividend / modiiiiis = residue (remainder)

_Answer_
Dividend ee + Remainder
J

Figure 11-11 Grade school division compared to modular math.

Same dividend (13) f Different dividends § Random dividends

— different modulus — same modulus (10) and random modulus }

13mod10= 3 | 13 mod 10 = 13mod10= 3

13 mod 11 = 21 mod 10 = 14mod10= 4
13 mod 12 = 1 25 mod 10 = 14mod11= 3}
13 mod 13= 0 | 32mod10= 2 | 15mod11= 4]
13 mod 14 = 13 | 4,567 mod 10 = 7| 15mod12= 3]
13 mod 15= 13 1,247 mod 10 = 7 } 28 mod 12 = A
wsarnansrnsbovsssshonseetee eaoconcesnaenonsenecnapsianennt ene AN ANBAR OROOEY

If you’re not familiar or comfortable with modular math, glance at some of

these modulo examples to solidify your understanding. Because modular math
is often easier than division, all these examples can be done in your head.

Recall 13 mod 14 = 13 because:

O remainder 13
A tS

Figure 11-12 Modular math examples.

106 CuaptTer 11 © MAKING Pustic Keys: MATH TRICKS

Modulo Multiplication—
(example: Modulo 10)

If product < 10
“normal multiplication”

If product equals or > 10

after normal multiptication,
divide by 10 and use remainder §

Examples:
| 3x3 =9 (same as usual)
3x4 = 12 (different)
12/10=1 remainder 2

Figure 11-13 Multiplication modulo 10. The product is always less than 10 because
modulo is about remainders and not quotients.

Modular Inverses
Multiplicative As you have seen, in grade school math the inverse of any whole number is easily
inverses are two computed; it’s simply 1 divided by the integer. For example, the inverse of 8 is
numbers multipligd 1/8. Modular inverse pairs—two whole numbers multiplied together that equal
together that 1—are the favorite modulo property of cryptographers. We’ll see how Alice uses
equal 1. modular inverse pair numbers to force BlackHat to solve a time-consuming
puzzle.
Figure 11-14 compares the simple inverse of 8 and the more difficult-to-
determine inverse of 3modulo 10. (Appendix A has more details on finding
modular inverse pairs.)
Figure 11-15 shows a simple inverse you learned in grade school as well as
a modular inverse. Multiplying any number (1, 2, 3, ... 9) by 3 x 7 modulo 10
is the same as multiplying by 1, the original number doesn’t change. If you like,
instead of separately multiplying by 3 and then 7 you can multiply by 21 (3 x 7),
as shown in Figure 11-16. The important point is that multiplying by a modular
inverse pair is just like multiplying by 1.
 MODULAR INVERSES 107

Inverses ;

Simple inverses: Modulo inverses:

(fractions OK) (no fractions allowed)

sae 4 =1/8 Sid (ee! O41 Qei

3x 7mod10=1

Modulo inverses:
Simple inverses: 4x3x7mod10=4

4x8x1/8 =4 —or in separate steps—

4x3mod10=2
2x 7mod10=4

Figure 11-15 Multiplying using simple and modulo inverses.

Multiplicative Identity

Sequence x 21 Mod 10

(3x 7) (restored)

Figure 11-16 Multiplying by a modular inverse pair.

108 CHAPTER 11 e MAKING Pustic Keys: MATH TRICKS

Multiplying by a This is the modular math trick that modern-day cryptographers put to good
modular inverse use. You can make modular inverse pairs that are much more difficult to find
pair is just like than inverses such as 3 and 7 mod 10. Because there are an infinite number of
multiplying by 1. moduli and an infinite number of inverse pairs, cryptographers can choose a pair
that, unless you know the secret generating numbers, will be very, very difficult
to find.
Now let’s separate the process into two parts to create public and private
keys. We’ll need to use a slightly larger modular inverse pair to see how Alice
makes a public/private key pair—in particular, how Alice creates a public key
inverse of her private key.
Real-world public We used 21 (3 x 7) mod 10 because the numbers are easy to work with.
key methods use When you use modulo 10, the answers are restricted to 0-9 because mod 10
moduli more than means remainders after division by 10 must be less than 10. Because bigger
200 digits long. moduli have more inverse pairs, cryptographers prefer much bigger numbers.
For example, RSA uses moduli more than 200 digits long to make the search
even more frustrating for someone who doesn’t know the trick numbers. For-
tunately, we don’t need numbers that big to show how public/private key inverse
pairs scramble and restore messages. A modulus of 101 is sufficient to illustrate
public key math tricks and stil! is relatively easy to work with.
Figure 11-17 shows an example of another modular inverse pair (22 x 23
mod 101). If you multiply any number from 1 to 100 by 22 x 23 modulo 101,
the result is the original number because 22 x 23 mod 101 = 1; so it’s the same

ee | ean
m) raed

0 0 0
1 506 1
3 1,518 3
5 2,530 5
10 5,060 10
20 10,120 20
40 20,240 40

Examples:

1 x 506 = 506. 506/101=5R1

3x50 1,518/101 =15R3 |

Figure 11-17 A multiplicative identity using modulo.

 UsinG MODULAR INVERSES TO MAKE A Pustic Key 109

as multiplying by 1. (If you still find modulo a bit puzzling, see the section
“Modulo Calculations” later in this chapter.)
It’s important to see that 22 x 23 mod 101 works as a multiplicative iden-
tity just like 8 x 1/8 or 7 x 3 mod 10. Multiply any number by 506 and divide it
by 101, and the remainder is the original number. It works every time for all
numbers less than 101, the modulus.
By the way, you may have noticed that the column labeled “Original Num-
bers” in Figure 11-17 is Alice’s super-increasing sequence from the beginning
of the chapter. (We sneaked that in when you were concentrating on modular
inverse pairs.)

Using Modular Inverses to Make a Public Key

Alice keeps the Recall that Alice (or BlackHat) can quickly and easily figure out any sum made
easy numbers for from the super-increasing number sequence (1, 3, 5, 10, 20, 40) first shown in
herself and makes Figure 11-3. These are the numbers she uses to solve her easy problem; it’s her
difficult numbers private key.
for BlackHat. Here’s how Alice uses her private key and modular inverses to create her
public key. She simply multiplies each of her private key numbers by 23 mod
101, shown in Figure 11-18. That transforms the private key numbers 1, 3, 5,
10, 20, 40 into her public key 23, 69, 14, 28, 56, 11.

Private Key Public Key

(super-increasing sequence) mod 101

Figure 11-18 Manufacturing a public key from a private key using modular inverses.
110 CHAPTER 11 © MAkiNG Pustic Keys: MATH TRICKS

Putting It All Together

Now let’s watch Bob use Alice’s public key to encipher his stock picks. Even
though BlackHat has a copy of Alice’s public key, he can’t quickly figure out
which numbers Bob chose.

Giving BlackHat a Difficult, Time-Consuming Problem

Recall the example from the beginning of this chapter, shown again and labeled
Alice’s private and
“Private Key” in Figure 11-19. The figure also includes Alice’s newly minted
public keys
public key, which Alice openly distributes. Her customers use it to request stock
reports in the next newsletter. She keeps her private key private.
In the beginning of the chapter Alice openly distributed her super-increas-
ing sequence (private key). Bob and BlackHat made copies. Bob summed A (1),
B (3), and F (5) and sent the number 9 to Alice. Although Alice easily figures out
that 9 means A, B, and F, so does BlackHat.
Bob makes the sum
Now Alice openly distributes her public key and does not disclose her pri-
106. BlackHat can’t vate key. Now when Bob selects stock A, B, and C he adds 23 + 69 + 14 and
quickly figure out sends the sum 106 to Alice. Even though BlackHat has a copy of Alice’s pub-
which numbers lic key, he must spend a long time figuring out which numbers sum to 106.
Bob used. Because BlackHat doesn’t know and can’t easily figure out the modular inverse
pair Alice used to make her public key, she has successfully forced BlackHat to
solve a time-consuming and difficult problem.
If you’re not convinced that BlackHat’s problem is much more difficult than
Alice’s, try to figure out which numbers sum to 103. You’ll find the answer just
before the “Review” section. How does Alice transform Bob’s message, 106, to
an easy problem?

Public Key
(openly distributed)

Private Key select and sum

(not disclosed) stock numbers
Amazon.com
Barnes & Noble
Ford Motor
General Motors
IBM
Microsoft

Figure 11-19 Alice’s public and private keys.

 PuttinG It Att TOGETHER 111

Trapdoor to the Easy Problem

Alice knows how to transform the difficult problem (finding which public key
stock numbers sum to 106) into a much easier one (finding which private key
stock numbers sum to 9). As shown in Figure 11-20, Alice multiplies 106 by 22
mod 101 and gets 9. She then easily figures out that 9 can be made only by sum-
ming 5, 3, and | (which are A, B, and F).
Why does this work? Recall that the modular inverse pair is 23 x 22 mod
101. Figure 11-21 shows that each number in Alice’s public key is created by
multiplying each number of her private key by 23 mod 101. Figure 11-21 also

106 x 22=2,332 \
2,332 mod 101 = 9}
9=5+3+1 SESE a,
ip le ZN 93+ 69 + 14 =106 J

Figure 11-20 BlackHat intercepts but can’t figure out Bob’s stock requests.

Private Key Public Key Private Key

(Column 1 (Column 2 (Column 3 (Column 4

x 23) mod 101) x 22) mod 101)

Figure 11-21 Alice manufactures a public key from her private key, and then, to show it’s reversible, she
converts her public key back to her private key using her modulo inverse pair 23 x 23 mod 101.
 112 CHAPTER 11 @ MakinG Pustic Keys: MATH TRICKS

shows she can convert each public key number back to its private key by mul-
tiplying by 22 mod 10, the other number of this particular modular inverse pair.
Alice can use this method to convert public key numbers or sums of public key
numbers to corresponding private key numbers, that is, 106 converts to 9.
Again, it’s not important to remember the intricacies of this particular cryp-
tographic system. But using modular inverses to effectively multiply by 1 is the
cryptographic math trick behind most public key cryptographic systems. Appen-
dix A shows how RSA creates public/private key pairs using modulo inverses.

Knapsack Cryptography
Alice’s simplified public key system presented here is based on the first commer-
cial public key system to offer confidentiality. Called the knapsack, it was in-
vented by Ralph Merkle and Martin Hellman. The knapsack is no longer a
secure system because its design was based on a telltale mathematical pattern
that eventually gave it away. The knapsack’s weakness, discovered by Adi Shamir
(the S in RSA), is not in the use of modular inverses but rather is in an under-
lying part of the knapsack’s private key. In fact, modular inverse pairs are used
more in RSA than in the knapsack. RSA, probably the most widely used pub-
lic key cryptographic system, is the subject of Chapter 12.

Modulo Caiculations
As promised, all the intermediate calculations of Figure 11-18 are shown in
Figure 11-22.

Exercise: Find Which Numbers Sum to 103

Convert the public key sum (103) to the private key sum (103 x 22 mod 101 =
44). Then find which private key numbers sum to 44. The number 44 is
uniquely made by summing 40, 3, and 1, which correspond to M, B, and A, re-
spectively. So 103 must be made by adding 23 (A), 69 (B), and 11 (M); see Table
11-2.

Table 11-2 After Alice converts 103 to 44, she knows that Bob picked stocks A, B, and M.

A B F G i M
public 23 69 14 28 56 11 23 + 69+ 11= 103
private I 3 5 10 20 40 1+3+40=44
 Review 113

Modulo Multiplicative Identity

Original *99*93
Quotient & Calculations Mod 101
Numbers (506)

0 0 0 eOie= 0 0

1 506 5 Oils 505 1

3 i}Silks) 15 Oi 1s 3

5 2,530 25 AIO = 2/525 5

10 5,060 50 “Oy = 5,050 10

20 10,120 100 =1015= 10,100 20

40 20,240 200 Oils 20,200 40

The second column shows the number multiplied by 506 (=22*93),

(2.9 1x 50617506):
The quotient column shows how many times that number is divisible
by 10N(e.97. 5067/1015).
The calculations columns show how the remainder is figured, (e.3.,
506 505'=11)):

Examples:
eX 5O6i— sD 06 506 = Sea lOlerat
Sxt50Ol=al oie A Dil = desi Onis

Figure 11-22 Detailed intermediate calculations of Figure 11-18. The numbers dem-
onstrate that 22 x 23 mod 101 is like multiplying by 1.

Review
Public key cryptography, although complex, is based on the simple mathemati-
cal concept of multiplicative inverses. Multiplicative inverses are two numbers
that when multiplied together equal | (e.g., 8 and 1/8). In modular mathemat-
ics, two whole numbers are inverses if, when they are multiplied together, the
answer is | (e.g., 7 x 3 mod 10 = 1).
Cryptographers use modular inverse pairs to help create secure public and
private keys. Multiplying a message by one of the inverse pairs scrambles (en-
crypts) it, and multiplying the encrypted message by the other inverse pair re-
covers (decrypts) it. For example, suppose the message is 4. To scramble it, you
use 4 x 7 mod 10 = 8. To recover it, you use 8 x 3 mod 10 = 4.
114 CHAPTER 11 © MakinG Pustic Keys: MATH TRICKS

Almost all public key systems base their security on the difficulty of per-
forming inverse calculations. By using simple math tricks in very complex ways,
cryptographers have built public key systems that allow Alice to create and
openly distribute her public key—without compromising the security of her
private key or messages encrypted with her public key.
 Chapter 12
@ Private Key Assurances

CREATING DIGITAL SIGNATURES

UsING THE Private Key
Authentication
Integrity
Nonrepudiation

n Chapter 10 Bob used Alice’s public key to encrypt a message and gain con-
fidentiality with Alice. In this chapter Alice uses her private key to offer Bob
(and her other customers) the other cryptographic assurances: authentication,
integrity, and nonrepudiation.
Let’s briefly review some public key concepts. Alice’s public key provides
Bob confidentiality because only Alice can decrypt a message encrypted with her
public key. Although Casey knows Alice’s public key, he can’t decrypt Bob’s
messages to Alice (see Figure 12-1).
. Public key cryptography allows Alice to openly distribute her public key and
solves the secret key distribution problem discussed in Chapter 8, arguably the
most outstanding cryptographic achievement of the past millennium.
Public key Amazingly, public key cryptography solves another problem crucial to
cryptography lets e-commerce and Internet cyber relationships. The second big win for public key
you emulate cryptography empowers Alice (or any private key holder) to emulate signed
written signatures paper documents. This use of public key technology is called a digital signature.
Because many legal systems and trust are based on signed paper documents, the

Figure 12-1 Alice’s customers send her confidential messages requesting stock
reports in her next newsletter. Only Alice can decrypt these messages.

115
116 CuHarter 12 © CREATING Diaitat SIGNATURES USING THE PRIVATE Key

significance of cryptographic digital signatures to the development of e-com-

merce is difficult to overemphasize.

Written and Digital Signature Assurances

In Figure 12-1, each of Alice’s customers sends her requests to include particular
stock reports in her next newsletter. Using the confidentiality afforded by Alice’s
public key, each of her customers encrypts his or her requests so that no one else
can discover his or her particular interests. Alice reports on every stock re-
quested in her newsletter. To save money on mailing, Alice does not mail the
newsletter in an envelope but rather sends it as an open newsletter at the bulk
rate.
Although Alice and her customers don’t care who reads her stock reports,
her customers want assurances that they receive her genuine, unaltered newslet-
ter. In cryptographic terms, Alice and her customers are concerned with authen-
tication of the newsletter (knowing that it contains only Alice’s genuine stock
reports) and not with confidentiality (ensuring that the information stays secret).
Written signature In the paper world, Alice achieves authentication by personally signing each
assurances newsletter; her signature assures her customers that the newsletter was created
by Alice and was not changed during transit (see Figure 12-2).
Digital signature In the Internet scenario, as shown in Figure 12-3, Alice and her customers
assurances are also concerned with authentication and not with confidentiality. The news-
letter is sent by e-mail to many customers and passes through many computers.
Alice and her customers don’t care that other customers (or anyone else) can
read the e-mailed newsletter; Alice’s customers want assurances that they receive
Alice’s genuine newsletter and that the newsletter has not been altered in transit.

Tamperproof Newsletter

Stock Reports On: From: Alice

A, B, F, G, |, and M
To: Alice’s
ONicp Customers

Figure 12-2 A tamperproof, signed newsletter is signed by Alice and can’t be re-
placed by BlackHat without being detected.
 REVIEWING AND COMPARING AUTHENTICATION 117

AliceDotCom Internet Casey

Stocks Provider

Figure 12-3 Alice e-mails her newsletter to her customers.

Reviewing and Comparing Authentication

Secret key and public key cryptography differ in how they provide
authentication.

Secret Key Authentication

For thousands ofyears, encryption meant secrecy (confidentiality). Authentica-
tion (genuineness) is a byproduct of secret key cryptographic systems. Bob trusts
the confidentiality and authenticity of the messages sent by Alice because he
trusts that only he and Alice share their secret key.
If Alice has only one customer (say, Bob) and a shared secret key with him,
it’s easy to get those assurances. Alice encrypts the newsletter with the secret key
and sends it to Bob with a MAC or a message digest.’ If BlackHat substitutes
his own newsletter for Alice’s newsletter, it simply won’t decrypt with Alice and
Bob’s shared secret key.

Private Key Authentication

Public key Because public key cryptography has public and private keys, cryptographic
assurances are assurances are implemented differently than with secret key cryptography.
implemented
differently from
secret key
assurances.
1. A message digest is another kind of message fingerprint. It is introduced in Chapter 7
and explained in more detail in Chapter 13.
118 CHaptern 12 © CREATING DiiTAL SIGNATURES USING THE Private Key

Public key cryptography allows messages to be encrypted with the private key
(as well as the public key).’
Understandably, encrypting with the private key can be confusing because,
until this chapter, encryption has been associated with confidentiality. But Alice
doesn’t encrypt with her private key for the purpose of making confidential
Many copies of messages. Instead, Alice encrypts her newsletter with her private key to prove
Alice’s public key to Bob that the newsletter he receives originated from her.
but one copy of Recall that when Alice makes her public/private key pair, she openly distrib-
her private key utes many copies of her public key to her many customers. She never shares her
private key; there is only one copy of her private key. So any message that Bob
Private key or anyone else decrypts with Alice’s public key must have been encrypted with
encryption Alice’s private key.
provides This means that encrypting with her private key gives Alice a way to prove
authentication, she authored the message (author authentication) and to assure recipients that
integrity, and the message was not altered in transit (message authentication, also. known as
eulig STEelie) integrity). So even though a private key encrypted message does not provide
confidentiality, it does provide authentication and integrity (see Figure 12-4).
(Notice in Figure 12-4 that a slightly different symbol is used to illustrate a
private key encrypted message. We use this symbol in the rest of the book.)
Private key You'll also see that private key encrypted messages provide nonrepudiation.
encrypted
message

Alice’s|
IC@S| pip
2.
ews | * 7
pd.
Internet

‘ Alice’s
News
p

Figure 12-4 Alice encrypts her message using her RSA private key. Any owner of her
public key can decrypt the message.

2. Although the phrase “encrypted with the private key” is widely used and accepted,
purists prefer the terms that are discussed in the section “Signing Terminology” later
in this chapter.
 AUTHENTICATION AND INTEGRITY UsiING PRIVATE AND Secret Keys 119

Authentication and Integrity Using Private

and Secret Keys
Pulolic key As has been explained, secret key cryptography also supports authentication and
cryptography integrity. But Alice must share a separate secret key with each customer, some-
supports thing that’s too difficult to administer (see Chapter 8). Public key cryptography
authentication and supports authentication and integrity more efficiently. Alice needs only encrypt
integrity more one newsletter, which she then copies and sends to each public key holder. Any
efficiently than public key holder decrypting the newsletter is assured that Alice encrypted the
secret key
newsletter (ensuring authenticity) and that the newsletter has not been altered
cryptography
since Alice encrypted it (ensuring integrity). Of course, all assurances are null
and void if someone else has Alice’s private key. But the key to your privacy isn’t
something you intend to share.
Definition: digital Private key encryption is just like signing your name, and that’s why it’s
signature called a digital signature. Vhis is another important reason to keep your private
key private.
But what if BlackHat intercepts Alice’s encrypted newsletter and substitutes
his own private key encrypted newsletter (see Figure 12-5)?
Decrypting BlackHat’s spoofed newsletter with Alice’s public key makes
gibberish. You might think that because BlackHat knows Alice’s public key, he
could figure out how to make encrypted text that decrypts to an intelligible
message. So far there’s no known successful attack of this kind.
If BlackHat wants to convince Bob that his forged newsletter is from Alice,
BlackHat must somehow dupe Bob into using BlackHat’s public key instead of
Alice’s public key. For example, BlackHat could intercept Alice’s e-mail, which

gibberish f

Figure 12-5 BlackHat intercepts Alice’s newsletter and substitutes his own, which
he sends to Alice’s customers who end up with gibberish after decrypting with Alice’s
public key.
120 CHAPTER 12 © CREATING DiaiTaL SIGNATURES USING THE PRIVATE KEY

distributes her public key to Bob, and substitute his public key for Alice’s. In
Chapter 22, you’ll see what happens when BlackHat successfully substitutes his
public key for Alice’s. Digital certificates help Bob prevent BlackHat from suc-
cessfully completing that switch; see Chapters 16 through 18.

Private Key Authentication Methods

Now let’s take a look at the private key authentication methods: RSA and Digital
Signature Algorithm (DSA).

RSA
Since its invention in the late 1970s, RSA using a sufficiently long key has with-
stood all known attacks. Interestingly, a recent plausible attack against RSA was
by Adi Shamir, the S in RSA.
RSA offers all RSA is the only widely used public key cryptographic system that enables
cryptographic its public and private keys to encrypt messages. The math behind RSA makes
ASSUFANCEs. both public and private key encryption equally secure. This means that RSA
provides both confidentiality (encrypting with public key and decrypting with
private key) and digital signing (encrypting with private key and decrypting with
public key). Almost all other popular cryptographic methods support one or the
other but not both. RSA%s versatility seems almost too good to be true. Surpris-
ingly, because RSA is so versatile, if Alice uses the same RSA key pair for both
confidentiality and digital signatures, BlackHat can mount an attack to recover
encrypted plaintext (see Chapter 22). Because of these kinds of attacks and for
other reasons, many cryptographers believe that anyone using RSA should keep
two RSA key pairs: one pair used exclusively for signatures and a second pair for
everything else.
om ieee. As shown in Chapter 11, the knapsack method is based on the difficulty of
aceon finding numbers that exactly sum to a given total. RSA’s security is based on the
factorization. difficulty of factoring the product of two (large) prime numbers. RSA is still
secure against attack, but larger and larger prime numbers are needed because
of the ever-increasing power of microprocessors.
RSA, like all good commercial encryption formulas, is openly published.
Allowing anyone to attack the method helps to prove or disprove its strength.
(See Appendix A for a more in-depth mathematical look at RSA security and
information about how to make RSA key pairs.)

3. Recently, Shamir theorized a way to cryptanalyze a 540-bit RSA key. Most public key
systems use at least a 1,024-bit key.
 Private Key AUTHENTICATION METHODS 121

DSA
Digital Signature Algorithm is used only for digital signatures. As with RSA,
DSA’s private key encryption provides authentication, integrity, and
nonrepudiation. But unlike RSA, DSA cannot be used for confidentiality.*
DSS is the U.S. DSA was proposed to NIST and was adopted as a U.S. Federal Informa-
government tion Processing Standard (FIPS) in the early 1990s. At the time, several contro-
standard that versial issues surrounded DSA. For example, some believed that because RSA
mostly addresses was already in wide use, it should be adopted as the standard; and some believed
DSA that NSA had too much development oversight over DSA. DSA has proven to
be as secure as RSA. DSA is described in FIPS Pub 186-1 (revised in 1998) titled
“Digital Signature Standard (DSS).”°

RSA

Alice’s ra Se Alice’s
ss
ees
News Internet

Sign (Private Key Encrypt) Verify (Public Key Decrypt)

DSA

Alice’s Oe
News Internet

Sign (Private Key Encrypt) Verify (Public Key Decrypt)

Figure 12-6 Comparing RSA and DSA signing and verification. Note that RSA veri-
fication (decryption) recovers the original signed (encrypted) plaintext. DSA veri-
fication is “yes” (accept) or “no” (reject).

4. Although a modified DSA can support public key encryption, this feature is complex
and seldom used.
5. Although DSS is mostly about DSA, it also approves RSA as a signature method.
122 CHAPTER 12 e@ CREATING DiaitAL SIGNATURES USING THE PrivATE Key

RSA signature A major difference between RSA and DSA, shown in Figure 12-6, is that
verification RSA digital signature verification (public key decryption) does not need the
recovers plaintext, original plaintext. DSA, like most other popular digital signature methods, does
but DSA does not. need the original plaintext to verify the digital signature. In other words, RSA
digital signature verification recovers plaintext; DSA does not.
DSA, as it’s most often used, gives Bob a simple “yes” or “no”—that is, it
accepts or rejects the validity of the digital signature. In practice, this distinc-
tion doesn’t matter because, as you’ll see in Chapter 13, both signing methods
compress (digest) the plaintext before signing.
RSA and DSA produce signatures in about the same amount of time, but
RSA verifies signatures much faster than does DSA. But DSA can precompute
some of its values and thereby produce signatures faster than RSA. Even with
precomputed values, however, RSA verifies much faster than DSA.°

Signing Terminology
Formal terminology: Although you'll see the terms private key encryption and public key decryption used
Only with RSA is for RSA, DSA, and so on, technically speaking, they should be used only for
private key RSA (because, as seen in Figure 12-6, only RSA keys encrypt and decrypt
encryption plaintext). When you’re using digital signature methods, the technically correct
equivalent to terms are signing (instead of private key encrypting) and verifying (instead of
signing and public public key decrypting). Although private key encrypting and public key decrypting
key decryption are widely accepted and used, we use signing and verifying in the remainder of
equivalent to the book. To accustom you to this nuance in the terminology, from time to time
verification.
we'll write signing with private key encryption in parentheses and verifying with
public key decryption in parentheses.

Nonrepudiation
After Alice digitally signs (encrypts with her private key) and sends her news-
letter, the recipient is assured that it was made by Alice (or someone who knew
her private key). Alice can’t deny or repudiate her newsletter recommendations.

6. Because DSA can generate signatures faster than RSA, perhaps DSA will be used to
generate digital signatures on smart cards (see Chapter 23). Then the slower signa-
ture verification process can be handled on more powerful network server computers.
 SUMMARY OF PuBLic Key ASSURANCES 123

This cryptographic assurance, called nonrepudiation, is an essential component

of Internet commerce.
For example, Bob requests that Alice buy Widget Corporation for his ac-
count, and Alice responds with a digitally signed confirmation (a message en-
crypted with her private key). Alice can’t later deny that she sent the
confirmation because, as mentioned previously, no one can forge a signed (en-
crypted) confirmation that will verify (decrypt) with Alice’s public key.’ Of
course, someone who stole Alice’s private key could forge the signed
confirmation.

Assurances in Both Directions

In real-world In the simple system just shown, we assumed that only Alice created a public/
systems every private key pair and that she has shared her public key with Bob and her other
person has his or customers. Alice uses her private key to assure Bob of her authenticity, message
her own public/ integrity, and nonrepudiation. But because Bob only has Alice’s public key, he
private key pair. can’t offer Alice the same assurances. To assure Alice that Bob’s communications
to her are from him, Bob must create his own public/private key pair and share
his public key with Alice. In Part IV we show cryptographic assurances in both
directions.

Summary of Public Key Assurances

Figure 12-7 briefly summarizes public key cryptographic assurances and shows
the symbols we use in the remainder of the book.
Alice’s public/private matched pair is shown as white and black, respectively.
A white (public) key encrypted message makes a confidential message and is
shown against a black and dark gray background to illustrate concealment or
secrecy. A black (private) key signed (encrypted) message is indisputably made
by Alice (the sole holder of the private key) and is shown against a white and
light gray background to illustrate openness or easy visibility. Anyone can verify
that the private key signed (encrypted) message is from Alice and then read it
because anyone can get and use Alice’s public key.

7. Recall that this assurance can’t be made with secret keys alone; Untrusty denied that
he sent Alice and Bob a secret key encrypted confirmation (Chapter 7).
124 CHAPTER 12 © CREATING DiGitaL SIGNATURES USING THE Private Key

PUBLIC KEY CRYPTOGRAPHY ASSURANCES

Encrypt (with Public Key)

Tr Wl Confidentiality—privacy of message

LJ
SISNIN (with Private Key)

Authentication—exposes identity imposters

Integrity—exposes message alteration (aka message

authentication)

Nonrepudiation—cannot deny sending message

Figure 12-7 Public key cryptography provides the same assurances as secret key
cryptography, but those assurances are provided differently. Public key cryptography
also prevents the sender from denying sending a message (that is, it assures
nonrepudiation), something that is not supported in secret key cryptography with-
out a trusted third party.

Public Key Means Public / Private Key

Private keys are It’s also instructive to clarify some public key terminology. All public key cryp-
kept secret but tographic methods have both pubic and private keys. Nevertheless, public key
never shared. cryptography is seldom referred to as public/private key cryptography. A private
key is always kept secret (concealed or undisclosed), just as secret keys are kept
secret. However, one important difference is that private keys are never shared;
secret keys are often shared between two (or more) people.

Assurance Initiated
Figure 12-8 shows who initiates a particular assurance. For example, Bob, a
customer who has a copy of Alice’s public key, initiates confidentiality by en-
crypting a message with Alice’s public key.

Compressing before Signing

Signing (encrypting with a private key) is extremely slow, so you usually add a
time-saving (and space-saving) step before you encrypt the message. It’s called
 Review 125

Public Key Cryptographic Assurance

Initiated by Encrypting with Public or Private Key

Initiated by Confidentiality Authentication Integrity Nonrepudiation

Alice’s
Customers

t=
t= t=
Figure 12-8 Cryptographic assurances with public and private keys.

message digesting or hashing. “Digesting” might conjure an image of someone

eating a message—yummy, but that’s not quite what it means. Chapter 7 briefly
introduces message digests, and Chapters 13 and 14 discuss them in more depth.

Review
Public key confidentiality is one-way—from public key holder to private key
holder. Bob, Casey, and BlackHat have copies of Alice’s public key and can send
Alice confidential messages. Alice cannot send them confidential messages en-
crypted with her private key.
But Alice can provide her public key holders some assurances through the
use of signing (encryption) with her private key. Alice can assure her public key
holders that her messages are from the authentic Alice and haven’t been altered
in transit. She signs (encrypts) the messages with her private key (see Figure
12-4). Private key encryption is called digitally signing. Digital signatures need
a public key cryptographic system; each person has a private key, which is not
shared.
Authentication, integrity, and nonrepudiation extend from the private key
holder to public key holders (note the plural).
In general, after Alice creates her RSA or DSA private/public key pair, only
she uses her private key. Her customers know only Alice’s public key; that’s all
they use. In fact, if someone other than Alice ever learns her private key, her
entire public key cryptographic system is insecure. All future messages lack any
assurances.
 Pae r
ee

5 ete Se
“aesicsa aan
an

7 a eee > pannaey

OT SIG ea SO Oe ems- Gey Ate ie | fF i eee

= -

ae ’ _ ord : wi wat ah :
ees yc ter fap De ‘+ tp Deg Oe -
- ag ny* an as. ee a) “Gad >< Sey? ests y 2, © outa —
ft yall: Ly eal ee ratLeite wa *. ~ re gy pe 1.6 eth We
_
a

i
:

:
Rel
2
ens bigute go <i SURES cperend cdi
TVPG PS" =... aime
wa
a ee ee a by
PH,
Noivshalom veal"Prtss, a» =! agp rig ety ues lh he
Sens re
_ po: Lia ait i pe »ru 3 an nd wre

out Hag
Mer be Ovi tai Peale Ore Nua ikaw ign’ ge oor
<+vay ie aisT?, yr (hee beaters ronal Be --
el RadaFOF si G0 eR OM Mla. 9.4L dd
Ao ie Wh ae ee cae ms oy ‘Pyne Wietipen —* 7
ee? en 7
|
Bag repiaie
! ure ee
e etn ad en
v" - |) on abs ox bia sage hia stn nails T © - Y

ep + av "heads 9% ‘glad :
reing 4MOL ae pF s rae lA idle ornttg 4)

be cc Be BS
ou —

asirs A, ive énieligy 6.u ale vig 98 7

4
,
7
44 1 aa a 7 _ 7
Siem an a -
 Chapter 13

HASHES
NON-KEYED MESSAGE DIGESTS

I: Chapter 12, Alice signed (that is, private key encrypted) her newsletter to
assure her clients that the newsletter they received was Alice’s genuine, un-
altered newsletter. But signing anything except a small message takes too much
time.
Message digests Public key encryption and decryption methods, such as RSA and DSA, are
make public key as much as 1,000 times slower than secret key encryption, such as DES or the
cryptography more new AES standard, Rijndael. This means that an encryption that takes one
efficient. minute in DES takes many hours in RSA, obviously much too long for fast-
paced e-commerce. So cryptographers invented message digests to make private
key signing more efficient.
This chapter shows how Alice uses signed message digests (instead of a
signed message) and how Bob uses Alice’s signed message digest to verify the
origin (authenticity) and the genuineness (integrity) of Alice’s newsletter.
Definition: message A message digest is used as a proxy for a message; it is a shorter, redundant
digest represention of the message.’ Redundant, in computer lingo, refers to the rep-
etition of a message to identify whether the message was modified during
transmission.
Communication redundancies verify that the sent message was correctly
received. For example, in communications between a control tower and a pilot,
shown in Figure 13-1, communication redundancies are used to confirm that
the data sent was correctly received. The pilot’s reply is a compact, redundant
version of the control tower’s message.
Message digests Message digests add similar redundant assurances to digital data commu-
act as proxies for nications. And because a message digest is usually much smaller than the under-
larger data lying message, it’s faster to sign (private key encrypt) and verify (public key
decrypt) a message digest than a lengthy message.

1. MACs, discussed in Chapter 7, are also message digests. But MACs are made with
secret keys; this chapter looks at message digests that are made without secret keys.
The next chapter examines both types of message digests in more depth.

127
128 CHAPTER 13 e HaAsHes: Non-KEyED MESSAGE DIGESTS

Flight 12345
Cleared on Runway #8 12345 on 8 south @ 150
Approach from south
at 150 knots

Figure 13-1 Communication redundancies ensure that the message received accu-
rately reflects the message sent.

Coming in For a Landing: Don’t Shoot!

Identification Friend or Foe (IFF) devices were developed during Worid
War Il so US aircraft wouldn’t be shot down by friendly fire. Cryptogra-
phy was incorporated into the devices to stop the enemy from repli-
cating them. After the war, the IFF device was redesigned to fit into an
aircraft’s nose. A team led by Horst Feistel, later of DES fame, tested the
improved system and also developed the first practical block ciphers.
IFF without cryptography evolved into the Mark X, an essential part of
civilian and military air traffic control today.

Message digest, A message digest is also analegous to a fingerprint. You can authenticate a
aka (cryptographic) person’s identity by verifying facial characteristics, name, height, weight, age,
hash, aka digital knowledge of the mother’s maiden name, and so on. Similarly, a fingerprint is
fingerprint, aka also a small piece of data that authenticates identity. Because fingerprints and
cryptographic message digests are used as unique proxies for a much larger whole, message di-
checksum gests are also known as digital fingerprints (or message fingerprints). Vhey are also
referred to as cryptographic hashes’ or cryptographic checksums. We use these terms
interchangeably as.well as using the more abbreviated terms digest and hash.
Message digest Message digest methods supercompress messages so that encryption and
methods decryption operate on less data and, therefore, take less time. Secure Hash Al-
supercompress gorithm (SHA-1), the message digest algorithm currently recommended by
messages. government and private cryptographers, will compress all of Microsoft Office
to about the same amount of disk space occupied by 20 xs:
LED EERO CPE REAM D Ho
A message digest
Although message digests are similar to popular file compression programs
cannot be such as PKZip, WinZip, gzip, or Stufflt, a major difference is that popular com-
uncompressed. pression programs are made to compress and restore files. Message digest pro-
grams can’t and don’t restore their compressed messages; they on/y compress
messages. Just as a person cannot be reconstructed from a fingerprint (not yet
anyway), the original file cannot be reconstructed from the message digest (not
yet anyway).

2. Cryptographic hashes are not the same as the hashes used in computer programming.
Cryptographic hashes, although similar, add important security features.
 DETECTING UNINTENTIONAL MODIFICATIONS 129

Detecting Unintentional Modifications

Before we look at message digests, it’s instructive to look at other schemes that
also act as redundant proxies. Schemes such as parity checking and checksums
were invented before their cryptographic offspring and share many of the same
goals.
Typical (not cryptographic) checksum programs search for unintentional
message modifications that originate in things such as noisy communications
channels. Like message digests, checksums are designed to identify whether a
message has been modified. For example, suppose that Alice sends the checksum
and message to Bob. Bob independently calculates a checksum on the sent data
and compares it to the checksum sent by Alice. If the checksums don’t match,
Bob knows that data were modified or lost during transmission.
Figure 13-2 shows an example of a simplistic checksum error detection
code. Alice makes a checksum stating the number of 0’s and 1’s in her message.
Both the message and the checksum are sent to Bob. The checksum program
in Bob’s computer also computes a checksum (counts the number of 0’s and 1’s
in the message he received) and compares it against the checksum he received
from Alice. In Figure 13-2, the checksum Bob independently makes doesn’t
equal the checksum Alice sent, so the message might be rejected because the
number of0’s and 1’s received is incorrect. (The message might be accepted if,

Noisy channel
error

Checksum Checksum
Sent: Sent:
6 ‘0's 10000 | |& ‘O's
4‘1’s 1 ‘ 4 ‘1's

From Alice From Alice

| received:
7 ‘0's and 3 ‘1’s.
Something went
wrongs.

Figure 13-2 Detecting unintentional modifications. Alice makes and sends a

checksum of her data (6 0’s and 4 1’s). Bob independently calculates the number of
0’s and 1’s and compares it to the checksum sent by Alice. Bob knows that he should
have received one fewer O bit and one more 1 bit.
130 CHAPTER 13 e HAsHes: Non-kEYED MESSAGE DIGESTS

for example, it was a graphic containing thousands of bits and the presence of
one altered bit was acceptable.)
Message digests Checksum methods can easily be applied to any message of any size, and the
are (cryptographic) checksum report is usually much smaller than the underlying message. Message
checksums. digests operate in a similar fashion; you can also apply them to any size message
and output a small digest. Message digests are specialized checksums; hence the
name cryptographic checksums.
Let’s review our symbols and add two new ones before we see how Alice and
her customers use message digests to prevent BlackHat from perpetrating a
fraudulent newsletter. Figure 13-3(a) shows Alice signing, and 13-3(b) shows
Bob verifying her newsletter.
Figure 13-3(c) introduces new symbols to illustrate the creation of a mes-
sage digest. The symbols represent the plaintext message (Alice’s newsletter)
crumpled into a unique wad of paper. The pictures of Alice’s newsletter and its
corresponding message digest aren’t to scale. In reality, Alice’s newsletter could
be 10,000,000 bytes or more, whereas a SHA-1 message digest is only 160 bits
(20 characters). Figure 13(d) shows a signed (private key encrypted) message
digest. Figures 13-3(e) and 13-3(f) contrast with 13-3(b); the message digest (in-

Signing Without Hashes Verifying Without Hashes

Alice’s == " 22S A Alice’s

News = (= « aes == News

(a) Signing (6) Verifying

Encrypting with Decrypting with
Private Key Public Key

(c) Hashing (e@) Hashing

(Making a (Making a
Message Digest) Message Digest)

Vee th ot”

(d) Signing (f) Verifying (step 1 of 2 steps)

Encrypting with Decrypting with Public Key
Private Key

Figure 13-3 (a), (6): Signing and verifying the whole message (no digest). @), (eds
Making and signing a message digest. (e), (f): Making and verifying a message digest.
 DETECTING INTENTIONAL MODIFICATIONS 131

stead of the message) is used for signing and verification. The rest of this chapter
explains how a signed message digest verifies message integrity (ensuring that
the message was not altered during transit).

Detecting Intentional Modifications

Because message digest signing and verification is probably one of the most
confusing cryptographic processes, let’s look at the pieces of that process one
step at a time. First, let’s see how an unsigned (not private key encrypted) mes-
sage digest detects intentional modifications, just like the checksum shown in
the preceding section. Then we’ll show BlackHat successfully attacking an un-
signed digest. Finally, we’ll show how a signed message digest stops BlackHat.
Figures 13-4 and 13-5 show how Alice and her customers use a message
digest as a redundant proxy for her newsletter. In Figure 13-4 Alice makes a
message digest and sends both the newsletter and the (unsigned) message digest
to Bob (and her other customers). Bob verifies the newsletter’s authenticity and
integrity with the three steps shown in Figure 13-5.

Figure 13-5 Bob independently calculates a digest and compares it to the digest
sent by Alice. If they are equivalent, he trusts that the message has not been modi-
fied during transit.
132 CHAPTER 13 e@ HAsHes: Non-KeyeD MESSAGE DIGESTS

1. Bob extracts Alice’s newsletter and independently calculates a message

digest.
2. Bob extracts the message digest Alice sent to him.
3. If Bob’s independently calculated message digest (from step 1) equals the
message digest he received from Alice (from step 2), he trusts that the news-
letter has not been modified since Alice made the message digest.

BlackHat Note that Alice did not sign anything—that is, she hasn’t used her private
successfully attacks key to digitally put her identity on the message or digest. Let’s watch BlackHat
because Alice convince Bob he has Alice’s newsletter, when in reality BlackHat has intercepted
hasn't attached Alice’s newsletter and substituted his forgery. In Figure 13-6, BlackHat forges
anything uniquely Alice’s newsletter, and makes a message digest from the forgery (a gray news-
hers to the letter depicts BlackHat’s forgery). Then, in Figure 13-7, BlackHat intercepts
message.
Alice’s genuine newsletter and message digest and substitutes his forged “Alice’s
NEWZ)” and digest.
In Figure 13-8, Bob independently calculates a message digest from the
forged newsletter following the same procedure shown in Figure 13-5. Because
his calculated message digest is equivalent to the one he received, he accepts the

Alice’s
News

Alice’s Genuine BlackHat’s Forged

Newsletter Newsletter

Figure 13-6 BlackHat forges a newsletter and makes a message digest from the
forgery.

Figure 13-7 BlackHat intercepts Alice’s genuine newsletter and digest and substi-
tutes his forged newsletter and digest.
 SIGNING THE MESSAGE DIGEST 133

Figure 13-8 Bob verifies that the newsletter hasn’t changed since the attached
message digest was made.

newsletter as unaltered since it left the newsletter creator. Bob’s logic isn’t
wrong; the message and the message digest are a matched pair. But as shown in
Figure 13-8, there’s no signed (private key encrypted) message digest to help
Bob detect that Alice did not create the newsletter he received. Unfortunately,
Bob buys CrashingDotCom.
Let’s recap how BlackHat tricked Bob. Bob uses the newsletter/digest pair
to determine whether the newsletter was modified after it left the sender. But
BlackHat becomes the sender by substituting his own newsletter/digest pair.

Signing the Message Digest

The difference To prevent BlackHat from successfully forging her newsletter, Alice signs a
between an message digest of her newsletter. Figure 13-9 illustrates the difference between
unsigned and a a signed and an unsigned digest. Figure 13-9(a) shows Alice making and send-
signed message ing a digest. Alice and Bob tried this in Figures 13-4 and 13-5, but it was suc-
digest cessfully attacked. Figure 13-9(b) shows Alice making and sending a signed
digest.
Verifying a signed First, let’s see how Bob verifies that the newsletter he receives is Alice’s
message digest authentic newsletter. Then we’ll examine how the signed message digest detects
BlackHat’s forgeries. Figure 13-10 shows Bob verifying that the message has
not been modified since Alice made and signed the digest. (For convenience, the
upper-left corner of Figure 13-10 shows Figure 13-5.) Figure 13-10 is similar
to Figure 13-5 except that Bob first decrypts the signed digest with Alice’s public
key. Bob then verifies the newsletter’s genuineness in the same way as shown
previously.
As shown in Figure 13-9(b), Alice attached her identity to the newsletter
digest. Bob knows that the newsletter is authentically from Alice because only
Alice’s public key will verify (public key decrypt) a message digest equal to the
one Bob independently calculates from the newsletter he received.
134 CuHapteR 13. © HASHES: NON-KEvED MESSAGE DIGESTS

(a) Alice sends (b) Alice sends message

message and digest and signed digest

ce
Ondo
moon oo a,

Alice digests her 7 Alice digests and signs

newsletter... 2s her newsletter...

...and sends the newsletter and ...and sends the newsletter and
unsigned digest to Bob. signed digest to Bob.

Figure 13-9 The difference between a message digest and a signed message digest.
An unsigned message digest doesn’t detect BlackHat’s forgery.

Review Bob uses

Bob Alice’s public
independently key to decrypt
calculates Alice’s signed
‘ newsletter . digest so he
CG2\ | digest — oF: can verify it
ete ¥
against the
Figure 13-5 ] digest he
Unsigned digest 4 made
an “A, independently
vem it a from her
& “plaintext.

Figure 13-10 Bob verifies Alice’s newsletter.

 SIGNING THE MESSAGE DIGEST 135

Detecting BlackHat’s Forgery

Signing digest The signed newsletter digest prevents BlackHat from fooling Bob with his forg-
detects BlackHat’s ery. Let’s illustrate what happens when BlackHat tries to send his forged news-
forgery. letter to Bob.
Let’s first review some basics in Figure 13-11. In particular, notice that
encryption with one key and decryption with its matching key is like multiply-
ing by 1. In Figure 13-11(a), a plaintext message is encrypted and decrypted, and
a message digest is signed (encrypted) and verified (decrypted) with Alice’s pri-
vate/public key pair. In Figure 13-11(b), a message digest is signed (encrypted)
with BlackHat’s private key and verified (decrypted) with Alice’s public key. Note
that because BlackHat’s private key is not a companion to Alice’s public key, the
result of encryption/decryption is like multiplying by anything other than 1. In
other words, BlackHat can’t make a digest, sign it with his private key, and ex-
pect that decrypting with Alice’s public key will produce his digest. With this in
mind, we’re ready to see why BlackHat can’t successfully complete his forgery.
Figures 13-12(a) and (b) compare Bob verifying Alice’s authentic newslet-
ter and rejecting BlackHat’s forgery. In both (a) and (b), Bob receives a plaintext
newsletter and an encrypted newsletter digest. He calculates a newsletter digest
from the plaintext newsletter. Then he decrypts the encrypted newsletter digest
with Alice’s public key.
In Figure 13-12(a), Bob’s calculated digest and the digest he decrypts with
Alice’s public key are equal; Bob accepts the newsletter as genuine. But in Fig-
ure 13-12(b) they are not equal, and Bob rejects the newsletter. In (b) they are
not equal because, as you saw in Figure 13-11(b), signing (encrypting with
BlackHat’s private key) and verifying (decrypting with Alice’s public key) is like

Figure 13-11 (a) Encrypting and decrypting with Alice’s private/public key pair is like
multiplying by 1, but (6) encrypting with BlackHat’s private key and decrypting with
Alice’s public key is like multiplying by anything except 1.
136 CHapteR 13. © HASHES: NoN-KEYED MESSAGE DIGESTS

BlackHat
(b)

Figure 13-12 Bob decrypts a digest using Alice’s public key. (a) Bob retrieves exactly
what Alice signed; (6) Bob retrieves something different from what BlackHat signed
because BlackHat’s private key is not paired with Alice’s public key.

multiplying by anything but 1. Because BlackHat doesn’t have Alice’s private

key, he can’t make a signed (encrypted) newsletter digest that correctly verifies
(decrypts) with Alice’s public key.

Replay Attacks
BlackHat could fool Bob by sending a copy of an old Alice newsletter and di-
gest. For example, suppose that BlackHat recorded Alice’s November 2000
newsletter. In February 2001 he intercepts Alice’s newsletter and substitutes the
one from November. This is called a replay attack. To defeat this attack, Alice
can timestamp her newsletters.
 SUPPLEMENT: UNSUCCESSFULLY IMITATING A MESSAGE DIGEST 137

Supplement: Unsuccessfully Imitating a

Message Digest
Although the following attack won’t work, it’s instructive to examine because
digests are designed to protect against this attack.’
Because BlackHat can’t easily attack Alice’s signed message digest, he con-
templates the attack shown in Figure 13-13. In the left portion of the figure,
BlackHat makes a newsletter that digests to the same value as Alice’s newslet-
ter. Again, Alice’s genuine newsletter is white and BlackHat’s is gray. In the right
top portion of the figure, BlackHat removes Alice’s newsletter—but not Alice’s
signed message digest—and substitutes his forgery. Bob decrypts Alice’s signed
digest, independently calculates a hash from BlackHat’s forged newsletter, and
accepts it as authentically Alice’s. BlackHat was successful because his fraudu-
lent newsletter and Alice’s newsletter made equivalent message digests.
BlackHat’s full attack is shown in Figure 13-14. As before, Alice makes a
newsletter and a signed newsletter digest. BlackHat intercepts Alice’s newslet-
ter and substitutes his own newsletter; note that he does not substitute a new
signed newsletter digest.

~~~ Alice’s
public key

Figure 13-13 BlackHat makes a newsletter digest equivalent to Alice’s newsletter

digest.

3. This is an optional section. You need not read or understand this section in order to
understand the rest of the book.
138 CHAPTER 13 e HAsHes: Non-KEYED MESSAGE DIGESTS

BlackHat substitutes his

forged newsletter—bout
leaves Alice’s signed
message digest as is.

Alice signs

Bob is duped. He verified that

the newsletter hasn’t been ~
altered since it left the creator.

Figure 13-14 BlackHat forges a newsletter. Because BlackHat’s newsletter digest is

exactly equivalent to Alice’s newsietter digest, Bob mistakenly accepts BlackHat’s
forgery.

Message digest As before, Bob receives BlackHat’s forged newsletter and Alice’s signed
assurances prevent newsletter digest. He independently calculates a newsletter digest except that
this attack. now he doesn’t know that the newsletter is BlackHat’s forgery. As before, Bob
decrypts Alice’s signed message digest. He compares the two digests and accepts
BlackHat’s forgery. The shaded ovals show that BlackHat tricked Bob (and
Alice) by defeating the uniqueness of Alice’s message digest program; he was
able to make a newsletter whose digest was equal to Alice’s newsletter digest.
Unfortunately, Bob has no way to detect this forgery, and he accepts BlackHat’s
newsletter as Alice’s genuine newsletter.
Fortunately, cryptographic message digest methods ensure that BlackHat
can’t make an equivalent digest. That’s the subject of Chapter 14.

Review
Because public key encryption and decryption are slow, cryptographers invented
a condensed representation of a message, called a message digest or crypto-
graphic hash. Message digests are used as short proxies for usually much larger
messages and are designed to detect intentional modification to a message.
 Review 139

By signing the newsletter digest, Alice attaches her identity to the digest just
as if she had signed her newsletter. She signs the message digest because it’s
more efficient than signing the underlying message.
Alice sends and Bob verifies using the following basic procedure.

Alice makes a message digest from a plaintext message.

wo
= Alice signs the message digest and sends the signed digest and plaintext
message to Bob.
3. Bob independently re-creates the message digest from the plaintext.
= Bob decrypts the signed message digest with Alice’s public key.
5. Bob verifies that the message is authentic if the message digest he created
is identical to the decrypted message digest he received from Alice.
 Chapter 14

MESSAGE DIGEST
ASSURANCES

hapter 13 ended with BlackHat trying to forge a newsletter whose message

digest exactly equaled Alice’s newsletter digest. This chapter shows how
cryptographers stop that kind of attack (see Figure 14-1) and others by using
message digest security features. You’ll see how message digest design stops
BlackHat from making undetectable modifications to Alice and Bob’s messages.

Alice’s
News
Buy
| AWL.com {|

Figure 14-1 BlackHat can’t find a newsletter that makes the same message digest as
Alice’s newsletter. This means that he can’t fool Bob into accepting his forged
newsletter.

Two Message Digest Flavors

Message digests come in two flavors—keyed and non-keyed—as shown in Fig-
ure 14-2.

141
142 CHarTeR 14 e MessaGeE Dicest ASSURANCES

Definition: Non-keyed message digests are made without a secret key and are called
modification message integrity codes (MICs) or modification detection codes (MDCs). MIC is
detection codes more commonly used, but MDC seems to be a more straightforward descrip-
tion of how a non-keyed message digest works. Most public key digital signa-
tures use non-keyed message digests.
Keyed! message digests, known as message authentication codes (MACs), com-
Definition: message
authentication bine a message and a secret key. MACs require the sender and receiver to share
codes a secret key. This chapter reviews and extends the discussion of MACs presented
in Chapter 7, where you saw the shared secret key used in conjunction with a
secret key encryption method, such as DES or Rijndael (the new AES standard).
Note that although the term hash function is usually reserved for non-keyed
message digests, it is sometimes used to refer to both keyed and non-keyed di-
gest functions.

Message Digest (Hash, Digital Fingerprint) |

Message Integrity Codes (MIC) |

aka Modification Detection |
Message Authentication Codes |
Codes (MDC) (MAC)

Non-keyed
Keyed
(Message + Secret Key)
(Message alone) |

ar
Sw”
e
Non-keyed Keyed
Hash or Message Digest Message Digest (MAC)
(MIC or MDC)

Figure 14-2 Two types of message digests, keyed and non-keyed.

1. “Keyed” does not mean that the message digest is signed (private key encrypted).
Instead, it means that the digest is made with a secret key.
 Non-KEvED MessAGE Digest ASSURANCES 143

Non-keyed Message Digest Assurances

Non-keyed Non-keyed message digests implement three security assurances—one-wayness,
message digest weak collision resistance, and strong collision resistance—to stop BlackHat from
assurances: one- making message digest forgeries. We’ll describe and show some examples of
wayness, weak each of these security assurances.
collision, strong
collision
One-wayness
One-wayness ensures that you can’t recover the newsletter from a digest. The
digest process is irreversible. If you are trying to find the person who made a
particular fingerprint without matching the fingerprint against a comprehen-
sive databank of fingerprints and their owners, it’s not likely that you'll succeed.
Similarly, after Alice hashes her newsletter, it’s computationally infeasible to
reverse the process; that is, given the newsletter digest, you can’t find a news-
letter that made it, as shown in Figure 14-3.
Because one-wayness ensures that the original message is not recoverable,
a message digest doesn’t have to be sent (or stored) as a confidential message.

Collision Resistance
Message digest collision resistance has much in common with airline seating.
We'll use the airline seating analogy to describe both weak and strong collision
resistance.

Figure 14-3. One-wayness: message digest computations are irreversible.

144 CHAPTER 14 © MessAGE Dicest ASSURANCES

There’s Bob. | wonder

who’s with him. I'll surprise
him later in this chapter.

Figure 14-4 The Cryptographic Airlines seat reservation program is collision-resistant.

Each passenger is assigned a particular seat; no two passengers are ever assigned the
same seat.

Suppose that Cryptographic Airlines (CryptoAir) has a seat reservation

program that assures passengers and CryptoAir’s gate personnel that each pas-
senger is assigned a particular seat and that no two passengers are ever assigned
the same seat (see Figure 14-4). CryptoAir’s seating program is collision-
resistant.’

Weak Collision Resistance

Weak collision Let’s say Alice reserves seat 3A on a CryptoAir flight (shown in Figure 14-5).
resistance prevents Weak collision resistance assures her that BlackHat can’t convince CryptoAir to
BlackHat from assign seat 3A to any other passenger. Similarly, weak collision-resistant hash
perpetrating the functions assure Alice that BlackHat can’t find another newsletter whose digest
fraud shown at the is exactly equal to Alice’s newsletter digest.
end of Chapter 13. Weak collision resistance stops BlackHat from successfully convincing Bob
to accept his fraudulent newsletter. When Bob independently calculates a news-
letter digest from BlackHat’s newsletter, it does not equal the decrypted news-
letter digest Alice made and sent (see Figure 14-6).

2. Of course, CryptoAir’s pilots are also, hopefully, collision-resistant!

 Non-keveD MESSAGE Dicest ASSURANCES 145

What a relief! Even though many Sy

people have tickets | know no
one has been assigned my seat. a
pes y

aiaAK
Figure 14-5 Alice is assured that no other passenger is assigned her seat, 3A.

BlackHat can forge

my newsletter but
not my newsletter
digest.

Figure 14-6 Weak collision resistance assures Alice and Bob that BlackHat’s forged
newsletter will not hash into one identical to Alice’s newsletter digest.

Examples of One-way and Weak

Collision Resistance
Following are two problems solved by one-wayness and weak collision resis-
tance: detecting modifications and sharing data without revealing contents.
146 CHaArTER 14 e MessAGe Dicest ASSURANCES

Detecting Modifications
Using one-wayness Suppose Alice wants to know whether any file on her computer is modified
and weak collision while she’s gone. She can’t trust file dates becanse they’re too easily modified.
resistance to detect A poor solution is for Alice to copy all the files to a backup device and carry
modified files it with her everywhere. Not only is this approach inconvenient, but also if the
backup copy is lost or stolen, her files are at risk.
A better solution is for Alice to make a message digest and write the 160-
bit output (about 20 characters) on a piece of paper. When she returns, she re-
runs the digest program and checks the new message digest output against the
message digest she took with her. If they’re equivalent, she’s guaranteed that not
even one bit, of any file, was modified while she was gone.
One-wayness and weak collision resistance help Alice protect her data.
One-wayness ensures that the message digest does not give any clue as to the
contents of the files because it’s impossible to get back to the original documents
after they have been hashed (digested). Weak collision resistance ensures that
BlackHat can’t modify any file in such a way that the modified file will result in
an equivalent message digest.
Cryptographers have other, even more cryptic names for these two hash
assurances. They refer to one-wayness as first pre-image resistance and to weak
collision resistance as second pre-image resistance.

Sharing Data Without Revealing Contents

When Alice and Bob were married, Alice asked for a prenuptial agreement (she
had made a bundle in her dot-com brokerage firm). Now she wants an attorney
to hold and be able to verify the agreement, but she doesn’t want the attorney
to know what’s in it unless she and Bob divorce.
Using one-wayness To implement her plan, Alice hashes the prenuptial agreement and sends
to share a secret a copy to their attorney. The hashed prenuptial is a proxy for the plaintext
without revealing prenuptial, but the attorney has no feasible way of knowing what is in the
its contents plaintext prenuptial. If Alice and Bob call it quits and someone disputes the
contents of the prenuptial, Alice can send the attorney a copy of the plaintext
prenuptial (along with a substantial retainer). The attorney hashes the plaintext
and compares it to the message digest Alice sent him originally. If they’ re
equivalent, it means that the plaintext prenuptial has not been modified since
the message digest was made.
Weak collision One-wayness prevents the attorney, or anyone else, from recovering the
resistance prevents prenuptial from the digest. Weak collision resistance, in turn, prevents Bob from
Bob from making a creating a forged prenuptial that hashes into a digest equivalent to the one held
forgery by the attorney. If Bob could find another prenuptial that would hash into an
equivalent digest, the attorney would have no way of knowing which prenup-
tial was the original and which was the forgery.
 Non-KEYED MESSAGE Digest ASSURANCES 147

In most instances one-wayness and weak collision resistance offer enough

cryptographic assurances to prevent forgeries. Nevertheless, sometimes weak
collision resistance doesn’t have sufficiently formidable barriers. In those cases,
strong collision resistance is needed. Let’s see how it works.

Strong Collision Resistance

Cryptographic Airlines’ gate personnel want assurance that no two passengers
are assigned the same seat (see Figure 14-7). Similarly, no two messages can be
found that make equivalent digests.
Definition: strong Whereas Alice is concerned only about herself and seat 3A (her reserved
collision resistance seat)—something that is ensured by weak collision resistance—CryptoAir’s gate
personnel are concerned with every passenger and every seat.’ For that, they
need strong collision resistance, or the assurance that no two passengers are ever
assigned the same seat. The difference is a subtle but important one. Weak
collision resistance stops forgery of a particular message; strong collision resistance
stops forgery of any message.
Let’s illustrate the difference between weak and strong collision resistance
by taking a second look at Alice and Bob’s prenuptial agreement.
Although weak collision resistance stops Bob from forging a prenuptial that
hashes to the prenuptial Alice created, it doesn’t stop Alice from creating such
a forgery. How can this be? Suppose that Alice and Bob call it quits, and Alice
decides to cut him off from as much money as possible. Bob claims that the
prenuptial agreement contained sentences entitling him to 50 percent of all the

Figure 14-7 Strong collision resistance assures each and every passenger that his or
her seat won’t be given to another passenger.

3. CryptoAir never overbooks its flights and is, of course, an imaginary airline.
148 Cuarter 14 e MessaGe Dicest ASSURANCES

money earned during the marriage; the agreement is shown on the left side of
Figure 14-8. Bob sighs with relief when the prenuptial hashes to the value given
to Alice’s attorney many years ago. But then Alice produces another prenuptial,
and it contains the sentence shown on the right side of Figure 14-8. To Bob’s
amazement, it also hashes to the same value. How did Alice defeat weak colli-
sion resistance?
Recall that weak collision resistance stops Bob or Alice (or anyone) from
making another prenuptial that hashes to an equivalent digest to the one shown
on the left side of Figure 14-8, the digest Alice and Bob sent their attorney. But
because Alice created the origirial prenuptial, she gave herself a much easier task.
Here’s what she did. When Alice created the prenuptial agreement, she made
many prenuptials, each of which effectively states, “Bob gets one-half,” shown
on the left side of Figure 14-9. She then created many prenuptials that cut Bob
off, shown on the right side of Figure 14-9. She had only to matchaa one
agreement from the left side to ay one from the right side.
Bob must match the particular prenuptial Alice gave him. Because Alice can
create many prenuptials before she selects a particular prenuptial to give to Bob,
she can match any one of them.
Birthday attack The scenario just described is often called a birthday attack because it uses
the analogy of finding equal birthdays. Suppose that Bob’s birthday is February
1. If Bob wants to find another person who shares his birthday, he’ll have to ask
about 180 people before he likely finds someone whose birthday is also February
1. But Alice’s task is much easier; she need only find any two people who have
the same birthday. Let’s say the first three people she asks have the birthdays
February 1, June 2, and September 3, respectively. If the fourth person she asks
shares any one of those birthdays, Alice’s search is finished. If the fourth person’s
birthday is December 10, the fifth person Alice asks need only share any of the
previous four birthdays. Alice’s task takes much less effort (and time) than Bob’s
task.

rs oh a A .. Bob won't
pa one-nalroral | AA} pj get any money |
_/ | money earned | \_ ¢ é earned during |
| during our
| Our marriage... }
| marriage...

Figure 14-8 Bob and Alice have different prenuptials that hash to the same digest.
Alice gave Bob their prenuptial when they were married. How did she find another
prenuptial that hashed to the same digest as the one she gave Bob?
 Non-KEYED MESSAGE Dicest ASSURANCES 149

...Bob will get ...Bob will get

50% of all 0.005% of all
money earned money earned
during our during our
marriage... marriage...

Alice claims =
they agreed
...Bob will get to this one. ...Bob won't
1/2 of all
get any money |.
| money earned
earned during | >
| during our
our marriage...
marriage...

...Bob will get Digests ...Bob will get

one-half of all match ZERO of all
| money earned | money earned
during our |_| during our
| | marriage... [4 Marriage...
ae - |& Bob agrees TN
to this
...Bob will get Peep uaual, Bob will get
ps fifty percent of | _ | 0 of all money
_f | all money nee | earned during
[ | earned during / | our marriage... |}
:
our marriage..p j J
i

Figure 14-9 Alice makes many potential prenuptials. By the way, note that the last
two messages in the right-hand column make different message digests; ZERO digests
to a different value than 0 does.

Fortunately, cryptographers have compensated for this possibility, making

message digests about a trillion trillion times larger (2*° ). In other words, al-
though Alice has a much easier forgery task than Bob, her task is still so time-
consuming that it’s infeasible.
If you're given a Although strong collision resistance prevents these kinds of attacks, there
document, make a is an important lesson to be learned. Before Bob signs the prenuptial he should
small change make a small and inconsequential change to the agreement Alice gave him. The
before signing It. small change ensures that none of Alice’s potential forgeries, shown in the right-
150 CHarPter 14 e MessAGeE Dicest ASSURANCES

...Bob will get one-half } ...Bob will get one -half

of all money earned of all money earned
during our marriage... during our marriage...

Figure 14-10 Bob adds a blank space after the word one and eliminates Alice’s
ability to use coincidental collisions such as those shown in Figure 14-9.

hand column of Figure 14-9, will hash to the identical digest that Bob signed.
As shown in Figure 14-10, even adding a space after the word one will change
the message digest enough so that it’s unlikely to match any forgery Alice might
make.

Non-keyed Digest Implementations

The two most popular non-keyed message digest programs are Message
Digest 5 (MDS) and Secure Hash Algorithm-1 (SHA-1). Ron Rivest, the R in
RSA, invented MD2 soon after he worked on RSA. MDS is the latest version.
NIST (the National Institute of Standards and Technology) and NSA enhanced
MD4, MD5S’s predecessor, to produce SHA-1.
MD5 (128 bits) is MDS makes a 128-bit digest; this means that a birthday attack (an attack
more susceptible against MD$’s strong collision resistance) can be mounted using 64 bits (128/
to birthday attacks 2), and that’s now.considered too vulnerable; MD5 collisions have been found
than SHA-1 (160 for particular kinds of messages. (Recall that DES is considered vulnerable be-
bits). cause it uses a 56-bit secret key.) Let’s see why SHA-1 and other message digest
programs are more secure against birthday attacks.
SHA-1 (160 bits): SHA-1, often abbreviated to SHA, makes a 160-bit digest; this means that
the popular current a birthday attack can be mounted using 80 bits (160/2). Mounting an 80-bit
choice birthday attack requires about 65,000 times more effort than mounting a 64-bit
attack.* This means that a successful one-hour attack against MD5 would need
many years (65,000 hours) to be successful against SHA-1. So far, SHA-1 has
been immune to cryptanalytic attacks successfully mounted against MDS.
Although not as widely known as MD5 and SHA-1, RIPEMD-160 is an-
other secure 160-bit non-keyed digest. In fact, Hans Dobbertin, the cryptanalyst
who successfully attacked MDS, was also a cryptographer on the team that de-
veloped RIPEMD-160. Like MD5 and SHA-1, it’s also based in large part on
MD4.

Ge /2 = 2 = 65,536.
 Keyep MessAGE Dicest ASSURANCES 151

Keyed Message Digest Assurances

Whereas an MDC depends on one-wayness and collision resistance to ensure
security, message authentication codes (MACs), the other type of message di-
gest, bases its security on using secret keys.
MAC has two parts: Let’s review and expand the example of MAC shown in Chapter 7. No
message and secret matter what type of MAC you use, they all have two parts: a message (or file)
key. and a secret key. A MAC combines and then compresses a message (e.g.,
Internet Browser) anda shared secret key (see Figure 14-11). Many, if not
most, MACs are made with secret key block ciphers, such as DES. As with
MDCs, the MAC file acts as a proxy for a much larger file. In our example, Bob
verifies the authenticity of the sender (Alice) and the message (Internet
Browser) by comparing the MAC Alice sent him against the MAC he inde-
pendently produces.
The secret key cipher (e.g., DES) and shared secret key make BlackHat’s
forgery attempts computationally infeasible. This means that MAC security is
closely tied to the security of the underlying secret key cipher and secret key.

A MAC Made with DES

The Data Authentication Algorithm (DAA) is made using DES and a compres-
sion method. It’s also the subject of the Federal Information Processing Stan-
dards (FIPS-113) publication “Computer Data Authentication,” which was
published in 1985 by NIST.

‘Compressed
50
MegaBytes
8 Bytes MAC
i (= 64 bits)

Figure 14-11 (a) A MAC is a digital fingerprint of a message and a secret key. (b)
Using their shared secret key, Bob independently creates the identical MAC of the
message sent by Alice.
152 CHAPTER 14 e Messace Dicest ASSURANCES

Spring 2000: Because DES keys (56 bits) are believed to be increasingly susceptible to
American Bankers brute force cryptanalysis, DES-MACs are similarly susceptible. Although (as of
Association spring 2000) NIST hasn’t withdrawn DES-MACs as a U.S. federal processing
removes standard, a prominent banking standards committee (American Bankers Asso-
DES-MACs from ciation) removed DES-MACs from the recommended list, advising readers,
recommended list “Continue to use single DES-based X9.9 [MACs] until a replacement is imple-
mented . . . [with] actions that can be taken to reduce the risks.” Its recom-
mended actions include using triple-DES-like MACs, public key cryptographic
methods, and modification detection codes (MDC), discussed earlier in this
chapter.
A widely used MAC will most likely evolve from Rijndael, the new Ad-
vanced Encryption Standard. The following explanations use DES-MACs be-
cause the new MAC will probably behave like a DES-MAC.

DES-MAC Security
The two possible brute force attacks against MACs attack either the secret key
or the MAC itself.
Definition: selective Because the DES and DAA methods are known, ifthe secret key isn’t se-
MAC forgeries cret, anything done with DES/DAA is insecure. If BlackHat sniffs the line and
gets a valid plaintext/MAC pair, he tries all the possible keys, as shown in Fig-
ure 14-12. At least one key must make the correct transformation.’ After
BlackHat gets the secret key, he can manufacture a MAC for any selected
plaintext, a potentially damaging forgery often referred to as a selective forgery.

Figure 14-12 BlackHat figures out the secret key used to make the MAC.

5. Although it’s not important to our discussion, it’s possible that more than one key can
make the matching MAC; in that case, BlackHat needs more plaintext/MAC pairs to
determine the correct key.
 Kevyep MessAGE Dicest ASSURANCES 153

Definition: Even without knowing the secret key, BlackHat is also successful if he can
existential MAC forge any valid plaintext/MAC pair. In this case, referred to as an existential forg-
forgery ery, BlackHat can’t choose a particular plaintext message. Instead, he’s simply
trying to find a pair that will verify when properly digested with the valid secret
key.
For example, in Figure 14-13 BlackHat tries different plaintexts until one
of his plaintext digests matches the digest being attacked. Existential forgeries
need online verification, but that’s not out of the question with automated re-
sponse systems. Because BlackHat must try many different variations of
plaintext, this attack is usually less damaging than a selective forgery. But even
Example: A existential forgeries can be damaging.
damaging Suppose BlackHat has earned a $10 rebate and knows that the vendor is
existential forgery sending the rebate via an electronic check and associated MAC to his bank. He
sees this as a perfect opportunity to increase the amount of the check. Although
BlackHat lacks the secret key and thus can’t control the exact amount of his
forgery, he can try all numbers between | billion and 9 billion (8,000,000,000
numbers). If the MAC is only 32 bits long, he’s guaranteed a match after about
4 billion® tries.
The lesson is this: It’s probably advisable to use much bigger MACs, no less
than 128 bits’ and arguably no less than 160 bits.

i
a S S

a
Lo)
Sn call

Figure 14-13 BlackHat finds another message that makes the same MAC as the white
message; the other messages don’t make an identical MAC as the white message.

6. 32 bits can hold only about 4 billion (4,000,000,000) different combinations.

7. 128 bits can hold about 4 billion x 4 billion x 4 billion x 4 billion different
combinations.
154 CHapteR 14 © MessAGe Dicest ASSURANCES

Message Digest Compression

As mentioned in previous chapters, cryptographic compression is similar to that
of popular compression programs such as PKZip, WinZip, and Stufflt, with the
difference that cryptographic compression is one-way. Plaintext cannot be re-
covered after it is cryptographically compressed. MDCs and MACs compress
files in about the same way except that MACs add the secret key to the cauldron.
Figure 14-14 shows how one particular MAC (DAA) compresses a message
(or file) of any length (smaller than about one million trillion characters) to 64
bits.’ The message is broken into 64-bit (8-byte) chunks. The first two 64-bit
chunks are compressed together, and then DES encryption is applied to the new
64-bit chunk. The new chunk is then combined with the third 64-bit chunk,
DES encryption is applied to it, and so on. So whereas a DES plaintext encryp-
tion produces ciphertext about the same size as the original pen a MAC
is much smaller than the plaintext file.

/
INVES os
Newsletter |
Buy@ | i
> >
See

SP
oarrere roreamnsnrecnintcoiaeisinstmtenntanints
messinteheeeesnreaEEER IARHNER ORIN>| 64bits|

LEGEND

Plaintext
DES
Be
O—m Encryption
[ea bits/ Digested
text

Figure 14-14 Making a MAC from Alice’s newsletter. (1) Two 64-bit chunks are com-
bined to make a new 64-bit chunk. DES encryption is applied to the new chunk. (2)
The output of step 1 is combined with the third 64-bit chunk. DES encryption is ap-
plied to the new chunk. (3) The output of step 2 is combined with the fourth 64-bit
chunk. DES encryption is applied to the new chunk. The process repeats until the last
64-bit chunk is combined and DES encryption is applied. The last chunk is the MAC.

8. Although it is not important for our simple overview, if the input file is less than 64
bits or if the file is not evenly divisible by 64, bits are added to the end of the last
chunk.
 HAsHEeD MAC 155

Digest Speed Comparisons

Table 14-1 shows some throughput comparisons of software implementations.
For a speed yardstick, DES is listed first. Hashed MAC (HMAC), the topic
of the next section, is a new kind of digest method that combines keyed and non-
keyed message digests.

Table 14-1 Comparing the throughput of message digest functions. (HMAC is dis-
cussed in the next section.) Source: www.eskimo.com/~weidai.

Method Megabytes / Sec

DES 7
MD5 Di,
SHA-1 2S)
RIPE-160 24
DMAC-RC6 18
HMAC/MD5 56

House of Cards
Here’s an interesting rub: Although modern cryptography is dependent
on one-way functions (OWFs), there’s no proof that one-way functions
actually exist’—in other words, that there aren’t trapdoors. It’s possible
that all of modern cryptography may be a house of cards! But don’t
relive your Y2K fears; there are OWFs that are provably as secure as
other “hard” math problems. The insecurity comes from the fact that just
because mathematicians believe that some problems are hard (and
time-consuming) isn’t proof that they really are.

Hashed MAC
As shown in Table 14-1, MACs execute much more slowly than non-keyed di-
gest functions such as SHA-lor MDS. So in the mid-1990s, cryptographers
proposed a few different ways to combine MACs with non-keyed digest
functions to speed up processing.

9, Without making some additional assumptions.

156 CHapTER 14 e MessAGE Dicest ASSURANCES

In a 1996 paper, “Keying Hash Functions for Message Authentication,”

cryptographers Hugo Krawczyk, Mihir Bellare, and Phil Rogaway proposed
two ways to combine MAC and non-keyed hash functions. One of those meth-
ods, HMAC, has become the de facto standard.
HMACs use a secret key and a non-keyed hash function. As of this writing,
most HMACs use SHA-1 or MDS. HMACs are as secure as MACs. As substan-
tiation for that claim, current real-world systems such as SSL (Chapter 20) and
IPsec (Chapter 21) have standardized on HMAC.
An additional attractive feature of HMAC is that it’s designed to easily in-
stall and use various non-keyed hash functions. This means that if SHA-1 or
MDS or both are successfully cryptanalyzed, HMAC can be easily retooled to
use other, more secure non-keyed hash functions. HMAC has been likened to
putting together a home entertainment center; if a particular component fails
or becomes obsolete, you simply replace that component.

Review
There are two types of message digests. Keyed, or message authentication codes
(MACs), depend on secret keys for security. Non-keyed codes are known by two
names: message integrity codes (MICs) and modification detection codes
(MDCs). Another name for MIC or MDC is cryptographic checksum.
The security of MICs and MDCs depends on three assurances: one-
wayness, weak collision resistance, and strong collision resistance.
The need for processing speed prompted the invention of another message
digest function. HMAC, the new kid on the block, combines a MAC (secret key)
and an MDC (hash function) to make a secure and more rapid message digest.
 Chapter
15

COMPARING SEcRET Key,

Pustic Key, AND
MessAGE DIGESTS

Ssome cryptographers believe that secret key, public key, and message digest
systems are so different that comparisons are irrelevant. However, we think
you'll find this review useful. In this chapter we compare and contrast secret and
public key encryption in terms of speed, key length, and cryptographic assur-
ances so that you can readily understand why they are used together in the real-
world systems discussed in Part IV.
Various public key cryptographic systems offer various mixes of crypto-
graphic assurances and operation speeds. Because RSA is the most widely used
approach and offers every cryptographic assurance, in this chapter we often use
RSA as a proxy for public key cryptography.’
Although DES is all but obsolete, encrypting with DES three times (Triple
DES) is the de facto standard until Rijndael, the new standard, becomes widely
used. Interestingly, both DES and RSA were released at about the same time in
the late 1970s. Secret key systems have been studied and used for thousands of
years; public key cryptography is less than 50 years old. Nevertheless, both types
can be attacked. Although public key can be attacked in ways that secret key
cannot (see Chapter 22), neither is more immune to attack than the other.
Public key cryptography (e.g., RSA) can do anything that secret key cryp-
tography (e.g., DES) can do and more. So why does anyone use secret key
cryptographyr

Encryption Speed
Encryption speed: Speed is the biggest difference between the two types. DES is at least 100 times
secret key is faster faster than RSA; a 30-second DES encryption takes RSA more than 50 minutes.
In some cases, DES is as much as 1,000 times faster than RSA.

1. This is not meant to endorse RSA or DES.

157
158 Cuapter 15 © ComparING Secret Key, Pusiic Key, AND MESSAGE DiGEsTs

Although Triple DES (DES encryption done three times) is obviously

slower than DES, all of NIST"s candidates for AES are faster than (single) DES.
For example, RC6, a NIST AES finalist, is about three times faster than DES
in some software implementations.
In general, message digests complete a little faster than do secret key meth-
ods, but message digests don’t offer confidentiality.
Pulolic key As you'll see in Part IV, real-world systems such as secure e-mail, Secure
cryptography |s Socket Layer, and IPsec encrypt (and decrypt) much more with secret key cryp-
used only tography. Public key cryptography is used only sparingly, mostly for authenti-
sparingly. cation and exchanging (or agreeing on) a secret key.

Key Length
Secret keys are A few years ago, DES (with a 56-bit key) and RSA implemented with a 512-bit
much smaller than key were considered adequate for secure encryption. This means that an RSA
public keys. key was about 10 times the size of aDES key.
As you’ve seen, 56-bit encryption is so insecure that NIST required all AES
candidates to support at least 128-bit key length. Similarly, RSA users have also
been forced to double their key size to at least 1,024 bits, and many users de-
mand an even bigger key. This means that the minimum advisable secret key
length (128) is still about one-tenth the length of the advisable RSA key (1,024).
A new wrinkle: RSA keys are getting so big that many public key implementations have
elliptic curve been forced to use a new public key technology called elliptic curve cryptogra-
cryptography phy (ECC), described in Appendix A. Because ECC uses much smaller keys
than RSA, Motorola, for example, uses ECC in its cellular phones.

Ease of Key Distribution

Key distribution: As you saw in Chapter 7, secret key distribution is a tough problem. Each sender
public key is better and receiver must share a secret key. Managing secret key networks is feasible
only for a small network of users and is all but impossible for a network of 1,000
or more users. Secret key cryptography by itself is not an option for a network
of millions of users, so it can’t support Internet e-commerce. Public key was
invented mostly to solve the problem of secret key distribution.
Public keys don’t The security of a public key cryptographic system relies on each person
need to be secret. knowing his or her private key, undisclosed to anyone and not shared with any-
one. A public key, by contrast, can be freely distributed to more than one per-
son. A public key can be put on a business card, published on an Internet site,
or e-mailed as plaintext.
 CryPTOGRAPHIC ASSURANCES 159

But public keys Because the public key doesn’t have to be a secret between Alice and Bob,
must be protected. public keys are easier to distribute than secret keys are. But as you’ll see in
Chapter 22, if BlackHat can trick Bob into thinking that BlackHat’s public key
is really Alice’s public key, BlackHat can read all of Bob’s confidential messages
to Alice. Digital certificates help prevent BlackHat from perpetrating this fraud
(see Chapters 16 through 19). Even with its distribution problems, for ease of
key distribution, public key is better than secret key.

Cryptographic Assurances
As shown in Table 15-1, both methods offer confidentiality, user authentication,
and message integrity. Public key also offers nonrepudiation; secret key, with-
out a trusted third party, doesn’t offer this assurance.

Symmetric (Secret) Key

Review: symmetric Recall that secret key cryptography is often referred to as symmetric cryptog-
cryptography i. raphy because the same key encrypts and decrypts (see Figure 15-1). Usually
there are only two holders of a particular secret key. Both holders share their
secret key equally; they are equal partners, and neither can do more or less with
the secret key than the other. Secret key cryptography implements confidenti-
ality, authentication, and integrity symmetrically for both holders of the secret
key; either holder can demand (and offer) confidentiality, authentication, and
message integrity from (to) the other.

Asymmetric (Public) Key

Review: asymmetric In contrast, public key is called asymmetric cryptography. There is one and only
cryptography one private key holder and usually many public key holders. The public and
private key holders are not equal partners. Consequently, the cryptographic
assurances—confidentiality, authentication, integrity, and nonrepudiation—are
asymmetrically shared among private and public key holders (see Figure 15-2).

Table 15-1 Cryptographic assurances.

Assurance Prevents Secret Key Public Key

Confidentiality Snooping x
Authentication Masquerading z
Integrity Message alteration without detection x x
Nonrepudiation Sender’s false denial .
160 CHapteR 15 © CompaRriNG Secret Key, Pustic Key, AND MESSAGE DIGESTS

_ With my copy of our shared With my copy of our shared }

secret key | can: secret key | can (also):
e send you confidential e send you confidential
messages. messages.
© prove to you who | am. ¢ prove to you who | am.
© prove my message was © prove my message was
not altered in transit. not altered in transit.

Figure 15-1 In symmetric (secret key) cryptography the holders look symmetric and
have identical attributes.

Because | have the only copy } Any one of us with Alice’s

of my private key | can: public key can:
© prove who | am. e send Alice confidential
® prove my message was messages.
not altered in transit. e verify Alice’s identity.
e send you messages that | ° validate signed messages _
can't later deny sending.
But | cannot send a
_ confidential message with
Ny private key

Figure 15-2 In asymmetric (public key) cryptography the holders look different and
have different attributes.
 REVIEW 161

Only the public key holders (Bob) can send confidential messages to the private
key holder (Alice). In contrast, if Alice encrypts a message with her private key,
it’s decipherable by Bob or anyone with the public key, so it’s not confidential.
But Alice’s signed (private key encrypted) messages prove her authenticity (iden-
tity) and prove that her messages were not altered in transit (integrity). In ad-
dition, she can’t later deny sending the message (nonrepudiation).

Review
Table 15-2 summarizes similarities and differences in various aspects of secret
key and public key cryptography.

Table 15-2 Summary of secret and public key attributes.

Attribute Secret Key Public/Private Key

Years in use * ‘Thousands Less than 50

Current main use Bulk data encryption Key exchange, digital signatures
Current standard DES, Triple DES, and Rijndael RSA, Diffie-Hellman, DSA (Elliptic
curve is a challenging newcomer)
Encryption / decryption
speed Fast Slow

Keys Shared secret between at least Private: kept concealed by one person
two people (usually only two) Public: widely distributed
Key exchange Difficult and risky to transfer Easy and less risky to deliver a
a secret key public key
Private key never shared
Key length 56-bit obsolete 1,024 suggested (RSA)
128 -bit considered safe Some users demand 2,048
~172 (elliptic curve)

Confidentiality,
authentication,
message integrity Yes Yes

Nonrepudiation No Yes
Need trusted third party to act Digital signatures: don’t need trusted
as witness third party

Attacks Yes Yes

 ernie
nV eee gie Denier ie
Qyerunm bekp_poan

reasdiet es ane ba lp
papaglalyey ts ee

—— :
OO . onal 9 a
tellinerlane, |SlibeT=
Ho etoagan anninignn semen cbiptld Okspj
- ~~. Pala i op pescthohind re

a Siar Ltt dost.

din ee rT

Ca” a, 7 *~ ii pins eatyrelee a 7

(¢Q8 nadia Yeats et i eet

gts barnyaty oxycnehowe

rua eantreetny
Hot. | wal puant wart)
ryle AadmesitouriSlak sae @ Previn
peingatlinste see Pr eae 3 SAG Poke rer
'

4 fui wine \ the

 PART Ill

DISTRIBUTION OF
PUBLIC KEYS
key cryptography changed 3,000 years of key exchange. For thousands
of years, Alice and Bob had to somehow exchange a secret key without any-
one else’s seeing it. Furthermore, the shared secret key had to remain secret for-
ever. Public key cryptography changed all that, allowing Alice (and Bob) to
exchange public keys openly. Public keys don’t need to be secret. In fact, some
Internet companies want as many people as possible to know their public keys.
Even though public But as we’ve seen, even though Alice can openly distribute her public key
keys can be openly to Bob, they need assurances that BlackHat can’t substitute his public key for
distriouted, Alice’s public key. For example, in Figure PIII-1, after BlackHat successfully
recipients need mounts a man-in-the-middle attack (see Chapter 22) between Alice and Casey,
assurances that he can read Casey’s confidential messages to Alice and masquerade as Alice to
they are receiving Casey. As a result, delivery of authentic public keys is still a problem.
the genuine public
Let’s use a real Internet e-commerce example. Amazon.com wants you to
key.
feel secure when you communicate with it. The company sends you its public
key so that you can send it confidential messages (encrypt with its public key).
You also use Amazon’s public key to verify the company’s signed (private key en-

Figure PIll-1 Alice openly distributes her public key to Bob and Casey. But BlackHat
intercepts the key on the way to Casey and substitutes his public key for Alice’s public
key.

163
164 Part Il DisTRIBUTION OF PuBLic Keys

crypted) messages (to make sure they’re really from Amazon and not from one
of its competitors). You must trust that you have Amazon’s authentic public key.
How does Amazon get you its public key? The popular current answer is to use
digital certificates. Digital certificates are used in real-world systems such as
Secure Socket Layer (SSL), secure e-mail (S/MIME and PGP), virtual private
networks (VPNs) and Internet Protocol Security (IPsec), to name a few.
Chapter 16 examines how digital certificates protect public keys and ex-
plains why BlackHat has a much more difficult job corrupting public keys when
they are wrapped in and delivered with digital certificates, as shown in Figure
PIII-2.
After explaining how digital certificates protect public keys, we discuss two
popular standards—X.509 and PGP—in Chapters 17 and 18, respectively.

Figure PIll-2 Alice openly distributes her digital certificate. BlackHat can’t easily sub-
stitute his public key for Alice’s public key.
 Chapter 16

DIGITAL CERTIFICATES

I: Chapter 12, Alice signed (used her private RSA key to encrypt) a newslet-
ter; only her matching RSA public key verifies (decrypts) the newsletter into
meaningful text. Recall that digital signing authenticates the message author and
ensures message integrity, as shown in Figure 16-1.
Digital certificates Digital signing is also used to make digital certificates. The person who cre-
and digital ates a digital certificate proclaims something like this: “I attached H. X. Mel’s
signatures are public key to this digital certificate and then signed (a hash of) it with my pri-
signed (private, key vate key.”
encrypted). We’ll see that any user of H.X. Mel’s digital certificate must completely
trust the competency and honesty of the person who creates H.X. Mel’s certifi-
cate. We’ll also see that for anyone to confidently use H.X. Mel’s digital certifi-
cate, they must also trust they have a validated copy of the certificate creator’s
public key. But before we examine these trust points, let’s first show the two
component parts of every digital certificate.
Digital certificates have two parts: plaintext and the same plaintext hashed
and digitally signed. Figure 16-2 shows a digital certificate created by Alice for
her daughter, Dawn. The plaintext, in the top part of the certificate, openly
states that Alice created the certificate for Dawn and that Dawn’s public key is
attached. The plaintext, hashed and signed (in the bottom part), completes
Alice’s certification of the contents shown at the top.

Figure 16-1 Alice signs her newsletter.

165
166 CHAPTER 16 © =Diaitat CERTIFICATES

Alice
Proclaims

Dawn’s -
public

Alice
Proclaims &.

Dawn’s
public : Authentication
Integrity
= Nonrepudiation

Figure 16-2 Alice makes a digital certificate to hold Dawn’s public key.

Digital certificates Digital certificates can include plaintext because there’s usually nothing
are openly secret about their contents—the digital certificate creator (e.g., Alice),
distriouted and someone’s public key (e.g., Dawn), and so on. Digital certificates must include
include plaintext. plaintext because, as mentioned in Chapter 12, many digital signature methods,
such as DSA, don’t recover plaintext as a byproduct of the verification process.
Plaintext is included so that the recipient of the digital certificate knows who
issued the certificate and whose public key is enclosed. Also, as you’ll soon see
in Chapter 17, because Bob (and other Internet users) collects many digital
certificates, he can look through the plaintext part of a digital certificate before
he decides to spend computer time verifying the authenticity of the certificate
and public key enclosed.
Include signed A digital certificate must include a signed hash because, as explained in the
hash for integrity introduction to Part II, e-mailing a plaintext public key is susceptible to a man-
in-the-middle attack. Including a signed message digest over the plaintext in the
top part allows the recipient to detect tampering.
 ATTACKING DiGiTAL CERTIFICATES 167

Verifying a Digital Certificate

Definitions: issuer, | Figure 16-3 shows Alice issuing a digital certificate for Dawn. Alice is the issuer
subject (the one who signs with her private key); Dawn is the subject (the certificate
contains her public key). Then Alice sends the digital certificate to Bob, who
wants a trusted copy of Dawn’s public key.
Bob verifies a Bob verifies that Alice signed the digital certificate just as he verified Alice’s
digital certificate in | newsletter in Chapter 12. The difference is that now, instead of a newsletter, he
the same way that — gets Dawn’s public key.
he verified the Bob hashes plaintext in the top part and uses his copy of Alice’s public key
newsletter in to verify (decrypt) the bottom part. Because, as shown in Figure 16-3, both parts
Chapter 12 are equal, Bob has verified that Alice created the digital certificate and that it has
not been altered since Alice made it. Just as Alice’s signed newsletter assured her
customers, Alice’s signed digital certificate assures Bob that he has Dawn’s public
key—assuming that Bob trusts Alice and trusts that he has Alice’s public key.

Figure 16-3 Bob verifies a digital certificate. Bob uses his trusted copy of Alice’s pub-
lic key to verify that Alice made the digital certificate. (Shown is RSA verification; DSA
is slightly different.)

Attacking Digital Certificates

Even though digital certificates and their attached public keys are openly dis-
tributed, they can be compromised if handled without proper safeguards. Let’s
see four ways that BlackHat can attack digital certificates.
168 Cuapter 16 e Diaitat CERTIFICATES

Attacking Attacking the Creator of the Digital Certificate

competency
If BlackHat can successfully masquerade as Dawn, he can convince Alice that
his public key is Dawn’s public key. Then Alice will mistakenly put BlackHat’s
public key on the digital certificate she creates for Dawn. BlackHat can then
masquerade as Dawn to Bob or anyone who receives Alice’s mistakenly created
digital certificate. Bob must completely trust Alice’s competency.

HIt’s really
*BlackHat’s
public key.
Malicious Certificate Creator
Attacking reliability Bob completely trusts that Alice will never issue a fraudulent digital certificate.
This means that Bob trusts that Alice would never issue a digital certificate in
Dawn’s name that contains BlackHat’s public key instead of Dawn’s public key.
If Alice did perpetrate this kind of fraud, BlackHat could easily masquer-
ade as Dawn to anyone who trusts Alice.

Attacking the Digital Certificate User

Weak link: Bobo Bob must protect his copy of Alice’s public key. If BlackHat substitutes his public
must get and key for Alice’s public key on Bob’s computer, BlackHat can masquerade as Alice
protect Alice’s and send Bob digital certificates supposedly from Alice. A weak link of public
public key key cryptography is that Bob must have and protect his copy of Alice’s public
key.

The Most Devastating Attack

Unauthorized use If BlackHat somehow gets Alice’s private key, he can forge Alice’s signature on
of private key digital certificates. Anyone retrieving BlackHat’s forged certificates has no way
of knowing that BlackHat perpetrated the fraud. For example, with a copy of
Alice’s private key BlackHat can create and sign a digital certificate, which then
appears to have been made by Alice and appears to contain Dawn’s public key.
In reality, it has been made by BlackHat and contains any public key BlackHat
chooses. Anyone using BlackHat’s forged digital certificate (e.g., Bob) has no
way of knowing otherwise—until Bob is notified that Alice’s private key has been
compromised.
Nevertheless, all the major e-commerce communication programs use digi-
tal certificates as the de facto technology for distributing public keys. Secure
Socket Layer, secure e-mail, virtual private networks, and IPsec all use digital
certificates.
 UNDERSTANDING DiGiTAL CerTiFICATES: A FAMILIAR COMPARISON 169

Understanding Digital Certificates:

A Familiar Comparison
‘Trying to keep track of all these people and their keys can be a little confusing.
Here’s an analogy that may help. A digital certificate is not very different from
another common means of identification: a driver’s license. Refer to Figure 16-4
as we compare a digital certificate to a state-issued driver’s license.

Issuer and Subject

After H. X. Mel satisfies the requirements, Minnesota makes and issues a driver’s
license that contains Mel’s name and picture. Minnesota is the authority that
issues a license for the subject, in this case Mel.
Similarly, with digital certificates, Alice issues (certifies and makes) a digi-
tal certificate that contains Dawn’s name and Dawn’s public key. Alice is the
authority who issues a certificate for the subject, Dawn.

issuer Authentication
Cryptography can The Minnesota Department of Motor Vehicles (DMV) laminates and binds the
prove ID better DMV seal and Mel’s photograph to the license. The DMV seal asserts that the
than pictures can DMV believes Mel’s photograph is accurate; making alterations to Mel’s picture
is difficult.

INNCSOts « Issuer -
Dept of Motor
Vehicles
LICENSE
Subject
H.X. Mel<
\ — Seal of
Issuer
Certifies ~

oe ie
Expires Sept. 1, 2003< Expires ---———

Figure 16-4 A digital certificate is like a driver's license.

170 CHAPTER 16 e =Diaitat CEertiFicATEs

Similarly, Alice signs (private key encrypts) Dawn’s public key in the certifi-
cate. Alice’s digital signature authenticates her assertion that Alice believes
Dawn’s public key to be accurate. Cryptography makes altering the digital cer-
tificate much more difficult than altering Mel’s photograph on his driver’s
license.

Transfer of Trust from the Issuer to the Subject

Mel uses his license photograph, created by the DMV, to prove his identity to
a stranger, the clerk at a 24-hour convenience store. The clerk trusts that she
knows what a real license looks like and trusts that the DMV put Mel’s correct
picture on the license. The clerk must also trust that her eyes can correctly
match Mel’s photograph to Mel’s physical appearance. If the clerk trusts the
DMV and her eyes, she takes Mel’s personal check.
Bob trusts that Similarly, Dawn uses her digital certificate, issued by Alice, to prove her
Alice signed public key to Bob. Bob trusts that Alice put Dawn’s correct public key on the
Dawn’s public key digital certificate. Just as the clerk trusts her eyes to verify a driver’s license, Bob
and that he has must also trust that he has Alice’s correct public key. Alice’s public key is used
Alice’s correct to accept (or reject) the integrity of a digital certificate (and Dawn’s attached
public key public key).
Bob trusts Alice, so he trusts that he has Dawn’s public key. For example,
suppose that Dawn e-mails a signed (private key encrypted) report to Bob.' Bob
trusts that the report originated with Dawn after he verifies (decrypts) it with
Dawn’s public key. How can Bob get Dawn’s public key? Alice e-mails Bob
Dawn’s public key on a digital certificate issued by Alice. How does Bob know
that BlackHat didn’t intercept the e-mail and substitute BlackHat’s public key?
Definition: chaining Bob verifies that the digital certificate and Dawn’s attached public key were
not altered in transit because the digital certificate verifies with his copy of
Alice’s public key. Bob has chained from his trusted copy of Alice’s public key to
a trusted copy of Dawn’s public key. You'll learn more about chaining in Chap-
ters 17 and 18.
Table 16-1 summarizes these analogies. In Chapters 20 and 21 you'll see
how digital certificates are used to prove identity to e-commerce vendors and
Internet correspondents.
Note that digital certificates are verified by software that’s inherently much
more accurate than the matching skills of a human eye.

1. Recall that private key encryption ensures that she authored the report. Private key
encryption does not ensure confidentiality.
 UNDERSTANDING DiaiTAL CERTIFICATES: A FAMILIAR COMPARISON 171

Table 16-1 Trust: Comparing a driver's license picture to a digital certificate.

License: Digital Certificate:

What the Clerk Trusts What Bob Trusts

DMV put Mel’s accurate picture on license. Alice put Dawn’s key on the digital certificate.
Clerk knows what a license looks like. He has Alice’s public key.
Her eyes can match Mel’s DMV photo to his His copy ofAlice’s public key will correctly verify
physical appearance. (or reject) the integrity of the digital certificate.

Issuer’s Limited Liability

Bob can’t (easily) The DMV certifies only that Mel has successfully completed a driving test and
sue Alice for an that Mel’s picture is on the front of the license. A victim of Mel’s bounced checks
incorrectly issued or reckless driving can’t sue the DMV’
digital certificate. Similarly, Alice certifies only that Dawn identified herself and that Alice
signed Dawn’s public key on Dawn’s certificate.’ A victim of Dawn’s improper
and/or unethical use of her public/private key pair can’t sue Alice. For example,
if Dawn signs a message and denies authorship by falsely claiming that her pri-
vate key was stolen, Alice is not legally responsible for Dawn’s deception.

Time Limits
The DMV requires that Mel renew his license every few years. Although Mel
is a law-abiding citizen, car rental firms won’t rent to him if his license has
expired.
Digital certificates also need to be renewed. Bob should never trust the
public key on Dawn’s digital certificate after the expiration date (see the front
of the digital certificate in Figure 16-4).

Revoking Trust
If Mel violates driving laws, the DMV can revoke his license before the expira-
tion date. Car rental companies likely find a DMV revocation list very useful.

2. Of course, anyone can sue anyone for anything. Winning is another story.
3. In Chapter 17 you'll see that Alice and Dawn can choose different ways for Dawn to
prove her identity to Alice. For example, presenting yourself in person is stronger
than presenting yourself via e-mail.
172 CHAPTER 16 e@ =Diaitat CERTIFICATES

Revoking a digital If Dawn violates Alice’s guidelines, Alice can revoke the digital certificate
certificate she made for Dawn before the expiration date. But how will Bob know that
Alice has revoked Dawn’s certificate? How to handle distribution of certificate
revocation lists is the subject of on-going discussions and is covered in the next
two chapters.

More than One Certificate

It’s often useful to If Mel lives in The Netherlands for part of each year, he might want to get a
have more than Dutch driver’s license. The two licenses might come in handy if, for example,
one digital Mel has to prove his identity to a British bank.
certificate. Similarly, Dawn might want more than one person (say, Trusty Tom) to
issue her a digital certificate. For example, she might want to prove her public
key to someone who doesn’t completely trust Alice but does trust Trusty Tom.

Fees for Use

Issuing digital By issuing a license to (young man) Mel, the DMV enables him to drive legally.
certificates for The DMV gets a few dollars (and a smile) from Mel. A few dollars from every
profit driver can amount to a substantial sum.
By signing Dawn’s digital certificate, Alice enables Dawn to send it to any-
one who has and trusts Alice’s public key. If Alice’s public key has been widely
distributed, she can issue digital certificates to help other people deliver their
public keys. Alice may collect a few dollars from Dawn. A few dollars from many
Internet users can mount into a substantial sum. In Chapter 17 you'll see an
example of businesses built on issuing digital certificates.
Note that Alice’s issuance of Dawn’s certificate does not give Alice any new
way to deliver her own public key because anyone using Alice-issued digital
certificates must already have Alice’s public key.

The Needs of Digital Certificate Users

Retrieve, certify, Digital certificate users have three basic needs.
notify
1. They want to be able to retrieve digital certificates from online merchants
and others with whom they want encrypted communications. In Figure
16-5(a), Bob retrieves some certificates.
2. ‘They want to get their own public key certified and posted to Internet re-
positories, where others can retrieve it. In Figure 16-5(b), Bob gets his digi-
tal certificate verified and posts it to an Internet repository.
 GettinG Your First Pustic Key 173

3. They want to know whether a digital certificate is still trustworthy—that is,

whether the public key attached to a digital certificate is no longer consid-
ered secure. In Figure 16-5(c), Bob receives notification that he can no
longer trust the public key attached to a digital certificate.

In Chapters 17 and 18 you'll see how two digital certificate systems (X.509
and PGP) satisfy these needs of certificate users.

alice@aliceDCS alice @aliceDCS

Figure 16-5 Bob needs (a) certificates from online merchants (such as e-Bay.com)
and others (such as Alice); (6) someone who will certify Bob’s public key and a way
to post his digital certificate; and (c) notification if someone’s digital certificate is no
longer secure.

Getting Your First Public Key

How might Bob get Alice’s public key? Professional digital certificate compa-
nies (VeriSign, ATT, and the like) negotiate with software sellers to have their
public keys put in special digital certificates included in shrink-wrap software.
For example, Internet browsers such as Internet Explorer and Netscape include
dozens of so-called root digital certificates.*

4. See Chapter 17 for a discussion of root digital certificates and how to use them to get
more digital certificates.
174 CHaPTER 16 e@ Diaitat CERTIFICATES

Certificates Included in Your Browser

Figure 16-6 shows how you can see the digita! certificates put on H. X. Mel’s
disk by Microsoft’s IE 5.0 when the browser was installed. In Chapter 17 and
Part IV, you'll see how these digital certificates (and their public keys) are used.
The security of public keys distributed this way is based on the following
assumption. If you got your browser from a CD, your certificates should be
genuine because BlackHat would have to forge a CD with bogus copies of digi-
tal certificates, forge a copy of Internet Explorer with Microsoft's logo, stock the
shelves of your local retailer, and so on. Although BlackHat’s work is a little
easier if you download your browser from an Internet site, it’s still difficult. The
list in Figure 16-7 shows some of the certificates you’re probably already
trusting.

In Microsoft IE 5.0, click on Tools.

Select Internet Options.

Select the Contents tab.

Click on Certificates.

Use certificates
topas' Seale —
ye ‘authorities,
ae .

Figure 16-6 Tosee digital certificates packaged with your Microsoft IE 5.0, click on
Tools, Internet Options, Content.

Review
Digital certificates are the preferred way to securely deliver public keys. A digital
certificate is a specialized document signed by a trusted third party. The top part
of a digital certificate contains plaintext identifying the issuer (signer), the sub-
ject (the entity whose public key is attached), the subject’s public key, and the
 REVIEW 175

Certificate Manager

Intended purpose: J<all> |j

Personal |Other People |intermediate Certification Authorities Trusted Raot Certification Authorities | a j

issued To ieee Bert le

CQGTE CyberTrust Root GTE CyberTrust Root 4/3/04 GTE CyberT
CQGTE OyberTrust Rost GTE OyberTrust Root 2/23/06 3TE CyberT
http: //warw.valicert.com/ http: www.valicert.corm/ 6/25/19 ValiCert Clas
Shttp://www.valicertcom/ http://www. valicert.corn/ 6/25/19 =ValiCert Clas
Bhttp:/ wwew.valicert.com/ http: //www.valicert.com/ 6/25/19 ‘WaliCert Clas
/G3IPS SERVIDORES IPS SERVIDORES 12/29/09 IPS SERVID!
EfkeyWitness 2048 Root KeyWitness 2048 Root 5/5/04 KeyWitness !
) Microsoft Authenticode(trn) Root Aut... Microsoft Authenticode(tm) 12/31/99 Microsoft Aut
{Microsoft Root Authority Microsoft Root Authority 12/31/20 Microsoft Ro
i NetLock Expressz (Ciass C) Tanusit.. NetLock Expressz (Class C).. 2/20/19 NetLock a ;
,

Figure 16-7 Some of the digital certificates Microsoft’s IE 5.0 put on H. X. Mel’s com-
puter. (Netscape installs digital certificates, too.)

expiration date of the certificate. The bottom part of a digital certificate con-
tains the issuer’s signed hash of the top part.
The consumer of a digital certificate must have a trusted copy of the issuer’s
public key to correctly verify the certificate. The issuer, subject, and consumer
are reviewed in Table 16-2.

Table 16-2 Digital certificate players.

Player Action Analogy

Issuer Creates and signs certificate DMV

Subject Sends issuer his or her public key Licensee
Consumer Uses subject’s public key Car rental firm that
(on certificate) confirms licensee ID
 be oe
i gah ae S
- 1 é on
we “9

f tine — 4

ae ars

ST = -_
pctuet ¥ Sharing Ges wean amin -He Si - igh?

— lediind eke ee _ < ined lt = dap, of

_ 3.

fee rel irs <e

amp teiraiies | ite,

; ee,
Sloat Pedy 084 ral dei ari acl
ogee =
tor-< eo, _) as, |
Ged

ead * fod *

Dc eee anaes Fee ile!pewpret

| <a = Adi P * idears! oT
 Chapter 17

X.509 Pustic Key

INFRASTRUCTURE

ow that you’ve seen how digital certificates help with the delivery of pub-
lic keys, we'll examine two ways a network of digital certificates can be
managed. This chapter and Chapter 18 look at digital certificate administrative
frameworks, which are called public key infrastructures (PK1).'! The two major
PKI frameworks are X.509 and Pretty Good Privacy (PGP).
There’s more discussion here on X.509 because it seems to fit the corpo-
rate/government model, and, as a result, most of the effort (and money) seems
to be coalescing around X.509. Nevertheless, PGP has some attractive at-
tributes.” PGP is discussed and contrasted with X.509 in Chapter 18.
Although there are several standardization bodies,’ most of the work on
X.509 and other Internet standards seems to come from an Internet Engineer-
ing Task Force (ETF) subcommittee, called the PKIX working group. The
PKIX group promotes, enhances, and develops methods to administer X.509
certificates.*

1. PKTisa generic term; perhaps a more descriptive name would have been digital cer-
tificate infrastructures. Don’t confuse PKI with another widely used public key acro-
nym, PKCS (public key cryptographic standards). PKCS are suggested guidelines
published and owned by one company, RSA Data Securities. PKCS #1 is discussed
at the end of Chapter 22.
2. Efforts are under way to make X.509 and PGP interoperate.
3. For example, the International Organization for Standardization (ISO), the Inter-
national Electrotechnical Commission (LEC), the International Telecommunication
Union (ITU), NIST, and the American National Standards Institute (ANSI).
4. X.509 was originally an ITU recommendation. PKIX’s goal is to further specify
X.509 for use with Internet applications, such as e-mail, SSL, and IPsec.

177
178 CHAPTER 17 © X.509 Pustic Key INFRASTRUCTURE

About IETF
_ The Internet Engineering Task Force is a group of beanie and compa-
nies interested in the harmonious operation of the Internet. Anyone
can download information about IETF standards from its site, |
— www.ietf.org, without charge. _ - _
7 members (and their publicatio are Usually very technical, a
e: “There are those in the IETF
we refuse to wear ang other than suits. Fortunately, they are well —
known (for other reasons) so they are forgiven this particular
idiosyncrasy.”

Why Use X.509 Certificate Management?

In Chapter 16 we outlined the needs of a typical digital certificate user, and they
are reviewed in Table 17-1. Briefly, there are two types of digital certificate
users: a subject and a consumer. A subject needs to get his or her own public key
certified and posted to Internet repositories. A consumer needs to retrieve and
use digital certificates and know whether a digital certificate is still trustworthy.
Most digital
But most digital certificate users probably don’t want any responsibilities for
certificate users administering digital certificates and probably don’t have the knowledge or re-
don’t want any sources (such as a valid source of random data) that are required to generate
certificate strong public/private key pairs. Most digital certificate users simply want PKI
administrative to work with as little effort as possible on their part. Enter the manager.
responsibilities To give certificate users a transparent digital certificate solution, digital
certificate managers want a centrally controlled system or, in X.509-PKI par-
lance, a certificate authority (CA).

Table 17-1 Digital certificate user’s needs reviewed.

What a Digital Certificate User Wants

Public key certified by a trusted third party

Retrieve other users’ certified digital certificates (public keys)
Notified if a trusted certificate has been prematurely revoked
 Wuart Is A CertiFicATe AUTHORITY? 179

What Is a Certificate Authority?

A certificate A CA manages digital certificate application, certification (authentication of the
authority manages applicant), issuance, and revocation. In this respect a CA is similar to the DMV,
application, a driver’s license authority (see Chapter 16). A CA is also similar to a key dis-
certification, tribution center (KDC) introduced in Chapter 8. Both KDCs and CAs act as
issuance, and trusted third parties.
revocation. A notable difference between a KDC and a CA is the type of key with which
each is entrusted. Users of a KDC trust the KDC with their secret keys and trust
that the KDC keeps their secret keys secret. Because public keys don’t need to
be secret, a CA doesn’t keep any secrets, except, of course, its own private key.
This chapter examines some of the more important CA responsibilities.’
Although a CA can outsource most of its responsibilities, for simplicity we as-
sume that it handles all the management functions. When that’s not the case,
we'll specify.

Application, Certification, and Issuance

CA authenticates A CA should validate an applicant’s identity before issuing a digital certificate.
the applicant and Suppose our applicant is Bob. Once the CA has identified Bob, the CA must
ensures that the verify that Bob has the matching private key before issuing him a digital certifi-
applicant has the cate. The digital certificate is like a traditional letter of introduction; it effec-
matching private tively says, “I, the CA, hereby identify Bob and assert that this is really Bob’s
key. public key.” Most CAs offer various classes of digital certificates depending on
the certifying documents the applicant submits and the fee paid to the CA.

Low Assurance Certificates

In Figure 17-1, Bob applies for a digital certificate over the Internet under the
applicant name [email protected]. The CA issues and sends a digital certificate
to the e-mail address [email protected].
Low assurance
Because the CA doesn’t know whether the owner of the e-mail account
means that the CA [email protected] is really Bob, this certificate is a Jow assurance digital certificate.
has not validated It is so named because, for example, Bob may have stepped away from the com-
the applicant in puter long enough for BlackHat to apply for and get the digital certificate us-
person. ing Bob’s e-mail account. Or perhaps Bob uses a system (such as Windows 98)
that doesn’t restrict logon and BlackHat applied to the CA without Bob’s
knowledge.

5. The IETF has suggested CA standards. See www.ietf.org.

180 CHAPTER 17 e X.509 Pustic Key INFRASTRUCTURE

Internet

Online person
‘[email protected]’

Physical persons

Figure 17-1 Bob applies to a CA over the Internet for a low assurance certificate. A
high assurance certificate requires that Bob apply in person.

Most CAs ask for a For further assurance, the CA can request that the applicant pay for the
credit card and certificate with a credit card and then issue the certificate to the exact name that
issue the low appears on the card. If BlackHat also knows Bob’s credit card number, he could
assurance successfully impersonate Bob.
certificate to the For a low assurance certificate the CA may only validate whoever can get
name on the card. the e-mail at [email protected]. The CA is confident that’s true because the cer-
tificate is sent to [email protected]. If Alice gets the e-mailed certificate, it’s OK
with the CA because the CA has validated only a subject who can receive mail
at [email protected]. The CA is assured that the applicant at [email protected]
has the matching private key after successfully completing something like a
challenge response.° (A short review of a challenge and response protocol is in
Figure 17-10 at the end of this chapter.)
Low assurance digital certificates from a commercial CA such as VeriSign
are called a “Class 1 Individual Subscriber Persona Not Validated” and give only
“assurances that communications originate from a particular source. Class 1
Certificates do not provide proof of identity.”’ The boldface type, added by
VeriSign, emphasizes that the company did not authenticate the certificate
owner in person.
Low assurance The use of low assurance certificates does not mean that the CA uses less
certificates may use secure cryptography. Both low and high assurance certificates can use the same
the same high- cryptographic methods and key lengths.
quality
cryptography as
high assurance High Assurance Certificates
For a high assurance digital certificate, the CA most likely will require the ap-
plicant to appear in person and present more than one form of identification,

6. A few CAs issue digital certificates only if they can create the public/private key pair.
7. PKI Disclosure Statement from www.verisign.com.
 Wuat Is A CertiFicATte AUTHORITY? 181

High assurance such as a driver’s license or a passport, so that the CA can match a certified pic-
means that the CA ture to the applicant. Of course, this procedure doesn’t prevent forgery, but it
should validate the does make it more difficult. CAs can implement other user authentication prac-
applicant in person tices to preclude almost any imagined forgery. For example, before a CA issues
and verify the a certificate for an e-commerce company, the CA may verify the company phone
applicant in other numbers with independent commercial databases, phone the company execu-
ways. High
tive offices, and confirm the application. High assurance certificates cost more
assurance
than low assurance certificates.
certificates are
more costly.
A CA may outsource the registration and authentication tasks to a local
registration authority (RA).° For example, an RA with many offices can save
HxMel.com the considerable expense of sending each of its 1,000 geographi-
cally dispersed employees to a CA. Instead, a CA-approved RA can verify and
issue each of HxMel’s employees high assurance digital certificates. The CA
might even empower the RA with other responsibilities, such as creating an
employee’s public/private key pair.

Distribution
Because nothing on a certificate is secret, the CA can store it in a certificate
repository and/or send it to the subject (applicant); certificates can be e-mailed.
A CA can decide to outsource digital certificate storage to a dedicated
server. Proposed PKIX standards for publishing and retrieving certificates use
the Lightweight Directory Access Protocol (LDAP).’ The CA might also ex-
change digital certificates with other CAs and even certify other CAs. CA cross
certification is still in its infancy, and there are still many logistical problems.
Other CA paying Who might want to pay the CA for a copy of a digital certificate? CAs (and
customers their venture capitalists) believe that anyone who wants someone else’s certified
public key—for example, users of digital signature schemes that use public key
cryptography—will pay a minimal amount for each certificate.

Certificate Revocation
Although a digital certificate is normally expected to be valid during the dates
listed on the certificate, a CA can revoke a certificate prematurely.
Revoking a single Suppose that HxMel’s CA issues a digital certificate to a temporary contrac-
digital certificate tor, Iemp3. When Temp3 completes his work, HxMel’s business partners need
to know that Temp3’s digital certificate has been withdrawn. (Temp3’s public key
no longer represents HxMel, and his private key cannot be used to sign
contracts.)

8. Sometimes this is referred to as an LRA, or local registration authority.

9. See the LDAP working group on www.ietf.org.
182 CHAPTER 17 e %X.509 Pustic Key INFRASTRUCTURE

If Temp3 returns to work, a new digital certificate and public key must be
issued. In other words, revoked digital certificates cannot be renewed; that
would entail too much administration, potential error, and possible fraud.
What if the CA\s If a CA’s private key is compromised, all certificates issued after the private
private key Is key was compromised should be revoked because a certificate user can’t be sure
compromised? whether the genuine CA or BlackHat used the CA’s private key to make and
issue certificates.
Definition: Revoked certificates are put on a certificate revocation list (CRL). A certifi-
certificate cate user or holder should check the most recent CRL just as a merchant vali-
revocation list dates a credit card before completing a transaction.

Polling and Pushing: Two CRL Delivery Models

Definition: polling There are two basic CRL delivery models. One model, known as-polling, re-
quires the certificate user to request the current CRL whenever the user needs
a public key on a digital certificate. One problem with polling is the time de-
lay between CA certificate revocation and CA publication of a new CRL. For
some applications, even a delay of a few hours is too long.
Definition: pushing In the other model, known as pushing, the CA delivers users new CRLs as
soon as it revokes a certificate. A problem with pushing is that the user must
store each new pushed CRL even if it doesn’t contain any relevant revoked cer-
tificates. Also, because the CRL is pushed, the CA and the user must ensure that
BlackHat doesn’t intercept and delete the pushed CRL before it reaches the
user.

Building X.509 Trust Networks

Definition: root CA Just as each state has its own DMV, each particular X.509 PKI implementation
has a root CA. For example, any company may have its own CA or, if finer
granularity is needed, even a CA for each company division or department. In
Figure 17-2, a root CA" we'll call Root CA issues Alice a digital certificate. After
Alice has been issued a certificate, Bob can get it from either Root CA or Alice.
Bob uses his copy of Root CAs public key to verify Alice’s certificate and pub-
lic key (see Chapter 16 for information about the verification process).
Definition: self- Why does Bob trust his copy of Root CA’s public key? Root CA has a dis-
signed certificate tinctive digital certificate, issued by Root CA and to Root CA. In other words,
Root CA is both issuer and subject; it’s called a self-signed digital certificate.

10. Some authors refer to root CA as “top CA” or “most-trusted CA.”

 BuitpINc X.509 Trust Networks 183

ROOT

1
Teer:

Figure 17-2 Bob uses his copy of Root CA’s public key to verify that he received
Alice’s genuine public key.

Root Certificates
Self-signed (root) A self-signed certificate is also called a root certificate, and it’s the foundation"!
digital certificates of every X.509 PKI implementation (see Figure 17-3). X.509 PKI software looks
are accepted for self-signed (root) certificates, extracts the attached public key, and assumes
without additional it is trusted. This means that the root CA digital certificate and its associated
verification public key are often accepted without additional verification.'’ Chapter 16 shows
some examples of self-signed certificates in an Internet browser.
A root CA distributes its public key in a self-signed certificate with Internet
browsers and on other public Internet sites. Figure 17-4 shows a screen shot of
a GTE CyberTrust self-signed certificate shipped with Microsoft’s browser.

Issuer Issuer —>

Subject Subject —>

Root issues for Alice Root issues for Root

Figure 17-3 Root CAss certificate is a self-signed certificate and is explicitly trusted.
We use a certificate symbol with a black background to emphasize its unique
characteristics.

11. Asynonym for foundation is base. Base means “bottom part,” as in the base of a moun-
tain. Nevertheless, a root CA is most often shown on top, so we show it that way, too.
12. Although commercial CAs often publish their certificates (e.g., on Web sites) for
verification, few users validate the CA root certificate.
184 CHaPTER 17 e X.509 Pustic Key INFRASTRUCTURE

Certificate

In |.E. 5, click on: This certificate is intended to:

Tools *Guarantee the identity of a remote computer
Internet Options eGuarantee your identity to 4 remote cormputer
Content «Ensure e-mail came frorn sender
«Protect e-mail from tampering
Certificates eEnsure the content of e-mail cannot be viewed by others
Trusted Root CA
View

>Issued to: GTE Cyberlrust Root

In Netscape 4.7,
click on:
Communicator, 2%» Issued by: GTE CyberTrust Root
Tools
Security Info
Valid from 2/23/96 to 2/23/06
Certificates
Signers
Edit

Figure 17-4 A self-signed digital certificate in Internet Explorer.

Note that the issuer and subject is GTE CyberTrust. Most popular browsers
(such as Netscape) also include many different root CA certificates. Internet
e-commerce systems such as Secure Socket Layer rely on self-signed certificates
as the beginning point of trust. A root CA that serves only a particular company
has other ways to distribute root certificates, such as personal installation, com-
pany e-mail, and so on.
Trust flows from the Ina simple X.509 PKI, the root CA signs every certificate. In Figure 17-5,
CA. A CA root Root CA issues Alice and Bob certificates. Alice verifies Bob’s certificate with
certiticate is trusted Root CA’ public key; Alice now has a trusted copy of Bob’s public key. Similarly,
by everyone in the Bob verifies Alice’s digital certificate. Alice and Bob have trusted copies of each
CAs PKI. other’s public keys only because they trust Root CA and trust that they have
Root CA’s public key (genuine digital certificate).
 Buitpinc X.509 Trust Networks 185

Figure 17-5 Root CA issues certificates for Alice and Bob. They trust each other's cer-
tificates and public keys because they trust the issuer (Root CA) and trust that they
have Root CA's genuine public key.

All X.509 ps There are many public and private CAs, and each is independent. For ex-
certificates trust the ample, GTE Certificate Company CA issues certificates without consulting
validity of some other certificate companies. As we said, as of this writing, there are
root CA certificate interoperability issues between CAs. Also, whenever Bob trusts a particular digi-
tal certificate, Bob implicitly trusts the issuer (say, xYz Certificate Company) of
that particular certificate.
Popularity of X.509 One reason that companies like the CA model is that it makes it easy to
certificates bring someone new into the trusted network of digital certificates. In Figure
17-6, Root CA issues Casey a digital certificate and gives him a copy of Root
CA’s certificate (public key). That’s all that Root CA has to do to bring Casey
into the trusted network. Casey can retrieve a copy of Alice’s and/or Bob’s digital
certificate from Root CA, or he can retrieve a copy of those certificates from
either Alice or Bob. Alice and Bob can, likewise, get Casey’s digital certificate.
All the participants—Alice, Bob, and Casey—trust each other’s public keys be-
cause they trust Root CA, which issued the certificates. But note that if the Root
CA self-signed certificate is untrustworthy, so is every certificate that Root CA
signed.
Definition: As we mentioned, a root CA can outsource registration and distribution of
subordinate CA certificates. It can also give Alice authority to issue digital certificates, making
her a subordinate (sub) CA." Usually, the CA directs the sub CA to sign certifi-
cates with the sub CA’s private key and not with the CA’s private key.

13. This is most often abbreviated as sub. In this context, sub means “subordinate” and
not “substitute.”
186 CHAPTER 17 e X.509 Pustic Key INFRASTRUCTURE

ROOT

Figure 17-6 Root CA issues Casey a digital certificate and brings Casey into this par-
ticular root CA’s trusted network.

This management strategy might be reasonable if the root CA issued cer-

tificates to full-time employees and the sub CA issued different certificates to
contractors and visitors. Sub CA Alice might have different registration and
authentication processes for her group of certificate holders. (Or sub CAs can
be used for different registration tasks. For example, VeriSign has a sub CA for
each of its low, middle, and high assurance certificates.)
Chaining trust from In Figure 17-7, Alice issues a certificate to Temp3. Bob can retrieve Temp3’s
the root CA certificate from Alice’s public repository, and because Bob has Alice’s certificate,
he can verify Temp3’s certificate issued by Alice, as shown in Figure 17-8.
Bob verifies Temp3’s certificate as follows:

1. Bobuses his trusted copy of Root CAs digital certificate to extract Root CA’s
pubic key (Root CA’s public key is accepted without verification).
2. Using Root CAs public key, he verifies Alice’s digital certificate and extracts
a copy of Alice’s public key.
3. Using Alice’s public key, he verifies Temp3’s digital certificate and extracts
a copy of Temp3’s public key.!*

Bob trusts Temp3’s digital certificate because he trusts Root CA and Alice,
the certificate chain from Root CA to Temp3. If either Root CA or Alice is not

14. If Temp3 is empowered to issue certificates (e.g., for other temp workers), the cer-
tificate chain would grow another link.
 BuitpINc X.509 Trust Networks 187

Figure 17-7 Alice, a sub CA, issues a digital certificate to Temp3. Bob gets a copy of
Temp3’s certificate.

chain
Kertisicn

Figure 17-8 A certificate chain. Bob verifies Temp3’s digital certificate.

totally trustworthy, Bob is taking a risk in trusting that he has a valid copy of
‘Temp3’s public key.

More Risks and Precautions

As previously stated, the CA must ensure the absolute security of its private sign-
ing key. Because every CA-issued digital certificate is ultimately signed with the
CAs private key, a compromised CA private key means that every digital certifi-
cate under this particular CA is suspect. That includes any digital certificate
signed by a sub CA (under this particular root CA).
188 CHAPTER 17 e X.509 Pustic Key INFRASTRUCTURE

In addition to the need to explicitly trust the root CA, PKIs carry other
associated risks. For example, suppose that BlackHat can compromise a single
digital certificate in a certificate chain and block access to the current CRL."
If BlackHat’s attack is successful and users can’t get the current CRL, they may
incorrectly validate a digital certificate at the end of the chain.
Digital fraud is a budding, burgeoning business. The phrase caveat emptor
(“let the buyer beware”) is as relevant now as it was when secret keys were in-
vented thousands of years ago. But even the best distribution system requires
you to trust someone and to take acceptable levels of risk.

Distinguished Names
Definition: Distinguished names are used to give the subject of every digital certificate unique,
distinguished identifiable characteristics. Suppose that Root CA issues Alice a certificate and
names places it in a certificate repository (database). How is Alice, wife of Bob, differ-
entiated from the other Alices in the world? The answer is that the CA issues
the certificate to a distinguished name. As shown in Figure 17-9, Bob trusts that
the CA’s distinguished name for Alice has enough data elements (country, busi-
ness, business unit, e-mail address, etc.) to ensure that there’s only one Alice,
wife of Bob, mother of Casey and Dawn, and so on.

Alice . Alice
USA, Calif ' Netherlands
O0-29 toh:

Figure 17-9 Distinguished names are used to differentiate digital certificates.

15. By using, for example, a denial of service attack.

 X.509 Certiricate DATA 189

Certification Practice Statement

Definition: A CA operates under internally generated legal guidelines called a certification
certification practice statement (CPS). A good CA will publish its CPS for prospective custom-
practice statement ers to read. The CPS details how the CA authenticates its clients, issues certifi-
cates, and so on. The CPS doesn’t protect Alice or Bob as much as it protects
the CA, whose lawyers wrote it.

X.509 Certificate Data

X.509 has been around since 1988 and currently has three versions, titled, not
surprisingly, vl, v2, and v3. V3, released in 1996, is the latest and requires cer-
tain fields, or information that must be included, as shown in Table 17-2. Fol-
lowing is a brief description of the required fields on an X.509 certificate.
References to Alice or Dawn are from Figure 16-2.
Signature method The signature method identifies the method the CA used to sign (private
field key encrypt) the digital certificate. Although we’ve used RSA to sign, other sig-
nature methods, such as DSA, are considered just as secure.
Issuer field: The issuer can be anyone, but it should be someone who acts responsibly.
Certificate users Recall that a digital certificate is only a private-key-signed (encrypted) message
trust the certificate that also contains someone else’s public key. Your nephew can sign a certificate
issuer proclaiming it contains the public key of Jerry Garcia, late leader of perennial
road band the Grateful Dead. Grateful as Garcia might be, he’s not going to be

Table 17-2 X.509 v3 mandatory fields.

Field Name Description

Version v1, v2, or v3

Serial # Must be unique.
Signature method The method used to sign the digital certificate (for example, RSA or
DSA).
Issuer name (e.g., Alice) The signer or entity (person, company, etc.) whose private key signed
(encrypted) this certificate. In Figure 16-2, Alice issued the certificate.
Valid time period Begin and end time the issuer keeps records for this particular
certificate.
Subject name (e.g., Dawn) The person or company whose public key material is included in the
next field. In Figure 16-2, we used Dawn.
Subject’s public key Public key and public key method. For example, RSA, DSA, and
Diffie-Hellman are three popular options.
190 CHAPTER 17 e X.509 Pustic Key INFRASTRUCTURE

Mini-Review
Challenge/Reponse
CA challenges Bob:
Using Bob's public key, CA
encrypts challenge phrase “abcde”
(“FiveAM” -> “aocde”) and
sends it to Bob.
Response
Bob responds to CA: “FiveAM”
Bob decrypts the
challenge with his private -mszexre@ewvow
key (“aocde” -> “FiveAM”)
and returns it to CA.
(See Chapter 7 for more.)

Figure 17-10 A challenge response.

able to tell you from the grave that your nephew is not acting responsibly as an
issuer. Did your nephew issue this certificate as a macabre joke, or did he fail to
properly check out the person who requested the certificate?
Valid time period
The time period field contains the issuance and expiration dates for which
field the issuer certifies the subject’s public key; this field is also called the validity
interval. The issuer must keep records on the subject until expiration. Most is-
suers keep records past the expiration date.
You might think that the issuer would be liable if it incorrectly certifies a
public key or doesn’t quickly inform you when a digital certificate is prematurely
revoked (i.e., the issuer has withdrawn the certification of the subject’s public
key). Not so; see the earlier section, “Certification Practice Statement.”

Challenge Response Protocol

Figure 17-10 shows a brief version of a challenge response (introduced in Chap-
ter 7). This is one way that the CA can verify Bob has the matching private key
before issuing Bob a digital certificate.

Review
The root certificate authority (CA) is the single focal point of X.509 certificate
policies. Digital certificate users trust the accuracy of the public keys the CA
issues. Like a DMV, the CA controls certificate application, certification, issu-
ance, expiration, and revocation.
The CA can outsource most of these functions to subcontractors. For ex-
ample, a PKI defines terms and definitions for registration authorities (RAs),
 REVIEW 191

who act on behalf of the CA. The CA can also outsource the distribution of the
certificate revocation list (CRL).
ACA root certificate is self-signed by the CA and is usually accepted as valid
without additional verification. Commercial CA root certificates are often dis-
tributed through another trusted source, such as Netscape’s Internet browser.
Company CA root certificates can be distributed in other ways.
 vert ) sal es Se ee ee

att 17 ane? rs! aenaoncmsa tT oh jolt teeVertaal me ang gil

tprtcg * 4 1900) naka cet oeAen:
Malet pate rot (!-og »:aedatedbe! begicinens shins WAL A
=fASN: Sort tiie py tomy Madde Lures.) verde ee ee yok
Perea! (orm! ¢ eed ai > tae jM>* hae i: >. Ol hom
ne sip f sabinalienil int dy ayseils ex: it f? imeytur
a
a ‘x *e
i
st r i

7 >.<

— = ~~,

> ~ — *..

— 4 . 12 = » 2 ~~ -
=
oe

7 7 ~~ Pat ; > aT ‘ ale oe

imia i hen 6 igi) Sey
c @ : j :

- _ = : a) de ‘ ' vt re ore
= _ —— < : if ey

cy . ae new me, ©

peas pura ® ’ Ry a
- = 28 @ on Pa mee ¢ oa a! —— "y ug wa fieg 3
bert TV oe ee 6 AY ee Ws a ern. T6* Nl sta heres a

= Area Bet Tt: ——_ s ve | - » * ae de dus av ‘yas ar

wT “> ie = ow Pw ee mi ; sence

-“,~
=_— thallanys Beapansa Princo
i
a m/e aay rT -@ 2b he)> (Awl A sie naarth
rm Srienss (ihe LA Eup val Piya his (uty fig ces
gains + 01% = Sr

ate “1X VRE Fri onicsath ie

= ao ea Ice sailed ‘ca
=) Cul abe ee > bate =
a a ray: aan aall -

, aay
hy. me” @yiey
 Chapter 18

Pretty Goop Privacy AND

THE Wes oF TRUST

PGP PKIs don’t use Ks based on Pretty Good Privacy (PGP) were invented to serve the indi-
aCA vidual Alices and Bobs of the world. Compared with an X.509 PKI, a PGP-
based PKI presents much less bureaucracy that must be managed. In a classic
PGP-based PKI, each user issues and manages his or her own digital certificates;
there’s no certificate authority (CA). This does not necessarily mean that PGP
digital certificates are less trustworthy than X.509 certificates. Instead, it means
that users of PGP-based PKIs don’t have a central controlling authority that as-
sumes responsibilities. PGP cryptographic methods and keys are as strong as
those used with X.509.

The History of PGP

PGP created by Phil A discomfort with central controlling authorities is one reason PGP was in-
Zimmermann vented. Its founder, Philip Zimmermann, uncomfortable with the federal
government’s record on individual privacy protection, decided to create a prod-
uct that would give an individual the power to protect his or her own privacy.
But it was not an easy birth.

Why Philip Zimmermann Created PGP

“The government has a track record that does not inspire confidence
that they will never abuse our civil liberties,” Philip Zimmermann explains
in Why |Wrote PGP, a document that can be downloaded with his soft-
ware. He proposes one solution to counter the U.S. government’s trend
to outlaw cryptography and encroach on individual privacy: To make
cryptography harder to criminalize, use it as much as possible while it
is legal. He wants to avoid privacy being outlawed because that would
mean that “only outlaws will have privacy.”
(Continued)

193
194 CHAPTER 18 e Pretty Goop Privacy AND THE WEB OF TRUST

Zimmermann’s approach to digital certificate administration, with its

“web of trust,” mirrors his concern that people should have the power
to control their own privacy. He writes, “PGP empowers people to take
their privacy into their own hands. There’s a growing social need for it.
That’s why | created it.”

During the late 1980s, Zimmermann designed a user-friendly product for

personal computer encryption. In June 1991 he asked a friend to post PGP ona
computer bulletin board where it could be downloaded for free around the world.
The story of PGP’s birth and turbulent early years is engagingly related by
Simon Singh in The Code Book (see the Bibliography). According to Singh,
Zimmermann used RSA patented technology, and he didn’t have a license to use
it. RSA did not want to give him a free license and pursued him for patent in-
fringement.' A bigger problem came when the FBI visited Zimmermann in
1993. For the next three years he was the subject of a grand jury investigation,
which examined the issue of whether Zimmermann was an arms dealer because
PGP had been exported over the Internet.
Singh relates that during the investigation, public support for Zimmermann
grew and cryptographers and civil libertarians established an international fund
to help finance his legal defense. In addition, in 1995 Massachusetts Institute of
Technology Press published Zimmermann’s The Official PGP User’s Guide, a
600-page book distributed worldwide. Singh writes that the legal authorities
were concerned that bringing Zimmermann to trial would “achieve nothing
more than a constitutional debate about the right to privacy, thereby stirring up
yet more public sympathy in favour of widespread encryption.” In 1996, the case
against Zimmermann was dropped. The patent issue was also eventually re-
solved when RSA granted him a license to use its technology in PGP. Current
versions of PGP also support Diffie-Hellman.
PGP is freely In 1997 Zimmermann sold PGP to Network Associates and became one of
available; Network the company’s senior fellows. Although PGP is now sold commercially, you can
Associates sells a still download it for free from www.MI edu.
commercial Because of Zimmermann and others who fought for widespread use of
version. commercial encryption products, we now have choices in how to handle the
security of our communications. So let’s see how these choices compare in re-
gard to digital certificates.

Comparing X.509 and PGP Certificates

Both X.509-based PKI and PGP-based PKI are based on digital certificates.
Figure 18-1 shows the major differences.

1. RSAss patent expired in September 2000.

 ComPariING X.509 ANp PGP CertiFicaTes 195

Issuer # Subject Issuer /Subject Issuer = Subject

(except for Root CA)

| Authentication(s) At least 1
Always 1 1 (Signed Hashes) Often more than 1

> |ssuer » Alice

Alice’s
Public
Key

Signer(s) 4
of digital
certificate Z

More than one

authentication
(signed hash

Figure 18-1 Comparing X.509 and PGP digital certificates.

X.509 user Almost all X.509 digital certificates have a separate issuer and subject (in
certificates are Figure 18-1, Root CA issued a certificate for Alice). Only a root CA issues its
created by a own certificate; that is, only a root CA certificate is self-signed.
trusted CA. Self-signed certificates are easy to forge. That’s why, as you saw in Chap-
ter 17, self-signed certificates are only as trustworthy as the delivery source. For
example, Netscape delivers an ATT digital certificate with the Netscape
Internet browser.
All PGP users create PGP doesn’t use the CA concept. Instead, each user signs his or her own
and sign their own digital certificate; the issuer and subject are identical (in Figure 18-1, Alice is-
digital certificate sues a certificate for herself). This means that all PGP certificates are initially
self-signed; they’re similar to X.509 root certificates except that PGP certificates
196 CHAPTER 18 e Pretty Goon Privacy AND THE WEB OF TRUST

X.509 certificates are seldom, if ever, included with Internet browsers. PGP certificates obtain
have one signer trustworthy status in other ways.
(the issuer); PGP A classic X.509 certificate format allows only one signer per certificate.
certificates allow PGP’s certificate format allows more than one person to sign any particular
more than one certificate; in theory, each additional signer adds trustworthiness to the certifi-
signer. cate. Let’s explain with an example.

Building Trust Networks

In Figure 18-2 Alice makes her own certificate and delivers it to Bob.
But BlackHat can intercept Alice’s e-mail to Bob (or Casey), substitute a
forgery, and sign Alice’s name. How does Bob trust a certificate he receives from
Alice? The most secure way is for Alice to put a copy of her public key on a disk
and hand-deliver it to Bob. Personal hand delivery is secure, but it is not usu-
ally convenient in a world of global communications.

Bob Validates Alice’s Key

Public keys have Here’s an easier way Bob can validate that Alice’s certificate (and public key) was
fingerprints not corrupted during transit. The current version of PGP freeware, distributed
(HxMel’s is at end by MIT, displays a unique public key fingerprint, shown in Figure 18-3. Bob
of book). should call Alice and say, “I got your public key; its fingerprint [expressed as

Figure 18-2 In the PGP model, each user creates and distributes his or her keys.
Here, Alice sends her digital certificate to Bob.
 BUILDING TRUST NETWoRKS 197

Hi, Alice, | recognize your voice. The

public key | got from you is:
‘framework’, ‘regain’, ‘nightbird’...

Figure 18-3 Public key fingerprint displayed by PGP.

hexadecimal numbers] is 661A 5AFD....” If it hasn’t been corrupted, the pub-

lic key fingerprint Bob received will match the fingerprint Alice reads from her
computer. Because Bob trusts his knowledge of Alice’s voice and her confirma-
tion of her correct fingerprint, Bob trusts that he has Alice’s public key (unless
someone intercepts Bob’s phone call and imitates Alice’s voice). HxMel’s PGP
key is at the end of the Epilogue.
PGP transforms the As a convenience, PGP includes a word representation of the hexadecimal
public key numbers, such as “framework, regain, nightbird. .. .” The 20-word fingerprint
fingerprint into is made from a list of words carefully chosen so that each word has a distinguish-
distinct words. ing sound. In that way, Bob is unlikely to misunderstand what Alice says. For ex-
ample, because the PGP word list includes regain, the word list doesn’t include
remain, remainder, and retainer. Figure 18-3 also shows Alice’s fingerprint ex-
pressed as words (as well as numbers). Figure 18-4 shows Alice sending her
certificate to Bob and Bob’s confirming phone call.

Casey Validates Alice’s Key Sent by Bob

PGP also allows a user to validate the trustworthiness of another user’s digital
certificate (public key); that is, PGP empowers Bob so that he can formally
corroborate the trustworthiness of Alice’s digital certificate.
198 Cuapter 18 e Pretty Goon Privacy AND THE WEB OF TRUST

Figure 18-4 Bob confirms that he received Alice’s correct public key.

Beginning a PGP
Let’s look at an example. Figure 18-5 assumes that Alice sent Bob her digital
web of trust. certificate and that Bob verified it using the key fingerprint as in Figure 18-4.
Bob then sends Casey his self-signed digital certificate. In addition, Bob sends
Definition: trusted
Casey Alice’s digital certificate after adding his signature (verification), shown
introducer
here as a seal with the letter B (for Bob).’ Casey calls Bob and validates Bob’s
public key fingerprint. If Casey trusts Bob, Casey can also trust Alice’s digital
certificate (Bob added his signature to Alice’s certificate in Figure 18-5). Casey
doesn’t need to call Alice to verify her fingerprint. Bob is acting as what PGP
calls a trusted introducer, which is similar to an X.509 CA.

Dawn Validates Alice’s Key Sent by Casey via Bob

Casey adds his Let’s look at Figure 18-6, where Dawn enters this PGP community and wants
signature (and Casey’s and Alice’s public keys. Casey sends Dawn his digital certificate; then
more Dawn calls him and validates Casey’s digital fingerprint (not shown in Figure
trustworthiness) to 18-6). Dawn also asks Casey to add his signature to Alice’s digital certificate,
Alice’s certificate. which Casey received from Bob. Casey does so and sends it to Dawn. Then
Dawn uses her validated copy of Casey’s public key to verify Casey’s signature
on Alice’s certificate.*
Maybe Dawn trusts Casey enough that she doesn’t need any additional
verification. But because each additional signature increases Dawn’s trust in
Alice’s digital certificate, she might also want to verify Bob’s validation of Alice.
In that case, Dawn will need a verified copy of Bob’s public key. She can ask Bob
to send it to her directly, or, given that she already has a verified copy of Casey’s
public key, she can ask Casey to sign and send Bob’s certificate.

3. This may seem different because classic X.509 certificates allow only one signature.
4. Alternatively, Dawn can request and validate Alice’s certificate from Alice directly.
 BuiLDING Trust Networks 199

¢
Bob signs 3 *,
Alice’s digital e

certificate
*

A
e
s
s
s
s
os
a
s
s
s
=
Cy
2
=
=
bal
=
ad
af
*
«

Figure 18-5 After Bob verifies Alice’s digital certificate with a phone call to Alice, he
sends Casey his (Bob’s) certificate along with Alice’s certificate validated by him (Bob).

Casey adds his

signature to Alice’s
digital certificate.
(Bob’s signature is
there, too.)

Figure 18-6 Casey sends Dawn his digital certificate and Alice’s digital certificate
signed by Bob and Casey. Then Dawn verifies Casey’s signature on Alice’s certificate.
200 CHAPTER 18 e Pretty Goop Privacy AND THE WEB OF TRUST

p RY] |
| Alice} Bob}
&euuws ~Gausoss

O-»
Ufporrmnonnen

Figure 18-7 Centralized versus decentralized control: comparing an X.509 PKI to a

PGP PKI.

Web of Trust
Definition: web of From this limited example, it’s apparent that the PGP model rapidly forms an
trust intricate web (of trust). A visual comparison of the PGP and the X.509 models
(see Figure 18-7) shows the difference in how trust is established. PGP’s trust
model is based on a web oftrust, as opposed to the X.509 model, in which all trust
emanates from the certificate authority.

PGP Certificate Repositories and Revocation

PGP users have an option to automatically store copies of their certificates in
centralized databases where other users can retrieve them. Each individual
 Review 201

certificate owner or some surrogate the owner designates handles certificate

revocation.

Compatibility of X.509 and PGP

As of this writing (late 2000), most PKI systems don’t support both X.509 and
PGP certificates. This unfortunate incompatibility—which means that those
using one model can’t securely communicate with those using the other
model—is also evident in secure e-mail systems (discussed in Chapter 19).
However, there is some indication that the two models are moving toward
interoperability. X.509 is adopting some PGP features, such as certificates with
multiple signatures, and PGP is adopting some X.509 features, such as central-
ized control.

Review
Philip Zimmermann developed Pretty Good Privacy (PGP), a strong encryp-
tion system designed for the masses and based on RSA public key cryptography.
PGP is available for free from several Internet servers; probably the most well
known source is MIT.
PGP’s digital certificates are similar to X.509 self-signed (root) certificates
except that PGP certificates can contain more than one signature. In contrast
to X.509’s centralized control (certificate authority) trust model, PGP uses a
distributed trust (web of trust) model.
 eee ee S = ae.

een adiiiia! cere se Ma 0 iat

7

ore a, 7, ot ia ddd Tbs wai

staid v ve 0 he
snebivatyle Dyrery of‘aw cai as nil sah rig re |
wr miipee egy atdh nual = ; i Hen
ite mai Al Lig) 4i , i
ol a) Wao ery. peer elle —~ Ai
ier ier he unite oA ‘alo oe 7
aepemiie'y he ve ate ea aitauss Te oe oa =e
Le Je LY a ee
oe

i ey ~ . ;
a 7

ss nm
-
an
ieee = a,
a

Hd @ ‘Yanan gated rialIPjctrakcorah* GY nen va a i)

mryerr vad ite Gethin hevesd bi gat. Are ioe hha dite Piva
fal Ada mi vies wiriain) Terese wien” et dain i 4 .
= ar his - 0 iiem yevrty i. “p - a
mgs mn |S
aad Pit bal fifo VDE, Se wee Was!
D merece aro omit a Sotm — i av ;
art Joti arar (9) oe hovers hazy hovilincne: (CLM
; ens er re ee _
- a Sen 6Ere Th *. ied 7a ; roaring Pie a:

> & a s

a>» Pow i | . a. a 7
ee ee ee Apes tae Wor US eel tars DS) Gaeag
ee Re Nie Sey Cae ib of OIE emt the S ‘0 ik
a ee en ee ee ee) ee ss
aa
SPDs Gos tf Wap n peut
titSeats a whats
oe. — wan i; yy

« “avaieReposean
- Wie «ai

se, €isit
ih vet
a
 PART IV

REAL-WORLD
SYSTEMS
ow that we’ve presented all the ingredients (secret keys, public/private keys,
hash functions, and digital certificates) for cryptographic systems, let’s see
how those pieces operate collectively in the real world. In the next five chapters
we show how secure e-mail (S/MIME, PGP), Secure Socket Layer (SSL), and
Internet Protocol Security (IPsec) provide security. We also describe a few fa-
mous attacks and discuss how to protect your keys.
These real-world systems implement some or all of the cryptographic as-
surances we’ve been discussing since Chapter |: authentication, confidentiality,
integrity, and nonrepudiation. In addition, because all three systems encrypt the
majority of their data with a secret key, each includes (secret) key agreement or
key exchange.!
Although the three systems don’t implement the assurances and key ex-
change in the same order, they all follow roughly the path shown in Figure
PIV-1. Secure e-mail users can demand all the protections shown here, and,
with the exception of nonrepudiation, so can SSL and IPsec users.
Authentication
(Validate the other side)
Key Agreement / Exchange
(Agree on or exchange a secret key)
Confidentiality
(Exchange encrypted messages)
Integrity
(Proof message not modified)
Nonrepudiation
(Proof you got exactly what | sent)

Figure PIV-1 General flow and attributes of cryptographic systems, secure e-mail,
SSL, and IPsec.

1. In this text, key exchange means that Alice encrypts a secret key with Bob’s public key
and sends it to Bob. Key agreement means that Alice and Bob independently compute
the identical secret key using Diffie-Hellman. At times we also use key exchange more
broadly to apply to both situations.

203
204 PartIV ¢ Reat-Wortp Systems

E-mail Cryptographic Parameters

Alice’s e-mail messages to Bob usually go to Boh’s e-mail server and usually are
not sent directly to Bob’s computer. Bob can retrieve Alice’s e-mail after Alice
sends it, whether or not Alice is still connected to the Internet.
ee aaicencier Alice unilaterally chooses her cryptographic protections and parameters. So
unilaterally picks an e-mail receiver doesn’t negotiate cryptographic assurances or parameters
cryptographic with an e-mail sender; the receiver takes it or leaves it. For example, if Alice
assurances and encrypts e-mail with Triple DES, Bob’s computer must be able to decrypt
parameters. using Triple DES. This shouldn’t be a problem if both e-mail users are using
the same cryptographic program—for example, PGP.’

Negotiation of SSL and IPsec

Cryptographic Parameters
SSL and IPsec users |Unlike secure e-mail, SSL and IPsec assume that Alice’s and Bob’s computers
negotiate are connected to each other, and they allow Alice and Bob to negotiate which
cryptographic cryptographic assurances and parameters they want to use (see Figure PIV-1).
assurances and SSL assumes that a client and a server relationship exists between the two
parameters. parties: A customer (for example, Bob) wishes secure exchanges with some
merchant (for example, AliceDotComStocks). IPsec, on the other hand, treats
each end of the connection in the same way. Both SSL and IPsec first exchange
plaintext in which Bob sends a greeting to Alice and offers a variety of poten-
tial suites of cryptographic parameters from which Alice should choose (see
Figure PIV-2).
Overview of SSL SSL and IPsec can be roughly categorized as two-part systems, as shown in
and IPsec Table PIV-1. In part 1, both SSL and IPsec exchange plaintext messages, au-
thenticate each other, and agree on secret keys. In part 2 they use their agreed-

Hello, it’s Bob. Let’s talk with:

3DES, RSA, SHA-1 or DES, DSA, MD5, or...
Shee 8 SaaS
cae|
STS LCL OLLELE ON LL OE NEEL NEL TENT NTT

OK, let’s use DES, DSA, MD5.

Figure PIV-2 A first SSL or IPsec message.

2. But some older versions of aprogram (such as PGP) may be incompatible with newer
versions of the same program.
 User INITIATION OF CrypToGRAPHIC E-mail, SSL, AND IPsec 205

on secret keys to encrypt (decrypt) confidential messages with integrity. Both

SSL and IPsec offer assurances in many different ways; for example, depending
on the situation, secret key exchange may be completed before authentication.

Table PIV-1 General overview of IPsec and SSL as two-part systems. They first ex-
change plaintext messages, authenticate each other, and agree on secret keys; then
they use the secret keys to exchange confidential messages with integrity.

Part 1

Hello There Bob initiates an Internet connection with Alice

Authentication Bob challenges Alice: prove you have private key
Key exchange Exchange secret key
Part 2

Confidentiality Encryption using secret key cryptography

Integrity Detect whether confidential messages altered in transit

Note that neither SSL nor IPsec offers nonrepudiation.

User Initiation of Cryptographic E-mail, SSL,

and IPsec
Cryptographic e-mail applications and SSL require that the user explicitly in-
voke cryptographic protections. For example, as you'll see, an e-mail user must
select the option of encrypting his or her e-mail. Similarly, a user must invoke
Sol:
In contrast, IPsec provides its cryptographic protections by default and does
not require invocation by the user. In fact, IPsec is meant to be transparent to
the user, who may not be aware IPsec is even installed on the computer.
 : | — a va a
~~ ee hha —
ie

>
eee i nae yt eenenmeers:” 7
eat or ¥ eM Mae abi Oey ' live Whe =
eas wt {t brag aligoneTT To eT wateie pi _oe Am
Aud anally <bd
ee hy o-taerlh eBee Alig se
5 Bete in ale Freq ont al Ge EA
eau tgve /GwneiG. 1eeteBy,
eS panna ort “ies -W TESeh ¢ MMREEO aad ae IE), ed is wit ers. Sa
aaa GP) gae™, ip” pereanest i |
chads =
Nag: teat bal } ea Fi BoB aes WP
=<

; ; = @ J oramypyo 4 Gb

= = i ae 5 7 iy vite Ley
< 7 = q ; ‘ fimo 2) a)

MUAY Wh escoipe weuln Wiis) saad i qual

Crye UL at Xey Vin y. styl Lot] Ww

Dai ~~ Vi 1 ey air eri rl -

NeSwe ay, ae
siiaké 7 x 7 pene a r- 7 7

igri
<>.
Des ~

et ;
7 . 7 -
7 r
kare .
i. c
ies omy ily .oal fio) a coun
— >
Ee winepes
—
Wes 7 — ha ¥tid - -
eo .anet <
—
-
niviegy oud? aati?~ wivy tie
<a arieswit om
:
: 7
. 2 a ‘ aepeg C9 cil mo re ipa
Liye ; pchpaiieie i |) epee

: pS attaeiecdayi2 io ‘neiteizint itt)

7 CAUrtine,

gts: Poni - : « on ak REN ad

aett CPi
tertaiinas Gia:duitjee i ieae j _
: eatihie Ae aoe
i ¥ yes y toe ipa jbo
tinted

she ae ee caese Ll reall

“arGen! Nv «ex alle

Bi cae ig open dliyAl eailitgCony eh see Thpnes «if Siar” vs

tee ne Count pea) ae htt: cdgwars
ht ed Paar iiatuipyys Ong
saw oS Ag Me, yin Cae ania aels
7 > = ana

——- me
a
. 7 oe ae
ei.
; =
2 ap é or’ ae -

aa = . _
7

Big tin eA a
7 : a
 Chapter 19

Secure E-MAIL

MM e-mail products have cryptographic protection built in, and you can
also install your own cryptographic programs. For example, Microsoft
Outlook Express comes with S/MIME (Secure/Multipurpose Internet Mail
Extension) support. But because some copies of Outlook Express S/MIME
support only 512-bit public keys, some users might want to add PGP, which
supports longer public keys.
Check that your There are many e-mail application programs; each one differs at least
e-mail program slightly from the others. Just as each e-mail application has particular charac-
uses keys of the® teristics, each cryptographic e-mail add-on has particular characteristics. Each
appropriate lensth. secure e-mail program can offer unique choices for secret key methods, size of
secret key, and so on. For example, some secure e-mail programs offer only 40-
bit secret keys (recall that DES offers 56-bit keys).'

Generic Cryptographic E-mail Messages

Although there are differences among cryptographic e-mail add-ons, they all
share a common characteristic: There’s only a single message from e-mail
sender to receiver.
All the cryptographic assurances and parameters—as well as the e-mail text
itself—are contained within the one message. This is in contrast to SSL and
[IPsec (Chapters 20 and 21), in which sender and receiver exchange many mes-
sages just to establish cryptographic assurances and parameters.
In Figure 19-1, Alice prepares an e-mail for Bob including all possible
assurances.

1. By now, you realize that 40-bit keys aren’t particularly secure against a crypto-savvy
snoop.

207
208 CHAPTER 19 e ~=Secure E-MAIL

Generate one-time 1. Alice generates a secret key for one-time use. This kind of secret key is
secret key (session called a session key. (Most e-mail programs use secret key cryptography for
key) bulk data encryption. Recall that encryption with a secret key is much faster
than encryption with a public key.)
Encrypt e-mail with 2. Alice uses the session key to encrypt the e-mail. Many e-mail systems also
session key encrypt a timestamp with the e-mail signature to thwart replay attacks (see
Chapter 22).
Encrypt session key 3. Because Bob doesn’t have Alice’s newly created session (secret) key, Alice
with receiver's encrypts the session key with Bob’s public key. This is an example of secret
public key key exchange. (Encrypting a secret key with a public key is sometimes re-
ferred to as enveloping the session key.’)
Sign with sender’s 4. Alice signs a digest of the e-mail plaintext and the timestamp.
private key 5. Alice sends the e-mail package to Bob.

When Bob receives Alice’s e-mail, his private key decrypts the encrypted
session key, and the session key decrypts Alice’s encrypted message. Bob uses his
copy of Alice’s public key to verify Alice’s signed message digest.
Verifying the
As shown in Chapter 13, the message digest acts as a condensed, redundant
signed digest copy of the e-mail message. The e-mail and signed digest ensure that BlackHat
can’t alter the e-mail plaintext without being detected (it thereby ensures the
integrity of the message). When Bob verifies the signed digest (with Alice’s
public key), it also assures him of the authenticity (origin)* of the e-mail mes-
sage and provides nonrepudiation (Alice can’t deny signing the message).
A secure e-mail program should also give Bob the option to check whether
Alice’s digital certificate (and attached public key), used to verify her signed
message digest, has been revoked. Because checking certificate revocation can
be time-consuming, many e-mail programs allow the receiver to set whether
and when the program will automatically check revocation lists.

2. Obviously, Alice must have Bob’s public key. As discussed, digital certificates are the
preferred way to deliver public keys. Different e-mail programs provide different ways
to retrieve digital certificates. For example, S/MIME mostly uses X.509 digital cer-
tificates; PGP mostly uses PGP digital certificates. Fortunately, S/MIME, PGP, and
other e-mail vendors provide online (real-time) access to their subscribers’ certificates.
If Alice doesn’t already have a verified copy of Bob’s public key, she can get one from
an online server.
3. In cryptography lingo, the data origin.
 INVOKING CRYPTOGRAPHIC SERVICES 209

Generate Session Key

To Bob
From Alice,
i” {>
)
Confidentiality:
Plaintext e-mail message encrypted with
session key

a
« Bob
=
—— SrA

Secret Key Exchange:

Session key encrypted with Bob’s
RSA public key

From Alice

Authentication and Nonrepudiation:

Alice signs hash of message and timestamp

5. E-mail message sent to Bob

Figure 19-1 Alice prepares a secure e-mail message for Bob.

Invoking Cryptographic Services

Users must invoke Users of secure e-mail must invoke cryptographic services from most e-mail
cryptography packages; they are not automatic. Figure 19-2 shows a screen shot of S/MIME
and PGP services offered with Microsoft Outlook Express.
Although the top of Figure 19-2 shows that both S/MIME and PGP ser-
vices are available, none has been selected; the message will be sent as unsigned
plaintext, neither encrypted nor signed. At the bottom of Figure 19-2, PGP
encryption and signing are requested, so the message will be encrypted and
signed.
210 CuHapteR 19 @ Secure E-MAIL

> Cryptography Decrypted

Becneeng Br reg cE ch gy po oe RO ee Pe rene ey Po

encryption offered
Cr ;re reer Deel te
but none selected yptography Deciypted

rs Cryptography Decrypted

User must have

private key and
recipient’s public
key

Figure 19-2 Cryptographic services available in Microsoft Outlook Express. Top: No

cryptographic services invoked. Bottom: PGP encryption and signing services invoked.
 CONFIDENTIALITY AND AUTHENTICATION 211

Figure 19-3 Setting default cryptographic services.

Although the need to select cryptographic services may seem obvious, at

least one recent study of secure e-mail users found that many experienced
Internet users were not properly invoking e-mail cryptographic services. They
mistakenly believed that encryption and authentication are transparently and
automatically invoked just because cryptographic e-mail icons appear on the
menu bar.
Users can usually Most secure e-mail programs, such as those bundled with Microsoft prod-
set their software ucts or add-ons such as PGP, allow users to choose default settings. Figure
to default to 19-3 shows a screen shot in which encryption and signing have been set as de-
cryptographic fault parameters.
protections.

Confidentiality and Authentication

Confidentiality and authentication must be applied appropriately if a user of
secure e-mail is to achieve the desired cryptographic assurances.

Choosing Services
E-mail users must also know the difference between the encryption (confiden-
tiality) and signing (authenticity) options. Usually, any message that is encrypted
should also be signed. Encryption does not necessarily imply that the message
can’t be altered in transit.*

4. For an example, see Chapter 22.

212 CuHapter 19 @ Secure E-MAIL

Positioning Services
Some e-mail programs allow a user to choose the order in which confidential-
ity and authentication are invoked. The user can choose to first encrypt with
secret key and then sign with private key, or vice versa. There are significant
differences between these two approaches, and experts disagree on which is
more desirable.

Encrypt and Then Sign

A message using this option (top, Figure 19-4) allows the recipient, or anyone
else, to verify the signatures before decrypting the message. This option is useful
in automated verification systems; public keys perform the verification process,
and the encrypted message can be passed to some other service for decryption.
IPsec, discussed in Chapter 21 and Appendix B, encrypts and then signs.
IPsec uses the principle that it’s better to verify first so that unauthenticated
packets can be discarded before time is wasted on decryption.

Signed
Plaintext Secret Key Confidential Private Key See ad

cS
Confidential
Plaintext Private Key Signed ‘ecg Secret Key Signed

Figure 19-4 Comparing encryption and signing sequences. Top: encrypted and then
signed. Bottom: signed and then encrypted. For simplicity, hash is not shown.
 REVIEW 213

Sign and Then Encrypt

Some cryptographic experts recommend the use of this option (bottom, Figure
19-4). PGP and Secure Socket Layer (discussed in Chapter 20) sign and then
encrypt; they use the principle that the signature should be over plaintext be-
cause plaintext is the essence of the message.
Encryption after signing hides private key signatories. But the receiver must
first decrypt before authenticating and so can’t quickly discard forged packets.
This means that BlackHat can send forged packets to Bob, claiming they’re
from Alice. Bob must decrypt each one before any of them fails authentication.

Deterring E-mail Viruses

Signing deters If you accept only signed e-mails, it’s much more difficult for BlackHat to vio-
viruses late your computer. A signed e-mail is verified before most viruses can take
control. If BlackHat intercepts Alice’s e-mail to Bob and substitutes his forged
e-mail, it will fail authentication when Bob verifies it with his trusted copy of
Alice’s public key. The forged e-mail will not get the chance to launch its de-
structive payload because it’s simply dropped or quarantined.
Of course, if BlackHat can alter the cryptographic verification program or
substitute a forged copy of Alice’s public key, he can violate the authenticity
check and fool Bob into accepting his e-mail.

Review
There are many secure e-mail packages, each with its own characteristics. Each
can offer various choices for secret key methods, public key methods, message
digest methods, and so on.
In general, secure mail encryption follows this pattern:

ak ° Alice generates a session (secret) key.

2. She encrypts the plaintext message with the secret key (to ensure
confidentiality).
3. She encrypts the session key with Bob’s public key (key distribution).
4. She signs a hash of the message and timestamp (to ensure authentication,
integrity, and nonrepudiation).
5. She sends the secret key encrypted message, the public key encrypted ses-
sion key, and the signed hash to Bob.
214 CHAPTER 19 e Secure E-MAIL

Most secure e-mail packages require that the sender invoke encryption,
either by setting the program’s default to automatic encryption or by selecting
encryption and signing each time e-mail is sent. Knowing the difference be-
tween encryption and signing and the assurances provided by each method can
help users to make appropriate choices when encrypting e-mail messages.
 Chapter 20

SECURE SOCKET LAYER AND

TRANSPORT LAYER SECURITY

f you’ve used your credit card over the Internet, you’ve probably used Secure
Socket Layer (SSL). Its main purpose is to make e-commerce users feel se-
cure about sending their financial information over the Internet.' SSL seems to
complete the transaction quickly, and much of what goes on in that short time
is transparent to the user.
SSL is a data communication protocol (set of agreed on procedures) that
implements three cryptographic assurances—authentication, confidentiality,
and message integrity—and provides secure key exchange between an Internet
browser and an Internet server. Note that SSL does not offer nonrepudiation.
Padlock ‘To notify users that they’re using SSL, current versions of the Netscape and
symbolizes SSL Microsoft Internet browsers display a small padlock (see Figure 20-1). Older
session versions of Netscape display a blue border around the browser window.

Internet Browser

www. DigitalCertificatesIinc.com

Digital Certificates Inc.

(our trust transferred to you)
1 year registration fee ... $14.95

—Please submit name and credit card number—

Name: HxMel
Card #: 1874-0637-4212-0130

Secure Socket Layer —=—>

Figure 20-1 The SSL symbol is shown in a typical browser window.

1. SSL is also infrequently used for e-mail, ftp (file transfer protocol), VPN, and so on.

215
216 CHapteR 20 e Secure Socket LayeR AND TRANSPORT LAYER SECURITY

History of SSL
Netscape developed SSL in 1994 and released version 2 in early 1995. By that
time, William Gates, Jr.,understood the importance of the Internet and quickly
developed and released a competing Microsoft product called Private Commu-
nicating Technology (PCT); it briefly competed with SSL. Media attention to
SSL bugs and PCT forced Netscape to release SSL version 3 (SSL v3) in 1995.
PCT is seldom used anymore.
IETF set standard In 1996 the Internet Engineering Task Force (IETF) formed a committee,
the Transport Layer Security (TLS) working group, to develop and publish an
SSL standard. In January 1999, the TLS working group published the TLS
protocol, which was based on SSL v3. Both Microsoft and Netscape support
TLS. Interestingly, Microsoft implemented TLS in its browser before Netscape
did.
SSL comes first in the title of this chapter because, as we’re writing this
book, more people have heard of it than TLS. The differences between SSL v3
and TLS version | are minor. Almost everything in this chapter is applicable to
SSL v3 as well as TLS. At the end of the chapter we note some differences.

Overview of an SSL Session

Figure 20-2 shows the symbols used in this chapter.
Figure 20-3 presents an overview of an SSL/TLS session. (More SSL/TLS
details follow in the next section.)
SSL/TLS allows two Negotiating cryptographic parameters between two computers that prob-
computers to ably don’t know each other’s cryptographic capabilities is the first thing SSL/
negotiate TLS participants must do. (SSL/TLS accommodates a variety of cryptographic
cryptographic choices from which the client and server may choose.) Then Bob uses Alice’s
parameters. public key to send her a secret. They use the secret to independently make the
identical secret key. Next, in our example, Bob authenticates Alice, a server
merchant, but Alice does not authenticate him. Note that because SSL/TLS
uses the agreed-on secret key for authentication, Alice and Bob agree on a se-
cret key before authentication. Finally, they use the secret key to exchange
messages.
 Overview OF AN SSL SESSION 217

Qe ie
Private Key Plaintext

a |

bob Signed Message

|

Public Key (Private Key

Encrypted)

Random Number
Q-m Confidential Message
Secret Key (Public or Secret Key
(also Random
Number Generator) Encrypted)

Hash Function
Digital Certificate

Compression
Timestamp like PKZip
Root Certificate

Figure 20-2 These symbols are used to represent the concepts discussed in this
chapter.
218 CHapter 20 © Secure Socket LAyeR AND TRANSPORT LAYER SECURITY

Overview of SSL/TLS Session

(Alice a server...Bob a client)

(and negotiate crypto parameters)

Bob:
a Alice. Let’s talk. ‘Send me your
public key.

Alice:
Sends Bob her digital cer d)

KEY AGREEMENT

Alice & Bob

e Use random number to independently Sf
6 generate shared secret keys. 0

BOB AUTHENTICATES ALICE

CONFIDENTIALITY AND INTEGRITY

Alice & Bob

Figure 20-3 Overview of an SSL/TLS session. Bob, a customer, authenticates Alice,

a merchant.

An SSL Session in Detail

Let’s watch as Bob, an Internet customer using his browser, connects to an
Internet server and merchant, AliceDotComStocks. (We’ll abbreviate
AliceDotComStocks as Alice unless we feel it’s worth reinforcing that Alice is
the merchant server.) Although SSL/TLS can accommodate many different
 AN SSL Session IN DETAIL 219

cryptographic variations, for simplicity we show only one cryptographic varia-

tion in the following example.

Hello and Negotiate Parameters

Bob, the client, In Figure 20-4, Bob sends a plaintext message Hello and suggests some param-
initiates contact eters for their conversation. Bob also sends Alice an alternative in case she can’t
and suggests some accommodate his first suggestion. For example, if Alice can’t do TLS, Bob of-
cryptographic fers her the option SSL v3. Although we’re showing only one alternative, Bob
parameters. may include many possible alternatives.
Alice responds. Alice responds with her choice of cryptographic parameters. In Figure 20-5,
Definition: Cipher Alice agrees with all of Bob’s suggestions except that she requests DES instead
suite of Triple DES. Alice and Bob agree to converse using RSA for key exchange,
HELLO
Can we talk with:

Version:
TLS version 1 if you can, else SSL v3
Key Exchange:
RSA if you can, else Diffie-Hellman
Secret Key Cipher Method:
TripleDES if you can, else DES
Message Digest:
SHA-1 if you can, else MD5
Data Compression Method:
PKZip if you can, else gzip
Random #:
196,201,083

Figure 20-4 Bob sends Hello and suggests parameters.

-— HELLO YOURSELF
| hear you. Let’s talk with:

TLS version 1
Key Exchange:
RSA
Secret Key Cipher Method:
DES
Message Digest:
SHA-1
Data Compression Method:
PKZip
Random #:
823,495,127

Figure 20-5 Alice responds.

220 CHaptTerR 20 @ Secure Socket LAYER AND TRANSPORT LAYER SECURITY

DES for bulk data encryption, and SHA-1 for message digesting. They also
agree on a data compression method.’ Put together, all these agreements are
called a cipher suite. (It’s not likely that Alice couldn’t accommodate Triple DES;
we’re showing it simply as an example of an alternative option. Rijndael isn’t
offered because it’s still too new.)

Exchanging Digital Certificates

SSL allows the After responding to Bob’s He11o, Alice sends Bob her digital certificate.’
client to In our example, a trusted root CA signed Alice’s certificate. Bob uses his
authenticate the trusted copy of that particular root CA’s public key to verify Alice’s certificate
server. Bobo and enclosed public key (see Figure 20-6). Recall from Chapter 17 that Internet
authenticates Alice. browsers install trusted CA certificates (public keys).
Only if Alice sends her digital certificate to Bob does SSL/TLS permit her
to request Bob’s certificate. She’s not required to request Bob’s certificate, and
even if she does request it, he need not comply. Later in the chapter we show
why.

Internet
Browser

Figure 20-6 Alice sends her digital certificate. Bob uses the trusted CA certificate to
verify Alice’s digital certificate (her public key).

2. A compression program that also decompresses data, such as PKZip, WinZip, gzip,
or Stuffit.
3. And any other digital certificates Bob needs to build a digital certificate chain to
Alice’s digital certificate.
 AN SSL Session IN DETAIL 221

Key Agreement (Exchange)

Definition: pre- Bob generates a 48-byte random value called a pre-master secret (see Figure
master secret 20-7). He encrypts it with Alice’s public RSA key and sends it to her. Then Alice
decrypts the pre-master secret with her matching private RSA key.
So far, our examples of secret key exchange have indicated that two people
need share only one secret key. Real-world systems prefer to use more secret
keys to thwart cryptanalysis. In SSL/TLS each end of the connection (Alice and
Bob) generates six secret keys.
SSL/TLS uses six Alice generates three secret keys for Alice-to-Bob messages, shown on the
separate secret left in Figure 20-8. The first key (such as a DES secret key) is for encryption,
keys. the second key is for the message integrity (HMAC), and the third key is used
to initialize the cipher (IV).* Note that these keys are used only for messages
Alice sends to Bob and not for messages Bob sends to Alice. Alice generates and
uses three additional keys for Bob-to-Alice messages. Similarly, because Bob
must generate exactly the same keys as Alice, he generates three secret keys for
Alice-to-Bob messages and three keys for Bob-to-Alice messages, shown on the
right in Figure 20-8.
It’s not important for our discussion, but if you’re interested, later in the
chapter you'll find additional specifics on how the six shared SSL/TLS secret
values are generated.

Figure 20-7 Bob generates a 48-byte random number called a pre-master secret. He
encrypts it with Alice’s public key and sends it to her.

4. Think of cipher initialization as random plaintext that primes the cipher pump. In
cryptographic literature it’s often abbreviated IV.
222 Cuapter 20 e Secure Socket LAYER AND TRANSPORT LAYER SECURITY

Alice Bob to Alice Bob to

to Bob Alice to Bob Alice

Secret Omm Orr > Om canal Secret

/ i i

v Orn Orr pa Yom

leaks
Figure 20-8 Alice’s and Bob’s identical shared secret keys.

Authentication
AliceDotComStocks It is at this point that you might expect Alice to authenticate Bob, but in our
(the server example she doesn’t. How can Bob get away without being authenticated?
merchant) doesn’t There are two major reasons.
always authenticate First, Alice will check that Bob’s credit card (you know she’ll ask for it soon)
Bob (the client). hasn’t been invalidated by the credit card company, and that’s all the authenti-
cation she currently needs. Also, it takes time for her to authenticate Bob, and
she doesn’t want an impatient Internet customer to click off her site and can-
cel the sale.
Second, most e-commerce clients don’t yet have digital certificates, and
e-commerce merchants are currently assuming the risk entailed. However, Alice
and other e-commerce merchants probably won’t assume this risk much longer
as they get stung by Internet con artists. If you’re interested, at the end of the
chapter you'll find more specifics on how Alice can authenticate Bob.
Bob authenticates Bob sends Alice a message encrypted with their shared secret keys. This
that Alice has message, called a finished handshake message, is the first message encrypted with
independently the secret keys Bob and Alice independently generated during the key agree-
calculated the ment phase.
identical secret Alice responds to Bob with her own encrypted finished handshake message.
keys. Bob is now assured that he must be communicating with Alice because Bob sent
the pre-master secret encrypted with Alice’s public RSA key (Figure 20-7). Only
Alice could have decrypted the pre-master secret used to calculate the six shared
secret keys.
Alice and Bob can now begin to use their six shared secrets for bulk data
encryption, such as ordering merchandise with a credit card or insurance forms.
 AN SSL Session IN DETAIL 223

Confidentiality and Integrity

Figure 20-9 shows the general steps Alice takes to prepare an SSL/TLS secure
message using the agreed-on cipher suite and secret keys.’

1. She compresses the message using the agreed compression method.

2. She hashes the compressed data and her secret HMAC key to make an
HMAC.
3. She encrypts the combination of compressed data and HMAC with her
Alice-to-Bob DES key.

Recall that the HMAC secret key is different from the DES encryption
secret key.
Bob receives the SSL/TLS encrypted message and reverses the process, as
shown in Figure 20-10.

DOS LOLOL GOT GEESE OOO gps

es aaa aparece
a ase AES ES
q
ashe
E E
rat

1. Compress
DLL ALAA a
ETI
ALAIN
Ss
Scosamauanenmunenaneamrmr
saree eRe RRR NTN
2. Hash eeeonarnae
YEE
Re
US
Seven Soe
STAN ENONOO AUNENOT
3. Encrypt
| LLY
GEE
EOE
EEE
OED
E
OEE

Figure 20-9 Alice prepares an encrypted message for transport.

ELL EEL ALDARA LLE EL LADLE LEE EEELED DLE PoSo ce ss nr 6 en ee a:

RIIITIS
NOUN
INTO
SONINO

i:
1. Decrypt / 2. Authenticate wf
EU
SSO
3. Decompress |
y
SSCs
ACAI ULLL EEE LEO DEOLUSEOBE EOE GOEL EEL LEE LED ELE LLL LLL LE LI ES j
LATERAL
ORAS SA
LEO
ISL
Natt
aEE
SR

Figure 20-10 Bob verifies and recovers a message from Alice.

5. In this overview, we omit some details such as data fragmentation and padding.
224 CHAPTER 20 © Secure Socket LAYER AND TRANSPORT LAYER SECURITY

1. He decrypts the combination of compressed data and HMAC with his copy
of Alice-to-Bob DES key.
2. He authenticates the message in two steps. First, he hashes the decrypted
compressed data and secret HMAC key. Then he compares (see the sym-
bol “= 2”) the HMAC from step | to the HMAC from this newest hash.
2. He decompresses® and recovers the plaintext message.

TLS Variations
The preceding example shows Bob encrypting a random number, the pre-mas-
ter secret, using Alice’s public RSA key. After Alice decrypts it with her private
RSA key only Alice and Bob know the pre-master secret used to generate the
six shared secret keys.
SSL/TLS can also use Diffie-Hellman (see Chapter 10 and Appendix A) to
independently create the shared pre-master secret key and six shared secret keys
shown in Figure 20-8. One of the Diffie-Hellman variations doesn’t support
authentication.

Anonymous Diffie-Hellman
Anonymous Diffie- One variation, called Anonymous Diffie-Hellman, allows Alice and Bob to si-
Hellman doesn’t multaneously generate six shared secrets without either one authenticating the
authenticate Bob or other. But then neither Bob nor Alice is certain who is on the other side of the
Alice. connection. Why would anyone use this approach?
As we said, AliceDotComStocks is often satisfied with receiving a credit
card number and is willing to assume any risks entailed in someone else’s use of
Bob’s credit card without Bob’s authorization.
What about Bob? Bob can decide to trust that he has downloaded the au-
thentic AliceDotComStocks Web page and associated forms. Perhaps it’s not a
big risk. People often give their credit card numbers to strangers on the tele-
phone, in restaurants, and so on. Should you reveal your credit card number this
way? Well, most of us do, and not enough of us have had problems with this to
stop using credit cards in this way. But if you’re sending something very valu-
able over the Internet—such as the password to your bank account or personal
financial or health records—it’s not a good idea to trust Anonymous Diffie-
Hellman key agreement.

6. Remember, compression means using a compression-decompression method such as

PKZip, WinZip, or StuffIt. Don’t confuse this with HMAC, which does not
decompress.
 ComparinG TLS, SSL v3, aNp SSL v2 225

Fixed and Ephemeral Diffie-Hellman

Fixed and Both of these Diffie-Hellman variations support authentication. In Fixed (or
Ephemeral Diffie- static) Diffie-Hellman, Alice and Bob exchange their public Diffie-Hellman
Hellman support values using trusted digital certificates. In Ephemeral Diffie-Hellman, Alice and
authentication Bob exchange their public Diffie-Hellman values signed with RSA or DSA keys.

Comparing TLS, SSL v3, and SSL v2

SSL v3 and TLS are The TLS standard says that “TLS version 1.0 and SSL v3 are very similar, [and]
almost identical thus, supporting both is easy.” Some of the differences include minor changes
in HMAC calculations, cipher suite support, and pseudo-random number cal-
culations. You can think of TLS as “SSL v3.1.”
SSL v3 and SSL v2 The differences between SSL v3 and SSL v2, however, are more pro-
are very different. nounced. No one who has access to SSL v3 should use SSL v2. Arguably, us-
ers should turn off support for SSL v2 in their Internet browsers.

A Big Problem with SSL v2

Because of the way SSL v2 negotiates the cipher suite, BlackHat can convince
Alice and Bob to use much weaker encryption than they are capable of using.
This is called a cipher suite rollback attack. For example, even though Alice and
Bob can do Triple DES (i.e., 168-bit encryption), BlackHat can attack their SSL
v2 cipher suite negotiations and convince them to use something much weaker,
such as 40-bit encryption.

A Possible Problem with TLS and SSL

The danger of No version of TLS or SSL protects against traffic analysis. A cryptanalyst doing
traffic analysis traffic analysis watches the number of messages sent from and to a particular
Internet address. Although the analyst may not know what’s inside each mes-
sage, it’s possible that the knowledge of heavier-than-usual message traffic be-
tween two addresses can be, by itself, useful information. For example, a heavy
exchange of messages between legal offices in separate cities might signal inten-
tions that an adversary could use to his or her advantage.
The threat posed by BlackHat’s use of traffic analysis probably doesn’t af-
fect most Internet users. Nevertheless, it’s a serious enough concern that Chap-
ter 21 shows a way to limit the damage from traffic analysis.’ SSL and TLS can’t.

7. Supplemental tech note: TLS (and SSL) are above the TCP/IP layer in the proto-
col stack. There’s no way they can hide the address and port ofthe source and desti-
nation addresses.
226 CHAPTER 20 e Secure Socket LAYER AND TRANSPORT LAYER SECURITY

Generating Shared Secrets

Definition: master As promised earlier in this chapter, this section describes some of the steps that
secret occur after Bob sends Alice the pre-master secret. Alice and Bob use the pre-
master secret, the random values they exchanged in the Hello messages, and
a pseudo-random function (PRF) to independently and simultaneously gener-
ate a master secret.
The PREF is very similar to a message digest function run many times; it
adds enough uncertainty to the generation of secrets that it makes replication
by an attacker infeasible. After completing two rounds of PREF, Alice and Bob
have independently generated six equivalent secrets, as shown in Figure 20-11.
Use both SHA-1 The PRF uses two different message digest functions because, as stated in
and MD5 for the IETF TLS standard document, “In order to make the PREF as secure as
added security. possible, it uses two hash algorithms in a way which should guarantee its secu-
rity if either algorithm remains secure.” This means that two different message
digest methods are used in case BlackHat cracks one of them; the other hash
function, which presumably is secure, ensures that BlackHat can’t generate the
same secrets generated by Alice and Bob.
After generating the six shared secrets, the pre-master secret is no longer
needed and should, for security reasons, be deleted.

Six shared
secrets

Figure 20-11 Alice and Bob use the pre-master secret, pseudo-random numbers,
and pseudo-random functions to produce six shared secret values. Presumably, an
attacker can’t imitate their process.
¥
 Review 227

Bob Authenticates Himself to

AliceDotComStocks
If AliceDotComStocks wants to authenticate Bob, she requests his digital cer-
tificate after she sends hers to him. We’ll pick up the action after Bob sends Alice
the pre-master secret and his digital certificate containing his RSA public key.
Bob uses RSA to Bob authenticates himself to Alice by verifying that he has the private RSA
authenticate key that matches the public RSA key on the digital certificate he just sent Alice.
himself to Alice. Bob digests a combination of the master secret and some previous messages. He
Definition: then signs the digest (encrypts it with his private RSA key) and sends it to Alice.
certificate verify The message Bob sends to Alice (shown in Figure 20-12) is called a certificate
message verify message.
Alice verifies the certificate verify message with her copy of Bob’s public
RSA key. She trusts that she must be communicating with the owner of Bob’s
private key and the person who knows their shared master secret—Bob.
Message digest It’s instructive and reinforcing to note that even though BlackHat can also
assurance in action decrypt this message with Bob’s public key, he can’t recover Alice and Bob’s
e master secret because Bob digests the master secret before he signs it. Recall that
a secure message digesting function, such as MDS or SHA-1, implements one-
way assurance (see Chapter 14). One-way assurance (and a sufficiently long
master secret) prevents BlackHat from “going backward” to the master secret.

Handshake
Messages
+

Master Secret

Figure 20-12 Bob authenticates himself to Alice.

Review
Secure Socket Layer (SSL) and the newer standard ‘Transport Layer Security
(TLS) are used to securely send information over the Internet, and the two stan-
dards are very similar. Both are designed to negotiate cryptographic parameters
between two computers. SSL/TLS implements three cryptographic
228 Cuapter 20 © Secure Socket LAYER AND TRANSPORT LAYER SECURITY

assurances—authentication, confidentiality, and message integrity—and pro-

vides secure key exchange between an Internet browser and an Internet server.
SSL/TLS goes through the following steps to complete a secure transac-
tion: negotiating parameters, exchanging digital certificates, secret key agree-
ment (exchange), authentication, and bulk data encryption (confidentiality and
message integrity).
 Chapter 21

IPsec OvervIEW

C ompanies (or anyone) exchanging electronic data between the home office
and field offices want secure communication assurances. Leased lines, dedi-
cated to the lessor, provide secure communications, but this approach is too ex-
pensive and much less flexible than Internet communications. A virtual private
network (VPN) based on Internet Protocol Security (IPsec) is the current com-
mercial choice for secure Internet communications.
Internet security Is Business to business (B2B) electronic communication is becoming a neces-
driving IPsec. sity for companies’ survival. For example, some hospitals permit their suppliers
access to their network and internal databases. The supplier queries the hospital
database to analyze levels of supplies and then is able to deliver those supplies
that are needed. Obviously, this arrangement is efficient. But the hospital needs
to protect some parts of its internal network, such as patients’ medical records.
Similarly, computer road warriors want assurances that when they log on to a
home office computer server from a hotel room, all the data they exchange with
the home office is secure.
In the not-too-distant future, it’s predicted that most Internet users will
control their bank accounts, health insurance, and perhaps even home appli-
ances through the Internet.

Enhanced Security
IPsec can IPsec (sometimes spelled IPSec) offers authentication, confidentiality, integrity,
authenticate any access control, protection against replay attacks, and limited protection against
data packet that traffic flow analysis. In brief, an [Psec-enabled computer can authenticate any
enters and encrypt data packet that enters and encrypt any data packet that leaves.
any data packet In Chapter 20 you saw how Alice and Bob use SSL/TLS to secure Internet
that leaves. transactions. Secure e-mail and SSL/TLS are application programs, and they
usually require that the user request cryptographic services; the use of cryptog-
raphy is not automatically the default.

229
230 CHAPTER 21 e IPsec Overview

IPsec is completely IPsec, in contrast, operates under the application level, transparent to the
transparent to the user. It empowers an IPsec administrator' to provide cryptographic protections
user. to all incoming and outgoing Internet data transfers. This means that an IPsec-
enabled computer automatically protects e-mail, Web browsing, file transfers—
any electronic communication between itself and another [Psec-enabled
computer. [Psec automatically negotiates cryptographic protections with an-
other [Psec-enabled computer that has acceptable credentials. If the other com-
puter is not [Psec-enabled, IPsec can allow or disallow communication in a way
that’s transparent to the user. Microsoft has already embedded many IPsec fea-
tures into Windows 2000.
IPsec negotiations Another significant IPsec security feature is that cryptographic protections,
are secret. such as the choice of cipher method, can be secretly negotiated. In contrast,
SSL/TLS protections are negotiated with plaintext messages. (In Chapter 20,
Bob sends a plaintext message to Alice suggesting a cipher method; Alice re-
sponds with a plaintext message.) .
In this chapter we present an overview of IPsec and explain some of the
benefits it offers to HxMel employee Bob as he connects through the Internet
to Alice at AliceDotComStocks.” *
As we discuss IPsec in this chapter, we use the symbols shown in Figure 21-1.

Key Management
IPsec-compliant systems* must support manual distribution and automated
negotiation of secret keys.

1. Or knowledgeable user.
2. Asin Chapter 20, where appropriate we’ll abbreviate Alice DotComStocks as Alice.
3. ‘Technical Note: SSL and TLS are implemented above the transport layer at the ap-
plication layer. IPsec, in contrast, is implemented below the transport layer. The
base standards document suggests three ways to implement IPsec:
1. Integration into Internet Protocol (IP); changes to the IP source code are
required.
2. Under IP, between IP and native drivers; no changes to IP source code are
required. This is referred to as a bump in the IP stack (BITS).
3. Outboard crypto processor, referred to as bump in the wire (BITW).
In any case, applications don’t need to know it’s there.
4. That is, [Psec-compliant systems that follow the IETF standards.
 Key MANAGEMENT 231

PlainText
Oot
Secret Key

Confidentiality Message Integrity

(Secret Key Encryption)

Figure 21-1 Symbols used in this chapter.

Manual Distribution
Manual distribution means that a controlling authority acts as a key distribution
center (KDC, discussed in Chapter 8) and manually distributes secret keys.
Although manual distribution is the simplest form of key management, it has the
same problems as a KDC—for example, difficulty in changing secret keys.
Manual key distribution is suitable for small IPsec installations.

Automated Distribution
Automated key management is required for any system except a small user
group. Automated negotiation makes and distributes secret keys as needed; ar-
guably, it’s the most complex and controversial part of IPsec. In addition, auto-
mated key management provides protections not available in manual
management—for example, anti-replay protection. In the following overview of
user authentication and key agreement, we examine IPsec’s default automated
key management system.
IPsec splits into
In this overview, we treat IPsec as consisting of two parts (see Figure 21-2).
two parts: key In the first part, Alice and Bob negotiate cryptographic parameters and assur-
management and ances, complete authentication, and agree on shared secret keys. The second
bulk data part provides bulk data encryption confidentiality and message integrity.
encryption.
232 CHAPTER 21 e IPsec Overview

User Authentication “ Bulk Encryption and

and Key Exchange Message Integrity

Figure 21-2 |Psec overview. Portions of part 1 communications are completed with
plaintext messages; part 2 communications consist entirely of encrypted transmissions.

IPsec Part 1: User Authentication and Key

Exchange Using IKE
Although the IPsec standard allows more than one automated key management
technique, Internet Key Exchange (IKE) is the default IPsec key exchange pro-
tocol. Most IPsec vendors have implemented a version of IKE in their products.

SSL/TLS and IPsec Key Agreement

SSL has one set of In SSL/TLS, Alice and Bob exchange one secret and negotiate one set of cryp-
parameters, one tographic parameters. Cryptographic parameters include choices such as bulk
secret exchange in encryption method and message digest method. SSL/TLS parameter negotia-
one phase. IKE has tions are completed with one round-trip message: one message from Bob to
two sets of Alice and one message from Alice to Bob.
parameters, two
IKE is more complicated than SSL/TLS key management. In IKE, Alice
secret exchanges In
and Bob exchange two secrets and negotiate two sets of cryptographic param-
two phases.
eters; each secret is associated with a set of parameters. You’ll see how, compared
with a single key exchange and a single set of cryptographic parameters, the use
of two secret key exchanges and two sets of cryptographic parameters adds se-
curity and speed.

Security Association
Definition: security One secret key together with one set of cryptographic parameters is called a
association (SA) security association (SA). SAs are very similar to SSL/TLS cipher suites (discussed
in Chapter 20); SAs contain shared secret keys, the names of cryptographic
methods that Alice and Bob use for encryption and authentication, and other
parameters.
 IPsec Part 1: User AUTHENTICATION AND Key EXCHANGE Usine IKE 233

Phases
IKE has two phases. IKE establishes two SAs in two-phase negotiations between Alice and Bob (see
Each phase makes Figure 21-3). Phase 1 exchanges are mostly plaintext (unencrypted) messages.
an SA. Phase 2 exchanges are all encrypted messages. Phase 1 makes SA-1; phase 2
makes SA-2. SA-1 parameters are used to encrypt and authenticate phase 2
messages. SA-2 parameters are used to encrypt and/or authenticate all part 2
(bulk data encryption) messages.

Phase 1: Key Agreement and Authentication

As with SSL/TLS, at the start of IKE phase 1 Alice and Bob must communi-
cate without encryption because they haven’t agreed on cryptographic param-
eters and cryptographic keys. So IKE phase 1 consists mostly of plaintext
message exchanges to negotiate cryptographic parameters and shared secret
keys (see Figure 21-4).
IKE uses Diffie- In phase 1, shared secret keys are established using Diffie-Hellman key
Hellman key agreement (see Chapter 10 and Appendix A); Bob authenticates Alice and vice
agreement. versa. Phase 1 can complete with three messages (aggressive mode) or six mes-
sages (main mode). Using three messages completes faster, but using six mes-
sages offers additional features, such as some denial of service protection.’
Phase 1 makes an At the completion of phase 1, Alice and Bob have set up an authenticated
authenticated secure channel between them. With their first shared secret they derive three
secure channel secrets: an encryption key, an authentication key, and an additional secret value.
between Alice and The keys are used to encrypt and authenticate all the phase 2 messages; the
Bob. additional shared secret value is used to derive the second set of secret keys.

IKE
Authentication - Bulk Encryption and :
and Key Exchange | Message Integrity |

Phase 1 od
(mostly unencrypted)

Caer:
f (encrypted)

Figure 21-3 IPsec showing IKE phases.

5. See “Clogging Attack” in Appendix B.

234 CHAPTER 21 e |Psec Overview

Part 1 User Authentication and Key Excahnge

Using IKE

Phase 1
Message
, Integrity ©

DES, MDS,

Messages Encrypted
with SA-1

SA-2
Agreed Params
Twofish, SH
Ea

Twofish, SHA, Max

| Authentication, ... or |

Figure 21-4 IKE phase 1 and phase 2 negotiations. In phase 1 they agree to use the
parameters in SA-1 (Triple DES, SHA-1, ...). All phase 2 negotiations are secured with
SA-1 parameters. In phase 2 they agree on SA-2 (Twofish, SHA-1, ...). SA-2 param-
eters are used in IPsec part 2.

Phase 2: Setting Up Bulk Encryption Parameters

Definition: quick All phase 2 messages are encrypted and authenticated with the SA-1 crypto-
mode graphic methods and shared secret key. Phase 2 always completes in three mes-
sages. Phase 2 doesn’t have any time-consuming public key operations and
quickly completes; it is called quick mode. In phase 2, Alice and Bob negotiate
cryptographic parameters used for bulk data encryption and calculate their sec-
ond set of shared secret keys (see Figure 21-4).
The second set of shared secret keys is calculated from the additional secret
value made in phase | along with new random numbers Alice and Bob inject
into the process.
 IPsec Part 1: User AUTHENTICATION AND Key ExcHANGE Usine IKE 235

IKE Nomenclature
Definitions: IKE-SA, As mentioned earlier, in each of IKE’s two phases Alice and Bob negotiate and
IPsec-SA agree on an SA. We took some liberty and renamed the SAs. The first SA ne-
gotiated in IKE phase | is actually called IKE SA (our SA-1). Then IKE phase
2 actually produces IPsec SA (our SA-2). Because IPsec is used to name the
whole process and IKE is the name of the key exchange protocol, the names
IKE SA and IPsec SA can be confusing. So for simplicity, we continue to refer
to the IKE SA as SA-1 and the IPsec SA as SA-2 (see Table 21-1). As far as we
know, these names are used only in this book.

Benefits of Two-Phase Key Exchange

IPsec’s two-phase key exchange is designed to negotiate new bulk encryption
keys quickly and securely as well as facilitate changes in bulk encryption
methods.

Changing Bulk Data Encryption Keys

Be ee

Secret keys age Secret keys age; each time they’re used, BlackHat gets more clues to use for
(they get used up). cryptanalysis. After a while, you should replace old secret keys with new ones.
If either Alice or Bob decides that a shared secret key is no longer secure,
two-phase key exchange allows them to securely and quickly change the secret
key by performing another phase 2 (quick mode) exchange and making a new

Phase 2 can be Phase 2 is fast because it uses secret key encryption rather than public key
used to quickly encryption. As noted in previous chapters, secret key encryption is much faster
negotiate new than (and is as secure as) public key encryption. Appendix B has more on IKE
secret keys. phases and options.
It’s so fast and easy to share a new SA-2 that a new SA-2 is given a /ifetime,
Definition: SA
lifetime
expressed either as a given amount of time or as a given amount of plaintext
encrypted. After its lifetime expires, Alice’s and Bob’s computers make and share

Table 21-1 Simplification of IKE nomenclature in this book.

Conventional IKE Names Names Used in This Book

IKE SA SA-1

IPsec SA SA-2
236 CHAPTER 21 e |Psec Overview

a new SA-2. IPsec handles this automatically; Alice and Bob may not even know
it’s happening. In contrast, SSL/TLS uses much slower public key encryption
to agree on a new bulk data secret key. Of course, if the secret key Alice and Bob
agree on in IPsec phase | is compromised, they must also begin a new phase 1.°

Creating Bulk Encryption Keys for

Separate Applications
Another benefit of two-phase exchange is that you can use a single SA-1 to cre-
ate many SA-2s. For example, Figure 21-5 shows Alice and Bob using their SA-1
to create an SA-2 for encrypting database files and another SA-2 for encrypt-
ing e-mail files. Note that the “database” SA-2 uses different cryptographic
parameters from those of the “e-mail” SA-2.

IPsec Part I:

Phase 1 :
makes SA-1 SA-1:; TripleDES, MD5, mye

IPsec Part Il:

Bulk E-mail files encrypted

encryption with SA-2 for E-mail
using two
different
SA-Qs

Figure 21-5 IKE can create many SA-9s. Here, IKE creates two SA-9s, one for each
separate application. Note that each SA-2 has different parameters and keys.

6. After an agreed-on time period, phase | keys also expire and must be renegotiated.
 IPsec Part 2: Buk DATA CONFIDENTIALITY AND INTEGRITY FOR MESSAGE OR FILE TRANSPORT 237

IPsec Part 2: Bulk Data Confidentiality and

Integrity for Message or File Transport
In IPsec part 2, Alice and Bob exchange encrypted messages using the param-
eters and secret keys (SA-2) made in IKE phase 2. After Alice and Bob agree on
SA-2, IKE hibernates until another key negotiation or new cryptographic pa-
rameters are needed. Figure 21-6 shows some of [Psec’s bulk data encryption
features.
A particular SA-2 is IPsec requires that an SA-2 be used in only one direction: either for in-
used only for bound or outbound messages an d not both. This means that IPsec requires
indound or Alice to have an SA-2 that is used only for her outbound messages. Bob’s in-
outbound bound SA-2 must have the identical cryptographic parameters and keys so that
messages andnot —_—he can decrypt Alice’s messages. Similarly, IPsec requires Bob to have an SA-2
both. that is used only for his outbound messages; and again, Alice’s inbound SA-2
must have the identical copy of his cryptographic parameters and keys so that
she can decrypt his messages.’
In Figure 21-7, Alice’s outbound cryptographic parameters and keys are
equivalent to Bob’s inbound and vice versa. Although, in our example, the only
differences between Alice’s inbound and outbound SAs are the secret keys, IPsec
allows more options. For example, although Alice’s outbound traffic used DES,
in theory Bob’s outbound could use Triple DES. Obviously, for this to work,
both Alice and Bob must accommodate DES and Triple DES.

Part 1
Part 2
Bulk Encryption and Message Integrity
All messages encrypted using SA-2 parameters
Virtual private networks

Figure 21-6 Overview of IPsec part 2.

7. Although SSL/TLS uses different cryptographic keys for outgoing and incoming
traffic, the cryptographic methods are the same.
238 CHAPTER 21 e IPsec Overview

‘Internet

Figure 21-7 Alice and Bob exchange encrypted messages protected by SA-2
parameters.

Some think |Psec’s IPsec is still evolving, and there are some controversial issues. For example,
versatility makes It some experts have criticized [Psec’s requirement of inbound and outbound SAs
too complex. as adding unnecessary complexity. IKE already negotiates SAs in pairs and as-
sures a separate secret key in each direction. Additionally, Alice and Bob should
agree to use the most secure encryption method they can for every message they
exchange. For example, with respect to the preceding paragraph, if Alice and
Bob can use Triple DES, it makes little sense for Alice’s outbound SA-2 to use
anything weaker (i.e., DES). Critics strongly argue against “needless” complex-
ity, which is often associated with potential security holes.
Other experts admit that it’s unfortunate that development of the two parts
of IPsec (IKE and bulk data encryption) has not always been coordinated per-
fectly. Additionally, they counter that although most cryptographic traffic is
equally protected in both directions, that’s not always the case. For example, a
company may distribute sales promotion materials to many regional offices over
the Internet in one-way protected traffic. Because the return traffic is not nec-
essarily protected, different inbound and outbound SAs are appropriate.

Protocol and Mode

Definitions: IPsec bulk encryption provides more options than does SSL/TLS. For example,
protocol and IPsec offers four confidentiality and message integrity options. The protocol at-
mode attrioutes tribute controls whether the data packet is protected by confidentiality or mes-
sage integrity (or both). The mode attribute controls how much of the data
packet is protected by these assurances.
 IPsec Part 2: Butk DATA CONFIDENTIALITY AND INTEGRITY FOR MESSAGE OR FILE TRANSPORT 239

Protocol: ESP or The protocol choices are formally called Encapsulating Security Protection
AH. Mode: tunnel (ESP) and Authentication Header (AH).° These IPsec options are most often
or transport referred to by their initials rather than by their long formal names. The mode
choices are called tunnel and transport.
Because there are two protocol choices and two mode choices, an IPsec data
packet must be protected by one of the four choices shown in Table 21-2.° All
data packets transmitted under the guise of an SA-2 (bulk encryption param-
eters) must adhere to the protocol/mode selection.

Table 21-2 |Psec data packets must be protected by one of these four choices.

ESP + Transport ESP + Tunnel

AH + Transport AH + Tunnel

As you can see in Figure 21-8, the most robust protection possible with a
single SA uses the ESP protocol and tunnel mode. ESP offers both message in-
tegrity (authentication) and confidentiality, whereas AH offers only message in-
tegrity.'° Tunnel mode encrypts more of the data packet than does transport
mode. Many vendors use ESP in tunnel mode to implement their VPN
products.

AH +Tunnel _

Figure 21-8 |Psec protocol and mode options. ESP offers confidentiality; AH does
not. Tunnel mode protects more data than transport mode. ESP in tunnel mode pro-
tects the most.

8. IPsec literature uses the term authentication to refer to authenticating the origin and
integrity of the message sent. Recall from Chapter 7 that integrity is also called
“message authentication.” In part, cryptographers reason this way: If amessage is
altered in transit, it means that the altered message came from a new originator.
9. IPsec also permits a “wildcard” option, but it is seldom mentioned in the IETF
standards.
10. AH authenticates slightly more of the data packet than ESP.
240 CHAPTER 21 e IPsec Overview

Virtual Private Networks

Routers or firewalls (we’ll refer to them as gateway computers) can use ESP in
tunnel mode to hide the addresses of internal computers from the outside world.
For example, as shown in Figure 21-9, Alice, a user in her company
AliceDotComStocks, works at a computer behind her gateway/firewall com-
puter. Similarly, Bob is a user behind the gateway at hxMel.com. When Alice
wishes to establish a secure session with Bob, her gateway automatically
negotiates security parameters (SAs) with Bob’s gateway. In this scenario, all the
IPsec processing is done on their respective gateways; BlackHat knows only that
the gateways are communicating and not which particular computers behind the
gateways are communicating. This is an example of a simple VPN. The me-
chanics are discussed in Appendix B.
It’s instructive to briefly mention two other competing VPN technologies:
Point to Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol
(E21 PR).
An industry group primarily headed by Microsoft and 3Com created
PPTP,; it’s supported across the Microsoft Windows product line. PPTP sup-
ports authentication and confidentiality between a client and a gateway or be-
tween two gateways without using public keys. Although early versions of PPTP
had significant problems (e.g., poor choice of hash functions), most of the se-
curity holes have been patched. But experts feel that PPTP is still vulnerable to
an offline password-guessing attack (see http://www.counterpane.com)
Microsoft advises PPTP for simple low cost VPNs.
L2TP is a combination of PPTP and another protocol, L2F, created by
Cisco Systems. Microsoft advocates using L2TP in concert with IPsec because
they feel [Psec doesn’t yet have good user authentication standards for client to
gateway communications. Note they agree that IPsec is fine for gateway to
gateway (machine-to-machine) communications. So L2TP sets up the session
and hands it off to [Psec for key negotiation and encryption.
Here’s a brief overview of each [IPsec protocol and mode, followed by some
examples. There’s more discussion in Appendix B.

Protocols
ESP is the more robust of the two protocols because it offers both confidenti-
ality and message integrity. Alice and Bob can agree to use ESP for confiden-
tiality and/or authentication, but they must choose at least one assurance.
AH provides only message integrity; it doesn’t provide confidentiality. But
AH authenticates slightly more of the message than does ESP.
 IPsec Part 2: BuLK DATA CONFIDENTIALTY AND INTEGRITY FOR MESSAGE OR FILE TRANSPORT 241

Internal Network
No IPsec Protections

AliceDCS HxMel.Com
ny Firewall/Gateway Firewall/Gateway
IPsec Protected IPsec Protected

Figure 21-9 Example of a simple virtual private network. !Psec-enabled gateway

computers act as protective proxies for Alice and Bob.

Modes
‘Transport mode protection can be used only between two end host computers;
it cannot be used if one of the computers is acting as a gateway that forwards the
data packets to their final destination. Transport mode protection uses less band-
width than tunnel mode because tunnel mode usually appends more data."
Tunnel mode protection can be used in any [Psec-enabled computer, and
it must be used when either end SA is a gateway—that is, if either end acts as a
proxy for the final destination of the data packet. As shown in Figure 21-9, tun-
nel mode hides Alice’s and Bob’s IP addresses from BlackHat.

ESP Examples
Figure 21-10 is an overview of ESP in transport mode and tunnel mode.

ESP in Transport Mode

End to end To use transport mode, Alice and Bob must have IPsec installed and must act
encryption, as host (final destination) computers. Their computers perform encryption/
authentication decryption and authentication/Vverification.
The ESP protocol in transport mode encrypts and authenticates applica-
tion data (e.g., e-mail) but does not protect the IP addresses. The gateways
(AliceDotComStocks and hxMel.com) allow traffic to flow directly from Alice
to Bob (and vice versa). Note that because the source address (from

11. Technical note: Tunnel mode adds an IP header which can be used to conceal the
ultimate source and destination. See Appendix B.
242 CHAPTER 21. © IPsec Overview

From: Bob@
ESP / Transport Mode HxMel.Com E-mail
To: Alice@ message
AliceDCS

“AliceDCS HxMel.Com
Internet Server Internet Server

ESP / Tunnel Mode From:

[email protected]
To: Alice@AliceDCS
From:
HxMel.Comi | : fe E-mail message
: : 1 From: Bob
To: AliceDCS To: Alice

Buy MS

Ermait E-mail
message message
From: Bob : . From: Boo
To: Alice i j To: Alice
Buy MS p, :

“ /AliceDCS HxMel.Com Bob

/ Internet Server Internet Server
(Removes Protection) (Adds Protection)

Figure 21-10 ESP in transport mode and tunnel mode.

 IPsec Part 2: Butk DATA CONFIDENTIALITY AND INTEGRITY FOR MESSAGE OR FILE TRANSPORT 243

[email protected]) and destination address (to Alice@AliceDotComStocks) are

not encrypted, BlackHat can sniff the line (perform traffic analysis) and figure
out that Alice and Bob are communicating.

ESP in Tunnel Mode

Firewall to firewall IPsec installed on the gateway (firewall) computers acts as a proxy for Alice and
encryption, Bob. The gateway computers perform encryption/decryption and authentica-
authentication, and _ tion/Vverification and then pass the unprotected data packets to Alice (or Bob),
hiding Alice and who doesn’t necessarily need IPsec installed on her (or his) computer.
Bob from BlackHat The ESP protocol in tunnel mode encrypts as much as in transport mode
and, in addition, conceals the final source and destination (e.g., Alice’s and Bob’s
Internet addresses). Note that Alice’s and Bob’s names have been removed from
the IP addresses. BlackHat knows only that traffic is flowing from
AliceDotComStocks to hxMel.com; he can’t figure out which computers behind
the gateway are exchanging messages.

AH Examples
Figure 21-11 shows how the AH protocol works in transport mode and tunnel
mode.

AH in Transport Mode
End to end The operation of the AH protocol in transport mode is similar to that of ESP
authentication in transport mode but without encryption. Alice and Bob must have IPsec in-
stalled and must act as host computers. Their computers perform authentica-
tion/verification.
AH authenticates more of the data packet than does ESP. Note that
[email protected] (and Alice@AliceDotComStocks) is authenticated; ESP does
not authenticate (protect) this data.

AH in Tunnel Mode

Firewall to firewall
The operation of AH in tunnel mode is similar to ESP in tunnel mode, but AH
authentication does not encrypt and conceal Alice’s and Bob’s addresses. This means that
BlackHat can still see the ultimate source (Bob) and destination (Alice) of the
e-mail. Tunnel mode AH offers limited benefit for the increased authentication
overhead.
244 Cuapter 21 e IPsec Overview

From:
[email protected]
To: Alice@AliceDCS

E-mail message
From: Bob
To: Alice
Buy MS

AliceDCS
Internet Server Internet Server

From: HxMel.Com
To: AliceDCS
From: [email protected]
To: Alice@AliceDCS
E-mail message
E-mail E-mail
message BRS ’ Oh) message
TIBI
ere To: Alice igre
From: Bob From: Boo
Buy MS
To: Alice To: Alice
Buy MS

AliceDCS HxMel.Com Bob

Figure 21-11 AH in transport mode and tunnel mode.

Management Control
Definition: security Every data packet that leaves or enters an IPsec implementation must comply
policy database, with the rules found in each IPsec implementation’s security policy database (SPD).
policies The SPD is the tool IPsec managers use to specify whether and how their com-
puters are allowed to interact with other Internet computers. The SPD speci-
fies rules, called policies, that govern the IPsec security provisions between
computers. Here’s a simplified example.
Definition: selectors Let’s say that Alice (at AliceDotComStocks) wants to send Bob (at HxMel)
some data using the file transfer protocol (FTP). From Alice’s perspective, the
 IMPLEMENTATION INCOMPATIBILITIES AND COMPLICATIONS 245

SA-2 that must be negotiated with Bob must comply with rules in her SPD. The
particular SPD policies (rules) that Alice must comply with are selected accord-
ing to the attributes in Alice’s data packets to Bob:

¢ The source of the data (Alice’s computer, identified by her IP address)

¢ The destination of the data (Bob’s computer, identified by his IP address)
¢ The protocol she’s using to send the spreadsheet (FTP)
e The name of the person to whom the data is being sent ([email protected])
¢ The source port (Alice’s FTP port)
¢ The destination port (Bob’s FTP port)

Each of the six attributes is called a selector.

Discard, process, A particular policy must make one of three choices; Alice’s data to Bob is
bypass either discarded, subjected to IPsec processing, or bypassed. “Discarded” means
that outbound data packets are not allowed to exit (or inbound packets are not
allowed to enter). “Subjected to [Psec processing” means that the SPD has iden-
tified protection rules with which to process the data packet (e.g., ESP, tunnel
mode, ‘Triple DES, and so on). “Bypassed” means that IPsec has determined that
the data packet should be allowed to exit (or enter) with no IPsec processing.
In any particular policy, five selectors can be blank, but at least one (usually
the source of the data) must be “filled in.”
Data flow control IPsec managers make policies that enumerate required security provisions
to and from their particular [Psec-protected network, and thus they control the
flow of data. Any data packet that seeks to enter or leave is checked against the
SPD and must comply with at least one policy. If no policy is found after the
selectors are evaluated, the packet is discarded.
Configuring SPD One of I[Psec’s strengths is its ability to select and configure multiple secu-
policies rity policies for any particular computer or a network of computers. IPsec can
configure each IP source address (e.g., Alice), IP destination address (e.g., Bob),
protocol (e.g., FTP), and so on. SPD selectors can be broadly or narrowly con-
figured. For example, a broad configuration might require that all traffic leav-
ing Alice’s computer use ESP, tunnel, Triple DES, and so on. A narrow
configuration might allow all users, except Alice, to communicate with Bob
using any protocol, whereas Alice must use FTP.

Implementation Incompatibilities
and Complications
SSL/TLS is a stable enough standard that AliceDotComStocks can interact
with almost any SSL/TLS standard implementation. This means that Bob can
246 CHAPTER 21 e IPsec Overview

use Netscape’s or Microsoft’s SSL/TLS implementation and get a secure cryp-

tographic connection to AliceDotComStocks.
IPsec isn’t as widespread as SSL, and there are still vendor compatibility
problems. If AliceDotComStocks and hxMel.com have IPsec implementations
from different vendors, they may not be able to set up a secure connection. For
example, currently IPsec mandates support of only DES; each vendor can in-
clude support for additional cipher methods (e.g., Rijndael, Triple DES, etc.)
but it’s not required. Alice and Bob can communicate only if they can agree on
an SA-1 and SA-2.
Security personnel agree that IPsec is complicated. In large part, that’s be-
cause IPsec delivers a much wider range of cryptographic services with many
more options than does SSL/TLS. The IETE the standards body for both IPsec
and SSL/TLS, has about 10 [Psec documents for every SSL/TLS document.
Although cryptographers argue over IPsec’s value in its current form, they
agree that it is the best protocol for delivering Internet communication secu-
rity at present. After evaluating IPsec in 1999, Applied Cryptography author Bruce
Schneier, together with Niels Ferguson, wrote, “We strongly discourage the use
of IPsec... . However, we even more strongly discourage any current alterna-
tives, and recommend IPsec when the alternative is an insecure network.”

Review
IPsec authenticates data entering and encrypts data leaving an [Psec-enabled
computer. Its cryptographic protections are delivered to the user as unobtru-
sively as possible.
The current [Psec standard can be visualized as having two parts. The first
part, IKE, manages authentication and key exchange. The second part manages
the bulk encryption process.
IKE is a two-phase protocol. The first phase sets up a secure authenticated
communication channel; phase | establishes encryption parameters that are used
to protect the second phase. The second phase makes encryption parameters
that are used in IPsec part 2, bulk encryption. Two-phase protocol key manage-
ment enables quick changes to encryption parameters.
IPsec bulk encryption offers confidentiality and message integrity protec-
tions in four potential configurations; two protocols (ESP and AH) and two
modes (tunnel and transport). Many vendors of virtual private network prod-
ucts implement their products using [Psec’s ESP protocol in tunnel mode.
Management control uses the SPD to make policies. Policies control if and
how computers communicate.
Although IPsec has some controversial issues, most of its critics agree that
it’s currently the best possible solution.
 Chapter 22

CRYPTOGRAPHIC GOTCHAS

his chapter describes a number of cryptographic attacks (gotchas) and ex-

plains how you can foil them.

Replay Attack
Suppose Alice sends her clients the daily interest rate and a buy/sell reeommen-
dation, signed with her private key. All her clients have trusted copies of her
public key. On Monday, Alice sends 6.5% don’t buy yet. Because this message
is only signed and not confidential, BlackHat decrypts it. On Tuesday, the Fed,
in uncharacteristic mania, drops rates to 5.5%; Alice sends 5.5% buy now. Be-
cause BlackHat wants to stall Alice’s clients, he intercepts Alice’s Tuesday mes-
sage (5.5%) and substitutes Alice’s Monday message (6.5%). It’s an authentic
Alice message; BlackHat didn’t alter it. It’s just old. This attack, appropriately
called a replay attack, is one of the more easily prevented attacks.
Lesson: Timestamp ‘To prevent a replay attack, Alice can timestamp or number her messages.
or number All the real-world systems we’ve discussed offer at least one of these options.
messages Interestingly, although IPsec requires the sender to number messages, the re-
ceiver is not required to use message numbering.

Man-in-the-Middle Attack
Although public keys need not be concealed (secret), this doesn’t mean that
public keys can simply be sent (or stored) without any protection. For example,
suppose Alice e-mails Bob her public key; then BlackHat intercepts it and sub-
stitutes his own (BlackHat’s) public key. BlackHat can now read all confidential
messages Bob sends to Alice and even masquerade as Alice to Bob. This is called
a man-in-the-middle attack.

247
248 CHAPTER 22 e CrypToGRAPHic GOTCHAS

Lesson: A trusted In Figure 22-1, BlackHat intercepts Alice’s public key (23, 69, 14, ...) and
public key means substitutes his own (99, 98, 97 ...). Bob uses BlackHat’s public key (thinking it
it’s been validated is Alice’s) to encrypt messages for Alice. To complete his subterfuge, BlackHat,
and protected. after decrypting and reading Bob’s message, encrypts it using Alice’s public key
and sends it to her (see Figure 22-2). Similarly, BlackHat can forge Alice’s sig-
nature to Bob—again, because Bob believes he has Alice’s genuine public key.
Is this too much work for BlackHat? That depends on how much he can gain
from it, doesn’t it?
Bob can verify Alice’s public key using digital certificates (see Chapters 15
through 17). But recall that digital certificates also rely on an initial trusted pub-
lic key.

99 98 97

Figure 22-1 Black Hat substitutes his own public key for Alice’s. Bob doesn’t know.

@ Bob encrypts a message

to Alice, unknowingly using
BlackHat’s public key.

@ BlackHat intercepts and

decrypts Bob’s message with < is
his (BlackHat’s) private key. Boe, '©
o° 5 ee
© BlackHat encrypts Bob’s is .
message with Alice’s public -
key and sends it on to Alice. »

Figure 22-2 BlackHat completes the deception.

 Does CONFIDENTIALITY IMpLy INTEGRITY? 249

Finding Your Keys in Memory

Here’s an attack that’s so obvious that, after you see it, you might wonder why
you didn’t figure it out yourself.
Figure 22-3 shows a snapshot of RAM bits; white is 0, and gray is 1. Can
you find the simplistic 26-bit secret key? Here’s how. Recall that cryptographic
keys are made to have as much randomness as possible; that makes them diffi-
cult to predict. It also means that a cryptographic key should contain approxi-
mately the same amount of0’s and 1’s—in our RAM picture, the same number
of gray and white boxes.
Random keys don’t The secret key begins four rows down on the left-hand side; about 13 white
look like normal boxes are alternated with 13 gray boxes. Ofcourse, real secret keys don’t alter-
data. That makes nate every 0 and 1 bit; that isn’t a random pattern. But that’s not the point. The
them easy to find in point is that a random key has statistical properties that “normal” data does not.
memory.
That gives the cryptanalyst something to look for in RAM: randomness. This
means that although random keys are hard to predict, their randomness makes
them easy to find.
To protect against this attack, a cryptographic software designer can split
the random key into smaller chunks so that its randomness doesn’t provide such
a big target.
This attack, discovered by Adi Shamir, the S in RSA, also illustrates a cryp-
tographic tenet: You can’t say that a system is totally secure because you never
know where an attack will come from.

Figure 22-3 Computer memory with a secret key.

Does Confidentiality Imply Integrity?

There’s a widely held, but mistaken, notion that secret key encryption (confi-
dentiality) implies that a message can’t be altered in transit without detection.
The mistaken argument goes like this: The secret key is shared only between
Alice and Bob, so BlackHat can’t change the encrypted message because
250 CHAPTER 22 © CrypTOGRAPHIC GOTCHAS

anything he substitutes will decrypt to gibberish (see Figure 22-4). Let’s dis-
prove this notion with two examples.

Example 1
Lesson: Always What if the ciphertext in Figure 22-4 contained a secret or public key, that is,
include a signed something random? Although BlackHat can’t decrypt the ciphertext, he can
digest or a MAC in substitute some other random ciphertext. When Bob decrypts BlackHat’s forged
digital messages. ciphertext, he’ll have no way to detect BlackHat’s forgery. BlackHat has success-
fully and covertly disrupted future communications between Alice and Bob. And
although BlackHat can’t read Alice’s communications to Bob, neither can Bob!

Perhaps secret—but not unalterable

Figure 22-4 Alice sends Bob a secret key encrypted message.

Example 2: Cut-and-Paste Attack

Secret key encrypted messages usually break the plaintext into approximately
8-character to 16-character blocks (chunks) and encrypt each individual block
separately (see Chapter 5).!
Unfortunately, if there are enough blocks of ciphertext, BlackHat can in-
sert fraudulent blocks of ciphertext, as shown in Figure 22-5. For example,
encrypted blocks 1-9 and 14—10,000 may be genuine, but blocks 10-13 may be
a forgery inserted by BlackHat.

Each number represents a different text block

Figure 22-5 BlackHat inserts forged packets into a genuine message.

1. Disregarding stream ciphers.

 Pustic Key As A CryPTANALYSIS TOOL 251

This attack is called a cut-and-paste attack. The details are beyond the
scope of this book, but you'll find references in the Bibliography. Note that
sending either a MAC or a signed message digest will detect this attack.

Public Key as a Cryptanalysis Tool

When Bob encrypts and sends a message to Alice using her public key, it’s sup-
posed to be unreadable by BlackHat. But it isn’t always unreadable unless you
follow some guidelines.

Example 1: The Chosen Plaintext Attack

Suppose Alice wants Bob’s opinion on how much to bid for a shopping center;
it is worth between $8,000,000 and $12,000,000. As shown in Figure 22-6, Bob
encrypts his opinion ($10,987,654 encrypts to 12341234) and sends it to Alice.
How can BlackHat find out what Bob encrypted?
Let’s review what BlackHat knows. He knows that Bob’s opinion is between
$8,000,000 and $12,000,000; the ciphertext Bob sent Alice (12341234); and
Alice’s public key. BlackHat uses his copy of Alice’s public key to encrypt every
number between 8,000,000 and 12,000,000. One number, 10,987,654, encrypts
to 12341234, the same ciphertext sent by Bob (see Figure 22-7). BlackHat
knows that this is the opinion Bob sent Alice.
Definition: chosen In cryptographic terminology, BlackHat has successfully mounted a chosen
plaintext attack plaintext attack. BlackHat chooses a set of possible plaintexts to encrypt with
Alice’s public key; one of the chosen plaintexts encrypts to the ciphertext sent
by Bob.

$10,987,654
Pe

l’ll copy the encrypted value

and try to replicate it!

Figure 22-6 Bob sends Alice his encrypted opinion, and BlackHat copies the
ciphertext.
252 CHAPTER 22 e CrypToGRAPHic GOTCHAS

Definition: padding Alice and Bob can prevent a chosen plaintext attack by adding random char-
acters, called padding, to Bob’s plaintext. This approach effectively increases the
number of possible plaintexts BlackHat must encrypt. Figure 22-8 adds five
characters of padding. Now BlackHat must encrypt 100,000 variations of
8,000,000 before trying 8,000,001.

(Chosen) Plaintext Ciphertext

BlackHat encrypts every BlackHat gets these
possible value with Alice’s enciphered texts.
public key.

ORS OMOMOROMOMO tl SRA Onn a4

oPS&or ono rokos wis Reser —P 68146004
Oo8s8000g00d0g2 -— = OP 4 a5 SOA ealine o
@ 8 © © © © @ & 5aeAre
Ss. 122304)

1098765 0 — Eventually BlackHat TAN 3S: “9 Be Vee 2

109 8765 2 — sameciphertext
sent We SoZ: ti 3 SOO
1 @9O 87 6S ® by Bob. OR 4 eon ONO
4

Figure 22-7 BlackHat mounts a chosen plaintext attack.

Additional padding makes BlackHat try 100,000

variations of 8,000,000 before trying 8,000,001

Padding Bob’s Possible Plaintext

Figure 22-8 Adding padding. BlackHat must try many more than 4,000,000 chosen
plaintexts.
 BiackHat Uses Bos’s RSA Private Key 253

Public Key Cryptographic Standards

RSA Securities publishes suggested standards to prevent this and other attacks
against public key cryptography. The standards, appropriately called Public Key
Cryptographic Standards (PKCS), are freely available from the RSA Web site,
www.rsa.com. This particular attack is addressed in PKCS #1, RSA Encryption
Standard, which includes a recommended padding scheme.

Example 2: The Bleichenbacher Attack

Unfortunately, as we have mentioned, nothing is provably secure.’ Even after
RSA published PKCS #1, a cryptanalyst, Daniel Bleichenbacher, discovered
another attack specifically against the padding scheme.
Lesson: Use only Although it was previously thought impossible, Bleichenbacher showed
Welostec anc how to figure out the entire encrypted message one bit at a time. The attack
tested requires Alice (the private key holder) to respond to about 1,000,000 of
cryptographic BlackHat’s probing messages, but that’s not infeasible in automated systems. To
systems. counter this attack, called a Bleichenbacher attack, RSA revised PKCS #1 pad-
ding. The attack is beyond the scope of this book; see the Bibliography for a
reference to additional papers.

BlackHat Uses Bob’s RSA Private Key

Bob keeps his RSA private key securely locked up (see Chapter 23) so that no
one else can ever use it. Well, here’s a way that BlackHat, with a little help from
an automated message response system, can trick Bob. BlackHat tricks Bob into
using his (Bob’s) RSA private key to decrypt a confidential message Alice en-
crypted with Bob’s public key. Watch closely as public/private keys are juggled
and confidentiality is breached with an ingenious BlackHat cryptographic
maneuver.
As shown in Figure 22-9 (upper left), Alice sends Bob a message. She signs
the message (encrypting it with her black private key) and then encrypts with
Bob’s white public key. In the upper right, Bob receives the message, decrypts
it with his private key, and verifies Alice’s signature with her public key. In the
bottom right, Bob returns to Alice the same plaintext Alice sent him along with

2. Perhaps one of the more tongue-in-cheek rumors is an NSA suggestion for protecting
valuable secrets. Grind the hard disk into small pieces, lock the pieces in an expen-
sive safe, dump the safe in the middle of the ocean, and protect the site with highly
paid military guards.
254 CHAPTER 22 e CryPTOGRAPHIC GOTCHAS

a return receipt, proving to Alice that he received her message; that is, he signs
with his private key and encrypts with Alice’s public key.
Bob’s automated message response system will do this for any signed, en-
crypted messages he receives. Figure 22-10 shows Bob’s system sending
BlackHat a similar return receipt. Don’t look for any BlackHat tricks in Figure
22-10. It’s exactly what Bob did for Alice.

Mice sends to Bob

4. Alice decrypts, verifies 3. Bob sends return receipt

to Alice; signs, encrypts

Figure 22-9 Alice and Bob exchange signed, encrypted messages. Follow arrows as
Alice signs plaintext and then encrypts, and so on.

1. BlackHat signs, encrypts 2. Bob oe verifies’%

"2@e
n®
eng
ow
%ae
5
exe

Pas
oa <

4. BlackHat decrypts, verifies 3. Bob sends return receipt

to BlackHat; signs, encrypts

Figure 22-10 Bob's automated response to BlackHat.

 BiackHat Uses Bos’s RSA Private Key 255

It’s easier to visualize RSA encryption/decryption (and sign/verify) cancel-

ing each other out if it’s shown in another way. Figure 22-11 is read from right
to left. Alice signs the plaintext message and encrypts it with Bob’s public key.
Bob decrypts with his private key and verifies Alice’s signature. It’s exactly iden-
tical to Alice and Bob’s message exchange shown at the top in Figure 22-9.
Figure 22-11 shows that Bob’s RSA private key/public keys cancel each
other out. When they are next to each other it’s like multiplying by 1. Then
Alice’s private/public keys cancel each other out, too.
Figure 22-12 adds Bob’s return receipt to Figure 22-11. After Bob recov-
ers the plaintext, his automated system makes Alice a return receipt by signing
and encrypting. Now we’re ready for BlackHat’s attack.
In Figure 22-13 BlackHat replays the original signed, encrypted message
Alice sent to Bob; it’s labeled “Alice to Bob.”
Because Bob’s automated response system believes that the message is a
genuine message from BlackHat, Bob’s system dutifully decrypts it with Bob’s
private key and verifies it with BlackHat’s public key. Bob’s private key cancels
out the public key encryption. Of course, BlackHat’s public key won’t cancel out
Alice’s private key signature, and the automated response system won’t recover
meaningful text. BlackHat hopes that the automated response system simply
makes a return receipt automatically, signs with Bob’s private key, and encrypts
with BlackHat’s public key.

Figure 22-11 Alice sends a signed, encrypted message. Bob decrypts and verifies.

Cancel Out

Cancel Out

Figure 22-12 Bob’s return receipt is added here.

256 CHAPTER 22 © CryPTOGRAPHIC GOTCHAS

Figure 22-14 shows how BlackHat figures out the original signed, en-
crypted message Alice sent Bob. BlackHat has fooled Bob into using Bob’s pri-
vate key to cancel out Alice’s use of Bob’s public key. See Bob’s circled private/
public keys.
Although Bob applies three more cryptographic keys to the message—
verify with BlackHat’s public key, sign with Bob’s private key, and encrypt with
BlackHat’s public key—BlackHat can cancel out each one. Obviously, BlackHat
can cancel out any encryption or signing done with BlackHat’s public or private
key. The only other canceling BlackHat must do is to cancel out signing (pri-
vate key encryption); he does that with openly available public keys.
Before you start worrying, let’s consider the implications of this attack.
First, it works only with a cryptographic method whose public and private keys
are used for encryption and decryption—that is, RSA (see Chapter 12). Second,
BlackHat figured out only one message encrypted with Bob’s public key; he did
not figure out Bob’s private key.
Lesson: Never sign It’s easy to protect against this attack; here are three ways. If you use RSA
(private key for confidentiality, use a different method (e.g., DSA) for signing. Or don’t use
encrypt) unknown the same pair of RSA public/private keys for both confidentiality and signing;
messages. instead, use one RSA key pair for signing and a second one for everything else.

__Bob's ew
Alice to Bob
receipt (Encrypted with
x Bob's public key) “y

— Decrypt Encrypt
Gow
®__ cancel out—*

BlackHat replays Alice’s message to Bob

So Bob decrypts (cancels out) Alice’s encryption with Bob’s public key

Figure 22-13 Bob’s automated response system sends BlackHat a response.

BlackHat’s ms ie rebum =
Attack é ceipt faeoO maa LAME EN

ReCancel Out on }
teen Canc) Out — es ji
“ ae Cancel Out yi
oe Saar VANCE Ota a = zat “ae seven

Figure 22-14 BlackHat figures out the encrypted message sent by Alice.
 REVIEW 257

Or better yet, always use a well-designed cryptographic protocol, such as SSL

v3, that never signs exactly the message sent to it. Recall, from Chapter 14, a
basic tenet of cryptographic protocol design: Never sign the exact data sent to you.

Review
Attacks against cryptographic systems are as creative as the cryptographic sys-
tems themselves. There are lessons to be learned from looking at each attack.
Replay attack: Messages should contain a timestamp or some other way to
identify them as new or old.
Man-in-the-middle attack: Trusted public keys must be validated and
protected.
Finding keys in memory: If secret keys can be identified, they can be at-
tacked when they are outside cryptographic protections.
Confidentiality does not imply integrity: Secret key encryption does not
prevent BlackHat from altering a message.
Public and private keys must be used carefully. Adhere to standards, use
separate methods and/or keys for confidentiality and signing, and never use your
private key to sign the exact message sent to you. And never sign unknown
messages.
 ove
‘ a - ;
ice"? =q -
~

——- any Shaye >

ear cenraces ol Mad oe aciapreo pia dei"wi-4
- Fe, renee Mire Ma pada (= Sanhpneeieh'
: a 7 Sy ae i ea
‘ = a T wsived
a . on a Sa ery, Cyan? .
_ ey ee. hale é pres
are iil 4
oi pe ST
DD be «

Ui Sree)
Ptyee sd tered
Set J) “Snraek
a Oper: hy slat’
= 7

\s oe ee BDA A

es Gwe =
tig
do 0g Mig whe

pk viveg,
 Chapter 23

PROTECTING Your Keys

N ew technology is on the horizon that will let people control processes in

their houses and bank accounts using a hand-held computer, but this trend
won't get very far without cryptography. Although modern cryptography has
become more complex and in many ways more secure, you need to be very vigi-
lant about your keys.
What you know, There are three currently accepted ways to protect your keys. You could use
what you have, a password or passphrase (“what you know”), a smart card (“what you have”),
who you are e or biometric identification (“who you are”). Or you could use some combina-
tion of the three.
Passwords, although the most popular approach, are the least secure.
They’re usually guessable by a wide variety of programs. Studies have shown
that it is easy to successfully guess the majority of passwords.
Biometrics is better, but this science is still in its infancy. Voice recognition
will falsely reject someone who has a cold, fingerprint identification will falsely
reject someone who has a small scratch, and there are those who may not want
laser beams in their eyes.!
As we explained in Chapter 22, even really big RSA keys aren’t any more
secure than 40-bit DES if BlackHat can easily find them in their storage place.

Smart Cards
Smart cards \ook like thin plastic bank cards, but they contain an embedded in-
tegrated circuit. In combination with some kind of reading and/or input device,
they provide a variety of computer functions, including digitized communica-
tions. Smart cards easily store cryptographic keys and algorithms while limit-
ing access to those keys. Smart cards are currently the most widespread
commercial solution for key management. Although not foolproof, smart cards

1. Sign in a laser beam lab: “Don’t look directly into laser with remaining eye.”

259
260 CHAPTER 23 e PRrortECcTING Your Keys

are particularly valued for providing secure authentication by creating and stor-
ing keys someplace more secure than a desktop computer.
Smart cards have First conceived in 1974, smart cards were put through their paces in 1984
been more readily during a trial by the French postal and telecommunications services to prevent
adopted in Europe vandalism and theft of public pay telephones. The trial was so successful that
than in the U.S. most French telephones now accept only smart cards. European banks have
pioneered the use of these cards in the financial industry, and in Germany more
than 70 million smart cards have been issued that carry health insurance infor-
mation. Use of this technology is taking off in Asia, Australia, and New Zealand
as well.
U.S. government A $1 billion purchase of smart cards by the General Services Administra-
GSA helps speed tion of the U.S. government should help speed the spread of smart card tech-
U.S. adoption nology in the United States.
Eventually, people will use these cards or something like them to prove
identity. Currently, to use a smart card, you need a reader and software. The
prices of smart card readers have been dropping and will most likely continue
to do so as use of the technology becomes more widespread. American Express
gave away readers with its trial of a new combination card called “Blue,” which
includes both a magnetic strip used on traditional credit cards and an embed-
ded chip that can be used for online purchases. Because smart cards can be used
in conjunction with a personal identification number (PIN) or even some type
of biometric scan, theft of your identity becomes much more difficult.

Types of Smart Cards

Smart cards can be thought of as tiny computers that must be supplied with
voltage, ground, and a clock by an external terminal. They come in two variet-
ies: memory cards and microprocessor cards.
Some people Memory cards are not as “smart” as microprocessor cards. Memory cards are
believe memory containers for information that can be read and modified. They are often used
cards should not for temporary purposes, such as a prepaid telephone card, and then disposed of.
be classified as Ifa memory card is lost, the finder can use the information it contains.
smart cards. Microprocessor cards, on the other hand, contain more sophisticated chips
and more memory than memory cards. Microprocessor cards can hold multiple
applications and passwords, and some even contain co-processors that encrypt
data stored in the chip. It’s the co-processor that allows the private key to never
leave the smart card. This means that cryptographic processing with the private
key is done entirely on the microprocessor card, and that limits the exposure of
the private key.
In terms of the mechanics of their use, smart cards can either be contact
cards or proximity cards or both. Contact cards, as their name implies, are read
by means of contact (such as insertion) with a device such as a card reader. Prox-
imity cards contain a chip that is connected to an antenna and can be read from
 Smart CARDS 261

a few inches to a few meters away. Proximity cards are intended for use in fast
transactions, such as mass transit. A combination card combines both capabili-
ties and offers even more versatility.

What’s Inside a Smart Card

Having a microprocessor allows these cards to operate like tiny data processing
systems. ‘Typically, inside is an 8-bit central processing unit (CPU) and three
types of memory—random access memory (RAM), electrically erasable pro-
grammable read only memory (EEPROM), and read-only memory (ROM).
There’s also an optional cryptographic accelerator to speed calculations.

Protections and Limitations

Obviously, if the card can be altered in an unauthorized fashion, it’s not secure.
So there are special epoxy coatings to protect the chip and special electronics
to protect against other attacks. For example, the best-designed smart cards
detect fluctuations in voltage, temperature, or clock frequency. If tampering is
detected, the card can be programmed to erase your private key and other criti-
cal data. ‘To avoid card cloning, an unalterable serial number is often burned into
the chip’s memory.
At the time of this writing, DES and Triple DES are commonly used in
smart cards and can be used to verify message integrity through the use of
message authentication codes (MACs). Bulk hashing is not feasible because the
card has limited ability to quickly handle data input and output.

Smart Card Attacks

Any system is breakable, including those that use smart cards. As we’ve empha-
sized throughout this book, you must assess the cost of breaking the system and
the value of the information to determine the kind of security measures you
need. When choosing a smart card, you should ask the manufacturer for refer-
ences to independent labs that have security-tested its system.
Smart cards can be attacked in various ways. Logical attacks examine the
bytes going to and from the smart card in order to uncover the private key, and
not all smart card manufacturers have implemented logical countermeasures. Io
cause a significant physical fluctuation, physical attacks usually require special
equipment.
In the Trojan Horse attack, a rogue application has been planted on a
workstation. The application waits until the user enters a valid PIN and then
asks the smart card to digitally sign some bogus data. You should also be alert
262 Crapter 23 e PROTECTING Your Keys

to social engineering attacks, which have been used since the dawn of time. The
idea is to trick you and steal what you know.
Technolosical As we’ve said before, just because a system was safe five or ten years ago,
advances affect that doesn’t mean it’s safe now. For example, Cartes Bancaires (CB), which holds
smart cards, too. the monopoly on the supply of bank cards based on smart card technology in
France, may have waited a little too long to begin replacing the 34 million “yes-
cards.” According to a Web-based report in The Irish Times on the Web,
cryptologists had advised CB for the past 15 years that its 320-bit, 96-digit code
needed to be longer because advances in technology were weakening it. For that
reason, the report said, at the end of 1999 CB began replacing the cards with
792-bit cards, a process scheduled for completion in 2004.
But CB’s actions were not in time to stop Serge Humpich, who worked
independently for four years and determined that the retail terminals that dis-
pensed small-ticket items, such as subway passes, were a weak link in the French
banking system. Reports indicated that he managed to compromise the smart
card system, in part because of factoring the public key.
Perhaps those 34 million “yes-card” holders will rest a little more at ease
now that French smart card inventor Roland Moreno has offered a reward of
one million francs (or about $150,000) to anyone who can demonstrate how to
read a bank card’s confidential code. French consumer groups spoke out for the
immediate replacement of all the old, less secure cards and the payment termi-
nals that Humpich was able to purchase, disassemble, and compromise. As of
this writing, CB was waiting to see whether Humpich’s discovery would result
in any serious fraud before taking such drastic and expensive measures as called
for by French consumer groups.
Smart cards could eventually replace all the credit cards and ID we carry in
our wallet as well as the keys to all our valuables.

Review
No matter how strong any cryptographic system is, an identity thief could steal
who you are (biometric scans), what you know (password), or what you have
(smart card). One of the best ways to be vigilant about your keys is to store them
someplace more secure than a desktop computer.
Smart cards, which are similar to credit cards, let you do that. Smart cards
come in two varieties: memory cards and microprocessor cards. Microproces-
sor cards, the more sophisticated of the two types, can hold applications, pass-
words, and even a co-processor that encrypts data stored in the card’s chip.
Manufacturers of smart cards design them in ways to protect against tam-
pering. Although smart cards offer good security, they can still be attacked and
are subject to technological advances that could weaken formerly strong keys.
 EPILOGUE

he following are excerpts from “Advanced Encryption Standard (AES)

Questions and Answers,” www.nist.gov/aes. This material pertains to
NIST’s selection of Rijndael as the proposed! AES standard.

How do you pronounce Rijndael?

The algorithm’s developers have suggested the following pronunciation alter-
natives: “Reign Dahl,” “Rain Doll,” and “Rhine Dahl.”

Who submitted the algorithm, and where are

they from?
The two researchers who developed and submitted Rijndael for the AES are
both cryptographers from Belgium: Dr. Joan Daemen (Yo’-ahn Dah’-mun) of
Proton World International and Dr. Vincent Rijmen (Rye’-mun), a postdoctoral
researcher in the Electrical Engineering Department (ESAT) of Katholieke
Universiteit Leuven.

Why did NIST select Rijndael to propose for

the AES?
When considered together, Rijndael’s combination of security, performance,
efficiency, ease of implementation, and flexibility make it an appropriate

1. We are writing this shortly after Rijndael was selected as the proposed standard in
October 2000. According to NIST’s estimates, Rijndael will become the official stan-
dard sometime in the spring of 2001 (April-June).

263
264 EPILOGUE

selection for the AES. . .Specifically, Rijndael appears to be consistently a very

good performer in both hardware and software across a wide range of comput-
ing environments. . . . Its key setup time is excellent, and its key agility is good.
Rijndael’s very low memory requirements make it very well suited for restricted-
space environments, in which it also demonstrates excellent performance.

What about the other four algorithms that were

not selected?
In terms of security, NIST states in its report that “all five algorithms appear to
have adequate security for the AES.” NIST is not saying that there is anything
“wrong” with any of the other four algorithms.

Will the AES replace Triple DES and DES?

The AES is being developed to replace DES, but NIST anticipates that Triple
DES will remain an approved algorithm (for U.S. Government use) for the
foreseeable future.

Is NIST concerned that the algorithm is of

foreign origin?
No. The complete algorithm specification and design rationale have been avail-
able for review by NIST, NSA, and the general public for more than two years.
From the beginning of the AES development effort, NIST has indicated that
the involvement of the international crypto community has been necessary for
the development of a high-quality standard.

Approximately how big are the AES

key sizes?
The AES will specify three key sizes: 128, 192, and 256 bits.
 H. X. MEL AND Doris Baker Pustic Keys 265

H. X. Mel and Doris Baker Public Keys

We walked from Caesar’s cipher to the Internet Highway where you can down-
load our PGP keys from http://web.mit.edu/network/pgp.html. Search for “H.
X. Mel” and/or “Doris Baker.” Our keys are shown next, and they should match
exactly
what you download.

H. X. Mel PGP Key

—— baci pepe PubilG KEY BLOCK
Version: PGPfreeware 6.5.2 for non-commercial use
<http: //www.pgp.com>

mQENAzn/ XNWHIWEITALVsnu2ToVcrC8JVIVEW1 8HppgwmxLV7ud/QhQeu/WYAIJOZ

Ut1TOQAkxneGRi PowV80gZ0E8QJe+ 6h4KVReEKxO4kDj VNSZR/RttzolFHyIATh6w
oPFOOCOffEIN41SXsDJtW2 4bKfKEbsgqlAD5ufumtvfGidHfy01W0eeR62TXON31M

mo30DLnUA6HmFoJYfespJh+qZAtYeQ8UleV/9k4iJ4ej9eP/5840711i1MGTX+TNT
3QTODwbky&xuChsVRT30849Zu/UhXxVpu+17DS5K8/vcSKb8
£zoxVJ040e7 LMKxD
PELQyM8 5UpU2XkkPZZzIzs2TXgHmkVealjznf1lEABRGOGEgulFgulE1lbCA8aHhA
SHhHNZWwuY29t POkKBFOMFEDn /XNyRV501iPOd+UQEBHhDQOH/
1xwzM8 8Nbea2FZn5R3L

2Q0wXv2accM1KvVpulNw9kCCRFOIVVVzBgz1/JQtwOwO03yjkvfIxYNvN00D147bj8
JsmzQrOATpTZJdRalodzJeDdIFryA1971iAy58d£khRvVOAotNVszO7gTItuZhB57v
XbkBIIkYYe0CBZ1K67kKN7OHZ2Z£E0RO07Hbig5W63
6dLC7wwF 3MxXqclwkhjwzTtqHx
xO0vYcWhcecegDiehtekxYJWYvpCkz6Q1MWc4iqJBAN5cCs9e0BryUg/46fjLakf54
9GoYLF+d0LNXLMGna9+g810PkKSkKDAD9HZJ6TOQDZwDh5b1p+yAbRi4nkHvJjEU1LOg
JSH=

=SUWJ
—END PGP PUBLIC KEY BLOCK—

Fingerprint: 661A 5AFD A462 77E1 8931 O9EA 143E 2DFB

framework Bradbury enlist Wyoming

regain gadgetry involve tolerance

olaLlalic onl a! company Algol undaunted

baboon cumbersome button Wichita

266 EPILOGUE

Doris Baker PGP Key

—-SECUN PCP SPUBLIGC VKHY SBE OCkK——
Version: PGPfreeware 6.5.2 for non-commercial use
<http://www.pgp.com>

mMOENAzn+Jw8AAAEIAN/U3tt6rDesNBUKK+L+MkeUSH/HBS3byCckw1
0bviQp7e0V

TpdD3 25bF3 0Bva4gqKx7 oKj c9gbtHmeZ2Xp16zoC5pie6DzxGHRXNSR/1lvVRKBn£Ss

al5xUB18NZCqB/EGVBevm+jLVJW21CzC56A09pITYcPzIK9Ha+Bhv+XTsG8abBzU
rrSnWqlh1lqoDd62ASvLUz/FSXES3HT/3e8Sm02DFBz8I11QJKITOt/HbBk60czn6eC
DhacYghI3 0noq0XhgGryJH+6m+t P5dtaZgHBexXV1CRsd96D0ckuj chtA+VyyTMO/
C6lrag+XGat ERWPUtCtCMJ+zzNmcR/ATX3kZ30IcABRGOHORvcm1
zl EJha2VyIDxk
YkBkb3Jpc2Jha2VyLmNvbT6JARUDBRA5 /icP/ATX3kZ30ICBAT+1iCAC65X5KhdrL
yxLy4GjFUNPQn0xzjD3TBrNGHS7FLvv44qZwNoSi6c+OyxyJ1jFn+ifFtYXwuBSh
prxOb1lkKe4YYbUPmwctIlI0ut/1gAbygTIXbMPx0pG8vi9yskKz2AVSawVv3VFFYWex
lx5el61LrgriAJGMWu7eaicucQOrTg2
PC1GtH9 z5XIHbAFIbDYxL7m7t5Y86uA+XP
Rx76xNHp61320sGtz6dyC5hwxDW5uuflyWDoD7BSZAC+ia4f£IXmDWxEn89RYY2ge
/xZ47GY/Gw4xU0x0zZxLELUdJ
yFUkK/WhCz 7nw6N3 eqfJwwwx6kP6ZSJ1mPK/WKiur
1y8VBymD /gAJ
=2mLj
12ND) PEND IEW IBIS AKERS IENLKOE
x—

igsintejeucjonesioe 8 INCOO Gis Wik mans 2OSs4. mii) S50) VALOy

ribcage fortitude gremlin Montana

Athens recipe trouble WAL Subie@ie
bison equation watchword breakaway
ellassne embezzle Hamlet aftermath
 AppendixA

Pusiic Key MATHEMATICS

(AND SOME Worps ON
RANDOM Numeers)

By Steve Burnett, RSA Security

In public key cryptography, what one key encrypts, the other decrypts. For some people, that’s all
they want to know. Some of you, though, may want more. How does it work? How can one key
encrypt yet not decrypt? How does the second key decrypt?
It’s based oh math and this appendix describes that math. Don’t worry; even if you’ve always said,
“T hate math” or “I was never any good at math,” you will be able to follow. The most difficult math
in public key crypto is long division.

Letters as Numbers
The first thing to know about public key cryptography is that it treats data as numbers. For example,
look at the letters s, a, f, and e. In addition to four letters, you could think of them as four numbers:
19, 1, 6, and 5 (s is the 19% letter of the alphabet, a is the 1*, and so on). You could put the letter
characters together and think of the result as one word: safe. Likewise, you could put the numeral
characters together and see the result as one number: 19,010,605 (see Figure A-1). The zeroes are
there to avoid confusion; without them, there could be multiple meanings. Without the zeroes, the
number would be 19,165, which could represent a, 7, p, e, or other letter combinations.
Now suppose we had some mathematical operation that manipulated the input. Maybe our
original 19,010,605 gets converted to 27,253,849. This mathematical operation has just encrypted
the original number. It just so happens that the word from which the number came has been en-
crypted as well. You cannot reconstruct safe from 27,253,849 (see Figure A-1).
Of course, if you want to recover the original plaintext, you need to perform some sort of “op-
posite” mathematical operation on the ciphertext number and convert that back to letters.
All public key algorithms do just this. They take your data—whatever that may be (e.g., letters
of the alphabet, raw computer data from a file, HTML material traveling on the World Wide Web,
etc.)—and treat it as numbers. They then perform various mathematical operations on those num-
bers and give you the results.

267
268 Appenpix A ® ~Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numeers)

safe
convert words to
big numbers

19,010,605
give the number
to the encryptor

it encrypts the
number

27,253,849

Figure A-1_ To encrypt letters, treat them as numbers; then encrypt the numbers. The letters are then
encrypted as well.

Why Math?
Why use math to encrypt? In symmetric key cryptography the operations are simply manipulations:
swap here, rotate there, exclusive-or someplace else. There is no real math involved. Why not use
the same sort of techniques to build a public key cryptosystem?
The answer is simple. No one has figured out a way to do public key cryptography except by
using math. In fact, if you asked a cryptographer if he or she thinks anyone will ever come up with
a public key algorithm that is not math, the answer will almost certainly be, “No, it’s impossible.”
Maybe someone will come up with a nonmath public key algorithm, but don’t count on it.

Yet Another Metaphor

The math of public key crypto is like a circular train track. On this track is a special train, which is
the only kind of train able to drive on this track. This train has no reverse, however, so it can only
go forward. The track is many miles long and next to the track, every foot or so, are boxes. There
are millions of boxes.
When Alice wants to send a message to Bob, she goes to his track. She starts at some random
point on the track. Next to that point is a box. She leaves the message, 7, in that box. Finally, she
rides the train a particular distance. How far? The public key tells her how far (see Figure A-2).
When she has traveled as far as the public key tells her, she gets out of the train and Bob gets
in. He rides a particular distance. How far? The private key tells him how far. If the public and pri-
vate keys match, Bob and Alice’s trips will travel the entire track. Together they make one revolu-
tion and Bob ends up where Alice started. He can get the message out of the box (see Figure A-3).
 Way MaTH? 269

Suppose an eavesdropper (call her Eve) sees where Alice stopped (see Figure A-4). She doesn’t
know where Alice started, though, and cannot recover the message. She could open each box along
the track until she finds the message. But because there are millions of boxes, that would take too
long. Furthermore, she cannot get into the train and backtrack because the train will not go in re-
verse. If she knew the dimensions of the track, maybe she could figure out, based on the public key,
how to backtrack without the train and recover Alice’s message. But the track is many miles long and
the only tool at her disposal is a one-inch ruler. It would take her too long to measure.

m m

Cc

Alice startsatsome The public key tells

random point and her how far to travel.
leaves her message.

Figure A-2 Think of public key encryption as a partial trip around a circular track.

The private key tells

Bob how far to travel.

Figure A-3 Think of private key decryption as the rest of the trip around the circular track.

Cc

What Eve sees

Figure A-4_ Eve sees only where the first trip ended, not where it started.
270 AppeNDIx A ® ~~Pustic Key MATHEMATICS (AND SOME Words ON RANDOM Numeers)

Some Background
Almost all public key crypto starts with the same mathematics. So before we talk about the specific
algorithms, let’s go over these concepts.

The Inverse
In cryptography, what we “do,” someone must later “undo.” The mathematical term related to this
concept of undoing is inverse. There are inverse functions and inverse numbers.
Inverse functions are pairs of operations. For example, multiplication and division are inverse
functions. What one function does, the other undoes (see Figure A-5).
Inverse numbers, on the other hand, are pairs of numbers. What one number does, the other
undoes. For example, 2 and % are multiplicative inverses (see Figure A-6).
Notice that if you use an inverse function, the second number stays the same, but the operation
changes. With inverse numbers, the operation stays the same, but it’s the second number that
changes. In other words, to undo an operation, you have two choices: (1) You can perform the in-
verse operation by the same amount, or (2) you can perform the same operation again, but this time
by the inverse amount (see Figure A-7).
In Figure A-7, look at the first line. Now replace the words starting point with the number 5.
Move on to the word operation and replace it with *. Substitute amount with 2 and the arrow with
=. Why do this? Just to see that Figure A-7 is a generalization, and 5 * 2 = 10 is a specific instance
of that generalization. Other operations could be other examples ofinstances of the generalization.
In fact, let’s look at another.

Start out at 5, multiply by 2, end up at 10

55S te (OP 10

10g-ie2sri=< 5
To undo the multiplication, divide

Figure A-5 Division is the inverse function of multiplication.

Start out at 5, multiply by 2,

Silt 52 = 940

10° S3G = 35
To undo the multiplication, use the inverse number

Figure A-6 With respect to multiplication, % is the inverse number of 2.

 Some BACKGROUND 271

starting point operation amount => result

result (ee a eae starting point

OR

starting point operation amount SS result

result operation inverse amount E> starting point

Figure A-7 After traveling a distance to get back to the starting point, either perform the inverse opera-
tion by the same amount, or perform the same operation by the inverse amount.

Other Inverses
Replace operation with “+.” What’s the inverse operation? It’sx, 66“ —“ of course. That one is easy. Think
about this one Replace starting point with “the corner of 6" and St. Joseph Streets.” The operation
could be “walk west” and the amount could be “one block.” The result would be “the corner of 7"
and St. Joseph Streets.” What’s the inverse operation? It would be “walk east” (see Figure A-8).
Let’s start at the corner of 6" and St. Joseph Streets again and perform our operation, “walk
west.” This time, however, we want to use the inverse amount, not the inverse operation. What
would the inverse amount be? It would be the amount necessary to circumnavigate the globe at that
latitude. Remember, when you want to use the inverse amount, you use the same operation. So the
question is really this, “Say we walk west one block and stop. Now we want to perform the same
operation again, ‘walk west,’ yet end up at our original starting point. How far would we have to
walk?”
We won’t end up at the starting point again until we have gone completely around the world.
Thus, in this case, the inverse amount is “circumference of earth at that latitude minus one block”
(see Figure A-9).

corner of 6th and walk one corner of 7th

St. Joseph Sts. west block (a and St. Joseph

inverse operation

corner of 7th and walk one : corner of 6th

St. Joseph Sts. east block and St. Joseph

Figure A-8 Another operation could be “walk west.” The inverse operation would simply be “walk east.”
272 Appennix A @ Pustic Key MATHEMATICS (AND Some Words ON RANDOM Numaers)

corner of 6th and walk one corner of 7th

St. Joseph Sts. west block — and St. Joseph

inverse amount

corner of 7th and walk rest of way corner of 6th

St. Joseph Sts. west around earth and St. Joseph

Figure A-9 If the operation is “walk west,” then the inverse amount is the amount necessary to perform
the same operation and end up where we started.

This sounds like an odd inverse amount. But it’s not a typical operation. The inverse amount
is what you need in order to end up where you started. And note that the inverse amount depends
on the latitude where you start. So there is no single inverse amount for the globe. To determine an
individual inverse amount, you have to know upon which latitude you’re starting.

Cryptographic Inverses
Similarly, in cryptography, there are inverse functions and inverse numbers. Actually, let’s call the
inverse number an inverse key. Symmetric key cryptography generally uses inverse functions, and
public key cryptography uses inverse keys. How do you get inverse keys? You use prime numbers
and modular math.

Prime Numbers
A prime number is simply a number that has only two factors, | and itself. For instance, 7 is prime,
since no number (other than | and 7) divides 7 evenly. On the other hand, 45 is not prime, because
3 and 5 divide it evenly. For example, 45 + 5 = 9 with no remainder.
A similar concept 1s relatively prime. Two numbers are relatively prime if they share no common
factors other than 1. For instance, 38 and 55 are relatively prime. Neither is prime, but the factors
of 38 are 1, 2, and 19, and the factors of 55 are 1, 5, and 11. The only number on both lists is 1, so
the two numbers are relatively prime. But 22 and 55 are not relatively prime because 11 divides both
22 and 55 evenly (see Figure A-10).

Modular Math
A modulus is like a maximum. Don’t look at numbers beyond the modulus. Working with modular
math simply means that when you reach the modulus, you start over. We’re all familiar with a form
 Some BACKGROUND 273

of modular math: the clock. Once you reach 12:00, start over. For example, 10 o’clock plus 4 hours
is not 14 o’clock, but 2 o’clock. The modular math we use in public key crypto is not exactly the same
as the clock, but it is similar. The important difference is we start counting at 0 and the maximum
value is actually the modulus minus one.
In modular math we deal only with positive integers—no fractions, no decimal points, and no
negative numbers. Only numbers less than the modulus are valid input or output to our operations.
For instance, suppose we choose 11 as our modulus. Then we are allowed to use only the numbers
from 0 to 10 as input (see Figure A-11).
Additionally, all our output will be numbers from 0 to 10. (Actually, as you'll see shortly, we can
have “intermediate” results that are negative or greater than the modulus. Final answers are always
greater than or equal to 0 and less than the modulus, but we may need to go outside the range for
a while before we get our answer.) It’s probably easiest to visualize modular math as a circle, simi-
lar to the clock, instead of a line (Figure A-12). Figure A-13 gives an example of arithmetic in modu-
lar math: 5 + 9 = 3 mod 11.

List the prime factors of the following numbers

7 45 22 55 38

‘ 1 1 1 1 1
7 3 2 5 2
5 11 od 1 19

prime, no not relatively

factors prime: share
other than not prime, common relatively
1 and itself has factors factor, 11 prime: share
other than no common
1 and itself factors

Figure A-10 These examples illustrate the concepts of prime and relatively prime.

Reach modulus,

Oe 10S BAS SiGe 7B 49 101 10) DA Qs)

Figure A-11_ As you travel down a number line, you might reasonably expect the number after 10 to be
11. But if we’re operating in modular math and the modulus is 11, the number after 10 is O because we start
over when we reach the modulus.
274 AppenpiIx A © Pustic Key MATHEMATICS (AND SomE Worps ON RANDOM NumBers)

Reach modulus
! -o 0
start over Re) 7

Figure A-12 In modular math we travel along a circle instead of a number line. With a modulus of 11, the
only valid input and output are the positive integers 0 through 10.

to add 5 and 9, move 5 spaces... ... then move 9 more.

5 + 9

Figure A-13_ To add 5 and 9 on a number line, you would travel 5 spaces, then 9 spaces, and arrive at 14.
On a modular math circle, you would travel 5 spaces, then 9 spaces, and arrive at 3.

Another way to approach it is to compute the “nonmodular” result and just travel that many
spaces around the circle. For example, Figure A-14 shows 6 * 3 mod 11. Since 6 * 3 = 18, travel 18
spaces around the circle.
How about 7* mod 11? This is an exponential: 7 raised to the 8° power, or 7 multiplied by it-
self 8 times (see Figure A-15). We could find the nonmodular answer and count that many spaces.
The nonmodular answer is 5,764,801. It would be too much trouble to count that many spaces.
There is a shortcut.
To perform 7° mod 11, we need to start at 0 and travel 5,764,801 spaces. If we make one com-
plete revolution of the track, we travel 11 spaces. We are at 0 again and we now need to travel only
5,764,790 spaces more. On the other hand, if we make four revolutions, we would travel 44 spaces
(4 * 11). Then we would be back at 0 and have only 5,764,757 spaces left (5,764,801 total minus the
44 we just traveled).
 Some BACKGROUND 275

That’s 11 spaces so far... ...and here’s 7 more to make a total of 18.

SOlO) 93.—=s/;mModiMr

Figure A-14 We computed the “nonmodular” answer, 18, then traveled around the circle that number of
spaces.

78

is the same as

DE Daa GFene
Sete: TOIT See ep,
rere
8 times
The answer is 5,764,801; you can
confirm this on a calculator.

Figure A-15 7° is an exponential, 7 multiplied by itself 8 times.

Likewise, ifwemake 524,072 revolutions, we will travel 5,764,792 spaces (524,072 * 11), we will
be back at 0, and we have 9 spaces left to travel (5,764,801 total minus the 5,764,792 we just trav-
eled). Once we travel those last 9 spaces, we’re done. What number did we land on? Nine, of course.
So the answer is 9.
But how do we know we want to travel a total of 524,072 revolutions? Division. To find
7° mod 11, compute 5,764,801 + 11 and you get 524,072, the number of revolutions. Any leftover
traveling (the remainder of division) will give us the answer (see Figure A-16).
So the rule could be, find the nonmodular answer, then divide by the modulus. The remainder
of that division is the modular answer. For example,

7® + 11 = something with a remainder of 9;

therefore,
imod j1= 9.
276 APPENDIX A © Pustic Key MATHEMATICS (AND Some Worps ON RANDOM Numsers)

524, 072 rem 9

11 |5,764,801 Division tells us that if we multiply 11 (our
55 modulus) by 524,072, we will get “close” to
26 the desired number. So do the
22 multiplication, the answer is 5,764,792.
44 What is the remainder?
44
~ 08 5,764,801 (this is the total to travel)
00— — 5,764,792 (this is 524,072 * 11)
80 9 (this is how many left over)
77
~
31
22
“9

Figure A-16 Long division (American style) describes modular math.

Some Exponential Identities

Let’s look at one last mathematical concept: identities. A mathematical identity is simply two ways
to say the same thing. For example, here’s a simple identity:

iss. Loe 41(0),¢

It doesn’t matter what number you place into x, the left side and the right side are always equal.
Put in 3 for x, you get 5 * (2 * 3) =10* 3. The left side is 5 * 6, which is 30. The right side is also
30.
Here is an exponential identity:

xe * x? — x (at)

It doesn’t matter what numbers you use for «x, a, and b. Again, the left and right sides are always
equal. See Figure A-17 for an example.
Here’s another exponential identity:

(xa)e = x (2%)

This one says, raise x to the ath power. Then raise the result of that to the bth power. The left
side always equals the right side. Figure A-18 is an illustration of this identity. 1
U8
VARIED
LE
With these simple math concepts, we can now examine the public key algorithms.
 Some BACKGROUND Q77

x? * yo = x(a+b)

For example,

3? is 3*3
and

3? is3*3*3
Therefore,

32 *°32='(3'*.3) 4:(3)*:3'* 3)

which is 3° or 32*3

Figure A-17_ This is an example of an exponential identity.

(x@)e = (ab)

For example,

33 is 3 * 3 * 3, and something? is
something * something

Therefore, if the “something” is 33...

(33)e137 2 32= (31013) (3.83.73)

which is 3° or 32°3

Figure A-18 This is an example of another exponential identity.

RSA
The most popular public key algorithm is RSA. The name comes from the initials of the inventors,
Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman. They used the fact that when a prime
number is chosen as a modulus, operations behave “conveniently.” One such convenience was dis-
covered by Pierre de Fermat in the 1600s (the name is pronounced “Fair-MAH”). He found that
if you use a prime for the modulus, then raising a number to the power (prime — 1) is 1. In other
words, for a prime p and any number m (well, any positive number 7 that is less than p),
nf’-”) mod p = 1.

Remember 7* mod 11? We computed the exponential, then divided by 11, and found the re-
mainder, which was the answer. How about 7!° mod 11? Should we compute the exponential and do
division? No, we know that 11 is prime and 10 is 11 — 1, so we use what Fermat discovered. We do
not need to make any computations to know that the answer is | (see Figure A-19).
Momodn tka)
278 Appenpix A @ Pustic Key MATHEMATICS (AND Some Words ON RANDOM Numeers)

Another mathematician in the 1700s, Leonhard Euler (pronounced “Oiler”), discovered that a
similar relationship exists when you use the product of two primes as the modulus. If 7 = p * g where
p and ¢ are prime, then
mek mod ns

For example, choose p = 11 and-g = 5. That means” = 55. It also means (p — 1)* (¢- 1) =
10 * 4 = 40. What is 38% mod 55? We don’t need to calculate anything; we know the answer is 1.
Actually, for this trick to work, the numbers m and n must be relatively prime. Since 38 is rela-
tively prime with 55, the equation works. Incidentally, that number being raised to a power (the m,
or 38 in this example) is known as the base (see Figure A-20).
Now let’s tweak Euler’s result by multiplying both sides of the equation by m.

me VoD Mod t= ie Im

Since 7 can also be written as 7z', here is what we would have:

hta MOGI =a

We can raise 77 to some power and the answer is 7 (see Figure A-21).
Mathematicians have a name for the number (p — 1)(g — 1); it’s called b(”), pronounced “phi of
n.” The symbol ¢ is the Greek letter phi, pronounced “fee.” Well, mathematicians pronounce it
“fee”; the academic honors organization Phi Beta Kappa pronounces it “fi” to rhyme with hi.

Fermat said this:

replace
the “m”
with 7

7° mod 11 = 1
and you have an example of this principle in action. No
need to make any pesky computations, the answer is
automatically 1. Or you can confirm this with a calculator.

Figure A-19 Fermat showed one way numbers behave conveniently when the modulus is a prime number.
 Some BACKGROUND 279

Euler said this:

m(P-1)(4-1) mod n = 1

replace
replace the “n”
the “m” with 55
with 38
replace the
\P=1)(G—-1)r
with (11-1)(5-1)

38°° mod 55 = 1

and you have an example of this principle in action. No

need to make any pesky computations, the answer is
automatically 1. Or you can confirm this with a calculator.

Figure A-20 Euler showed one way numbers behave conveniently when the modulus is the product of
two prime numbers. Note that the base (in this case, m, or 38) must be relatively prime with the modulus.

Remember the exponential identity?

with 1

“(p-1)(q-1)”
m(P-1)(4-1) *m' modn
= m(P-1(4-1) + 1

and you have an example of this principle in action.

Figure A-21 Apply the exponential identity in Figure A-17 to tweak Euler’s trick.
280 Appenpix A °® Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numsers)

This “special” exponent is [(p — 1) * (g — 1)] + 1. How is that useful? It means we can perform
some operations and end up where we started. For example, let’s compute powers of 7 with our
modulus of 55. Start with 7°, which is 7 * 7. To compute 7’, we need to find 7 * 7 * 7. We already
computed 7 * 7, which is 7’. So 7? is actually 7? * 7 (see Figure A-22).
Likewise, as Table A-1 shows, we can compute any power of 7 mod 55. ‘Take the result of the
previous computation and multiply it by 7. Of course, you need to find the modular answer from
that intermediate result. The final result will always be some number less than 55.
Notice in Table A-1 that when we reached 40, we did not do any computations. There’s no need;
we know the answer is 1. Same with 41. We don’t need to compute anything; we know that answer
is) 7:
Returning to our train track metaphor, we started at m and traveled a particular distance. We
then ended up where we started, at m. In the above example, we started at 7. If we travel “3” (which
means computing 7’, or 7 * 7 * 7), we end up at 13. If we travel “5” (7°, or 7*7* 7*7* 7), we end
up at 32. And if we travel “41,” also known as [(p — 1) * G — 1)] + 1, we end up back where we started,
17 Sei
If we can break that trip into two parts, we have crypto.

Table A-1 Computation of exponents of 7 modulo 55

What we're Re aimuloptication The result of the Compute the

computing multiplication modular answer

yf i 7 7 mod 55

P 77 49 49 mod 55
ie he) BD) i a AS 13 mod 55

iP eg 13) FS Ol 36 mod55

fie eet) XG Ss 252 32 mod 55

ie ree) BD dl a Ee: 4 mod 55

Te <don’t compute> <we know it’s I> 1 mod 55

Te <don’t compute> <itSylt ef 7 mod 55

ie 49 mod 55
 Some BACKGROUND 281

Tae = 49 = 49 mod55

P =7?*7 = 49*7=343 = 13 mod55

Remember 343 mod 55 is the remainder of 343 + 55.

343 +55=6rem13
or
oye” SYS) = SISKo)
343 — 330=13

Figure A-22_ Find 7°, then use that result to compute 7°. Remember we find the nonmodular result, then
divide by the modulus to get the actual answer. In this case, 343 mod 55 is the remainder of 343 + 55.

Two Trips .
Here’s how we can break that trip into two parts. Find two numbers, call them e and d, such that

e"d=((p=ne (q= 1),

Alice travels e. Bob then picks up where Alice left off and travels d. In mathematical terms, it
looks like this:

Alice: m® mod n™ c.
Bob: C7mod n= m.

Alice starts out at 7, her message, and travels a distance e. That’s the 7’. Where did she end
up? Who knows? She ended up somewhere, which we’ll call c for ciphertext. Now Bob starts where
Alice left off, c, and travels a distance d. That’s the c‘.
We know Bob will end up where Alice started, 7. How do we know? When we say that Bob
travels c’, we can replace the c with m’. After all, we know that ¢ = 7° mod n. So what Bob has re-
ally done is travel

(m?)? mod n.

This is actually m°*“ mod n. But what is e * d? It’s [(p — 1) * (g — 1)] + 1. So what Bob has actu-
ally computed is ~~"! mod n. What is that? It’s m (see Figure A-23).
When Bob makes his computations, he does not actually replace ¢ with 7°. He operates on c.
But mathematically speaking, operating on c is the same as operating on 7‘, since those two things
are equal (see Figure A-24).
282 AppenviIx A @ Pustic Key MATHEMATICS (AND Some Worps ON RANDOM Numsers)

Remember the exponential identity?

x? 6. (ab)

replace
replace
the “x” with the “6°

“m” and the

with “d”
“a” with “e”

(m*)? mod n = m*4

and you have an example
of this principle in action.
replace the “ed”
with (p-1)(q-1) + 1
since they are equal

= m(P-1(a-1) +1

Figure A-23 This illustration shows how we can put Euler’s trick and exponential identities together.

Bob computes
cd

replace the “c” with m¢,

since they are equal

(me)?
but (m*)? is the
same as m°¢

me4

replace with “ed” with

[(p—1)*(q-1)] + 1 since
they are equal

ml(P-1)*(a-1)] + 1

But we know what that value is: it’s “m”.

That’s how we know that cd =m

Figure A-24 Bob does not know what m is; but when he’s operating on c, it’s the same as operating on m*.
 Some BACKGROUND 283

Let’s return to our example. We had

p= 5.
Qa;
Nizrooe
Ke=1)* (Gti = 41,
We want to find an e and ad such that e * d = 41. Here’s where we run into a bit of bad news;
there is no pair of numbers that when multiplied together equal 41. It just so happens that 41 is a
prime number. Does that mean we cannot use this p and g? No, there is a way around this dilemma.
Remember when we described modular math, we said once you reach the modulus you start
over? That means that if we choose 40 as our modulus, 41 becomes 1 mod 40. In other words, find
e and d such that e * d= 1 mod 40 (see Figure A-25)
In the real world, to find e and d, you would pick an e and then determine d from it. The most
commonly used e¢is 3. So what is d such that 3 * d = 1 mod 40? This is a fairly easy problem to solve
using what is known as the Extended Euclidian algorithm (a description of which appears later). The
answer is 27.

3p 2 = 841.
e 81 + 40 = 2 remainder 1;

that is,

81 — (2 * 40).

Hence,

3 * 97 =1 mod 40.

You might be thinking, “Wait a minute. You were just talking about a modulus of 55. Now all
of a sudden you're saying the modulus is 40. Which is it?” This is the “trick” of the RSA algorithm:
two moduli. You use one modulus to create the keys and another modulus to encrypt. The
modulus to encrypt and decrypt is pg (p times g). The modulus to determine the key pair is
(p — 1)(q — 1), otherwise known as “p minus | times g minus 1.” Think of it this way:

0
39 1
te 41
38 ae 2
(49)
Figure A-25 If the modulus is 40, then 1 mod 40 behaves pretty much as 41 would behave. If we were
traveling along a number line, the numbers after 39 would be 40 then 41. But in modular math, those
positions are taken by O and 1.
284 Appenpix A © Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numeers)

Step 1: You find two prime numbers, p and q.

Step 2: Combine those two prime numbers by multiplying, 7 = pq.
Step 3: Combine those two prime numbers another way, ¢ = (p - 1)(¢ - 1).
Step 4: Using ¢, generate a key pair, e and d.
Step 5: Using e, d, and n, encrypt and decrypt.

In this example, the encrypting modulus is 55. The key-generating modulus is 40. The keys are
3 and 27 (let’s make the public key 3 and the private key 27). Once we have the keys, what do we do
with the 40? We don’t need it anymore, so throw it away (of course, throw it away so no one else
can find it).
Incidentally, remember when we were talking about inverses? We said there were inverse func-
tions and inverse numbers. We’ve just created an example of an inverse number. We have a num-
ber, 3, and its inverse, 27. How can 27 be an inverse of 3? Because it is the inverse modulo 40
G27 mod 40 1):
Each operation has its own special concept of inverse numbers. With multiplication, the inverse
of a number is “one over the number.” With “walk west,” the inverse of some distance was “the rest
of the way around the earth.” Now we have a modular multiplication inverse.
OK, back to the example. We can now do some encryption. For example, encrypt the letter s.
We convert it to a number and encrypt the number. It is the 19* letter of the alphabet, so let’s convert
it to 19. To encrypt the number 19, compute 19? mod 55. We can compute this on a calculator; the
answer is 39. That is our ciphertext. Figure A-26 shows how to make this computation on the cal-
culator that comes with Windows.
In our train track metaphor, we started at some point, 19. We then traveled a particular distance,
3. We ended up at some point, which happened to be 39. That sounds odd, but remember, we are
using a special train to “travel” (1.e., to perform modular exponentiation).
To decrypt, we need to compute 39”’. Your calculator may not be able to handle so large a num-
ber. One shortcut is to compute a table of select powers of 39 and combine them. The calculations
in Table A-2 take advantage of that trick we saw earlier, x’ * x’ = x“.

Table A-2 Select Powers of 39

What were Ag a multiplication The result ot the Compute the

computing multiplication modular answer

39! 39 39 39 mod 55

39? 39 * 39 1521 36 mod 55

39% BOL eG) = 306.” 36 1296 31 mod 55

59° Sp
Or = SilSil 961 26 mod 55

3916 B97 30 26" 20 676 16 mod 55

ee ee ee ee Some
eer BACKGROUND 285
see

; Calculator

Step 1: Enter 19, then click the x/y button (this button means “x to the
y”; the 19 is the “x”, the next number input is the “y”.

Step 2: Enter 3, then click the = button. After clicking the = button, the
display will read 6859.

Figure A-26 An example of modular exponentiation on a calculator (continued on next page).

286 Appennix A @ Pustic Key MATHEMATICS (AND Some Worps ON RANDOM Numeers)

Calculator

Step 3: Click on the Mod key, then enter 55.

Step 4: Finally, click on the = key and the answer is 39.

Figure A-26 (concluded) An example of modular exponentiation on a calculator.

 Some BACKGROUND 287

Look at what we did in the table. What is 39°, for example? It’s 39* * 39%, since 394 * 394 = 394),
We know what 39* mod 55 is; it’s 31. Hence, 398 mod 55 is 31 * 31 mod 55. With this table we can
find 39°’. Just as we found 8 by adding 4 + 4, we can add some numbers that together are 27. For
example, 16 + 8+ 2+ 1=27. Therefore,

39 Mod Dome= (89° 39° 4397 39) mod.55

= (16726 */36* 39) mod 55
= 584,064 mod 55
— 19.

We started out at 39, traveled a distance 27, and ended up at 19. That’s the original message we
were encrypting (see Figure A-27).
By now you've probably figured out that the operations are not partial trips around the track.
An operation is actually many trips around the track, plus a little bit more. That “little bit more” is
important. If you make 1 complete revolution around the track, you end up where you started. If
you make 1,000 revolutions, you end up at the same place. In other words, | complete revolution
and 1,000 complete revolutions look exactly the same. But once you’ve completed all the revolutions
necessary, you travel that last little bit, or partial revolution. Each trip ends with a different partial
revolution, orea “little bit more.”
But if you add the public key’s “little bit more” and the private key’s “little bit more,” they equal
one complete revolution.
So here is the RSA algorithm:

Find two primes, and call themp and 4.

Multiply them, and call the result 7.
Choose a public exponent relatively prime with (p — 1) and (g - 1), and call it e.
Find d such that e * d= 1 mod (p- 1) * (¢- 1).
Make 7 and e public, and keep d (andp and 4) secret.
To encrypt message m, ciphertext c = m‘ mod n.
bag
ed
the
ce
Ae
PB To decrypt, m = c’ mod n.

start with convert to encrypt (public decrypt (private convert to

a letter a number key of 3) key of 27) a letter

s———>
19 ————P 39 P19 Ps

Figure A-27 Our data took this path. We started with s, which is also known as 19. The 19 was encrypted
to 39. The 39 was decrypted to 19, which we know is another way of saying s.
288 AppeNDIX A © Pustic Key MATHEMATICS (AND SOME Words ON RANDOM Numsers)

Remember that the process involves two moduli. When we found our d (the private key), we
used a modulus of (p — 1) * (g - 1). Then when we encrypted, we used a modulus of p * g. Think of
this as a quirk of math. It just so happens numbers behave this way. And it is lucky they do, because
this “mixing of moduli” is what makes the algorithm secure. Here’s how.

Security
Suppose Eve has intercepted the ciphertext c, and knows 7 and e, the public key. How can she re-
cover m7?
Currently, the only known way to compute 7 (the message) from c (the ciphertext) is to use d
(the private key). But because that value is kept secret, Eve does not know what d is. Can she de-
rive d from 7 and e? Table A-3 lists the steps Eve would need to follow in order to find m.

Table A-3 Steps to Break RSA ©

What Eve wants to do How Eve can accomplish what she wants to do

Find 7. To find 7, Eve must know d.

Find d. ‘To find d, Eve must know e and (p — 1) * ¢ - 1).
e is known, so find (p — 1) * ¢- 1). To find (p — 1) * q — 1), Eve must knowp and 4.
Findp and ¢. To find p and g, Eve must factor n.

So to break the RSA algorithm, one needs to be able to factor numbers; that is, find all the
primes that evenly divide a number. For example, factoring 15 is easy; the prime numbers that evenly
divide it are 3 and 5. What about 44,197? With a calculator, it would not take long to factor it into
193 and 229:
But factoring 44,197 did take longer than factoring 15. Now imagine factoring 6,320,491,217.
Now how about a 200-digit number? Or 300 digits or more? Although mathematicians have been
studying this problem for a very long time, the only known ways to factor numbers take longer as
the numbers get bigger. In fact, if the number is big enough, even the fastest supercomputers would
need hundreds or thousands of years to come up with the answer. How big is big enough? Currently
1,024-bit numbers (about 308 decimal digits) are well beyond the capacity of current technology and
are expected to remain secure for many years. Therefore, if you want a secure RSA key pair, choose
big primes.
When you are encrypting with RSA, then, you don’t have to encrypt one letter at a time. Be-
cause your modulus is so big, you can encrypt many letters at once. Remember that we’re performing
modular math, and with modular math the input must be less than the modulus. But that also means
we can choose big numbers to encrypt as long as they’re less than the modulus. For example, we
converted the word safe into 19,010,605, which is 8 digits. If our modulus is 308 decimal digits, and
each letter is two digits, we can encrypt-as many as 154 letters at a time.
 Some BACKGROUND 289

Well, actually, in computers, all letters of the alphabet are converted to numbers that are at least
8 bits long. So if our modulus is 1,024 bits, we can encrypt up to 128 letters at a time.
You might be asking, “How does one find big primes?” Once again, it turns out that it is not
very difficult using what is known as the Fermat test (remember Fermat, the seventeenth-century
mathematician?). And there are many prime numbers. In fact, mathematical researchers’ tell us there
are more prime numbers of 512 bits or less than there are atoms in the known universe. In other
words, we will never run out of primes and the chances that two people use the same prime num-
bers in their keys are astronomically small. A section describing the process of finding primes is
coming up soon.

One Last Question

RSA works because we use inverse numbers. But isn’t there an inverse function? After all, we said
earlier that when you want to end up where you started, use either the inverse number or the in-
verse operation.
So is there an inverse function to RSA? If I know ¢, e, and 2, can’t I simply perform the inverse
RSA to get m? The answer to that question is yes. There is an inverse function to RSA, but no one
has been able to perform it in a reasonable amount of time. If the key is long enough, even the fastest
computers in the world would take hundreds, thousands, even millions of years to crank though all
the calculations.
Another inverse function would find d, the private key. The inverse function of modular expo-
nentiation to find the exponent is called discrete logarithms. Mathematicians have long been able to
find discrete logs. However, the known techniques for computing these values are very time-con-
suming. Once again, if the key is long enough, computers will not be able to make the computations
in a reasonable amount of time.
Another thought might be, “OK, so the inverse function is too time-consuming. But why can’t
just anyone compute inverse RSA keys? After all, if the owner of a key pair is able to compute an
inverse, then everyone else should be.” The simple answer is, that’s what makes public key cryptog-
raphy work. There are certain mathematical constructs where computing the inverse is easy for me,
but hard for you. This is a result of my limiting the amount of information I make public.
In our analogy, we used regular multiplication. The inverse number is “one over the number.”
In other words, the only information the attacker needs to figure out the inverse of a number is the
number itself. Since that’s an easy problem, we would not use regular multiplication as the founda-
tion of public key cryptography. But in RSA, in order to compute the inverse, one needs to know
three numbers, not just one. These numbers are p, g, and e. Remember, the public key contains e but
not p and q.

1. Did you ever wonder what a mathematical researcher does? It’s easy to picture a chemist doing research,
but a mathematician? Well, here’s a question mathematicians did research on: How many prime numbers
are there (at least an estimate)? Such research led to the prime number theorem, which is actually a collection
of “truths” about prime numbers, including a way to estimate how many there are of a given length.
290 Appennix A °@ Pustic Key MATHEMATICS (AND SOME WorDs ON RANDOM Numeers)

Bob has his p and g; Alice doesn’t. Therefore, Bob can compute the inverse, and Alice can’t.
Well, she has her own p and g, so she can compute her inverse. But it won’t be the same as Bob’s,
because they’ll have different p’s and q’s.
Your next thought might be, “That’s easy, then. To create public key cryptography, all I have to
do is use a mathematical construct where it takes a certain amount of information to compute an
inverse amount. Then if I keep some of the necessary information secret, only the owner of the
information (me) can compute the inverse.” Well, yes, that’s true. It is indeed as simple as that.
Good luck.

Finding Primes
The RSA algorithm depends on finding large primes. This is not very difficult to do. Here’s how:

1. Finda random number. °

2. Perform the Fermat test.

If it passes, great; you’ve probably got a prime. You can exit. If not, return to step 1.
What’s the Fermat test? That will be described shortly. But let’s actually try to find a prime more
efficiently.

1. Find a random number.

2. Make sure it’s odd, since all primes (other than 2) are odd.
3. Perform the Fermat test.
4. If it passes, great; you’ve probably got a prime. Exit. If not, continue on to step 5.
5. Add 2 to the current candidate (you now have the next odd number) and return to step 3.

There are software packages out there that use this method for finding primes. This algorithm
simply finds the first prime after a random value. You might be thinking, “That might last forever.
What if the next prime is not for a very long time?”
That’s a legitimate concern, it could be a time-consuming process. But mathematicians have
discovered that there are actually lots of primes. So many, in fact, that the “distance” between a
random number and the next prime is surprisingly small. How small? There’s a very good chance
that the next prime will be one of the next thousand odd numbers.
Of course, there’s certainly a chance it will not. However, computer programs have been writ-
ten to check the thousand odd numbers after a random number, and if no prime is found, to try a
new random value. These programs find primes in under four or five seconds on Pentium machines.
Actually, though, we can be even a little more efficient. It turns out the Fermat test is somewhat
slow. If there were a way to narrow the field before running the Fermat test, we could eliminate some
of the effort. There is a way:

1. Finda random number.

2. Make sure it’s odd, since all primes (other than 2) are odd.
 FINDING PRIMES 291

Divide by known primes.

a. Divide by 3. If it divides 3 evenly (that is, if our random number is evenly divisible by 3),
it’s not prime; don’t bother with the Fermat test. In fact, every third number after this ran-
dom value will also divide 3 evenly, so don’t try those either. Jump to step 5.
b. Divide by S. If it divides 5 evenly, it’s not prime (and every fifth number after it is not prime
as well).
c. Divide by 7.
d. Divide by 11.
e. ...andso on, divide by as many known primes as you want. If the number being tested di-
vides a known prime evenly, jump to step 6. If not, continue on to step 6.
Perform the Fermat test.
If it passes, great; you’ve probably got a prime. Exit. If not, continue on to step 6.
Add 2 to the current candidate (you now have the next odd number) and return to step 3.

This technique of dividing by known primes is known as sieving because it’s as if you’re drop-
ping numbers through a sieve. You let numbers that have known factors drop through, and those
for which we cannot find known factors remain to be tested further. This technique was first de-
scribed by Erafosthenes of Cyrene, a mathematician who lived from 276 BCE to 197 BCE. Cyrene
is now known as Shahhat, Lybia.
Let’s look at an example. Suppose we had the following random number:

116 (This is step 1, find a random number.)

It’s even, so we need to make it odd. That’s simple, add 1.
117 (This is step 2, make sure it’s odd.)
Divide by 3.
117 +3 = 39. (This is step 3a.)
We know 117 is not prime, since it divides 3 evenly. But we also know that 117 + 3, 117 +6,
117 + 9, 117 + 12, and so on (120, 123, 126, 129, etc.) are not prime, since they also divide 3 evenly
(see Figure A-28). So jump to step 6.
117 + 2 = 119. (This is step 6, add 2 to the current candidate.)
We now have the next odd number, 119, our next prime candidate. We have not eliminated this
number yet , so let’s perform the divide test. Actually, since we’ve already performed the divide test
with 3 and this number does not appear on our list of numbers that evenly divide 3, we know it does
not evenly divide 3. So don’t bother trying to divide by 3. Start with 5, then try 7.
119 + 5 = 23 rem 4. (step 3b)
119 +7 = 17.(step 3c)
292 AppENDIX A @ Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numeers)

Odd numbers with known factors, beginning with 117.

447 (divides 3 evenly)

119
121
423 (divides 3 evenly)
125
127
429 (divides 3 evenly)
131
133
435 (divides 3 evenly)
1337/

Figure A-28 Start with a list of possible primes, then cross off the numbers that evenly divide 3. Since 117
evenly divides 3, cross it off. Then cross off every third number after it.

So we can eliminate 119. And every seventh number after 119 will also evenly divide 7 (see
Figure A-29). Hence, we eliminate 126, 133, 140, and so on. Jump to step 6.

119 +2 Q—aOten (Step!)

The next number is 121. It’s not on the “divides 3” or “divides 7” lists, so try dividing by 5 and 11.

121 +5 =22 rem 1. (step 3b)

121 1ST (step 3G)

Eliminate 121, 132, 143, 154, and so on (See Figure A-30). Move on to step 6.

121+2=193.

We don’t have to do anything with 123 because it’s on our “divides 3” list. Skip any step 3 work,
and jump to step 6.

(PPR
wei eG do

The result, 125, divides 5 evenly. So eliminate 130, 135, 140, 145, and so on (see Figure A-31).
Jump to step 6.

125 +2=127.

The result, 127, does not divide 3, 5, 7, or 11 evenly. Let’s try the Fermat test.
 FINDING PRIMES 293

Odd numbers with known factors, beginning with 117.

+47 (divides 3 evenly)

449 (divides 7 evenly)
121
423 (divides 3 evenly)
1pos
127
429 (divides 3 evenly)
sph |
433 (divides 7 evenly)
435 (divides 3 evenly)
137

Figure A-29 Cross off the numbers that evenly divide 7. Starting with 119, every seventh number after it
evenly divides 7.

Odd numbers with known factors, beginning with 117.

+47 (divides 3 evenly)

+49 (divides 7 evenly)
424 (divides 11 evenly)
423 (divides 3 evenly)
125
127
429 (divides 3 evenly)
Si
483 (divides 7 evenly)
485 (divides 3 evenly)
1337/

Figure A-30 Cross off the numbers that divide 11 evenly.

Odd numbers with known factors, beginning with 117.

447 (divides 3 evenly)

449 (divides 7 evenly)
424 (divides 11 evenly)
423 (divides 3 evenly)
425 (divides 5 evenly)
127
429 (divides 3 evenly)
11534,
483 (divides 7 evenly)
485 (divides 3 evenly)
137

Figure A-31 Cross off the numbers that divide 5 evenly.

294 Appendix A @ Pustic Key MATHEMATICS (AND Some Worps ON RANDOM Numeers)

The Fermat Test

Remember that discovery Fermat made? For a prime p and a number m less than p,

m?-” mod p= 1,

What do you suppose 7?” equals?

mane “modp =n 1s
m?-'+! mod p= m.
m’ mod p= ™m.

Remember, this relationship (7 modp = m) is guaranteed to work if p is prime (see Figure

A-32).
What do you suppose would happen if p were not prime? What would the following equal ifr
is not prime?

m mod r

It turns out the answer is, “Who knows?” It could be anything. More important, it would prob-
ably not be m. For example, consider 2’? mod 9. The number 9 is not a prime, so the Fermat discov-
ery does not necessarily apply. You can find that answer on a calculator; it’s 0. How about 7° mod 15?
The calculator tells us it’s 13 (see Figure A-33). So you see, if we choose primes as our modulus,
numbers “behave conveniently.” If the modulus is not a prime, numbers don’t behave the way we
want them to.

Fermat said this, if p is prime:

m'°) mod p.=m

replace
replace the “p”
the “m” — with 13
with 7

7'3 mod 13 =7

and you have an example of this principle in action.

You can confirm this on a calculator.

Figure A-32 This figure shows an example of numbers behaving conveniently with a prime modulus.
 FINDING PRIMES 295

But if r is not prime:

m mod
r= ?
replace replace
the ern? the wes

with 7 with 15

7° mod
15 = 13
and the result is not what we started out with. Who
knows what it will be? It happens to be 13 here.

Figure A-33 This illustration shows numbers behaving inconveniently when the modulus is not prime.

That’s pretty much the Fermat test. Well, there is a twist: Make sure m is prime. We already
know a whole bunch of primes: 2, 3, 5, 7, 11, 13, 17, 19, and so on. Why use a prime for 7? That’s
coming up.
‘To be specific, here’s the test. We have a number we think might be prime. Call it our prime
candidate, call it 7, or call it whatever you want. OK, call itr. Take a known prime (call it 7) and find
m’ mod r. If the*answer is not 7m, then 7 is definitely not a prime. If the answer is ™, then 7 is prob-
ably a prime.
You might be troubled by the phrase “then 7 is probably a prime.” What do we mean by prob-
ably? Can’t we know for sure? It happens that there are combinations of m and r that are not prime
for which m’ mod r is equal to m. For example, compute 3° mod 6. It’s 3. So the number 6 passes the
Fermat test (if 3 is the 7).
In other words, we might have a prime candidate: It passes the Fermat test, yet in reality it’s not
a prime. Why? When the modulus is not a prime, the answer could be any one of the possible val-
ues (remember, the results of modular arithmetic are always the numbers less than the modulus).
One of the possible values is m, so there is just as much chance that the answer is as any other
value.
This is not likely to happen. In the real world we’re testing a number that’s 512 or 1,024 bits
long (154 to 308 decimal digits). That means the probability that the answer is 77 is one in a num-
ber larger than the number of atoms in the known universe. Actually, the underlying math is not
really that simple; but it is along these lines, and still, the probability of finding a nonprime that
passes the Fermat test is extremely small. In fact, if # is prime, mathematical researchers have de-
termined that the odds are even worse that a nonprime candidate will pass the Fermat test. That’s
why we choose a prime m when running this test.
Even though the probability is small, there is a chance. There is a solution to this dilemma. To
avoid these numbers, run the Fermat test using several known primes as mm. It turns out that those
nonprimes that pass the Fermat test with a particular 7 will almost always fail with another m. For
example, 6 passed the Fermat test when m was 3. What happens when m is 5? 5° mod 6 = 1. So 6 does
indeed fail the Fermat test, and we know it is not prime.
So when searching for prime numbers, when it comes time to run the Fermat test (FT), run it
more than once.
296 Appenpix A ¢ Pustic Key MATHEMATICS (AND SomE Worps ON RANDOM Numeers)

FT1: Find 2’ mod r. If the answer is not 2, give up; 7 is not prime. If the answer is 2, move on
to step FT2.
FT2: Find 3” mod r. If the answer is not 3, give up; 7 is not prime. If the answer is 3, move on
to step FT3.
FT3: Find 5” mod r. If the answer is not 5, give up; 7 is not prime. If the answer is 5, move on
to step FT4.
FT4: Find 7” mod r. If the answer is not 7, give up; 7 is not prime. If the answer is 7, say the
number is prime.

You could do more tests if you wanted. But research (including some by Ron Rivest no less) has
determined that you’d have to run this test for millions of years before you found a random
nonprime number that passed four rounds of the Fermat test.
There are numbers that pass the Fermat test that are not prime. Are there prime numbers that
fail the Fermat test? Is it possible to run the Fermat test on a prime number and mistakenly throw
it away? No. If a number is prime, it will always pass the Fermat test.
Incidentally, we had a candidate, 127. How does it do on the Fermat test? Your calculator may
not be able to handle such big numbers as 7'?”. Or maybe it can. If you want to try, go ahead. But
the answer is yes; 127 passes four rounds of Fermat.

Oe MOC ale hase.

3° mod 127 -='3.
Die MOG el27.5,
EImnod 12) = 7:

We'll say it is prime.

So to summarize, to find a prime,

1. Find a random value.

2. Make sure it’s odd.
3. Perform the sieve test. If it passes, move on to step 4. If it fails, go to step 5.
4. Pertorm four rounds of the Fermat test.
5. If it passes, call the candidate prime and exit. If it fails, move on to step 6.
6. Add 2 to the current candidate and return to step 3.

Finding the Inverse: The Extended

Euclidian Algorithm
To generate an RSA key pair, one must be able to find d such that ed = 1 mod (p - 1) * g - 1). An-
other way to state this is, one must be able to find d, the inverse of e mod (p — 1)(q — 1). How does
one find such an inverse? By using the extended Euclidian algorithm.
 FINDING THE INVERSE: THE ExTENDED EUCLIDIAN ALGORITHM 297

Donald Knuth describes Euclid’s algorithm as “the granddaddy of all algorithms, because it is
the oldest nontrivial algorithm that has survived to the present day.” Euclid published a form of the
algorithm in his book Elements in about 300 BCE, although historians believe a form of it was in-
vented up to 200 years earlier.’
What do we want to find? We have a number, say 7. And we have a modulus, say 40. What's our
d such that 7d = 1 mod 40? First, let’s give the algorithm, then we’ll explain why the algorithm works.
Create two columns of numbers as follows:
40 40
7 1
We'll do some simple multiplications and subtractions. How will we know what to multiply and
subtract by? We’ll make our decisions based on the numbers in the left-hand column. We’ll do to
the right-hand column exactly what we do to the left-hand column. We won’t even look at the con-
tents of the right-hand column when deciding what to do next.
Think of it this way: We will perform operations on the left-hand column, and the right-hand
column simply will be “along for the ride.”
Now, multiply the second row by a number. What number? Multiply by a number so the prod-
uct of this number and the second row is as close to the first row as possible without going over. How
do we know what the best number should be? We could try several numbers until we stumble onto
the correct oné, or we can divide. 40 = 7 = 5 with a remainder. The remainder happens to be 5 (a
coincidence). Therefore, multiply the second row by 5.
40 40
Ja = 150) {|bye ey

If we had multiplied by 6, we would have had 7 * 6 = 42. We want a number close to 40, but not
over. And notice we did to the right-hand column what we did to the left.
Now subtract the second row from the first.

40 40
7*5 = 35. 1*5=5.
40-35 =5. 40-5 =35.
Restore the second row to its original state and cross out the first row.

2. Ifyou don’t know, Donald Knuth is considered one of the giants in the history of computer science and soft-
ware engineering. Many call him “Saint Don.” Second, the story of the Euclidian algorithm illustrates that
the concept of “publish or perish” is nothing new. Some mathematician came up with a very useful algo-
rithm and did not publish it. His or her name is lost to antiquity. Euclid did not invent it, he just published
it, and to this day the algorithm bears his name.
298 AppenDIX A © Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM NumBeRrs)

What was the second row is now the first row. And what was the result of our arithmetic is now
the second row.
Do it again. 7 = 5 = 1 rem 2. So multiply the second row by 1 and subtract the result from the
first row.

Omg
we
7 1
5 lS: 30) 1h=135s
1—S=2; 1-35 =-34.

We now have a new first and second row.

And again (5 + 2 =2 rem 1).

5 | 35
2*9=4, -34*
2 =-68.
Bed i 35 — (-68)
= 103.

How do we know when to stop? When the result in the left-hand column is 1. And that’s what
we have now.
$46

2 -34
1 103

Now what? Look at the number in the right-hand column. It’s greater than the modulus. In
modular math we’re not allowed to have numbers greater than the modulus. No problem; perform
modular reduction (which we saw earlier).
 FINDING THE INVERSE: THE EXTENDED EUCLIDIAN ALGORITHM 299

103 mod 40= 103

- (2 * 40) = 103 - 80 = 23.

And that’s our answer, 23. That is, the inverse of 7 mod 40 is 23. Try it, 7 * 23
mod 40 = 161 mod 40 = 1.
When discussing RSA, we had the number 3 and a modulus of 40. We said the inverse was 27.
Let’s use the extended Euclidian algorithm to verify.

40 40
3 1

AOE 23i—al
so heme.

40 40
3*13=39. 413293.
40 - 39 = 1. 40-13 =97.

So the inverse is 27.

By the way, the answer might be a negative number. We said at the beginning that our inter-
mediate values can be outside the range, but our final answer is always a number greater than or
equal to 0 and less than the modulus. How do we convert a negative number into an appropriate
value? Simply subtract. Find the modulus minus the value. For example, what is -13 mod 40? See
Figure A-34. It’s simple:
—13 mod 40 would be 40 — 13 = 27.

go back 39 2 1
13 spaces 38 9

Figure A-34 If a number is negative, to find the modular answer, go “backwards.”

300 AppENDIX A @ Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numeers)

And that’s the extended Euclidian algorithm. Keep doing the multiply/subtract operation un-
til the answer in the left-hand column is 1. Perform the same operations to the numbers on the right.
When the left-hand column is 1, the right-hand column is the inverse. Just make sure you start with
the appropriate values in the appropriate places.

Why This Works

What you’re doing to the left-hand column is creating a path to 1. You have the modulus and the
number you want to invert (in our first example, the number to invert was 7). What does it mean
to invert 7 modulo 40? It means find the number that when multiplied by 7 mod 40 gives you 1.
What does it take to get from 7 to 1? Create a path using the multiplication/subtraction steps.
At the same time, start at 1 and take the same path. If this path takes 7 to 1, where will this path
take 1? The inverse of 7.
Is that a good enough explanation? No? How about this?
We think there are four numbers linked together in a special palate ai These inibers are
40, 7, 1, and some unknown value. Call this unknown value7 for “inverse.” We believe there is anz
such that 7 * 7 mod 40 = 1.
If we didn’t have the mod 40, the solution would be easy. We would use division: If 7 *7 = 1, then
i = 1/7. This is simple algebra: What you do to one side of the equation, you must do to the other.
We started with 7 *7 = 1. If we divide the left side of the equation by 7, then that side ends up be-
ing 7. But then we have to divide the right side of the equation by 7 as well, which leaves it as 1/7.
With the mod 40, we’re doing something similar. We start with 7 * 7 mod 40 = 1 mod 40 and
use division. Except this is modular math, so we have to use a special kind of division. The answer
to an “extended Euclidian algorithm divide” is the remainder of a normal divide.
Remember the first step? We had 40 and 7. We divided and got 40 + 7 =5 rem 5.
After the first “iteration” of this algorithm, the left-hand column contained 5. We said we had
computed 40 — (5 * 7), but isn’t that the definition of the remainder?
But to come up with an inverse, we have to end up at 1. After one divide, we didn’t end up at
1. So divide again. And again, until we do end up at 1.

Other Public Key Algorithms

We’ve now described the RSA algorithm. Everything about it. How to find primes and inverses and
how to encrypt and decrypt.
There are other public key algorithms. Here we’ll discuss some of the more popular ones:
Diffie-Hellman, DSA, and elliptic curves.

The Diffie-Hellman Algorithm

The name of this algorithm comes from the inventors, Whitfield Diffie and Martin Hellman. In this
algorithm, you can’t encrypt and you can’t do digital signatures.
 OTHER Pustic Key ALGORITHMS 301

Then what, you may ask, does it do? It performs “key agreement.”
The first problem public key cryptography tried to solve was how to get symmetric keys into
the hands of a correspondent without sending secret information over a public wire. With RSA, we
generated a random secret key and encrypted it using the recipient’s public key. With Diffie-
Hellman, we’re going to use the recipient’s public key to generate a secret key, then send public
information over the wire so the recipient can generate the same secret key.

Step 1: Generate the Key Pair

Alice wants her correspondents to use the Diffie-Hellman algorithm when sending messages. So she
generates her Diffie-Hellman key pair:

¢ Modulus: a big prime number (probably 1,024 bits long).

¢ Base: a number less than the modulus (it should possess some special properties described later).
¢ Private exponent: a random number (probably 160 bits).
¢ Public value: this is the base raised to the private exponent modulo the modulus.

In math notation it looks like this:

Find a prime p and generate a base g (with the special properties described later) and random
private exponent x1. Now compute the public key, call it yl, by performing g*' mod p. That is,
yl =g"' mod p.
Alice makes g, p, and yl public (those three numbers together are the public key) and keeps x1
private (so x1 is the private key).

Step 2: The Correspondent Computes Values

When Bob wants to communicate with Alice, he finds her public key and computes some values.
First he generates a random exponent, call it «2. He uses that random exponent to build a public
value, call it y2, by computing g*’ mod p. He uses the same g and p he got from Alice’s public key.

Step 3: The Correspondent Computes the Secret Value

Once Bob has his x2 and y2, he can build the secret value, call it s, by computing yl"? mod p. He’s
using Alice’s public key and his random exponent to generate the secret value.
This computation produces a number, some number, that we’re calling s. Bob uses some of the
bits of that number s as the secret key. He can use that secret key with a symmetric algorithm to
encrypt his message to Alice.
Along with the message, he sends Alice his public value, y2.

Step 4: Recipient Computes the Secret Value

Alice has Bob’s y2. She uses it to compute s = y2"' mod p. Now that she has s, she can build the se-
cret key and decrypt the message.
302 ApPENDIX A @ =Pustic Key MATHEMATICS (AND SOME WorDs ON RANDOM Numeers)

Wait a minute, Bob used yl and x2 to build s, and Alice is using y2 and «1. They’re starting with
different numbers, so won’t they end up with a different result? No, they will end up with the same
answer, guaranteed. Here’s why.
Remember that identity we saw earlier?

(x2)? = X70),
Change the letters and you have Diffie-Hellman.

Bob computes Alice computes

s=yl” mod p. s=y2* mod p.

But what is yl? But what is y2?
yl = g*' modp. y2 =g” mod p.
So another way to say what Bob computes is So another way to say what Alice computes is
sai)? mod p. s=(g”)*! mod p.
But this is that identity But this is that identity
s=g" ” mod p. s= 9 “| mod p.

They’re the same. Even though Bob and Alice use different input, the math is such that they
will produce the same output.
Here’s an example. Suppose Alice uses these numbers:

Di=toon
G=18.
x1 = 10.

That means

YAl=318'° mod 53.=24.

Bob finds Alice’s public key ($3, 18, and 24) and does some calculations of his own. Remember,
his x2 is just some random number.

Ol alte
y2 = 18"' mod 53 = 48.
$= 24"! mod 53 = 15.

Bob uses 15 as the secret key. He encrypts the message with some symmetric algorithm and
sends Alice the encrypted message and the number 48 (his y-value).
Alice now generates

§ = 48° mod 53 = 15.

 Orner Pustic Key ALGORITHMS 303

She uses 15 as her key and decrypts the message.

Both Bob and Alice generate the same secret value, even though they use different inputs to the
algorithm.
OK, what are those special properties of g? It must generate lots of different answers for dif-
ferent exponents. For instance, if our g is 52, what would g" be?

x1 g*

1 5

2 1
3 52
4 1
and so on

We don’t want 52 as our g; there are not that many possible answers. Remember, our secret value
(ultimately our secret key) is going to be a power of g. If 52 is our g, there are only two possible keys,
1 and 52. That’s not very secret.
But mathematicians have devised ways of generating g’s so that there will be lots of numbers with
different exponents. The use of the letter g comes from the word generator, because it is the num-
ber that will generate many answers. When the modulus is 53, the number 52 generates only two
possible answers. On the other hand, 18 generates 52 answers.
Incidentally, it is possible for two people to use the samep and g and the algorithm will still be
secure. However, in writing computer programs (the author has written plenty of Diffie-Hellman
code), it’s just easier if everyone uses a differentp and g. And sharingp and g does not buy you any-
thing significant. Since it’s not that difficult to find primes, you might as well find a new prime for
each user.

Security
Suppose Eve listens in on the conversation. She has the encrypted message, Alice’s public key (53,
18, and 24), and Bob’s public value (48). From all that information, can she come up with the secret
key and decrypt the message?
Eve has to compute 24 raised to some power or 48 raised to some other power to figure out the
secret. She doesn’t have to know both “some power” and “some other power”; just one. Bob used
11 and Alice used 10. In fact, those are the only two numbers that will work. But those numbers were
never sent over the wire. If Bob and Alice are smart, they’ll keep those numbers secret.
But Eve knows that 24 = 18"! mod 53. Can’t she simply “solve for x1”? Well, yes, she can. This
is known as the discrete log problem. Mathematicians know how to solve for «1 in this situation. The
problem is, the only known ways to solve this problem take so long to perform the computations
that even the fastest supercomputers would probably take thousands or even millions of years to find
the answer.
304 Appenpix A °@ Pustic Key MATHEMATICS (AND SomE Worps ON RANDOM Numeers)

Well, it will take all those years if the key is long enough. And how long should the key be?
Currently, 1,024 bits is secure and it is believed that 1,024 bits will remain secure for many years to
come.
So, given only the information that travels on the wire, Eve will not be able to figure out the
secret key.
One last note, we said 1,024 bits is the preferred length of RSA keys. Now we’re saying 1,024
bits is the length of Diffie-Hellman keys. Is that a coincidence? No, it’s not a coincidence. To break
RSA, you factor. To break Diffie-Hellman, you use discrete logs. These two problems are math-
ematically similar. It is generally believed that if you break one, you break both.

DSA
The letters DSA stand for digital signature algorithm. As the name implies, it is an algorithm that can
perform only digital signatures. This may sound impossible. After all, isn’t a digital signature the
encryption of a digest? If an algorithm can create a signature, then by definition, it encrypts, right?
DSA does not encrypt the digest. What it does is perform some mathematical operations on
some input and produce a couple of numbers. The input is the digest of the data to sign, the pri-
vate key, and a random number. The random number is generally called &. The output is a pair of
numbers, generally called r and s. Those two numbers together make up the signature (see Figure
A-35).

‘Datato
sign

DSA
Algorithm

Signer’s DSA
private key

Random “k”

Figure A-35 DSA signing takes in three inputs and gives two numbers as a result. These numbers make up
the signature.
 OTHER Pustic Key ALGORITHMS 305

If you have r and s, you cannot reconstruct the input values. With RSA, the signature could be
decrypted back into the digest of the data to sign. You can’t do that with DSA. It’s one-way.
‘To verify a digital signature, DSA performs some mathematical operations on some input and
produces a number. The input is the digest of the data to verify, the public key, and the s value from
the signature. The output is a number, generally called v. If v= 7, then the signature verifies (see
Figure A-36).
Remember that with Diffie-Hellman two parties produced the same secret value with different
input. DSA is doing something similar. Two sets of input can produce the same output, so long as
there’s a mathematical relationship between the two sets of input.
If there’s no mathematical relationship between the two sets of input, the two values, r and v,
will not be equal. And in what situation could we have a breakdown in mathematical relationship?
We could have a breakdown if the public key is not the partner to the private key used to sign.
Hence, if you have an r and v that match, then you know the only way someone could have
created the vis if he or she had access to the private key. Therefore, the owner of the private key must
have signed.
So how does it work? Math. And unfortunately, the math for DSA is a bit more complicated than
for RSA or Diffie-Hellman. At its foundation, DSA employs modular exponentiation just like RSA
and Diffie-Hellman, but it also uses modular inverse and multiplication.
e

Data to
verify

DSA
Algorithm

Vv:

ee,
Signer’s DSA
public key

Figure A-36 DSA verifying takes three inputs and gives one number as a result. If this one number matches
the rof the signature, the verification passes.
306 Appenvix A @ Pustic Key MATHEMATICS (AND SomE Worps ON RANDOM Numsers)

Those operations in and of themselves are not very difficult. It’s just that the number of steps
to sign and verify are numerous. And then to show that the v and v are indeed equal if the public and
private keys are a valid pair requires many steps of algebra.
It’s not difficult to understand, just long. And although in this appendix we usually do not shy
away from math, we are going to punt in this case.

Why DSA?
Back in the days of strict export control, U.S. cormpanies could not send their cryptographic code
outside of North America. Well, they could, but only at low key lengths. The U.S. government
considered crypto to be munitions and did not want it to get into the wrong hands. If it did, then
those hands could protect secrets the United States could not discover.
But DSA performs only digital signatures. People can’t use it to keep secrets, one to authen-
ticate. So there were no export restrictions on DSA.
If you wanted to build an application that performed digital signatures, you could use RSA.
However, the export of that algorithm was restricted, even if all you wanted to do was digital sig-
natures. So you couldn’t get full-strength RSA signatures.
Or you could use DSA to perform your authentication and use it at full strength.
The truth is, however, that if you had DSA code, you had Diffie-Hellman code. Well, with some
tweaks here and there you would. And in fact, with a few more tweaks, you had RSA code.
That means that anyone who exported DSA was in effect exporting Diffie-Hellman and RSA.
But the U.S. government allowed it nonetheless.

Elliptic Curves
Lately, another class of public key cryptography has emerged. This new family of algorithms is
known as elliptic curves (EC for short, or ECC for elliptic curve cryptography). It grew out of re-
search that was looking for formulas to determine the areas of ellipses. This research led mathema-
ticians to a family of equations that have special properties. These properties made it easy to adapt
the equations to cryptographic use.
First, Figure A-37 shows an elliptic curve. It’s not the only shape an elliptic curve can take, but
it is a common one.
Here’s the equation of an elliptic curve:

y®=x?4+x4+Q,

A point on the curve is a pair of numbers, x and y, that make the equation equal. For instance,
ifyis 2 and x is 1, then the equation looks like this:

Ore 1 + 1 +2
4=1+1+2.
 OTHER Pustic Key ALGORITHMS 307

Figure A-37 This is an elliptic curve. Not all elliptic curves look like this, but this is a common one.

So if you went to the graph and plotted ( = 1, y = 2), you’d find it lands on the curve.
Why is that equation above an elliptic curve? Because it follows a particular format. Here’s the
general format:

y? + aXy+ 4Y=X°+ ax? +ax+ a.

The values for the a’s (the a,, a,, a, and so on) are numbers. In our example, 2,, 2,, and a, were
0; a, was 1; and a, was 2. If you plug in any values for the a’s, you'll have an elliptic curve.

Prime Modulus
Cryptographers noticed that elliptic curves behaved conveniently when operations were performed
with a prime modulus. Actually, for the numbers to behave more conveniently, the values for the a’s
had to adhere to certain conditions. The first condition is that a,, 2,, and a, be 0. Then to make it
more confusing, the cryptographers decided to rename a, to a and a, to b. That means a crypto-
graphic elliptic curve is

y? mod p= (x?+ a* x+ 6) modp.

For example, let’s take our elliptic curve example and apply to it the modulus 11.

y® mod 11 = (x?
+ x+ 2) mod 11.

Now we’re only allowed to use integers from 0 to 10 as input. If we plug in 5 foryand 9 for x,
here’s what we get:
308 AppeNpix A — Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numeers)

25 mod 11 = (729 +9 + 2) mod 11

25 mod 11 = 740 mod 11
25 =(2 * 11) = 3 and 740 — (67 * 11) =3.

Both sides are 3, therefore the equation holds (you can confirm this on a calculator). Hence, we
have a point on our curve: (x = 9, y = 5).
You could find other points on the curve. For instance:

(1, 2) (6, 2)
C9) (6, 9)
(2, 1) (8, 4)
(2, 10) (9, 5)
(4,2) (9, 6)
(4, 9) infinity
In each pair of numbers, plug in the first number for x and the second for y (yes, it’s annoying
that the y comes first in the equation and the « comes first in the point description; math is like that
sometimes).
It would be easy to confirm that all these points make the equation work. Well, all but one
point—infinity. What’s that? That’s kind of a “cheater” point. In doing elliptic curve calculations,
sometimes we are forced to divide by 0. But you can’t divide by 0; that’s just not done.
Think about it; what’s 7/0 (seven divided by zero)? How many times will 0 go into 7? Zero times
what equals 7? There is no answer. No matter what you multiply by 0, the answer is 0.
Mathematicians sometimes “cheat” in such a situation; they use infinity. They say 7/0 is infin-
ity. Not always, but sometimes they do. In elliptic curves, they do.

Adding Points
Suppose you have two points on an elliptic curve and you want to add them. How would you? Just
add the «’s and y’s? No, it’s a bit more complicated. (Why so complicated? The answer to that ques-
tion is coming soon.) There are five rules of adding in the cryptographic elliptic curves we’re talk-
ing about right now. (Don’t try to understand all these rules now; just skim over them.)

Rule 1: infinity + infinity = infinity.

Rule 2: («,, y,) + infinity = (x,, y,)-
Rule 3: («,, y,) + @,, ~,) = infinity.
 OrHER Pustic Key ALGORITHMS 309

Rule 4: If x4 Rash Bsiy.) ae (X55

Vp)= yy 3)
where
x, =(\’ — x, -x,) mod p,
¥; = A@, — x) —y,) mod p,
and
Y>, SA
= EES modp.

Rule 5 (doubling): Ify, # 0, (is

9) + @, Hy) =2@
5.9,) = 5)
where
x, = (\? — 2x,) mod p,
¥, = A(w, — x,) —y,) mod p,
and
we 3x +a '
7. p.
Incidentally, the above rules require modular division. How does that work? Suppose we had
4/3 mod 11. What we’re really looking for is some number, call it t, such that 3 * t mod 11 = 4. Al-
gebra tells us taat what we do to the left side of the equation we do to the right. Multiply the left
by 3"! (three inverse, the number you multiply 3 by to get 1; remember the extended Euclidian al-
gorithm?). That means we have to multiply the right by 37':
Syl eseh fefimrexe!
Iq) = St 4.

Since
Soles =)
we have

EMOCMik= Sea e4:

Using the extended Euclidian algorithm, we find that 3" is 4 (3 * 4 = 12, which modulo 11 is 1).
That means the answer we’re looking for is 4 * 4 mod 11. 16 mod 11 is 5. So 4/3 mod 11 is 5.
OK, back to the addition rules. And what a set of rules it is! They’re not very intuitive. So why
have such a convoluted, complicated set of rules? (Here’s the answer promised earlier.)
Because.
That’s about as good an answer as there is. Because. The numbers just behave that way. Math-
ematical researchers figured it out.
Well, maybe there’s a little more to it than “because.” It turns out that with these sets of rules,
when you add one EC point to another, the result is a third EC point. Take two points on our sample
curve. Using the rules, add them together. Now check the answer. Does it make the equation work?
Take two EC points and try another set of addition rules. What do you get? Who knows, but
it won’t always be a point on the curve.
Take some curve (is it an EC curve? Maybe, maybe not) and find two points on that curve. Now
add those points following the EC rules. Is the answer another point on the curve? No? Then the
curve is not an elliptic curve.
310 AppennixA © Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numeers)

Notice something else about the curves. Sometimes in the computations, we divide by 0. If that
happens, stop the computations; just say the answer is infinity.
Notice also, that this weird point called infinity behaves like 0 would in regular addition. Add
something to infinity (rule 2), and you get the original something. Add something to its negative
(rule 3), and you get infinity.
Put this all together (the prime modulus, the rules for addition, and the infinity point) and
numbers behave conveniently.
Now add one more interesting little tidbit—multiplication. Say we have a point P on an ellip-
tic curve. Let’s multiply that point by a number, d. This number d is not a point on the curve; it’s
just a number. For example, let’s multiply the point (4, 2) by 3. That is, we’re finding

OP,
where dis 3 and Pis (4, 2).

Here’s how it works, find P + P + P. We first find P + P. That’s rule 5, the rule of doubling. The
result of that is some other point P, on the curve. Now find P, + P. That’s rule 4.

P+ P=(4, 2) + (4, 2) = (8, 7). Call this point P,

lee + P=(8, 7) + (4, 2) = (4, 9).

This is

Race Pe Ole
Sa P,

You can confirm that these are the right answers. Just make sure you follow the rules.
Thus, 3 * (4, 2) is the point (4, 9).
That number d (3 in the example) is known as a scalar, a single number used with nonsingle
numbers. A point is a pair of numbers, so it is not single. What we’re multiplying the point by (in
this case, d) is just a single number, so we call it a scalar.
Finally we can get to some cryptography.
Find an elliptic curve (which means you find a modulus p and parameters a4 and b) and a point
on that curve. Call this point P (isn’t that annoying that the cryptographers call the modulus lower-
case p and the point uppercase P?). Now take a random scalar d and find d * P. The result of this
multiplication is another point on the curve, Q. By the way, keep d secret.
Announce to the world your curve and tell everyone what your P and Q are. Then challenge
them to find d.
No one has yet figured out a way to find d in a reasonable length of time. If your modulus is big
enough (say 170 bits, which is about 51 or 52 decimal digits), the fastest supercomputers in the world
would still need thousands of years to find d.
We have cryptography. Someone can do a particular computation fairly easily, namely scalar
multiplication on an elliptic curve, but the inverse is extremely difficult. It’s a one-way function.
 Orner Pustic Key ALGORITHMS 311

The EC Diffie-Hellman Algorithm

One way to perform cryptography with elliptic curves is to do something similar to Diffie-Hellman.
In fact, the accepted name for this is indeed EC Diffie-Hellman.
Alice has her elliptic curve and two points. She also has a d, but she keeps that secret. Her d is
just some random number.

Alice’s public key: p, a, 6, P, Q,...

Alice’s private key: d,._.

Bob gets Alice’s public key and computes his own d. It’s just a random value. Next he finds a
point Q by multiplying dP.

Bob’s public key: p, a, 6, P, Q,..

Bob’s private key: di.Bob

Bob then multiplies his d by Alice’s Q.

e Secret value: S = (oRad © eae

What is Q,,,..? It’s d,,_.P. So what Bob has really done is compute

Secret value: S=d,,d,..

Bob ~ Alice
P.

He never knows what d pa ci_ 1s, but operating on Q,.,.. is mathematically equivalent to operating
Gnas
Alice
Now Bob sends Alice his Q. And Alice operates on that Q.

Secret value: ty SLees= 3 Rep Olees

What is Q,,.,? It’s d,,,P. So what Alice has really done is compute

Secret value: S= do, P.

That’s the same thing Bob computed.

Bob can use the secret value he computed to build an encrypting key. When Alice gets the
message from Bob, she uses the secret value she computed to build the decrypting key. It’s the same
secret value, so they use the same key. What Bob encrypts, Alice can decrypt.
Actually, since that secret value is another point on the elliptic curve, and the encryption key is
just a number, Alice and Bob need to decide beforehand how to extract a single number from a point.
The most common way is to use the x-coordinate, the x portion of a point. Remember, any EC point
is a pair of numbers, « and y. When it comes time to extract a single number from the point, just grab
the x number. What happens to the y? Nothing; it’s just ignored.
312 Appenpix A @ —Pustic Key MATHEMATICS (AND Some Worps ON RANDOM Numeers)

Security
Suppose Eve the eavesdropper listens in on Alice and Bob’s exchange. Eve knows what p, 4, 6, P, Qy),..
and Q, , are. Can she figure out what S is? In order to compute S, one must know either d,,... or a...
No one has ever been able to figure out how to determine S any other way. But Alice and Bob keep
their d’s secret. So Eve is out of luck.
Well, maybe she can figure out one of the d’s. For instance, she knows that

QWuice = Anice?,

and she knows Q,.. and P. All she has to do is solve for d. But this is that difficult problem we were
talking about. No one has been able to solve it in a reasonable amount of time.
Incidentally, that problem is known as the e//iptic curve discrete log problem.

More Uses for Elliptic Curves

Elliptic curves can be used to compute digital signatures.
Just as there is an EC Diffie-Hellman, there
isan EC DSA. Elliptic curves can also be adapted to perform encryption. Although, for performance
reasons, it’s rarely done in the real world.

Why ECC?
Why use ECC? Performance, key size, and data transmission size. Suppose you had an RSA key pair
of 1,024 bits (the most common size used in the real world). How long should an EC key be to get
the same level of security? Current research indicates it should be 170 bits.
At 170 bits, creating an EC digital signature using the DSA format is significantly faster than
RSA. To verify a signature, RSA is still faster than EC DSA. The combined times (signing time plus
verifying time) favor ECC.
Some digital signature applications use small, constrained devices (e.g., a Palm Pilot or smart
card) to compute the signature. Signature verification is performed by a very fast coinputer. The
signing machine has limitations and public key operations are slow. Since the server side will be
blazingly fast, regardless of the algorithm chosen, verification performance is not an issue. But sign-
ing performance is important. So developers can use ECC to make sure the signing portion is as fast
as it can be.
Another reason to use ECC is key size. Your signing device has to store the private key. An RSA
private key takes up about 256 bytes (maybe a few more) of space. The ECC key takes about 20 bytes
(maybe a few more) of space. If the signing device is a smart card, that can be an important 236 bytes.
The third reason is data transmission. When signing, the signer must send the signature out;
when performing EC Diffie-Hellman, the participant must send the intermediate values, that Q.
With RSA, the signature is 1,024 bits, and a key exchange intermediate value is 1,024 bits. An EC
signature is about 320 bits, and a key exchange intermediate value is 340 bits. Once again, if the
hardware performing the operations is a smart card or other small device, transmission of bits might
be expensive. If so, smaller values would be important.
 OTHER Pustic Key ALGORITHMS 313

Trade-Offs
Actually, ECC signing is significantly faster than RSA only when used with precomputed values.
That is, you can store your ECC key in a small space, but if you want to get the performance ad-
vantage, you also have to store some tables of precomputed values. These tables can be as many as
20,000 bytes. But if you don’t have 20,000 bytes of storage space laying around (e.g., on your smart
card), you may not be able to use the precomputed tables. If you don’t, then ECC is not that much
faster than RSA.
With ECC you can sign fast or save storage space, but you can’t do both. Of course, saving stor-
age space and transmission size may be reason enough.
Furthermore, using ECC with or without precomputed values to perform key exchange is not
much faster than using RSA. The only real advantage to using ECC to perform key exchange is key
and transmission size.
Another disadvantage to ECC is certificates. Public key crypto does not really work without
digital certificates, and digital certificates don’t really work without certificate authorities. It’s hard
to find ECC digital certificates. So even if you want to use ECC, you might not be able to get a
certificate.
Currently in the industry, RSA is winning. The issues of key size, transmission size, and signa-
ture performance concern makers of small devices. But they often find that RSA is fast and small
enough. Sure, it’s neither the fastest signer nor the smallest key, but it still works just fine. And RSA
has a well-developed certificate infrastructure.

Other Kinds of Elliptic Curves

The kind of ECC described in this appendix is known as F’. The F stands forfield. Thep stands for
the prime modulus p. That means all operations are performed over a field defined by the value p.
In other words, all operations are modular with a modulus of p.
There are elliptic curves over a different field. It’s a field described as F2”. Does that mean all
operations are modular with a modulus of F2”? Sort of. The rules of point addition change (remem-
ber the five rules of EC addition). But the rules of individual number addition change as well. That
is, there is point addition, and part of point addition is individual number addition. With F2” elliptic
curves, adding two numbers is not the same as adding two numbers in regular math.
As you can imagine, it becomes very complicated very fast. This book is going to leave an ex-
planation of such elliptic curves to a more advanced volume.
In certain situations these /2” elliptic curves can perform faster than the prime modulus curves.
But the foundation of prime modulus curves is regular modular math, the kind of math that RSA
or Diffie-Hellman use. So it might be easier for some people to implement the prime modulus flavor
of ECE,

Other Security Issues

ECC has not been around very long. Some people don’t trust these curves because they have not
been studied very much. Furthermore, even with little research, some of the F2” curves have been
314 Appenpix A © Pustic Key MATHEMATICS (AND SOME Worps ON RANDOM Numeers)

shown to be weak. That means that if you choose the wrong a, 6, and 2”, attackers will be able to
compute your private key more quickly.
There are good combinations of a, b, and 2”; but because there are bad combinations, some
researchers believe any combination is suspect. That’s why many users of ECC only trust a, b, and
p—the kind described in this appendix.

Pseudo-Random Number Generation

Suppose you have a computer program that encrypts things. When it comes time to generate the
key, the program needs some numbers. A key is just a series of numbers, but which numbers will the
program use? Where will it get its numbers?
Maybe it asks you for the numbers. It wants a 128-bit key, so it needs you to enter 128 bits. You
enter your bits by “randomly” typing on the keyboard. Each keystroke is one character, and each
character is 8 bits. For the 128-bit key you need to type 16 characters. It might look like this:

jeodivnfu348refj

But a crafty cryptanalyst would study people “randomly” typing at the keyboard. The results of
this research might show that people tend not to type numbers and to use only lowercase letters and
letters toward the middle of the keyboard, and that the pairs of characters are usually in left-hand/
right-hand combinations. Maybe people seldom enter the same character twice in a row, and maybe
there are 4 or 5 or 10 or 20 other prevalent patterns.
A brute-force attack in such a situation would begin looking at keys that follow the tendencies
of human typing. The attacker would not have to try, on average, one-half of the possible keys be-
fore stumbling onto the correct one. A search might look at, on average, only one-tenth or one-one
hundredth or maybe even one-one millionth of the possible keys before success.
We can see that keys chosen this way are not actually random. What we’d like is a program that
picks keys at random.

What Is Random?
We all probably have an intuitive idea of what “random” is. But, as you can imagine, cryptography
relies on more than intuition. Given a series of numbers, a cryptographer will apply tests to those
numbers to determine if they are random.
Since we’re talking computers, all numbers are represented in binary (1’s and 0's), so the first
test might determine whether the probability is 50% that the next number is 1 and 50% that it is
0. This is not the same thing as “the probability is about 50% that a number is 1 and about 50% that
it is 0.” Look at the following series of 1’s and 0°.

101010101010101010101010101010101010101010101010101010

Half are 1’s and half are 0’s, but it doesn’t look random. In this example, if a number is 1, it
appears the next number will be 0 with 100% probability. You can see there’s a difference between
the probability of “a number” and the probability of “the next number.”
 PseUDO-RANDOM NumBeR GENERATION 315

Another test might try to see if some patterns appear too often or too seldom. For example, if
there are three 1’s in a row (it will happen every so often), are they always followed by three 0’s? On
the other hand, is there a pattern that will never appear? If you have random 1’s and 0’s, look at every
group of three. There are eight possible combinations of 1’s and 0’s as groups of three:

000 1/8 of the time

001 1/8 of the time
OF170 1/8 of the time
Onl 1/8 of the time
100 1/8 of the time
101 1/8 of the time
1etO 1/8 of the time
i 1/8 of the time

Every so often, you would expect to find three 1’s in a row. If you never see that pattern, the
numbers might not be random.
There are many tests like these. So, are numbers random? Get a big sample of values from the
tool that generates those numbers (this tool is 4 random number generator, or RNG), and perform the
tests. If you have an RNG that passes all the tests, use it to generate your keys.
An attacker trying to break one of your messages will not be able to devise a method that tries
“more likely” keys first because no key is more likely than any other key. Attackers will, therefore,
have to try every possible key before stumbling onto the correct value.
You may ask, “Great. Where do I get my hands on one of these random number genera-
tors? Is it simply some software I install?”
That’s a problem. A computer is a machine that will always produce the same result given the
same input. It’s not random. So you can’t get random numbers out of a computer. A software package
could never produce truly random numbers.
On the other hand, there are indeed machines that generate random numbers, maybe by exam-
ining radioactive decay, or counting ions in the atmosphere, or examining heat variations in the
vicinity. Although such machines are not computers, a computer can communicate with them and
receive their random numbers.
Unfortunately, such RNGs tend to be very expensive and slow. The average user will not have
access to one.

The Pseudo-Random Number Generator

So what should the average user do? Use a pseudo-random number generator, or PRNG. This will
be an algorithm in software that produces numbers that look random, but are reproducible. Because
they are reproducible, we can’t say they are truly random. But the output of a PRNG will pass all
the tests of randomness. Hence, “pseudo-random.”
316 Appennix A @ Pusiic Key MATHEMATICS (AND Some Worps ON RANDOM NumeeRs)

Here’s how it works. Feed a “seed” to a PRNG and it will use that seed to generate numbers
that look random. If you feed a different seed, you will get different results. Using the same seed will
always get you the same numbers.
What is a seed? It’s just a series of numbers or characters. We’ll talk more about that in a little
while.
Most PRNGs work by using a message digest. Here’s a typical example.
Digest the seed to create an initial state. When it comes time to generate random bytes, digest
the state. The result of that digest is the first part of the output. If you need more random bytes than
one digesting will give you, update the state, maybe by adding a constant. Now digest this new state
to get the next block of data (see Figure A-38).
People who know some of the random bytes still won’t know what the next bytes are going to
be. To know what the next bytes are, one needs to know the state, but that’s kept secret. To figure
out the state, one needs either to know the seed used to create the state, or to reverse the digest. We
saw in the section on message digests that reversing a digest is currently not possible. Therefore, if
you choose a seed an attacker can’t figure out, and if you keep it secret (or just throw it away after
using it), an attacker can’t figure out what the next (or previous) bytes will be.
Incidentally, you may wonder why we bother with the state. You could just digest the seed to
get random output, and if you need more bytes, digest the output. If we did that, then knowing some
of the random bytes means knowing the next ones. If we digest output to generate the next output,
then so could an attacker.

seed: 39957026218907274868...

message digest
algorithm

message digest
algorithm

Figure A-38 A typical PRNG digests the seed to get a state. To produce output, it digests the state.
 PsEUDO-RANDOM NumBeR GENERATION 317

The numbers look random. You know they aren’t. After all, if you use the same seed again, you'll
get the same results. So they’re pseudo-random. But to an attacker they might as well be truly ran-
dom because there’s no way of knowing what the next bytes will be.
Why use a digest? The result of a message digest looks random; it passes all the tests of random-
ness. Furthermore, we can use as much seed as we want and still get output. Also, when we change
the state, even just a little, the output is radically different. Each block of output looks nothing like
the previous block.

The Seed
Suppose you have a program that says, “Give me a seed. Ill use it to build a PRNG, which I’ll use
to generate a key, which I'll use to encrypt the data.” It then instructs you to pound randomly on
the keyboard for awhile. The program will take those keyboard strokes as the seed. You enter
j3£289uev1lkm3248u34foims,
kj 3434894 flswoljgidji3dje834

The program digests that seed to produce a state, then digests the state to produce a key. It
happens to be
goo LO Ger 2b 4l Wcities ¥oseAlieesd?/) 7/4443) °9 0mediae

Using that key, the program encrypts your data.

Knowing how the program works, an attacker can give it the same seed, generate the same key
again, and decrypt the data. But finding the seed is not easy. An attacker would have to try all the
possible keystrokes a user might enter until he or she stumbled onto the correct sequence. It might
be just as easy to try every possible key.
“Wait a minute,” you might be thinking, “Didn’t you just say an attacker can study human be-
havior and figure out likely keystrokes?” Yes, except there is one thing going for the seed: size. If the
attacker has to figure out only 16 keystrokes, that’s not so hard. But if the attacker needs to figure
out 52 (as was the case earlier), it’s going to take a little more time, even allowing for human typ-
ing tendencies. What if you entered 100 keystrokes? Or 200? Even though an attacker can know
some patterns are more likely than others, the sheer size of the seed makes it a daunting task.
And that’s what a pseudo-random number generator does. It takes a huge amount of input, and
somehow “compresses” it (or we could say it digests it) to a smaller amount, which looks random.
“Still,” you may protest, “there were just too many patterns in your seed example. The pair 34
appears four times; the letter is in there a lot; there is only one non-alphanumeric character, and
probably more tendencies. I’m not sure it’s a very hard problem.” And you'd be right. Keystrokes
are not good random seed by themselves. So we need more (possibly better) seed bytes.
One source of seed material is the time of day. The Java programming language, for instance,
allows you to ask the computer, “What time is it, down to the millisecond?” Enter that as the seed.
Now the attacker has to know the millisecond when you seeded the PRNG. Does that sound like
a good enough seed? No. Although trying every possible millisecond may seem like a time-consum-
ing task, for a computer, it’s not.
That’s not to say keystrokes and time of day are bad seeds; it’s just that they are not sufficient.
318 Appenpix A @ Pustic Key MATHEMATICS (AND Some Worps ON RANDOM Numeers)

Entropy
Cryptographers use the term entropy for “sufficient seed.” It’s a term concerning the measurement
of movement from order to chaos. Something totally chaotic has high entropy. Something ordered
has low entropy. In cryptography, entropy is usually measured in bits. “How many bits of entropy
are there in this technique>” a cryptographer might ask. A true RNG would have 1 bit of entropy
for each | bit of output. It’s totally chaotic. Totally random.
A coin flip, for instance, has 1 bit of entropy. There are two possible outcomes. Let’s call “heads”
0 and “tails” 1. One flip produces either a 0 or 1. ‘Chat’s what 1 bit is, a 0 or 1. So one flip produces
1 bit, that bit being random, so there is | bit of entropy in a coin flip.
Another way to look at it is, “How many brute-force iterations must we execute to guarantee
finding the answer?” If we have complete entropy, the total number of brute-force iterations nec-
essary to guarantee finding a 128-bit key would be 2'*. But if we have low entropy, say 2 bits of
entropy for every 8 bits of key, the brute-force attack would simply not try those keys that are defi-
nitely not possibilities. We could find the answer after only 2° iterations.
We want a 128-bit key. It would be great if we had 128 bits of entropy, a totally random key. If
we don’t have an RNG, we’ll use a PRNG. Will we be able to get 128 bits of entropy from a PRNG?
The output will look random, so the attacker won’t try a brute-force attack on the output. Rather,
it would be faster to find the seed—unless the seed has enough entropy.
Keystrokes and time of day have order, so they have low entropy. It’s not that they have mo en-
tropy; it’s just low. In order to come up with a good seed, we need a source that has high entropy.
Or we need something with low entropy, but lots of it.
For instance, suppose we did research and discovered that the keystroke seed has 1/10 of 1 bit
of entropy of each | character (8 bits) of input. We want a 128-bit key, so we could ask for 1,280
keystrokes. To find the key, an attacker would have to find the 1,280 keystrokes, in the proper or-
der. Since each keystroke adds 8 bits of seed, this would seem to require 2'°" iterations ofa brute-
force attack. But of course, the attacker won’t try every possible combination of bits. Some
combinations will never be possible and others are highly unlikely.
The measure of entropy indicates that this is equivalent to a 2'"* brute-force attack. That’s the
same amount of work it would take to do a brute-force attack on the key itself. So cracking the
message by cracking the seed is equivalent to cracking the message by cracking the key.

Other Seeds
Because asking a user to sit at the keyboard and type thousands of characters may not be desirable,
developers often look for other seeds. A common seed is keystroke timings. How long did it take
the user to type five characters?
Mouse movements are common seeds. The mouse position at any one time can be described
as a pair of numbers, the coordinates of the screen. A seed collector may ask the user to move the
mouse around. Every so often, it checks where the mouse is. That’s the seed.
Some chips have information about the processes running. There might be four or five ques-
tions to ask the chip about itself. The answers vary widely based on what the user has been doing
since booting the machine. There might be 10 or 12 bits of entropy in those answers.
 PsEUDO-RANDOM NumserR GENERATION 319

Good programmers use several methods to gather a seed. Any one alone might not be sufficient,
but taken together, they do the job.

Seed as Key?
You may be thinking, “Why do we have to convert the seed into a pseudo-random number? If the
seed has all the entropy we want, why not use it as the key?”
The answer is size. The seed may have 128 bits of entropy, but we needed 10,240 bits (or more)
of seed to get it. Do you want to use a 10,240-bit key? Is it possible? Maybe the algorithm has a limit
on key size.
A PRNG will convert 128 bits of entropy spread out over a large number of actual bits, into
about 128 bits of entropy spread out over 128 bits.

Summary
If you have an RNG, use it. If it’s too slow, use the RNG to create a seed, then use the seed with a
PRNG to produce the bulk of your random bits. If you don’t have an RNG, collect seed bytes and
use a PRNG. Use plenty of different sources to find seeds. Make sure it would be as difficult for the
attacker to figure out the seeds as to figure out the information the PRNG produces.
 3. eee
DOR ail win wl rt ven nt Hit ecw telnet Aaontraet prior ier |
es ae > 4) See wits ar 4! i 4m FsBan
te ge
Seay
Se ts POP ees hg thdter (as ah eee
) ae ae Pipe SII ronal vag baad ey Ties

ae eee sea,
Tae 1 os Laeree aa on
shee
gos RSE peg t!9 teen ot a te:
ae
:

>
treet eGR coy res el
ath 3

Ste Se ae
f aay

© bot
(ee Bor

rw
On Aganey gt

J
"Si

{
aitn
irs te Are Mis bnae arc 1a3zrir & ene, Bee
|
a 7 : y Sy Fe! we Ja in 0 gover, rn ;

> \ ™ ® - i ee vie : wes Haran Ah

. Sya- . asl wer ihre T- ; a |

oe

” - iene det «seilbpse's over nghiebuind 16: at ner armas

0D Rabid oa) eineuo it dlee wee bpaarpy
beh ast om athte Lie De Waite Moma itr. gtia OVO
aais
a ar rink '—— iiy ae icmwe? wh tieesiiyt
me! aeha ihc ee ays
: ¢ len emmys ahi
yp
° at - Sebo te
- 7 nial, 9 that
2a)*s “s eit Wess hai
oe; feed — a, Vriren & >
5 >

iasciveta
ence ales
i= nme hat
 Appendix B

(A Few) IPsec Detaits

he basic overview ofIPsec in Chapter 21 is only the tip of the iceberg. IPsec is a very ambitious
undertaking, with many security options and different ways to implement them. Whole books
have been written on IPsec.
Our goal in Chapter 21 is to provide a framework to help you understand how the system works.
This appendix describes additional details of IKE authentication and key management as well as
further specifics of bulk encryption.
€

IPsec Part 1: IKE Authentication and

Key Management
Recall that although IPsec requires only manual placement of secret keys, Internet Key Exchange
(IKE) is the default automated key management system. Arguably, IKE is the most difficult part of
IPsec to learn. Interestingly, IKE is a somewhat scaled-down version of Internet Security Associa-
tion Key Management Protocol (ISAKMP), which defined two separate phases and security
associations.

IKE and Network Security

IKE draws extensively from three key management documents: ISAKMP, Oakley, and Secure
Key Exchange Mechanism (SKEME). It’s an impressive lineage. NSA created ISAKMP, cryptos-
rapher H. Orman created Oakley, and H. Krawczyk, who also created HMAC, created
SKEME. Before IKE, IPsec’s default key management protocol was known as ISAKMP/Oakley,
and some books and vendors still use that name in referring to IPsec key exchange.
The need for secure data transport was apparent even before the U.S. government
funded and developed the ARPANET (Advanced Research Projects Agency Network). The
first packet encryption technology in the commercial sector was developed by BBN (then
called Bolt, Barenek & Newman) in the early 1970s.

321
322 AppennixB @ (A Few) IPsec Detaits

IKE Phase 1
Here’s a step-by-step, slightly simplified example (see Figure B-1) of one way that Alice and Bob can
complete phase 1 negotiations—agree on a shared Diffie-Hellman (DH) secret, and authenticate
each other—using IKE’s aggressive mode authenticated with digital signatures. Phase 1 makes IKE
SA or, in our parlance, SA-1. We’re assuming that Alice and Bob already have each other’s public
RSA keys used for signature verification.

1. Bob sends Alice his public DH value and a random value (RV) and proposes cryptographic
methods that he wants them to use as SA-1. Not shown: Bob can send more than one proposal.
2. Alice uses Bob’s public DH value, her private DH value, Bob’s RV, and her RV to calculate their
shared secret key, SKEYID.
3. Alice sends Bob her public DH value, her RV, and signed proof that she calculated SKEYID.
Alice can’t just send the signed (private key encrypted) SKEYID because BlackHat could decrypt
it with Alice’s public key. So Alice hashes the SKEYID, Bob’s RV, and Alice’s RV.' She then sends
the signed hash. Recall that one-wayness prevents BlackHat from recovering SKEYID from the
hash.
4. Bob uses Alice’s public DH value and his private DH value to calculate their shared secret key,
SKEYID. Bob verifies the signed proof Alice sent in step 3 and authenticates that she calculated
the identical shared secret, SKEYID, that Bob calculated. Bob sends signed (RSA private key
encrypted) proof that he calculated SKEYID.
5. Alice verifies the signed proof Bob sent in step 4 and authenticates that he calculated the iden-
tical SKEYID as Alice.

Then they use SKEYID, a keyed hash function, and other values from the phase | exchange to
create three additional keys: SKEYID_a, SKEYID_d, and SKEYID_e.
They use SKEYID_e to encrypt all phase 2 messages (e stands for encrypt). They use SKEYID_a
as an HMAC secret key to authenticate all phase 2 messages (a stands for authenticate). They use
SKEYID_d to derive the bulk encryption secret key used after phase 2 is completed.

IKE Phase 2
All phase 2 messages are protected by the IKE SA (SA-1); that is, all phase 2 messages are encrypted
with secret key SKEYID_e and are authenticated by SKEYID_a. Alice and Bob can complete phase
1 in many ways, but in phase 2 they don’t have any options. Here are the phase 2 steps (see Figure
B-2):

1. Bob sends Alice one or more SA-2 proposals. Bob also sends a newly generated random num-
ber (RandomByBob), which uniquely identifies the message and thereby helps prevent replay
attacks. Not shown: Bob also sends authenticating data that he has made, in part, by using
SKEYID_a (the secret key derived in phase 1) and a hashed version of RandomByBob.

1. And some other values known to both Alice and Bob.

 IPsec Part 1: IKE AUTHENTICATION AND Key MANAGEMENT 323

his public D-H value Sees )

Propose: Phase 2: DES, MD5, ... Bob’s public
D-H value

2. Alice’s private
and Bob’s public .
D-H value : Alice
_ calculates secret
_ (SKEYID) key-

Om

mi
her public D-H value
: Signed proof she
Alice’s public Cae calculated secret key
D-H value Alice’s RSA
signed digest

4, -Alice’s public.
and Bob’s private

calculates secret (SKEYID) key

Authenticates Alice by verifying
her signed proof

secret key ;

Bob’s RSA
signed digest

5:
Alice
Authenticates Bob by verifying his signed proof

Figure B-1_ IKE phase 1: key agreement and authentication.

324 AppenpixB ¢ (A Few) IPsec Detaits

2. Alice responds that she agrees with one of Bob’s proposals and sends her own newly generated
random number (RandomByAlice). Not shown: She also proves to Bob that she received his last
message by sending authenticating data made by using SKEYID_a (the secret key derived in
phase 1) along with a hashed version of RandomByBob, RandomByAlice, and other variables.
3. Bob acknowledges the receipt of Alice’s message in a similar fashion to the way Alice responded
in step 2.
4. Both Alice and Bob independently and simultaneously generate the secret key material
(KEYMAT) they will use for bulk encryption. KEYMAT is made, in part, from SKEYID_d.
Recall that SKEYID_d was derived in phase 1 from SKEYID (derived from the Diffie-Hellman
secret).

After IKE phase 2 step 2, Alice and Bob have secretly agreed on the following: cryptographic
methods (i.e., DES and MDS), secret keys for buik encryption, and, although it’s not shown in Figure
B-2, other SA-2 parameters such as protocol and mode.

Perfect Forward Secrecy

Perfect forward secrecy (PFS) means that one specific secret is used only to make one secret key. If
that particular secret is compromised, only one secret key is compromised. As we have shown, IKE’s
bulk encryption keys were generated with the Diffie-Hellman (DH) shared secret derived by Alice
and Bob in phase 1.
Let’s briefly review the construction of the bulk encryption keys. In IKE phase 1 Alice and Bob
independently calculate their DH shared secret. From this they calculate SKEYID and then
SKEYID_d, and from SKEYID_d they calculate their bulk encryption key.
What’s important here is that SKEYID_d is a direct descendant of the DH shared secret. If
BlackHat can figure out the DH shared secret, he can also figure out all secrets derived from it,
including Alice and Bob’s bulk data encryption key. This means that the bulk encryption key doesn’t
have PFS (see Figure B-3, section labeled “Phase 2 no PFS”). If PFS is desired, Alice and Bob can
negotiate a new DH shared secret in phase 2 and use it to calculate the bulk data encryption key.
Because the new DH secret is not based on any previously shared secrets, it has PFS (see Figure B-3,
section labeled “Phase 2 with PFS”).
Alice and Bob can use this technique to calculate a new bulk data encryption key each time their
SA lifetime expires. Then if BlackHat somehow figures out one key, it doesn’t compromise all en-
crypted data. PFS is not the default because negotiating a new DH shared secret (using public key
calculations) takes a lot of time.

IKE Phase 1 Modes: Aggressive and Main

IKE offers two phase | mode options: aggressive mode and main mode. Let’s see how Alice uses
main mode to help her avoid denial of service attacks.

2. Perfect forward secrecy has nothing to-do with the theorized concept of perfect secrecy. The latter is as-
sociated with one-time pads (see Chapter 7).
 IPsec Part 1: IKE AUTHENTICATION AND Key MANAGEMENT 325

Messages encrypted and authenticated using SA-1:

(i.e., TripleDES, MD5, and Secret Key)

Encrypted _
with SA-1_ |

“random
number

random number

random
number

4. SKEYID Used to decrypt

Used to encrypt messages from
messages to Bob

Alice and Bob

Derive secret keys used for bulk message transfer
(Hash secret key, SKEYID_d, derived in phase 1)
Used to encrypt
Used to decrypt r..<© messages to
messages from Bob | Alice

Figure B-2_ IKE phase 2: Quick mode agrees on bulk encryption parameters.
326 Apprenpdix B © (A Few) IPsec Detaits

Denial of Service Attacks

The concept of denial of service became widely known in early 2000, when a number of
Web sites were shut down by such attacks.
The goal of a denial of service attack is to deny service to rightful computer users. Most
denial of service attacks don’t steal data or secret keys. Instead, the attacker wastes the
victim’s resources. It is analogous to someone using an electronic dialer to continuously dial
your phone number. No matter how fast you hang up, the electronic dialer rings it again.
No one except the electronic dialer can get through, effectively denying you the use of your
own phone.

Figure B-4 shows a high-level overview of the two IKE phase | modes. Aggressive mode, shown
earlier in Figure B-1, completes in only three messages: two from Bob to Alice and one from Alice
to Bob. Compared with main mode, in aggressive mode each message carries more data (represented
by thicker arrows in Figure B-4), and Alice must complete expensive public key calculations before
sending Bob her first (and only) message.

Part 1 Secret Key Generation

Using IKE
Phase 1
Input Bulk
lice > Encryption
( Bob F yj and
Message
Public/private Integrity
Diffie-Hellman Values

[_——————_ Phase 2 Input Using

0 no PFS SA-2

SKEYID

Phase 2 Input
Q—r with PFS

Numbers “
Public/private Output
Diffie-Hellman Values

Figure B-3_ Comparing phase 2 with and without perfect forward secrecy.
 IPsec Part 1: IKE AUTHENTICATION AND Key MANAGEMENT 327

Part 1 IKE User Authentication and Key Exchange

Part 2
: IKE Phase 1 Choic .
— _ Bulk
B : 3 encryption
Aggressive Main igh
3 messages 6 messages message
SS integrity

Figure B-4 IKE phase 1 choices: aggressive or main mode.

Main mode offers additional protections but requires six exchanged messages. Figure B-5 shows
a phase 1 main mode exchange. In main mode the same amount of data is exchanged as in ageres-
sive mode, but the data is distributed over additional messages.
The messages are grouped by twos to show symmetry. In main mode messages | and 2, Alice
and Bob negotiate SA-1 cryptographic parameters. In messages 3 and 4 they exchange DH public
values and then calculate their shared DH secret key. Finally, in messages 5 and 6 they authenticate
each other.
Aggressive mode is hasty, whereas main mode is cautious. There are a few reasons for choosing
the cautious main mode exchange. One is that BlackHat can mount a denial ofservice against Alice
if he knows she’s using aggressive mode. This type of attack is called a clogging attack.

Clogging Attack
In aggressive mode, after Alice receives Bob’s first message, she performs two time-consuming public
key calculations: She calculates the Diffie-Hellman shared secret and signs a message to Bob.
BlackHat launches an attack by sending Alice many requests to set up an IKE phase | key ex-
change; the requests contain forged return addresses. BlackHat has successfully forced Alice to waste
computer resources on public key calculations that are never used—a successful clogging attack, one
type of denial of service attack.
328 AppeNDIXB ¢© (A Few) IPsec Detaits

Alice’s |
cookie /
_for Bob _ Bob’s public
_ D-H value

Alice’s
cookie
__ for Bob

Alice’s public
D-H value

...Alice and Bob independently and simultaneously calculate shared secret key...

Main Mode

Figure B-5 IPsec main mode transfers.

Although BlackHat can’t continue to masquerade as Bob without Bob’s private key, that’s not
the point. The point is that in aggressive mode Alice sends only one message to the initiator of the
conversation, whether it’s Bob or BlackHat. She must authenticate herself in that message, and that
requires expensive public key calculations. As a result, aggressive mode doesn’t offer Alice protec-
tion against clogging attacks. .
 IPsec Part 1: IKE AUTHENTICATION AND Key MANAGEMENT 329

Cautious Cookies
Now let’s see how Alice can use main mode, along with cookies, to gain some protection against
clogging attacks. Alice creates a cookie’ by hashing the combination of arandom number she makes
and keeps secret (SecretRandom), Bob’s return Internet address (Bob’sIpAdd), and a timestamp (TS)
to thwart replay attacks.

Alice’s cookie for Bob = Hash of (SecretRandom + Bob’slpAddress + TS)

Alice adds the cookie to her first message sent to Bob and waits until Bob returns it to her. To
Bob, the cookie looks like a random number. When Bob returns the cookie to Alice, she duplicates
the initial cookie calculation and thereby gains more confidence that she is exchanging messages with
Bob’s Internet address. Only after Bob returns the cookie and has done his public key cryptography
does Alice begin her calculations. In effect, she has made Bob assist in his own (admittedly weak)
authentication.

Authentication Options
We’ve shown authentication using digital signatures. In this technique, Alice proves herself to Bob
by signing a message. IKE supports three other authentication options: public key encryption, re-
vised public key encryption, and preshared secret keys.
Here’s how Alice authenticates herself to Bob using public/private RSA keys. In main mode step
2, Bob sends Alice a message encrypted with Alice’s public RSA key. The message contains a ran-
dom number. Only Alice can decrypt the message (with her private RSA key). Alice and Bob inde-
pendently and simultaneously use the random number (and other ingredients) to make a shared
secret key. In main mode step 3, Alice sends Bob a message encrypted with their shared secret key.
Because Bob trusts only Alice and he knows the underlying random number used to make the shared
secret key, he has authenticated her.
Standard public key and revised public key work similarly. Revised public key completes phase
1 faster than standard public key (revised public key needs fewer public key computations). The
major reason that the standard option is still supported is that many vendors have standard imple-
mentations. Preshared secret keys can’t be used in all situations (e.g., mobile users can’t use preshared
secret keys in phase 1 main mode).

identities
IKE also requires that Bob—in our example, the initiator—send Alice his identity in phase | (ag-
gressive or main mode negotiations). “Identity” can include information such as domain name (¢.g.,
www.hxMel.com), user name strings ([email protected]), or the address of asecret machine. In some
instances (as with the address of a secret machine) the initiator wants its identity information
enciphered to protect it from Internet snoopers.

3. These cookies have nothing to do with Internet browser cookies.

330 AppenpixB ¢ (A Few) IPsec Detais

Table B-1 compares how identity information is sent in aggressive mode and main mode. Be
warned, though, that because cryptographic attacks are often discovered after a standards document
is released, this table and even some of the standard documentation can be misleading. Even though
it looks as if the use of digital signatures protects identity, it may not.
For example, if Bob uses main mode with digital signatures (see Figure B-5), here’s how
BlackHat can get Bob’ identity. Bob’s last message to Alice includes his identity information and a
signed message encrypted together as one message with the DH value they previously agreed on.
Alice decrypts Bob’s last message using her copy of their agreed DH value and authenticates Bob
using her copy of his public key. But up to this point Alice has not authenticated herself to Bob, so
BlackHat may have been masquerading as Alice. If that’s the case, Bob will discover it when “Alice”
sends him her last message because BlackHat can’t sign a message with Alice’s private key—but by
then he’s unwittingly disclosed his identity. We don’t believe that BlackHat can do this with a re-
vised public key—that is, we don’t know of a published successful attack.

Table B-1 How identity is sent in aggressive mode and main mode.

Identity Aggressive Main

Digital signatures Plaintext Ciphertext

Standard public key Ciphertext Ciphertext
Revised public key Ciphertext Ciphertext
Shared secret Plaintext Ciphertext

IPsec Part 2: Bulk Confidentiality and

Message Integrity
Security Association Fields
Here’s a description of some SA fields used by both ESP and AH protocols.

¢ Sequence Number and Antireplay. Help detect replay attacks (see next section).
¢ Lifetime. How long the SA is allowed to live before it must be renegotiated. This can be ex-
pressed as either time or number of bytes.
e Mode. Specifies either tunnel or transport mode. (This can be a wildcard, which means it can
be either tunnel or transport, but this adds even more complexity.)
e ‘Tunnel IP Address. Used in tunnel mode to determine ultimate source and destination of the
data packet (see last example in this appendix).
e Authentication methods (e.g., HMAC with SHA-1), keys, and so on.
¢ Encryption methods (ESP only), keys, and so on.
 IPsec Part 2: Butk CONFIDENTIALITY AND MESSAGE INTEGRITY 331

Sequence Number and Antireplay

The sequence number and antireplay attributes are used to detect data packets that BlackHat copies
and replays to disrupt the flow of genuine messages between Alice and Bob. Without replay pro-
tection, BlackHat could flood Alice (or Bob) with old packets.
The sequence number attribute works this way. IPsec requires that the sender number each data
packet, beginning at | and incrementing the sequence number by | for each data packet sent. If the
receiver is concerned about a replay attack, he or she checks for and refuses to accept more than one
data packet having the same sequence number. The receiver uses his or her antireplay window to
record the receipt of authenticated sequence numbers. Only the sender sets the sequence number;
only the receiver uses the antireplay window.
If antireplay protection is turned on, after about four billion (2**) data packets, Alice and Bob
must negotiate a new SA-2.

Architecture
Figure B-6 shows the additional headers IPsec adds and the extent of confidentiality and authenti-
cation protections.’ For each protocol (ESP and AH), the transport mode is represented as a road
above the tunnel mode.
Following are a few more details of the architecture (along with brief reviews of features dis-
cussed in Chapter 21).

ESP
Figure B-6 shows that only ESP (in both transport and tunnel mode) offers confidentiality. As well
as enciphering the application data payload, ESP can encipher the higher-level protocol (e.g., TCP)
part of the data package. Enciphering the higher-level protocol prevents BlackHat from knowing
which application is destined to receive the data. ESP can also add and encipher some padding (be-
tween 0 and 255 bytes). Encrypted padding, a form of traffic flow analysis prevention, hides the
actual size of the data payload.
Although it is not shown, the ESP header contains the security parameters index (SPI) and se-
quence number; the trailer contains the padding and authentication data. Also, ESP confidential-
ity encryption must use cipher block chaining (CBC) mode.
As shown in Chapter 21, the use of ESP in tunnel mode and a gateway computer can also hide
the ultimate source (e.g., Alice) and destination (e.g., Bob) of the data packet. The [Psec-enabled
gateway adds a new IP address header (see IP-New in Figure B-6) and encrypts the original IP ad-
dress header. The IP-New source is Alice’s gateway, and the IP-New destination is Bob’s gateway.
Bob’s gateway decrypts the data packet, learns that the ultimate destination is Bob, and forwards the
packet. Many, if not most, VPN vendors use this configuration. See Management Control and IPsec
Processing, Example 2: ESP Protocol in Tunnel Mode for more details.

4. Assuming IPv4 because headers are built somewhat differently in IPv6.

332 ApPENDIXB ¢ (A Few) IPsec Detaits

IP Packet
IP Address TCP / Data
(no protections)

ESP ESP Header Authenticating

IP Address

IP-New
| (gateway)
Header
SPI Address us F/ Data /Padding |
Authenticate

AH IP Address TCP / Data

‘Authenticate

Authenticate

LEGEND

Cryptographic Protections

Authenticate
Encrypted (e.g., HMAC)

Figure B-6 Layout of IPsec data packets.

 IPsec Part 2: BULK CONFIDENTIALITY AND MESSAGE INTEGRITY 333

ESP also offers authentication, shown by a gray area under the data packet in Figure B-6. Note
that ESP authentication does not include the outer IP header.

AH
AH offers only authentication. As you can see in Figure B-6, AH authenticates the outer header, but
ESP does not. This is what is meant by AH offering more authentication protection than ESP.
Experts disagree whether this additional protection is worth the additional complexity of adding AH
as an option.
As with ESP, the AH header contains the SPI and sequence number. But the AH header also
contains the authentication data, and that can make it more difficult to create AH’s encapsulated data
packet. Because AH doesn’t offer confidentiality (encryption), there’s no padding.

Combining SAs
Each SA can contain only one protocol: either AH or ESP. If more protection is desired, a sender
and receiver can negotiate multiple SAs. A collection of multiple SAs is called an SA bundle. For
example, in Figure 21-10 bottom, Alice and Bob’s communications are secured by the tunneled SA
between their respective gateway computers. Alice and Bob can add additional protection (another
SA) between their personal desktop workstations. In this case both Alice and Bob must enable IPsec
on their computers. Or further protection can also be added. For example, a supplemental SA might
be negotiated between the gateway computers in addition to the existing SAs.
Here’s another example of an SA bundle. Suppose a mobile user (Alice) is staying in a hotel
room. She connects to a particular computer (Alice’s desktop workstation) inside her company’s
(AliceDotComStocks) firewall. Alice negotiates an SA with the firewall and then another SA with
her desktop workstation.

Management Control and IPsec Processing

Here are some additional details and an example of management controls in action. Chapter 21
introduces the security policy database (SPD) as the mechanism used by IPsec management to
specify policies that govern the IPsec security provisions between computers. The SPD looks at each
incoming and outgoing data packet’s six selectors (IP source and destination addresses, protocol,
name, and source and destination ports). The selectors determine a particular SPD policy, which
states whether a particular data packet is discarded, subjected to IPsec processing, or bypassed.
Let’s end this appendix with two examples of outbound and inbound processing to see where
management control (SPD) interfaces with IPsec processing.

Example 1: AH Protocol in Transport Mode

First, Alice, perhaps at her home, sends a file directly to Bob, perhaps also at his home (before they
married). See Figure 21-11 top.
334 Appendix B ¢ (A Few) IPsec Detais

Outbound (Alice Sends to Bob) [Psec makes a copy of Alice’s selectors (the IP address source
is Alice, the IP address destination is Bob, and so on) and sends them to the SPD. An SPD policy
lookup determines that data leaving Alice destined to Bob is afforded IPsec protection (e.g., AH
protocol, transport mode, and so on).
If an SA hasn’t been made, IKE is invoked to make one. After IKE finishes making the SA, it
stores it in the security association database (SAD).° Every time IKE makes a new SA, it also tells
the SPD its location in the SAD.
IPsec then processes the data packet, adds the appropriate headers (including the SPI°), and
sends the packet to IP for shipping to Bob.

Incoming (Bob Receives from Alice) Alice uses her selectors to determine an SPD policy and an
appropriate SA. Bob doesn’t have that luxury. Some of the selectors may be encrypted. Fortunately
for Bob (and everyone), the SPI makes finding a particular SA in the SAD much easier.
Bob stores each SA in his SAD indexed by the SPI, outer header destination address, and pro-
tocol. Alice sends the SPI, destination address, and protocol as plaintext. Bob uses these three to
quickly locate the SA governing this communication with Alice.
If there is no matching SA (or if the packet fails the antireplay check), the packet is discarded.
The SPD governing policy is located and matched against the SA. Data authenticity is verified, and
the packet is passed to the transport layer.

Example 2: ESP Protocol (Encryption Employed) in Tunnel Mode

In this example, Alice’s computer is not IPsec-enabled and is behind her firewall at
AliceDotComStocks. Bob’s computer.is not [Psec-enabled and is behind his firewall at HxMel. Alice
sends a file to Bob (see Figures 21-9 and 21-10).

Outgoing (Alice Sends to Bob) =Alice’s computer forwards the packet to her firewall. The firewall
checks the selectors and locates an SPD policy that points to an SA that requires ESP tunnel mode
processing (e.g., Triple DES). In contrast to example 1 (AH in transport mode), the SA fields for IP
source and destination addresses are not Alice and Bob but rather Alice’s firewall and Bob’s firewall.
Recall that ESP in tunnel mode directs IPsec to add an additional IP address header and encrypts
the inner headers. The new headers (shown in Figure B-6 as [P-New source) are Alice’s firewall and
Bob’s firewall. This is how ESP in tunnel mode conceals the ultimate source (Alice) and destination
(Bob).

5. SAD is often referred to as SADB. There’s also a separate SAD for each protocol: one AH SAD and one
ESP SAD. For simplicity, our discussion refers to both AH SAD and ESP SAD as SAD.
6. The SPI is a number created by the sender (Alice) during SA negotiations. Although the sender (Alice)
doesn’t use the SPI, she puts it on every AH or ESP header (see Figure B-6) to help the receiver (Bob) find
the governing SA on his computer.
 IPsec Part 2: BuLK CONFIDENTIALITY AND MESSAGE INTEGRITY 335

Incoming (Bob Receives from Alice) ESP inbound processing is similar to AH inbound process-
ing. Bob’s firewall abstracts the SPI from the ESP header. Although ESP encrypts the old header,
the SPI is always sent as plaintext (see Figure B-6). Just as in example 1, IPsec uses the SPI to find
the appropriate SA in the SAD. After the SA is checked against the SPD, the packet is processed and
sent to Bob. One last note: Tunnel mode processing uses the outer headers (with the SPI and pro-
tocol) to find the SA but uses the inner headers as selectors to find the appropriate SPD rule. (Trans-
port mode does not make inner headers.)
 Tee o_o eet
hae nn amc 8 .
: a
> I

ee a aire nes exclsersouitdall)

iydnage® fafern . ig eit0004 ad neste? Vike™ enol ie eee
Geant PA Hepner Fax vat i> Dem hae maple io qecreacule aolhe ei
, paired aaly Me tng he ees AAT st Lh? ody (tr A? alee el
poner eee Hirose ma cdityounsA tal” Goehed salle FI rata
a pat TPE: ois nua CPs saltee. VW) ewer Awd Labenioeis
vv ur D = | ofa cilen soe oeyhe shang homy

eatin 0 ho om
 BIBLIOGRAPHY

Allen, Norman, and Thomas B. Polmar, The Encyclopedia ofEspionage, Gramercy Books, 1997, ISBN
0-517-20269-7. An alphabetical treatment of espionage.

Deavours, Cipher A., David Kahn, Louis Kruh, Greg Mellen, BrianJ.Winkel, and Editors, Se/ec-
tions from Cryptologia: History, People, and Technology, Artec House, 1998, ISBN 0-89006-862-3.
Cryptologic illuminations from the past.

Denning, Dorothy E., Information Warfare and Security, Addison-Wesley, 1999, ISBN 0-201-43303-
6. Introduction to cyber information warfare.

Diffie, Whitfield, and Susan Landau, Privacy on the Line: The Politics of Wiretapping and Encryption,
MIT Press, 1998, ISBN 0-262-04167-7. Nontechnical treatment of privacy issues.

Doraswamy, Naganand, and Dan Harkins, [PSec, Prentice Hall, 1999, ISBN 0-13-011898-2. Exten-
sive treatment of IPsec.

Feghhi, Jalal, Jalil Feghhi, and Peter Williams, Digital Certificates: Applied Internet Security, Addison-
Wesley, 1999, ISBN 0-201-30980-7. Extensive treatment of digital certificates.

Kahn, David, The Codebreakers: The Story ofSecret Writing, Scribner, 1967, ISBN 0-684-83 130-9. A
comprehensive history of cryptography.

Kaufman, Charlie, Radia Perlman, and Mike Speciner, Network Security: Private Communication in
a Public World, Prentice Hall, 1995, ISBN 0-13-061466-1. Introduction to cryptography without
the extensive mathematics background assumed by other books.

Menezes, A. J., P. C. van Ooschot, and S. A. Vanstone, Handbook ofApplied Cryptography, CRC Press,
1997, ISBN 0-8493-8523-7. Thorough mathematical cryptographic reference for professional
cryptographers.

Nicholos, Randy, ICSA Guide to Cryptography, McGraw-Hill, 1999, ISBN 0-07-913759-8. Compre-
hensive discussion of historical to modern-day cryptography.

337
338 BIBLIOGRAPHY

Schneier, Bruce, Applied Cryptography, Second Edition, Wiley, 1996, ISBN 0-471-12845-7. Essential
reference for cryptographic engineers by the foremost pundit in the field.
Singh, Simon, The Code Book, Doubleday, 1999, ISBN 0-385-49531-5. A historical account of cryp-
tography and a look at the future.
Smith, Richard E., Internet Cryptography, Addison-Wesley, 1997, ISBN 0-201-92480-3. In-depth
discussion of [Psec and link encryption.
Stallings, William, Cryptography and Network Security Principles and Practice, 2d edition, Prentice Hall,
1999, ISBN 0-13-869017-0. Practical discussion of cryptographic principles by a prolific author
of networking texts.

Stinson, Douglas R, Cryptography Theory and Practice, CRC Press, 1995, ISBN 0-9493-8521-0. In-
depth mathematical treatment.
Welsh, Dominic, Codes and Cryptography, Oxford University Press, 1988, ISBN 0-19-853287-3.
Based on author’s mathematics course on information theory.

Wrixon, Fred B., Codes and Ciphers: An A to Z of Covert Communication from the Clay Tablet to the
Mierdot, Pearce Hall General Reference, 1992, Ist edition (out of print). A summary of cryp-
tographic history in encyclopedia format.
Wrixon, Fred B., Codes, Ciphers & Other Cryptic & Clandestine Communication: Making and Breaking
Secret Messages from Hieroglyphs to the Internet, Black Dog & Leventhal Publishers, 1998, ISBN
1-57912-040-7. All types of clandestine communication techniques from antiquity to the
present, organized by subject matter.
For a more extensive review of most of these and other cryptography books, we recommend
www.youdzone.com/cryptobooks.html.

Articles
Bellovin, Steven M., “Problem Areas for the IP Security Protocols,” July 1996, USENIX UNIX
Security Symposium, www.usenix.org/publications/library/proceedings/sec96/full_papers/
bellovin/bellovin.txt. The cut-and-paste attack.
Bleichenbacker, D. “Chosen Ciphertext Attacks against Protocols Based on RSA PKCS#1,” Ad-
vances in Cryptology, CRYPTO 98
Marlowe, Lara, “French Banks Panic Over Electronic Cards,” March 15, 2000, The Irish Times on
the Web, www.ireland.com:80/newspaper/finance/2000/03 15/fin18.htm.
Sullivan, Bob, “Can Hackers Kill Credit Cards?” March 15, 2000, MSNBC, www.msnbc.com/news/
382141 .asp.

Smart Card Integrators, Inc., “Smart Card Information,” www.sci-s.com/sub/history.html.

 BIBLIOGRAPHY 339

Internet Resources
Although most sites are listed only once, many of them could be listed in more than one category.
All sites are also listed at www.hxMel.com.

Sites with Many Good Links

theory.lcs.mit.edu/~rivest/crypto-
security.html#Other R. Rivest, creator of RSA

www.Counterpane.com B. Schneier, author of Applied Cryptography

www.cryptography.com/ SSL 3.0 designer P. Kocher

www.infowar.com Long-time security activist W. Schwartau

www.io.com/~ritter/ Introduction by professional cryptologist T. Ritter

www.pbs.org/wgbh/nova/decoding/
textindex. htm] Public Broadcasting System

Standards
csrc.ncsl.nist.gov/fips/fips1401.htm U.S. government standards

www.letf.org IETF standards for e-everything

www.imc.org Internet Mail Consortium

www.rsasecurity.com/rsalabs/pkcs/ Public key cryptographic standards

U.S. Government
csrc.nist.gov/encryption/ First stopping point

gits-sec.treas.gov/krdptut.htm Government Information Technology Services

www.gsa.gov/aces/about.htm Public key information

www.nsa.2Oov Information Systems Security Organization

340 BIBLIOGRAPHY

Tutorials and Teaching

web.mit.edu/network/pgp.html MIT’s PGP distribution site

world.std.com/~franl/crypto/ Has good links as well

www.certicom.com Elliptic curve tutorial

www.conceptLabs.co.uk Introduction to cryptography

www.cosc.georgetown.edu/
~denning/crypto/ Cryptographic policy and good links as well

www.counterpane.com/insiderisks5 .html Some public key precautions

www.cs.adfa.oz.au/teaching/studinfo/
csc/lectures/ Australian military

www.hifn.com Introduction to cryptography and compression

www.iks-jena.de/mitarb/lutz/
certification/mc/cert.htm More public key precautions

www.math.washington.edu/~koblitz/
crlogia.html Teaching aids by an ECC inventor, N. Koblitz

www.microsoft.com/technet/security/
kerberos/default.asp Microsoft Kerberos

www.nsa.gov/ruseum/ NSA Cryptography Museum

www.timestep.com/ SSL and IPsec articles

www.und.nodak.edu/org/crypto/crypto/ University of North Dakota/American

Cryptogram Association

www.youdzone.com/rapelcgvba.html Interactive RSA tutorial and more

 BIBLIOGRAPHY 341

Applications and Selected Vendors

www.baltimore.com Example of a PKI retailer

www.celocom.com/web/celo/d.asp Example of a digital signature retailer

www.checkpoint.com Example of VPN and firewall builder and seller

www.cisco.com/warp/public/759/ Routers and cryptography

www.pgp.com ‘Two commercial distributors of PGP

Wwww.pgpl.com International PGP site

www.smartcardforum.org Smart cards

www.vpnc.org Virtual private networks

www.zks.net Remaining anonymous with Zero Knowledge

€

Privacy
www.computerprivacy.org Americans for Computer Privacy

www.eff.org Electronic Frontier Foundation

www.epic.org Electronic Privacy Information Center

News
www.fags.org/faqs/by-newsgroup/
sci/sci.crypt.html Newsgroup FAQ

www.icsa.net International Computer Security Association

www.infosecuritymag.com/ Information Security magazine

www.mercurycenter.com/ svtech/
reports/gmsv/ Silicon Valley’s local newspaper

www.nytimes.com New York Times

www.pwcglobal.com/cce PricewaterhouseCoopers

www.zdnet.com/zdnn/ecrime/ ZDNet dedicated site

342 BIBLIOGRAPHY

Bankers and Lawyers

www.abaecom.com/ American Bankers Association

www.bakerinfo.com/ecommerce Example of law firm specializing in digital signatures

www.bsa.org/policy/encryption/ Business Software Alliance policy

www.digsigtrust.com/ American Bar Association

www.ilpf.org/ Internet Law & Policy Forum

www.mbc.com Example of law firm specializing in cryptography

Computer Code
www.attrition.org/~wrlwnd/crypto
/crypto_tutorial/ ‘Tutorials, too

www.cryptix.org Java source code

www.cryptography.org North American Cryptography archives

www.ussrback.com Underground Security Systems Research

Miscellaneous
www.ams.org American Mathematical Society

www.attlabs.att.co.uk/andyc/enigma/
enigma_j.htm] Enigma implemented in Java

www.cacr.math.uwaterloo.ca University of Waterloo Center for

Cryptographic Research

www.hxMel.com Cryptographic glossary and AES update

www.interhack.net/people/cmcurtin/
snake-oil-fag.html What to watch out for!
 BIBLIOGRAPHY 343

www.isoc.org/internet/history Internet Society history

www.jargon.org The New Hacker's Dictionary

www.jya.com/cryptout.htm Another view

www.w3.org/Security/Overview.html World Wide Web security page

 a
— mt _ > a eens! a ae - - - .

a : _

ar Rist? sais te LT dhenet enone abel

ae a _—_" eo: | "

Saintes
—— . gio. ey Be
.
_ : 1 oe — me
os wipe ie VEO” SO” AS it aA
“we

PAAe di Yt heey Peri Pew’. PET ret yun be

——, Ww _ = = =

a,

a Ae
 INDEX

A cipher suite rollback, 225

ADFGVxX cipher, 27 clogging, 327-328
Adleman, Leonard, 86 cut-and-paste, 250-251
Advanced Encryption Standard (AES), 39, 263-264 denial of service, 326
Rijndael, 63, 152, 263-264 man-in-the-middle, 94, 247-248
speed of, 158 meet-in-the-middle, 41
Aggressive mode, 324-327 random keys in memory, 249
Algorithms, 8 , replay, 136, 247
Diffie-Hellman, 224-225, 233, 300-304 smart card, 261-262
digital signature (DSA), 121, 304-306 Authentication assurance, 53, 55-57
EC Diffie-Hellman, 311-312 of e-mail messages, 211-213
extended Euclidian, 296-300 with private/secret keys, 119-120
RSA public key, 277-288 secret key versus public key, 117-118
Secure Hash (SHA-1), 128, 150 in SSL/TLS, 221
Alphabet circles, concentric, 9 Authentication Header (AH), 239, 333
Anonymous Diffie-Hellman, 224 in transport mode, 243-244
Antireplay attributes, 331 in tunnel mode, 243-244
Assurances Avalanche effect, 42-43, 60
authentication. See Authentication assurance
collision resistance, 143-144
B
confidentiality. See Confidentiality
Babbage, Charles, 67
cryptographic, 159-161
Baker, Doris, PGP key, 266
digital signature, 116
Binary numbers, 43
integrity. See Integrity assurance
Birthday attack, 158
nonrepudiation, 53, 63, 122-123
Bit, defined, 43
one-way, 143, 146-147
Black Chambers, 47-48
signature, 116
Bleichenbacher, Daniel, 253
Asymmetric ciphers, 86-88
Bleichenbacher attack, 253
Asymmetric key cryptography, 159-161. See also
Block ciphers, 42
Public key cryptography
Brute force attack, 34
Attacks
Byte, defined, 43
birthday, 158
BlackHat uses Bob’s RSA private key, 253-257
Bleichenbacher, 253 C
chosen plaintext, 251-252 CA. See Certificate authority (CA)

345
346 INDEX

Caesar, Julius, 7 Codes, defined, 47

Caesar’s ciphers, 7-10, 46-47 Collision resistance assurances, 143-144
cryptanalysis of, 10-11 Combinations, locks and, 3-5
keys in, 10-11 Complex ciphers, 26
weakness of, 14 Compression
Cartes Bancaires (CB), 262 file and MAC, 62
Certificate authority (CA), 178-182 message digest, 154
root, 182-187 before signing, 124-125
subordinate, 185 Compression programs, versus message digest
Certificate revocation list (CRL), 182 programs, 128
Certificates. See Digital certificates Computers, cryptography and, 49-50
Certificate verify message, 227 Concentric alphabet circles, 9
Certification practice statement, 189 Confidentiality, 54-55
Chaining, 170 before digital age, 89-91
Challenge and response, 55-57 of e-mail messages, 211-213
Chase, Pliny Earl, 32 integrity and, 249-251
Checkerboard (Polybius) ciphers, 30-33 in SSL/TLS, 223
Checksum programs, 129-130. See also Message Confidentiality assurances, 53, 92
digests Confusion, principle of, 33, 34, 50
Chosen plaintext attack, 251-252 Contact smart cards, 260
Cipher block chaining (CBC), 42 Cookies, 329
Cipher circles, 12 Cribs, defined, 23
Cipher feedback (CFB), 42 Cryptanalysts, defined, 5
Ciphers Cryptographers, defined, 5
ADFGVX, 27 Cryptographic assurances, 159-161
asymmetric, 86-88 Cryptographic checksums. See Message digests
block, 42 Cryptographic hashes. See Message digests
Caesar’s. See Caesar’s ciphers Cryptography
complex, 26 asymmetric, 159-161
defined, 7 commercial/military need for, 48-49
iterated product, 34 in computer age, 49-50
knock, 31 defined, 4, 5
Larrabee, 48 in early history, 46-48
monoalphabetic, 14 knapsack, 112
polyalphabetic, 16-18 symmetric, 159-160
Polybius (checkerboard), 30-33 use of math in, 268-269
substitution, 8, 26-27, 29 Cryptology, defined, 5
symmetric, 86 Cut-and-paste attack, 250-251
transposition. See Transposition
Vigenére, 15-19 D
word origin of, 9 Data Encryption Algorithm (DEA). See Data
Cipher suite rollback attack, 225 Encryption Standard (DES)
Cipher suites, 219-220 Data Encryption Standard (DES), 24, 35, 37
Ciphertext, defined, 7 avalanche effect and, 42—43
Clock math. See Modular math as block cipher, 42
Clogging attacks, 327-328 cracking, 41
Cocks, Clifford, 87 Double, 41
Codebreaking devices, 50 history of, 38-39
 INDEX 347

key length, 158 Elliptic curve cryptography (ECC), 158, 306,

Moore’s Law and, 40 312-313
for smart cards, 261 security issues, 313-314
speed of, 157-158 Elliptic curve discrete log problem,
Triple, 41 312
use of mode method, 42 Elliptic curves (EC), 306-308
Dead drops, 83 adding points on, 308-310
Decipher. See Decryption for digital signatures, 312
Decryption, defined, 7-8 types of, 313
Denial of service attacks, 326 Ellis, James, 86-87
DES. See Data Encryption Standard (DES) E-mail messages, 204
Diffie, Whitfield, 41, 84 authentication of, 211-213
Diffie-Hellman key agreement, 233, 300-304 confidentiality for, 211-213
Anonymous, 224 cryptographic protection in, 207
Ephemeral, 225 deterring viruses, 213
Fixed, 225 generic cryptographic, 207-209
Diffie-Hellman-Merkle key agreement, 84-85 invoking cryptographic protections, 205
weaknesses of, 86 Encapsulating Security Protection (ESP), 239, 240,
Diffusion, 29-30, 32, 33, 34, 50 331-33
Digesting, 124-125 in transport mode, 241-243
Digests. See Méssage digests Encipher. See Encryption
Digital certificates, 94 Encryption
attacking, 167-168 defined, 7-8
compared to state-issued driver’s license, with private key, 118
169-172 Encryption standards
components, 165-166 AES, 39
exchanging, in SSL/TLS, 220 DES, 38-39
included in browsers, 174-175 historical need for, 37-39
needs of users of, 172-173 Entropy, 318
root, 173 Enveloping, 208
self-signed, 182-187 Ephemeral Diffie-Hellman, 225
verifying, 167 Exponential identities, 276-277
Digital fingerprints. See Message digests Extended Euclidian algorithm, 296-300
Digital signature algorithm (DSA), 121, 304-306
versus RSA, 122 F
Digital signature assurances, 116 Federal Information Processing Standard
Digital signatures, 119. See also Private key (HIPS); 121
encryption Feistel, Horst, 38
defined, 115-116 Feistel blocks, 38
elliptic curves for, 312 Fermat test, 294-296
Digital Signature Standard (DSS), 121 Fingerprints. See Message digests
Distinguished names, 188 Finished handshake, 222
Division, 103-106 Firewalls, 239
Double DES, 41 Fixed Diffie-Hellman, 225
Forgeries, detecting, 135-136
E Fractionating, 32
EC Diffie-Hellman Algorithm, 311-312 Friedman, Elizabeth, 49-50
Electronic codebook (ECB), 42 Friedman, William, 49-50
348 INDEX

H outbound/inbound processing, 333-335

Hashes. See Message digests protocols, 240
Hash function, 142 security features, 229-230
Hashing, 124-125 Inverses, 270-272
Hayes, Rutherford B., 26 modular, 106-109
Hellman, Martin, 41, 84, 112 modular multiplication, 284
Hill, Lester, 49-50 multiplicative, 102-103
Humpich, Serge, 262 IPsec. See Internet Protocol Security (IPsec)
IPsec-SA, 235
I Iterated product ciphers, 34
Identification Friend or Foe (IFF), 128
Identities, 276-277 J
Identity property, 101-102 Jefferson, Thomas, 6
IKE. See Internet Key Exchange (IKE)
IKE-SA, 235 K
Information theory, 50 Kahn, David, 32, 46, 50
Integrity assurance, 53, 59-62 Kappa test, 49
confidentiality and, 249-251 Kata kana, 48
with private/secret keys, 119-120 Kerberos, 70
in SSL/TLS, 223 Key agreement, 203 n. 1
Internet Engineering ‘Task Force (ETF), 178 im SSL/TLS, 221
Internet Key Exchange (IKE), 320 Key distribution centers (KDCs), 70-71, 75
authentication options, 329 Keyed message digests. See Message authentication
benefits of two-phase key exchange, 235-236 codes (MACs)
identities, 329-330 Key exchange, 203 n. 1
key agreement and authentication phase, Key length, 16-18
233-234 Key recovery, 71
phase 1, 321 Keys. See also Private keys; Public keys; Secret keys
aggressive mode, 324-327 adding, 13-14
main mode, 324-327 Caesar’s cipher and, 10-11
phase 2, 322-324 secret, 13
setting up bulk encryption parameters phase, separating method and, 12-13
234 Key splitting, 71
Internet Protocol Security (IPsec), 83, 94, 204-205 Key words, 23
authentication and, 239 n. 8 Knapsack cryptography, 112
bulk data confidentiality and integrity for Knock ciphers, 31
message or file transport, 237-245
bulk data confidentiality and message integrity, L
330-335 Larrabee cipher, 48
compatibility issues, 245-246 Letter frequencies, 15
IKE authentication and key management, Letters, as numbers, 267-268
321-330 Lifetime, 235
Internet Key Exchange (IKE), 232-236 Locks, combinations and, 3—5
management control, 244-245, 333
management of secret keys by, 230-232 M
modes, 241 MACs. See Message authentication codes (MACs)
 INDEX 349

Main mode, 324-327 N

Man-in-the-middle attack, 94, 247-248 National Institute of Standards and ‘Technology
Manual distribution, 231 (NIST), 38-39
Master secret, 226 National Security Agency, 38-39
Mauborgne, Joseph, 59 Nomenclators, 47
MDS (Message Digest 5), 150 Non-keyed message digests, 141-142
Meet-in-the-middle attack, 41 collision resistance assurances, 143-144
Mel, H. X., PGP key, 265 one-wayness assurances, 143
Memory smart cards, 260 weak collision resistance assurances, 144—145
Merkle, Ralph, 75, 80-82, 83, 84, 112 Nonrepudiation assurance, 53, 63, 122-123
Message authentication. See Integrity Nulls, 26
Message authentication codes (MACs), 60-62, Numbers
142, 151 binary, 43
compression, 62 letters as, 267-268
existential forgeries, 153 prime, 272
hashed, 155-156 pseudo random, 59, 314-319
made with DES, 151-152 random, 57—59
selective forgeries, 152 Number theory, 101
Message Digest 5 (MD5), 150
Message digests, 5, 127-128, 150 12)
compression, 154 One-time pad, 58-59
keyed. See Message authentication codes (MACs) One-wayness assurances, 143
non-keyed, 141-142 detecting modifications, 146
signing, 133-136 sharing data without revealing contents,
speed comparisons, 155 146-147
unsuccessfully imitating, 137-139 On the Roof Gang, 48
Message fingerprints. See Message digests Output feedback (OFB), 42
Message integrity codes (MICs), 142
Method, separating, and keys, 12-13 P
Microprocessor smart cards, 260 Padding, 252
Microsoft Outlook Express, 207 Padlock symbol, 215
Mode attributes, 238 Painvin, Georges, 26-27
Mode methods, 42 Patterns, in transposition ciphers, 22-23
Modification detection codes (MDCs), 142 Perfect forward security (PFS), 324
Modifications, detecting unintentional, 129-131 PGP. See Pretty Good Privacy (PGP)
Modular inverses, 97, 106-109 Plaintext, defined, 7
for public keys, 109 Poe, Edgar Allan, 15
Modular math, 103-106, 272-276 Policies, IPsec 244
Modular multiplication inverses, 284 Polling, 182
Modulo, 104 Polyalphabetic ciphers, 16-18
Modulus, defined, 104, 272-273 Polybius (checkerboard) ciphers, 30-33
Monoalphabetic ciphers, 14 Polybius square, 30
Moore’s Law, 40 Porta, Giovanni Battista, 22, 27
Moreno, Roland, 262 Pre-master secret, 221
Morse, Samuel F. B., 48 Pretty Good Privacy (PGP)
Multiplicative inverses, 102-103 certificate repositories and revocation, 200-201
350 INDEX

Pretty Good Privacy (PGP) (continued) Public key decryption, 122

compatibility of X.509 with, 201 Public key infrastructures (PKI), 177. See also
Doris Baker’s public key, 266 Pretty Good Privacy (PGP); X.509
history of, 193-194 Public keys. See also Private keys; Secret keys
H.X. Mel’s public key, 265 as cryptanalysis tool, 251-253
versus X.509, 194-196 modular inverses for, 109
Zimmermann, Philip, 193 Published secret key method, 35
Prime modulus, 307-308 Pushing, 182
Prime numbers, 272
Private Communicating ‘Technology (PCT), 216 Q
Private key encryption, 122. See also Digital Quadratic code, 31
signatures Quantum events, 58
Private keys, 92-94. See also Public keys; Secret Quick mode, 234
keys
authentication/integrity with, 119-120 R
authentication methods Random, defined, 314-315
Digital Signature Algorithm (DSA), Random numbers, 57-59
121-122, 304-306 pseudo, 59
RSA, 120 Redundancy, 50, 127
encrypting with, 118 Reilly, Sidney, 188
Product ciphers, 34-35 Relatively prime concept, 272
Protocol attributes, 238 Remainders, 103-105
Proximity smart cards, 260-261 Replay attacks, 136, 247
Pseudo-random function (PREF), 226 Residue, defined, 104
Pseudo-random number generator (PRNG), Rijndael, 63, 152, 263-264
315-317 Rivest, Ronald, 86, 150
Pseudo random numbers, 59 Root certificate authority (CA), 182-187
generation, 314-319 Root digital certificates, 173
Public key algorithms. See also RSA public key Rossignol, Antoine, 15
algorithm Rotational cipher, 8 n. |
Diffie-Hellman algorithm, 300-304 Rounds, 34
DSA (digital signature algorithm), 304-306 Routers, 239
elliptic curves, 306-308 RSA public key algorithm (method), 87-88, 120,
Public key authentication, versus secret key, 277-288
117-118 finding primes and, 290-293
Public Key Cryptographic Standards (PKCS), 253 inverse functions and, 288-290
Public key cryptography, 123-124, 163-164. See key length, 158
also Secret key cryptography speed of, 157-158
as asymmetric relationship, 91 versus DSA, 122
Diffie-Hellman-Merkle key agreement, 84-86
distribution of keys in, 92-94, 158 Ss
easy and hard puzzles, 82-84 Secret key authentication, versus public key,
key length, 158 117-118
letters as numbers in, 267-268 Secret key cryptography. See a/so Public key
security and, 158, 159 cryptography
speed of, 157-158 authentication assurance, 53, 55—57
use of math in, 268-269 confidentiality assurance, 53-55
 INDEX 351

integrity assurance, 53, 59-62 contact, 260

key distribution and, 158 memory, 260
key length, 158 microprocessor, 260
nonrepudiation assurance, 53, 63 protections and limitations for, 261
speed of, 157-158 proximity, 260-261
Secret keys, 13. See also Private keys; Public keys Speed, public key versus secret key,
authentication/integrity with, 119-120 157-158
delivery problem of, 77-82 SSL. See Secure Socket Layer (SSL)
encrypting (wrapping), 69 SSE v2,.225
IPsec management of, 230-232 SSL v3, 225
protecting, 72 Steganography, 47
sharing and exchanging, 65-67 Strong collision resistance, 147-150. See also Weak
trusted third parties for, 68-69 collision resistance assurances
Secure Hash Algorithm (SHA-1), 128, 150 Strong method, 34
Secure/Multipurpose Internet Mail Extension Subordinate certificate authority, 185
(S/MIME), 207 Substitution ciphers
Secure Socket Layer (SSL), 83, 94, 204-205 defined, 8
authentication, 222 transposition ciphers and, 26-27
confidentiality/integrity, 223-224 weaknesses of, 29
hello/negotiate parameters, 218-221 Sun-Tzu, 66
history of, 216 Super-increasing sequence, 99-100
invoking cryptographic protections, 205 Symmetric ciphers, 86
key agreement, 221-222 Symmetric key cryptography, 159-160. See also
padlock symbol for, 215 Secret key cryptography
session overview for, 216-218
v3 and v2 compared to TLS, 225 T
Security, RSA public key algorithm and, 288 ‘Tilden, Samuel, 26
Security associations (SAs), 232, 330 TLS. See Transport Layer Security (TLS)
Security policy database (SPD), 244-245, 333 ‘Traffic analysis, 225
Seed, 316-319 ‘Transport Layer Security (TLS), 216
Selectors, 244-245 Anonymous Diffie-Hellman variation of,
Self-signed digital certificates, 182-187 224-225
Sequence number attributes, 331 compared to SSL v3 and SSL v2,
Session key, 208 225
Shamir, Adi, 86, 112 detailed session in, 218-224
Shannon, Claude Elwood, 49-50 session overview for, 216-218
Shared secrets, generating, 226 ‘Transport mode, 239
SHA-1 (Secure Hash Algorithm), 128 AH in, 243-244
Shift cipher, 8 n. 1 ESP in, 241-243
Signature assurances, 116 Transposition ciphers, 21-22
digital, 116 adding cycles for, 23-25
written, 116 complex versus simple, 26
Signing, 122, 124-125 computers and, 25-26
Singh, Simon, 87 diagonal patterns for, 24-25
Smart cards, 259-260 patterns in, 22-23
attacks, 261-262 substitution ciphers and, 26-27
components, 261 Trapdoor function, 38-39
352 INDEX

‘Triple DES, 41 Ww
for smart cards, 261 Wallis, John, 15, 27
speed of, 158 Weak collision xesistance assurances, 144-145. See
‘Trusted introducer, 198 also Strong collision resistance
‘Trusted third party (TTP) detecting modifications, 146
defined, 68 sharing data without revealing contents, 146—
problems with, 71-72 147
Trust networks, building, 196-200 Webs of trust, building, 196-200
‘Tuchman, Walter, 41 Wheel cipher, 6
‘Tunnel mode, 239 Williamson, Malcolm, 87
AH in, 243-244 Word frequencies, 15
ESP in, 243 Wrapping, 69
Turing, Alan, 50 Written signature assurances, 116
‘Two-way confidentiality, 94
4
U X.509, 178
U.S. Federal Information Processing Standard certificate data, 189-190
(HIPS), 121. compatibility of PGP with, 201
versus PGP certificates, 194-196
Vv root certificates and, 182-187
Verification, 122
Vernam, Gilbert, 59 Z
Verser, Rocke, 41 Zimmermann, Philip, 193
Vigenére, Blaise de, 15-16
Vigenére cipher, 15-19
Viruses, deterring e-mail, 213
 ‘
i (V hat) :

sae

oa Dred}
~~

Does -
ONG mae 2. ot oxen i
adil avian aM) owes il 9c Bees
7
 Solutions trom experts you know and trust.
Home
Login Register About InformlT

www.intformit.com
Free, in-depth articles and supplements

Master the skills you need, when you need them

Choose from industry leading books, ebooks,

and training products

Get answers when you need them- from live

inform
experts or InformIT's comprehensive library

Achieve industry certification and advance

your career

Visit InformIT today

and get great content
from w |
Addison-
Wesley
SS SS

Addison-Wesley and InformIT are trademarks of Pearson ple / Copyright ©)2000 Pearson
 Security from the Experts
Cryptography
SSL and TLS
Designing and Building Secure Systems

Eric Rescorla

0-201-61598-3

Information
Warfare
and Secutity

Dorothy E. Denning

0-201-67516-1 0-201-43303-6

KERBEROS
Firewalls and A Network Authentication System
SS
inside Java’ 2
InterneL.Secwrity Platform Security
Agrchitecture API Design,
Countering Cyberspace Scoffiaws
Repellingthe Wily Hacker
wid Implementation
William R. Cheswick
Steven'M. Bellovin

a SUN

0-201-63357-4 0-201-37924-4 0-201-3 1000-7 0-201-30820-7

DIGITAL
CERTIFICATES
Applied Internet Security

Jalal Feghhi
Jalil Feghhi
Peter Williams
Poroword by Potee E
Moderator of the Internet Risks Foran

0-201-92480-3 0-201-30980-7 0-201-55805-X 0-201-63489-9

A
http://www.awl.com.cseng wv Addison-Wesley
at www.aw.com/cseng/register
You may be eligible to receive:
Advance notice of forthcoming editions of the book
Related book recommendations
* Chapter excerpts and supplements of forthcoming titles
- Information about special contests and
promotions throughout the year
* Notices and reminders about author appearances,
tradeshows, and online chats with special guests

Contact us
If you are interested in writing a book or reviewing — 2
manuscripts prior to publication, please writetousat:

Editorial Department
Addison-Wesley Professional
75 Arlington Street, Suite 300
Boston, MA 02116 USA
Email: [email protected]

Visit us on the Web: http://www.aw.com/cseng

Security/Cryptography q

Cryptography Decrypte
Fundamental security concepts like cryptography and digital signatures are becoming as much
a part of our everyday lives as megabytes and the Internet. Anyone working with computer
security—security professionals, network administrators, IT managers, CEOs, and ClOs—need
to have a comfortable understanding of the cryptographic concepts in this book.

Cryptography Decrypted shows you how’to safeguard digital possessions. It is a clear, com-
prehensible, and practical guide to the essentials of computer cryptography, from Caesar's
Cipher through modern-day public key. Cryptographic capabilities like detecting imposters
and stopping eavesdropping are thoroughly illustrated with easy-to-understand analogies,
visuals, and historical sidebars.

You need little or no background in cryptography to reaa Cryptography Decrypted. Nor

does it require technical or mathematical expertise. But for those with some understanding of
the subject, this book is comprehensive enough to solidify knowledge of computer cryptography
and challenge those who wish to explore the high-level math appendix.

Divided into four parts, the book explains secret keys and secret key methods like DES, public
and private keys, and public key methods like RSA; how keys are distributed through digital
certificates;.and three real-world systems. Numerous graphics illustrate and clarify common
cryptographic terminology throughout.

You will find coverage of such specific topics as:

—@ Secret key and secret key exchanges

*=-@ Public and private keys wh
~~ Digital signatures
-@ Digital certificates, Public Key Infrastructure (PKI), and PGP -
—~@ Hashes and message digests
--@ Secure e-mail, secure socket layer (SSL), and Internet Protocol Security (/Psee)
—@ Protecting keys* ~* .
® Cryptographic attacks
3 Authentication, confidentiality, integrity, and nonrepudiation

H.X.:Met consults and develops computer systems for organizations such as'Lucent, Xerox,
MIT, the U.S. Government, Motorola, Goldman Sachs, and PricewaterhouseCoopers.

Doris Baker is a freelance technical writer and editor.

“Even after ten yéars working in the field of information protection for a major electronics
manufacturiag company, | learned a lot from this book. | think you will too.” al
—From the Foreword by John Kinyon

idea tegntendtoaieeen

Cover design by Karin Hansen

Cover illustration by Cynthia Miller 9 "780201°616477
€ Text printed on recycled paper |
ISBN, O-201-61647-5
vv ADDISON-WESLEY $29.95 US $44.95 CANADA
Pearson Education —