Cryptography

in Context
Nathaniel Karst

November 19, 2014

Preface
It is safe to say that the world as we know it could exist without modern communication systems. But from online credit card transactions to secure messages
between organizations and their agents, these technologies allow us to trust
each other in an increasingly digital world. In these notes, we will begin to unpack these technologies, from both mathematical and practical perspective. You
will have the opportunity to implement many of these communication protocols
yourself, and in so doing, hopefully gain a deeper understanding and appreciation for the underlying ideas. We will regularly confront the ethical issues that
arise at the interface of these theoretic tools and their real world implementation, as the use and abuse of modern cryptography has serious implications for
the trajectory of our society.

How To Use These Notes

Content areas are intended to be relatively stand-alone. Each content area
discusses the overall idea behind the topic, and then proceeds to Matlab implementation. (While I have not thoroughly tested it, Octave should work as a
good substitute.) Each content area has associated studio problems located in
Appendix A. These problems are intended to be started in class with the help of
an instructor and completed outside class. The solutions for studio problems are
located in Appendix B. Teaching notes for instructors, including learning objectives and discussion questions where appropriate, are including in Appendix
C.

Acknowledgements
I would like to thank the Teaching Innovation Fund at Babson College for supporting the development of these notes and exercises. My thanks also goes to
the Spring 2014 cohort of Cryptology and Coding Theory for its help in molding
these notes for general consumption.

Chapter 0. Preface

Contents

Preface

1 Introduction
1.1 Communication Systems . . . .
1.1.1 Compression . . . . . .
1.1.2 Encryption . . . . . . .
1.1.3 Protection . . . . . . . .
1.1.4 Representations of Data
1.2 Matlab . . . . . . . . . . . . . .
1.2.1 Basic Arithmetic . . . .
1.2.2 Variable Assignment . .
1.2.3 Arrays . . . . . . . . . .
1.2.4 Scripts and Functions .
1.2.5 Loops . . . . . . . . . .
1.2.6 Provided Functions . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

1
2
2
3
4
4
6
6
6
7
9
9
10

2 Classical Cryptosystems
2.1 Transposition Ciphers . . . . . . . . . . . . . . . . .
2.1.1 Scytales to Matrices . . . . . . . . . . . . . .
2.1.2 Encryption in Matlab . . . . . . . . . . . . .
2.1.3 Decryption in Matlab . . . . . . . . . . . . .
2.1.4 Cryptanalysis . . . . . . . . . . . . . . . . . .
2.2 Caesar Ciphers . . . . . . . . . . . . . . . . . . . . .
2.2.1 Caesar Encryption and Modular Arithmetic .
2.2.2 Caesar Decryption and Additive Inverses . .
2.2.3 Groups . . . . . . . . . . . . . . . . . . . . .
2.2.4 Caesar Cryptanalysis . . . . . . . . . . . . . .
2.3 Ane Ciphers . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Ane Encryption . . . . . . . . . . . . . . .
2.3.2 Ane Decryption and Multiplicative Inverses
2.3.3 Rings . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

13
14
14
15
19
19
21
21
23
23
24
27
27
27
28

iii

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

Contents

2.4

2.3.4 Ane Cryptanalysis . .

Polyalphabetic Ciphers . . . . .
2.4.1 Encryption . . . . . . .
2.4.2 Decryption . . . . . . .
2.4.3 Cryptanalysis . . . . . .
2.4.4 Polyalphabetic Variants

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

32
34
34
35
35
38

3 Modern Cryptosystems
3.1 Die-Hellman Key Exchange . . . . . . .
3.1.1 Primitive Roots . . . . . . . . . . .
3.1.2 Key Exchange . . . . . . . . . . .
3.1.3 Matlab Implementation . . . . . .
3.1.4 Man-in-the-middle Attacks . . . .
3.2 RSA . . . . . . . . . . . . . . . . . . . . .
3.2.1 Encryption . . . . . . . . . . . . .
3.2.2 Decryption . . . . . . . . . . . . .
3.2.3 Security . . . . . . . . . . . . . . .
3.3 Cryptographic Hashes . . . . . . . . . . .
3.3.1 Properties . . . . . . . . . . . . . .
3.3.2 Applications . . . . . . . . . . . .
3.3.3 Cryptanalysis . . . . . . . . . . . .
3.4 Digital Signatures . . . . . . . . . . . . .
3.4.1 RSA-based Signature Scheme . . .
3.4.2 DLP-based Signature Scheme . . .
3.5 Zero-Knowledge Proofs . . . . . . . . . . .
3.5.1 Schnorr Authentication . . . . . .
3.5.2 Feige-Fiat-Shamir Authentication .
3.6 Ethics in Cryptography . . . . . . . . . .
3.6.1 Obligations to Customers . . . . .
3.6.2 Utility of Hacking . . . . . . . . .
3.6.3 What to do with a break-through .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

41
42
42
43
44
46
47
49
50
50
51
52
53
54
57
57
59
63
64
66
69
69
70
71

Appendix A Studio problems

A.1 Studio 1.1: Communication Systems
A.2 Studio 1.2: Matlab . . . . . . . . . .
A.3 Studio 2.1: Transposition Ciphers . .
A.4 Studio 2.2: Caesar Ciphers . . . . .
A.5 Studio 2.3: Ane Ciphers . . . . . .
A.6 Studio 2.4: Polyalphabetic Ciphers .
A.7 Studio 3.1: Die-Hellman . . . . . .
A.8 Studio 3.2: RSA . . . . . . . . . . .
A.9 Studio 3.3: Cryptographic Hashes . .
A.10 Studio 3.4: Digital Signatures . . . .
A.11 Studio 3.5: Zero-Knowledge Proofs .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

73
74
75
76
77
79
82
84
85
87
89
93

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

Contents
Appendix B Studio solutions
B.1 Studio 1.1 Solutions: Communication Systems .
B.2 Studio 1.2 Solutions: Matlab . . . . . . . . . .
B.3 Studio 2.1 Solutions: Transposition Ciphers . .
B.4 Studio 2.2 Solutions: Caesar Ciphers . . . . . .
B.5 Studio 2.3 Solutions: Ane Ciphers . . . . . .
B.6 Studio 2.4 Solutions: Polyalphabetic Ciphers .
B.7 Studio 3.1 Solutions: Die-Hellman . . . . . .
B.8 Studio 3.2 Solutions: RSA . . . . . . . . . . . .
B.9 Studio 3.3 Solutions: Cryptographic Hashes . .
B.10 Studio 3.4 Solutions: Digital Signatures . . . .
B.11 Studio 3.5 Solutions: Zero-Knowledge Proofs .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

95
96
98
100
103
106
110
112
115
118
121
128

Appendix C Teaching Notes

C.1 Teaching Note 1.1: Communication Systems
C.2 Teaching Note 1.2: Matlab . . . . . . . . .
C.3 Teaching Note 2.1: Transposition Ciphers .
C.4 Teaching Note 2.2: Caesar Ciphers . . . . .
C.5 Teaching Note 2.3: Ane Ciphers . . . . .
C.6 Teaching Note 2.4: Polyalphabetic Ciphers
C.7 Teaching Note 3.1: Die-Hellman . . . . .
C.8 Teaching Note 3.2: RSA . . . . . . . . . . .
C.9 Teaching Note 3.3: Cryptographic Hashes .
C.10 Teaching Note 3.4: Digital Signatures . . .
C.11 Teaching Note 3.5: Zero-Knowledge Proofs

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

131
132
133
134
135
136
137
138
139
140
141
142

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

Contents

Chapter

Introduction
Cryptography is just one of a collection of technologies that allows us to communicate with one another in a digital world. In fact, these technologies can be
abstracted outside the digital context into a so-called communication system.
This theoretic object is helpful in allowing us to examine what we consider
important in a communication scheme and how these various important pieces
might t together. The general communication systems also give us the opportunity to introduce some important archetypical characters, namely Alice, Bob,
and Eve, into our vocabulary.
In both the classical and modern cryptosystems that we will study, you will
have the chance to implement the system itself and a successful attack on that
system, when one exists. This implementation is incredibly helpful, as it allows
us to see the details of a particular system in action. These exercises do require
some experience programming. Well assume here that the typical student has
no prior knowledge. Well begin with some general examples and move into
more cryptographic applications as we gain condence.

Chapter 1. Introduction

1.1

Communication Systems

The hardware and software components of communications systems are knit

together by deep and fascinating mathematics. In the most general framework,
we consider one party, traditionally named Alice, who wants to send a secret
message to another party, traditionally named Bob. Alice can only communicate to Bob through a noisy public channel (e.g., postal service, hardwired
connection, radio, Wi) which is monitored by an eavesdropper, traditionally
named Eve, who hears everything that Alice says to Bob. In a full communication system, there are three main processes that are completed before Alice
transmits her message to Bob: compression, encryption, and protection as
seen in Figure 1.1. This conceptual framework was formalized by Claude Shannon and Warren Weaver in the mid-1940s. Shannon went on to develop the
eld of information theory, an enormously important subject which today
encompasses all compression, encryption, and protection technologies.

$OLFH

&RPSUHVV

3URWHFW

(QFU\SW

(YH

%RE

'HFRPSUHVV

'HFU\SW

&KDQQHO

&RUUHFW

Figure 1.1: General communication system with Alice sending a message to Bob
through a public channel monitored by Eve.

1.1.1

Compression

In order to save time and energy, Alice typically wants to send as short a message
as possible while getting her point across. She can use a suite of mathematical
techniques broadly called compression to make her message as small as possible while retaining most or all of its meaning. For instance, if Alice were trying
to send the message Lets meet together tonight at 9 oclock on the Boston

1.1. Communication Systems

Common. Looking forward to seeing you then!, a very simple compression
scheme would reduce this message to Meet tonight nine pm Boston Common.
While perhaps not as polite, this new message certainly conveys the same basic
idea as the original. You can imagine that compression techniques get quite a
bit more complicated than this small example, but the idea is still the same:
remove redundancy from the message.
Example 1.1.1. Imagine a census agent wants to transmit the aggregate genders she counted in a particular day. The list reads
M, F, M, F, F, F, N, M, M, . . . , F
There are 505 females (F), 490 males (M), and 5 individuals who preferred not
to respond (N) in the sample. How might she compress her message?
Rather than send 1,000 dierent characters, the census agent might send
something like 505F, 490M, 5N. Notice that she could have also sent the groups
in a dierent order without changing the message.

1.1.2

Encryption

Since Alice wants her message to Bob to be secret, she somehow needs to make
the message she sends across the public channel unintelligible to everyone but
Bob. She can accomplish this with a number of mathematical techniques broadly
termed encryption. An encryption technique matches each character in the
original message (called the plaintext in encryption protocols) into a unique
character in the encrypted message (called the ciphertext in encryption protocols). As far as displaying these messages, the traditional approach is to
Use only capital letters
Ignore punctuation and other non-alphabetic characters
Group characters in small sets in order to minimize human errors in processing
We will ask ourselves how our cryptographic tools would have to change if we
ignored some or all of these bullet points, but for now, lets stick to the easier
case.
Example 1.1.2. Suppose Alice and Bob could have agreed that an A in plaintext
will become a B in the ciphertext. Similarly, a B would turn into a C, and so on.
Using the display conventions laid out above, Alices compressed message Meet
tonight nine pm Boston Common would read
MEETT ONIGH TNINE PMBOS TONCO MMON
Using the encryption scheme outlined above, Alices message would be transformed in the following way:
NFFUU POJHI UOJOF QNCPT UPODP NNPO

Chapter 1. Introduction
While this ciphertext looks like complete gibberish, both Alice and Bob know
that a meaningful message lies underneath. But what about our eavesdropper
Eve? We could assume that she knows nothing about how Alice and Bob have
decided to encrypt their messages. This approach is called secrecy through
obscurity; Alice and Bob keep everything about their encryption scheme secret,
and in that way keep Eve from deciphering their messages. The issue here is that
if Eve somehow manages to get an idea of how the message is being encoded,
then Alice and Bob will underestimate her capabilities, which is in general a
very bad thing to do to an adversary. Instead we typically follow Shannons
maxim (also called Kerckho s law) which says in short The enemy knows
the system. In more detail, we assume that Eve knows everything about how
the message was encrypted except for a special piece of secret information call
the key. In Example 1.1.2 for instance, we assume that Eve knows that Alice
and Bob are encrypting by substituting one letter for another, but that she does
not know the secret substitution rule. If Eve wants to break the code, she needs
to gure out, in one way or another, what the substitution rule is. Both the
encryption process, called cryptography, and the breaking of ciphers, called
cryptanalysis, are huge elds, each with their own beautiful and powerful
results. We will discuss both in the context of several cryptosystems in these
notes.

1.1.3

Protection

The nal step Alice performs before transmission is protection. The public channel across which Alice and Bob communicate is a noisy place. We assume that
Alice and Bob are not the only pair of people trying to communicate over this
space. Moreover, many channels have inherent background noise that makes
hearing and understanding a message dicult. For a physical example, imagine
Alice is trying to tell Bob a secret in a crowded restaurant. Other pairs of people
are talking, theres noise from the kitchen, and the music playing is drowning
out much of the conversation. What can Alice do to get her message across?
She could talk louder. Or perhaps she could repeat herself several times, in the
hopes that Bob could piece together her meaning. Well see that these are only
two of the most basic attempts at message protection. There are sophisticated
mathematical techniques that allow Alice to systematically introduce extra information into her message so that Bob will be able to reconstruct her meaning,
even if some of her message is corrupted during transmission.

1.1.4

Representations of Data

In the classical cryptosystems discussed in Chapter 2, messages are traditionally

represented in uppercase letters without any spaces, punctuation, or other nonalphabetic characters. In many cryptosystems, however, it is convenient to be
able to perform arithmetic operations when turning plaintext into ciphertext.
This necessitates a consistent method for converting numbers to letters. The

1.1. Communication Systems

most straightforward is to associate the 26 letters in order with the numbers 0,
1, . . . , 25:
A 0, B 1, C 2, . . . , Z 25.
It may seem more natural to begin number at 1 instead of 0, but well see over
the course of our investigations that the presence of zero is extremely useful,
and indeed necessary, in many cryptosystems. We can therefore think of strings
of characters and arrays of numbers interchangeably and will frequently do so
without further mention. Rectangular arrays of numbers with either one row or
one column are called vectors. A rectangular array with r rows and c columns
is called an r c matrix. Vectors are a subset of matrices in the same way that
squares are a subset of rectangles. We will often think of messages in terms of
both vectors and matrices.
Example 1.1.3. The following array of characters and the numerical vector
are equivalent:
ZEBRA [25 4 1 17 0].
Example 1.1.4. The following array of characters and the numerical matrix
are equivalent:


L O
11 14

.
V E
21 4
In the modern cryptosystems discussed in Chapter 3, messages are traditionally represented by strings of 0s and 1s. Each 0 or 1 is called a bit (a
contraction of the phrase binary digit). We can represent text as a bit string
by representing each character as itself a bit string and then concatenating, that
is appending one after the other. Perhaps the most popular way to accomplish
this conversion is the ASCII (American Standard Code for Information Interchange). The ASCII alphabet is extensive. For instance, the ASCII bit string
for the letter A is 1000001, the ASCII bit string for the letter a is 1100001, and
the bit string for the character ! is 0100001. For a full list, check out the ASCII
Wikipedia page (click here).
The good news is that we rarely have to deal with this conversion explicitly.
Almost always it is enough to know that we can convert any string of characters
into a unique string of bits, and vice versa. We can therefore think of encoding just the bits themselves, and leave the worrying about the conversion to a
computer. Well discuss this paradigm in much more detail at the beginning of
Chapter 3.

Chapter 1. Introduction

1.2

Matlab

Matlab is an industry-standard computational package developed by MathWorks. In this section, we will cover some core computer programming ideas
and their corresponding implementation in Matlab.

1.2.1

Basic Arithmetic

At its most basic, Matlab is a high powered calculator. For instance, if we enter
1 + 2 in the command line, we observe
>> 1 + 2
ans =
3
Sometimes we dont want to show the output of a particular computation. We
can suppress the output by appending a semicolon:
>> 1 + 2;
>>
Note that Matlab has still performed the computation; it just hasnt shown us
the results. Basic arithmetic works much the way youd probably expect, with
+, -, /, *, and ^ all performing their traditional roles.

1.2.2

Variable Assignment

We often need to use the result of a computation for some other purpose. We can
store the results of a computation using variable assignment. An assignment
always has the form
variable name = variable value.
We assign the value on the right of the equals sign to the variable name on the
left of the equals sign. For example,
>> x = 1 + 2;
>> x
x =
3
The variable x now has value 3 and will continue to have this value until we
overwrite it or clear it.
Variable assignment can produce expressions that might not make sense at
rst look. For instance, consider

1.2. Matlab
>> x = 1 + 2;
>> x = 2*x;
The last line seems strange from a mathematical perspective. If we consider this
to be an equation, there is only one value of x that satises the constraint. But
this is not an equation! Its a variable assignment! So we take the value on the
right side of the equals sign and assign it to the variable name on the left side
of the equals sign. After the rst line executes, we have x = 3. The value on
the right side of the equals sign on the second line is therefore 6. So the second
line actually overwrites the old value of x with a new value of 6. While these
types of assignments are perfectly legal, and in some cases desirable, they can
also easily confuse people who are trying to read your code. Be careful using
them.

1.2.3

Arrays

One of the strongest aspects of Matlab is that it can deal with arrays and
matrices very eciently. We can generate arrays very simply.
>> a = 1:5
a =
1

Notice that we couldve arrived at the same result by entering

>> a = [1, 2, 3, 4, 5];
We can see that a is a 1 5 matrix, also called a row vector.
>> size(a)
ans =
1

To see exactly what the size function is telling us, we can type help size
in the command line.
We could turn a into a column vector b by appending a single apostrophe.
>> b = a
b =
1
2
3
4
5