Found tions of Cryp⊕graphy

or: The Unofficial Notes on the Georgia Institute

of Technology’s CS6260: Applied Cryptography

George Kudrayvtsev
[email protected]

Last Updated: October 30, 2020

Those who would give up essential Liberty, to purchase a little tem-

porary Safety, deserve neither Liberty nor Safety.
— Benjamin Franklin

1
0 Preface 6

1 Introduction 8

I Symmetric Cryptography 10
2 Perfect Security 11
2.1 Notation & Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 One-Time Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 The Beauty of XOR . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Proving Security . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Block Ciphers 16
3.1 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 ECB—Electronic Code Book . . . . . . . . . . . . . . . . . . . 17
3.1.2 CBC—Cipher-Block Chaining . . . . . . . . . . . . . . . . . . 17
3.1.3 CBCC—Cipher-Block Chaining with Counter . . . . . . . . . 18
3.1.4 CTR—Randomized Counter Mode . . . . . . . . . . . . . . . 18
3.1.5 CTRC—Stateful Counter Mode . . . . . . . . . . . . . . . . . 20
3.2 Security Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 IND-CPA: Indistinguishability Under Chosen-Plaintext Attacks 21
3.2.2 IND-CPA-cg: A Chosen Guess . . . . . . . . . . . . . . . . . . 23
3.2.3 What Makes Block Ciphers Secure? . . . . . . . . . . . . . . . 25
3.2.4 Random Functions . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 IND-CCA: Indistinguishability Under Chosen-Ciphertext Attacks 32
3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Message Authentication Codes 36

4.1 Notation & Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Security Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.1 UF-CMA: Unforgeability Under Chosen-Message Attacks . . . 38
4.3 Mode of Operation: CBC-MAC . . . . . . . . . . . . . . . . . . . . . 39

5 Hash Functions 41
5.1 Collision Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Building Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 One-Way Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Hash-Based MACs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Authenticated Encryption 49
6.1 INT-CTXT: Integrity of Ciphertexts . . . . . . . . . . . . . . . . . . 49
6.2 Generic Composite Schemes . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.1 Encrypt-and-MAC . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.2 MAC-then-encrypt . . . . . . . . . . . . . . . . . . . . . . . . 51

2
 6.2.3 Encrypt-then-MAC . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.4 In Practice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.5 Dedicated Authenticated Encryption . . . . . . . . . . . . . . 53
6.3 AEAD: Associated Data . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.1 GCM: Galois/Counter Mode . . . . . . . . . . . . . . . . . . . 54

7 Stream Ciphers 55
7.1 Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1.1 PRGs for Encryption . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Evaluating PRGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3 Creating Stream Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3.1 Forward Security . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.2 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8 Common Implementation Mistakes 59

II Asymmetric Cryptography 61
9 Overview 63
9.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.2 Security Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

10 Number Theory 65
10.1 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.2 Modular Arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10.2.1 Running Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10.2.2 Inverses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
10.2.3 Modular Exponentiation . . . . . . . . . . . . . . . . . . . . . 69
10.3 Groups for Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.3.1 Discrete Logarithm . . . . . . . . . . . . . . . . . . . . . . . . 70
10.3.2 Constructing Cyclic Groups . . . . . . . . . . . . . . . . . . . 71
10.4 Modular Square Roots . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.4.1 Square Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.4.2 Square Root Extraction . . . . . . . . . . . . . . . . . . . . . 75
10.5 Chinese Remainder Theorem . . . . . . . . . . . . . . . . . . . . . . . 76

11 Encryption 77
11.1 Recall: The Discrete Logarithm . . . . . . . . . . . . . . . . . . . . . 77
11.1.1 Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
11.1.2 Difficulty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
11.2 Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . . . . . . 81
11.3 ElGamal Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.3.1 Security: IND-CPA . . . . . . . . . . . . . . . . . . . . . . . . 82

3
 11.3.2 Security: IND-CCA . . . . . . . . . . . . . . . . . . . . . . . . 84
11.4 Cramer-Shoup Encryption . . . . . . . . . . . . . . . . . . . . . . . . 84
11.5 RSA Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.5.1 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
11.5.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
11.5.3 Securing RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
11.6 Hybrid Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
11.7 Multi-User Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 91
11.7.1 Security Definitions . . . . . . . . . . . . . . . . . . . . . . . . 92
11.7.2 Security Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 93
11.8 Scheme Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

12 Digital Signatures 95
12.1 Security Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
12.2 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
12.2.1 Plain RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
12.2.2 Full-Domain Hash RSA . . . . . . . . . . . . . . . . . . . . . 97
12.2.3 Probabilistic Signature Scheme . . . . . . . . . . . . . . . . . 98
12.3 ElGamal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
12.4 Digital Signature Algorithm . . . . . . . . . . . . . . . . . . . . . . . 100
12.5 Schnorr Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12.6 Scheme Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.6.1 Simple Multi-Signature Scheme . . . . . . . . . . . . . . . . . 103
12.6.2 Simple Blind Signature Scheme . . . . . . . . . . . . . . . . . 104
12.7 Signcryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

13 Secret Sharing 106

13.1 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 106
13.1.1 Registering Users . . . . . . . . . . . . . . . . . . . . . . . . . 106
13.1.2 Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
13.1.3 Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
13.1.4 An Alternative: Pretty Good Privacy . . . . . . . . . . . . . . 108
13.2 Secret Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
13.2.1 Shamir’s Secret Sharing . . . . . . . . . . . . . . . . . . . . . 109
13.2.2 Threshold Schemes . . . . . . . . . . . . . . . . . . . . . . . . 110
13.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . . . . . . . 111
13.4 Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

14 Epilogue 114

III Advanced Topics 115

15 Secure Cryptographic Primitives 116

4
 15.1 OWFs to PRGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
15.1.1 Extension by 1 Bit . . . . . . . . . . . . . . . . . . . . . . . . 117
15.1.2 Arbitrary Extension . . . . . . . . . . . . . . . . . . . . . . . 121
15.2 PRGs to PRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
15.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
15.3.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

16 Commitments 124
16.1 Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
16.2 Pedersen Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.2.1 Proof of Properties . . . . . . . . . . . . . . . . . . . . . . . . 125

17 Random Oracle Model 127

17.1 An Amazing PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
17.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
17.2.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

18 Zero-Knowledge Proofs 130

18.1 Knowledge Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
18.1.1 Example: Factorization . . . . . . . . . . . . . . . . . . . . . . 131
18.1.2 Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
18.2 Zero-Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
18.2.1 Example: Factorization . . . . . . . . . . . . . . . . . . . . . . 132
18.2.2 Example: Graph Coloring . . . . . . . . . . . . . . . . . . . . 133
18.2.3 Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
18.3 Schnorr’s Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
18.4 Interactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
18.5 Succinctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
18.5.1 Why Succinct Proofs? . . . . . . . . . . . . . . . . . . . . . . 137
18.5.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
18.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

19 Multi-Party Computation 139

19.1 Two-Party Computation . . . . . . . . . . . . . . . . . . . . . . . . . 139
19.1.1 Oblivious Transfer . . . . . . . . . . . . . . . . . . . . . . . . 140
19.1.2 Yao’s Garbled Circuits . . . . . . . . . . . . . . . . . . . . . . 140
19.2 Extending to More Parties . . . . . . . . . . . . . . . . . . . . . . . . 140

20 Elliptic Curves 141

Index of Terms 142

5
Preface

I read that Teddy Roosevelt once said, “Do what you can with
what you have where you are.” Of course, I doubt he was in the
tub when he said that.
— Bill Watterson, The Days are Just Packed

These are not official course materials; they were created throughout my time
taking the course, so there cannot be any guarantees about the correctness of the
content. You can refer to some official resources like Bellare & Rogaway’s notes
or Boneh & Shoup’s course for a better, deeper look at the concepts I cover here.
If you encounter typos; incorrect, misleading, or poorly-worded information; or
simply want to contribute a better explanation or extend a section, please raise
an issue on my notes’ GitHub repository.

Before we begin to dive into all things cryptography, I’ll enumerate a few things I do
in this notebook to elaborate on concepts:
• An item that is highlighted like this is a “term;” this is some vocabulary
that will be used and repeated regularly in subsequent sections. I try to cross-
reference these any time they come up again to link back to its first defined
usage; most mentions are available in the Index.
• An item that is highlighted like this is a “mathematical property;” such
properties are often used in subsequent sections and their understanding is
assumed there.
• An item in a maroon box, like. . .

Boxes: A Rigorous Approach

. . . this often represents fun and interesting asides or examples that

6
APPLIED CRYPTOGRAPHY

pertain to the material being discussed. They are largely optional,

but should be interesting to read and have value, even if it’s not
immediately rewarding.

• An item in a blue box, like. . .

Quick Maffs: Proving That the Box Exists

. . . this is a mathematical aside; I only write these if I need to dive
deeper into a concept that’s mentioned in lecture. This could be
proofs, examples, or just a more thorough explanation of something
that might’ve been “assumed knowledge” in the text.

• An item in a green box, like. . .

Definition 0.1: Example

. . . this is an important cryptographic definition. It will often be
accompanied by a highlighted term and dive into it with some math-
ematical rigor.

I also sometimes include margin notes like the one here (which just links back here) Linky
that reference content sources so you can easily explore the concepts further.

Kudrayvtsev 7
Introduction

Cryptography is hard.
— Anonymous

The purpose of a cryptographic scheme falls into three very distinct categories. A
common metaphor used to explain these concepts is a legal document.
• confidentiality ensures content secrecy—that it can’t be read without knowl-
edge of some secret. In our example, this would be like writing the document
in a language nobody except you and your recipient understand.
• authenticity guarantees content authorship—that its author can be irrefutably
proven. In our example, this is like signing the original document in pen (as-
suming, of course, your signature was impossible to forge).
• integrity guarantees content immutability—that it has not been changed. In
our example, this could be that you get an emailed copy of the signed document
to ensure that its language cannot be changed post-signing.
Note that even though all three of these properties can go hand-in-hand, they are
not mutually constitutive. You can have any of them without the others: you can
just get a copy of an unsigned document sent to you in plain English to ensure its
integrity later down the line.

crypto graphy
| {z } | {z }
secret writing

Analysing any proposed protocol, handshake, or other cryptographic exchange through

the lens of each of these principles will be enlightening. Not every scheme is intended
to guarantee all three of them, and different methods are often combined to achieve
more than one of these properties. In fact, cases in which only one of the three prop-
erties are necessary occur all the time. It’s important to not make a cryptographic
scheme more complicated than it needs to be to achieve a given purpose: complexity

8
APPLIED CRYPTOGRAPHY

breeds bugs.

Trivia: Cryptography’s Common Cast of Characters

It’s really useful to anthropomorphize our discussion of the mathematical

intricacies in cryptography. For that, we use a cast of characters whose
names give us immediate insight into what we should expect from them.

• Alice and Bob are the most common sender-recipient pairing. They
are generally acting in good faith and aren’t trying to break the cryp-
tographic scheme in question. If a third member is necessary, Carol
will enter the fray (for consistency of the allusion to Lewis Carroll’s
Alice in Wonderland ).
• Eve and Mallory are typically the two members trying to break the
scheme. Eve is a passive attacker (short for eavesdropper) that merely
observes messages between Alice and Bob, whereas malicious Mallory
is an active attacker who can capture, modify, and inject her own
messages into exchanges between other members.

You can check out the Wikipedia article on the topic for more historic trivia
and the full cast of characters.

Kudrayvtsev 9
PART I
Symmetric Cryptography

he notion of symmetric keys comes from the fact that both the sender and
T receiver of encrypted information share the same secret key, K. This secret is
the only thing that separates a viable receiver from an attacker.

Eve

K Alice Bob K

Symmetric key algorithms are often very efficient and supported by hardware, but
their fatal flaw lies in key distribution. If two parties need to share a secret without
anyone else knowing, how do they get it to each other without already having a secure
channel? That’s the job of Part II: asymmetric cryptography.

Contents
2 Perfect Security 11

3 Block Ciphers 16

4 Message Authentication Codes 36

5 Hash Functions 41

6 Authenticated Encryption 49

7 Stream Ciphers 55

8 Common Implementation Mistakes 59

10
Perfect Security

How long do you want these messages to remain secret? I want

them to remain secret for as long as men are capable of evil.
— Neal Stephenson, Cryptonomicon

s mentioned in the Introduction, algorithms in symmetric cryptography rely on

A all members having a shared secret. Let’s cover the basic notation we’ll be using
to describe our schemes and then dive into some.

2.1 Notation & Syntax

For consistency, we’ll need common conventions when referring to cryptographic prim-
itives in a scheme.
A well-described symmetric encryption scheme covers the following:
• a message space, denoted as the MsgSp or M for short, describes the set of
things which can be encrypted. This is typically unrestricted and (especially
in the context of the digital world) includes anything that can be encoded as
bytes.
• a key generation algorithm, K, or the key space spanned by that algorithm,
KeySp, describes the set of possible keys for the scheme and how they are
created. The space typically restricts its members to a specific length.
• a encryption algorithm and its corresponding decryption algorithm (E, D)
describe how a message m ∈ M is converted to and from ciphertext. We will
use the notation E(K, M ) and EK (M ) interchangeably to indicate encrypting
M using the key K (and similarly for D).
A well-formed scheme must allow all valid messages to be en/decrypted. Formally,
this means:
∀m ∈ MsgSp, ∀k ∈ KeySp : D(k, E(k, m)) = m

11
CHAPTER 2: Perfect Security

An encryption scheme defines the message space and three algorithms: (MsgSp, E, D, K).
The key generation algorithm often just pulls a random n-bit string from the entire
$
{0, 1}n bit space; to describe this action, we use notation K ←− KeySp. The encryp-
tion algorithm is often randomized (taking random input in addition to (K, M )) and
stateful. We’ll see deeper examples of all of these shortly.

2.2 One-Time Pads

A one-time pad (or OTP) is a very basic and simple way to ensure absolutely perfect
encryption, and it hinges on a fundamental binary operator that will be at the heart
of many of our symmetric encryption schemes in the future: exclusive-or.
Messages are encrypted with an equally-long sequence of random bits using XOR.
With our notation, one-time pads can be described as such:
• the key space is all n-bit strings: KeySp = {0, 1}n
• the message space is the same: MsgSp = {0, 1}n
• encryption and decryption are just XOR:

E(K, M ) = M ⊕ K
D(K, C) = C ⊕ K

Can we be a little more specific with this notion of “perfect encryption”? Intuitively, a
secure encryption scheme should reveal nothing to adversaries who have access to the
ciphertext. Formally, this notion is called being Shannon-secure (and is also referred
to as perfect security): the probability of a ciphertext occurring should be equal
for any two messages.

Definition 2.1: Shannon-secure

An encryption scheme, (K, E, D), is Shannon-secure if:

∀m1 , m2 ∈ MsgSp, ∀C :
Pr [E(K, m1 ) = C] = Pr [E(K, m2 ) = C] (2.1)

That is, the probability of a ciphertext C must be equally-likely for any two
messages that are run through E.

Note that this doesn’t just mean that a ciphertext occurs with equal probability
for a particular message, but rather than any message can map to any ciphertext

Kudrayvtsev 12
APPLIED CRYPTOGRAPHY Symmetric Cryptography

with equal probability. It’s often necessary but not sufficient to show that a specific
message maps to a ciphertext with equal probability under a given key; additionally,
it’s necessary to show that all ciphertexts can be produced by a particular message
(perhaps by varying the key).
Shannon security can also be expressed as a conditional probability,1 where all mes-
sages are equally-probable (i.e. independent of being) given a ciphertext:
∀m ∈ MsgSp, ∀C :
Pr [M = m | C] = Pr [M = m]

Are one-time pads Shannon-secure under these definitions? Yes, thanks to XOR.

2.2.1 The Beauty of XOR

XOR is the only primitive binary operator that outputs 1s and 0s with the same
frequency, and that’s what makes it the perfect operation for achieving unpredictable
ciphertexts.
Given a single bit, what’s the probability of the input bit?

x y x⊕y
1 1 0
1 0 1
0 1 1
0 0 0
Table 2.1: The truth table for XOR.

Suppose you have some c = 0 (where c ∈ {0, 1}1 ); what was the input bit m? Well
it could’ve been 1 and been XOR’d with 1 OR it could’ve been 0 and been XOR’d
with 0. . . Knowing c gives us no new information about the input: our guess is still
as good as random chance ( 12 = 50%).
Now suppose you know that c = 1; are your odds any better? In this case, m could’ve
been 1 and been XOR’d with 0 OR it could’ve been 0 and XOR’d with 1. . . Again,
we can’t do better than random chance.
By the very definition of being Shannon-secure, if we (as the attacker) can’t do better
than random chance when given a ciphertext, the scheme is perfectly secure.

2.2.2 Proving Security

So we did a bit of a hand-wavy proof to show that XOR is Shannon-secure, but let’s
be a little more formal in proving that OTPs are perfect as well.
1
See Definition 2.3 in Katz & Lindell, pp. 29, parts of which are available on Google Books.

Kudrayvtsev 13
CHAPTER 2: Perfect Security

Theorem 2.1. One-time pads are a perfect-security encryption scheme.

Proof. We start by fixing an arbitrary n-bit ciphertext: C ∈ {0, 1}n . We also choose
a fixed n-bit message, m ∈ MsgSp. Then, what’s the probability that a randomly-
generated key k ∈ KeySp will encrypt that message to be that ciphertext? Namely,
what is
Pr [E(K, m) = C]
for our fixed m and C? In other words, how many keys can turn m into C?
Well, by the definition of the OTP, we know that this can only be true for a single
key: K = m ⊕ C. Well, since every bit counts, and the probability of a single bit in
the key being “right” is 1/2:
Pr [E(K, m) = C] = Pr [K = m ⊕ C]
1 1 1
= · · · ...
| 2 {z2
2 }
n times
1
= n
2

Note that this is true ∀m ∈ MsgSp, which fulfills the requirement for perfect security!
Every message is equally likely to result in a particular ciphertext. 

The problem with OTPs is that keys can only be used once. If we’re going to go
through the trouble of securely distributing OTPs,2 we could just exchange the mes-
sages themselves at that point in time. . .
Let’s look at what happens when we use the same key across two messages. From the
scheme itself, we know that Ci = K ⊕ Mi . Well if we also have Cj = K ⊕ Mj , then:
Ci ⊕ Cj = (K ⊕ Mi ) ⊕ (K ⊕ Mj )
= (K ⊕ K) ⊕ (Mi ⊕ Mj ) XOR is associative

= Mi ⊕ Mj a⊕a=0

Though this may seem like insignificant information, it actually can reveal quite a bit
about the inputs, and eventually the entire key if it’s reused enough times.
An important corollary of perfect security is what’s known as the impossibility
result (also referred to as the optimality of the one-time pad when used in that
context):
2
One could envision a literal physical pad in which each page contained a unique bitstring; if two
people shared a copy of these pads, they could communicate securely until the bits were exhausted
(or someone else found the pad). Of course, if either of them lost track of where they were in the
pad, everything would be gibberish from then-on. . .

Kudrayvtsev 14
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Theorem 2.2. If a scheme is Shannon-secure, then the key space cannot be

smaller than the message space. That is,

|KeySp| ≥ |MsgSp|

Proof. We are given an encryption scheme E that is supposedly perfectly-secure. So

we start by fixing a ciphertext with a specific key, (K1 ∈ KeySp and plaintext message,
m1 ∈ MsgSp):
C = E(K1 , m1 )

We know for a fact, then, that at least one key exists that can craft C; thus if we pick
a key K ∈ KeySp at random, there’s a non-zero probability that we’d get C again:

Pr [E(K, m1 ) = C] > 0

Suppose then there is a message m2 ∈ MsgSp which we can never get from decrypting
C:
Pr [D(K, C) = m2 ] = 0 ∀K ∈ KeySp

By the correctness requirement of a valid encryption scheme, if a message can never be

decrypted from a ciphertext, neither should that ciphertext result from an encryption
of the message:
Pr [E(K, M ) = C] = 0 ∀K ∈ KeySp

However, that violates Shannon-secrecy, in which the probability of a ciphertext re-

sulting from the encryption of any two messages is equal; that’s not the case here:

Pr [E(K, M1 ) = C] 6= Pr [E(K, M2 ) = C]

Thus, our assumption is wrong: m2 cannot exist! Meaning there must be some
K2 ∈ KeySp that decrypts C: D(K2 , C) = M2 . Thus, it must be the case that there
are as many keys as there are messages. 

Ideally, we’d like to encrypt long messages using short keys, yet this theorem shows
that we cannot be perfectly-secure if we do so. Does that indicate the end of this
chapter? Thankfully not. If we operate under the assumption that our adversaries
are computationally-bounded, it’s okay to relax the security requirement and make
breaking our encryption schemes very, very unlikely. Though we won’t have perfect
secrecy, we can still do extremely well.
We will create cryptographic schemes that are computationally-secure under Kerck-
hoff ’s principle, which effectively states that everything about a scheme should be
publicly-available except for the secret key(s).

Kudrayvtsev 15
Block Ciphers

hese are one of the fundamental building blocks of symmetric cryptography:

T a block cipher is a tool for encrypting short strings. Well-known examples
include AES and DES.

Definition 3.1: Block Cipher

Formally, a block cipher is a function family that maps from a k-bit key
and an n-bit input string to an n-bit output string:

E : {0, 1}k × {0, 1}n 7→ {0, 1}n

Additionally, ∀K ∈ {0, 1}k , EK (·) is a permutation on {0, 1}n . This means its inverse
is well-defined; we denote it either as EK−1
(·) or the much more intuitive DK (·).

∀M, C ∈ {0, 1}n : EK (DK (C)) = C

DK (EK (M )) = M

In a similar vein, ciphertexts are unique, so ∀C ∈ {0, 1}n , there exists a single M
such that C = EK (M ).

Math Review: Functions

A function is one-to-one if every input value maps to a unique output
value. In other words, it’s when no two inputs map to the same output.
A function is onto if all of the elements in the range have a corresponding
input. That is, ∀y ∃x such that f (x) = y.
A function is bijective if it is both one-to-one and onto; it’s a permutation
if it maps a set onto itself. In our case, the set in question will typically be
the set of all n-length bitstrings: {0, 1}n .

16
APPLIED CRYPTOGRAPHY Symmetric Cryptography

3.1 Modes of Operation

Block ciphers are limited to encrypting an n-bit string, but we want to be able to
encrypt arbitrary-length strings. A mode of operation is a way to combine block
ciphers to achieve this goal. For simplicitly, we’ll assume that our arbitrarily-long
messages are actually a multiple of a block length; if they weren’t, we could just pad
them, but we’ll omit that detail for brevity.

3.1.1 ECB—Electronic Code Book

The simplest mode of operation is ECB mode, visually described in Figure 3.1. Given
an n-bit block cipher E and a message of length nb, we could just encrypt it block by
block. The decryption is just as easy, applying the inverse block cipher on each piece
individually:

C[i] = EK (M [i])
M [i] = DK (C[i])

M [1] M [2] M [b]

EK EK ...... EK

C[1] C[2] C[b]

Figure 3.1: The ECB ciphering mode.

This mode of operation has a fatal flaw that greatly compromises its security: if two
message blocks are identical, the ciphertexts will be as well. Furthermore, encrypting
the same long message will result in the same long ciphertext. This mode of operation
is never used, but it’s useful to present here to highlight how we’ll fix these flaws in
later modes.

3.1.2 CBC—Cipher-Block Chaining

This mode of operation fixes both flaws in ECB mode and is usable in real symmetric
encryption schemes. It introduces a random initialization vector or IV to keep
each ciphertext random, and it chains the output of one block into the input of the
next block.

Kudrayvtsev 17
CHAPTER 3: Block Ciphers

IV M [1] M [2] M [b]

⊕ ⊕ ⊕

EK EK ...... EK

IV C[1] C[2] C[b]

Figure 3.2: The CBC ciphering mode.

Each message block is first chained via XOR with the previous ciphertext before being
run through the encryption algorithm. Similarly, the ciphertext is run through the
inverse then XOR’d with the previous ciphertext to decrypt. That is,
C[i] = EK (M [i] ⊕ C[i − 1])
M [i] = DK (C[i]) ⊕ C[i − 1]
(where the base case is C[0] = IV ).
The IV can be sent out in the clear, unencrypted, because it doesn’t contain any secret
information in-and-of itself. If Eve intercepts it, she can’t do anything useful with it;
if Mallory modifies it, the decrypted plaintext will be gibberish and the recipient will
know something is up.
However, if an initialization vector is repeated, there can be information leaked to
keen attackers about the underlying plaintext.

3.1.3 CBCC—Cipher-Block Chaining with Counter

In this mode, instead of using a randomly-generated IV, a counter is incremented
for each new message until it wraps around (which typically doesn’t occur, consider
2128 ). This counter is XOR’d with the plaintext to encrypt and decrypt:
C[i] = EK (M [i] ⊕ C[i − 1]) (where C0 = ctr)
M [i] = DK (C[i]) ⊕ C[i − 1]

The downside of these two algorithms is not a property of security but rather of
performance. Because every block depends on the outcome of the previous block,
both encryption and decryption must be done in series. This is in contrast with. . .

3.1.4 CTR—Randomized Counter Mode

Like ECB mode, this encryption mode encrypts each block independently, meaning
it can be parallelized. Unlike all of the modes we’ve seen so far, though, it does not

Kudrayvtsev 18
APPLIED CRYPTOGRAPHY Symmetric Cryptography

ctr M [1] M [2] M [b]

⊕ ⊕ ⊕

EK EK ...... EK

ctr C[1] C[2] C[b] ctr += 1

Figure 3.3: The CBCC ciphering mode.

use a block cipher as its fundamental primitive.1 Specifically, the encryption function
does not need to be invertible. Whereas before we used EK as a mapping from a
k-bit key and an n-bit string to an n-bit string (see Definition 2.2), we can now use
a function that instead maps them to an m-bit string:
F : {0, 1}k × {0, 1}l 7→ {0, 1}L

R+1 R+2 R+m

FK FK FK

M [1] ⊕ M [2] ⊕ ...... M [m] ⊕

R C[1] C[2] C[m]

Figure 3.4: The CTR ciphering mode.

This is because both the encryption and decryption schemes use FK directly. They
rely on a randomly-generated value R as fuel, much like the IV in the CBC modes.2
Notice that to decrypt C[i] in Figure 3.4, one needs to first determine FK (R + i),
then XOR that with the ciphertext to get M [i]. The plaintext is never run through the
encryption algorithm at all; instead, FK (R + i) is used as a one-time pad for M [i].
That is,
C[i] = M [i] ⊕ FK (R + i)
M [i] = C[i] ⊕ FK (R + i)

Note that in all of these schemes, the only secret is K (F and E are likely standardized
and known).
1
In practice, though, FK will generally be a block cipher. Even though this properly is noteworthy,
it does not offer any additional security properties.
2
In fact, I’m not sure why the lecture decides to use R instead of IV here to maintain consistency.
They are mathematically the same: both R and IV are pulled from {0, 1}n .

Kudrayvtsev 19
CHAPTER 3: Block Ciphers

3.1.5 CTRC—Stateful Counter Mode

Just like CBC, this mode has a variant that uses a counter rather than a randomly-
generated value.

ctr + 1 ctr + 2 ctr + m

FK FK ... FK

M [1] ⊕ M [2] ⊕ M [m] ⊕ ctr += m + 1

ctr = 0n C[1] C[2] C[m]

Figure 3.5: The CTRC ciphering mode.

3.2 Security Evaluation

Recall that we established that Shannon-secure schemes are impractical, and that
we’re instead relying on adversaries being computationally bounded to achieve a rea-
sonable level of security. To analyze our portfolio block ciphers, then, we need new
definitions of this “computationally-bounded level of security.”
It’s easier to reverse the definition: a secure scheme is one that is not insecure. An
insecure scheme allows a passive adversary that can see all ciphertexts do malicious
things like learn the secret key or read any of the plaintexts. This isn’t rigorous
enough, though: if the attacker can’t see any bits of the plaintext but can compute
their sum, is that secure? What if they can tell when identical plaintexts are sent,
despite not knowing their content?
There are plenty of possible information leaks to consider and it’s impossible to enu-
merate them all (especially when new attacks are still being discovered!). Dr. Boldyreva
informally generalizes the aforementioned ideas:
Informally, an encryption scheme is secure if no adversary with “reasonable” re-
sources who sees several ciphertexts can compute any3 partial information about
the plaintexts, besides some a priori information.

Though this informality is not useful enough to prove things about encryption schemes
we encounter, it’s enough to give us intuition on the formal definition ahead.

3
Any information except the length of the plaintexts; this knowledge is assumed to be public.

Kudrayvtsev 20
APPLIED CRYPTOGRAPHY Symmetric Cryptography

3.2.1 IND-CPA: Indistinguishability Under Chosen-Plaintext

Attacks
It may be a mouthful, but the ability for a scheme to keep all information hidden
when an attacker gets to feed their chosen inputs to it is key to a secure encryption
scheme. IND-CPA is the formal definition of this attack.
$
We start with a fixed scheme and secret key, SE = (KeySp, E, D) ; K ←− KeySp.
Consider an adversary A that has access to an oracle. When they provide the oracle
with a pair of equal-length messages, m0 , m1 ∈ MsgSp, it outputs a ciphertext.
The oracle, called the “left-right encryption” oracle, chooses a bit b ∈ {0, 1}1 to
determine which of these messages to encrypt. It then passes mb to the encryption
function and outputs the ciphertext, C = EK (mb ).

m0 , m1 mb
A LR (m0 , m1 , b) EK (·)
? ?

Figure 3.6: A visualization of the IND-CPA adversary scenario.

The adversary does not know the value of b, and thus does not know which of the
messages was encrypted; it’s their goal to figure this out, given full access to the oracle.
We say that an encryption scheme is secure if the adversary’s ability to determine
which experiment the ciphertexts came from is no better than random chance.

Definition 3.2: IND-CPA

A scheme SE is considered secure under IND-CPA if an adversary’s IND-
CPA advantage—the difference between their probability of guessing cor-
rectly and guessing incorrectly—is small (≈ 0):

Advind-cpa (A) = Pr [A guessed 0 for experiment 0] −

Pr [A guessed 0 for experiment 1]

Since we are dealing with a “computationally-bounded” adversary, A, we need to be

cognizant about the real-world meaning behind resource usage. At the very least,
we should consider the running time of our scheme and A’s attack. After all, if the
encryption function itself takes an entire year, it’s likely unreasonable to give the
attacker more than a few hundred tries at the oracle before they’re time-bound.
We should likewise be cognizant of how many queries the attacker makes and how

Kudrayvtsev 21
CHAPTER 3: Block Ciphers

long they are. We might be willing to make certain compromises of security if, for
example, the attacker needs a 2512 -length message to gain an advantage.
With our new formal definition of security under our belt, let’s take a crack at break-
ing the various Modes of Operation we defined. If we can provide an algorithm
that demonstrates a reasonable advantage for an adversary that requires reasonable
resources, we can show that a scheme is not secure under IND-CPA.

Analysis of ECB
This was clearly the simplest and weakest of schemes that we outlined. The lack of
randomness makes gaining an advantage trivial: the message can be determined by
having a message with a repeating and one with a non-repeating plaintext.

Algorithm 3.1: A simple algorithm for breaking the ECB block cipher mode.
C1 k C2 = EK (LR(02n , 0n k 1n , b))
if C1 = C2 then
return 0
end
return 1

The attack can be generalized to give the adversary perfect knowledge for any input
plaintext, and it leads to an important corollary.

Theorem 3.1. Any deterministic, stateless encryption scheme cannot be IND-

CPA secure.

Proof. Under deterministic encryption, identical plaintexts result in identical cipher-

texts. We can always craft a adversary with an advantage. First, we associate ci-
phertexts with plaintexts, then by the third message we can always determine which
ciphertext corresponds to which input.
The proof holds for an arbitrary MsgSp, we chose {0, 1}n in algorithm 3.2 for con-
venience of representation. 

Analysis of CBCC
Turns out, counters are far harder to “get right” relative to random initialization
vectors: their predictable nature means we can craft messages that are effectively
deterministic by replicating the counter state. Namely, if we pre-XOR our plaintext
with the counter, the first ciphertext block functions the same way as in ECB.

Kudrayvtsev 22
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Algorithm 3.2: A generic algorithm for breaking deterministic encryption

schemes.
C1 = EK (LR(0n , 0n , b))
C2 = EK (LR(1n , 1n , b))
// Given knowledge of these two, we can now always differentiate
between them. We can repeat this for any m ∈ MsgSp.
C3 = EK (LR(0n , 1n , b))
if C3 = C1 then
return 0
end
return 1

The first message lets us identify the counter value. The second message lets us craft
a “post-counter” message that will be equal to the third message.

Algorithm 3.3: A simple adversarial algorithm to break CBCC mode.

// First, determine the counter (can’t count on ctr = 0).
C0 k C1 = EK (LR(0n , 1n , b))
// Craft a message that’ll be all-zeros post-counter.
M1 = 0n ⊕ (ctr + 1)
C2 k C3 = EK (LR(M1 , 1n , b))
// Craft it again, then compare equality.
M3 = 0n ⊕ (ctr + 2)
C4 k C5 = EK (LR(M3 , 1n , b))
if C3 = C5 then
return 0
end
return 1

3.2.2 IND-CPA-cg: A Chosen Guess

It turns out that the other modes of operation are provably IND-CPA secure if the
underlying block cipher is secure. Before we dive into those proofs, though, let’s define
an alternative interpretation of the IND-CPA advantage; we will call this formula-
tion IND-CPA-cg, for “chosen guess,” and its shown visually in Figure 3.7. This
formulation will be more convenient to use in some proofs.
In this version, the choice between left and right message is determined randomly at

Kudrayvtsev 23
CHAPTER 3: Block Ciphers

the start and encoded within b. There is now only one experiment: if the attackers
guess matches (b0 = b), the experiment returns 1.

$
b ←− {0, 1}

m0 , m1 mb
A LR (m0 , m1 , ·) EK (·)
? ?

C
b0

Figure 3.7: The “chosen guess” variant on IND-CPA security, where the attacker
must guess a b0 , and the experiment returns 1 if b0 = b.

Definition 3.3: IND-CPA-cg

A scheme SE is still only considered secure under the “chosen guess” variant
of IND-CPA if their IND-CPA-cg advantage is small; this advantage is
now instead defined as:

Advind-cpa-cg (A) = 2 · Pr [experiment returns 1] − 1

The two variants on attacker advantage in Definition 2.3 and the new Definition 2.4
can be proven equal.

Claim 3.1. Advind-cpa (A) = Advind-cpa-cg (A) for some encryption scheme SE.

Proof. The probability of the cg experiment being 1 (that is, the attacker guessing
$
b0 = b correctly) can be expressed as conditional probabilities. Remember that b ←−
{0, 1} with uniformally-random probability.

Pr [experiment-cg returns 1] = Pr [b = b0 ]
= Pr [b = b0 | b = 0] Pr [b = 0] + Pr [b = b0 | b = 1] Pr [b = 1]
1 1
= Pr [b0 = 0 | b = 0] · + Pr [b0 = 1 | b = 1] ·
2 2
1 1 
= · Pr [b = 0 | b = 0] +
0
1 − Pr [b = 0 | b = 1]
0
2 2
1 1  
= + Pr [b = 0 | b = 0] − Pr [b = 0 | b = 1]
0 0
2 2

Kudrayvtsev 24
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Notice the expression in parentheses: the difference between the probability of the
attacker guessing 0 correctly (that is, when it really is 0) and incorrectly. This is
exactly Definition 2.3: advantage under the normal IND-CPA definition! Thus:
1 1 
Pr [exp-cg returns 1] = + Pr [b0 = 0 | b = 0] − Pr [b0 = 0 | b = 1]
2 2| {z }
IND-CPA advantage
1 1
= + Advind-cpa (A)
2 2
2 · Pr [exp-cg returns 1] − 1 = Advind-cpa (A)
Advind-cpa-cg (A) = Advind-cpa (A) (3.1)


3.2.3 What Makes Block Ciphers Secure?

We can now look into the inner guts of each mode of operation and classify some
block ciphers as being “secure” under IND-CPA. Refer to Definition 2.2 to review
the mathematical properties of a block cipher. Briefly, it is a function family with
a well-defined inverse that maps every message to a unique ciphertext for a specific
key.
First off, it’s important to recall that we expect attackers to be computationally-
bounded to a reasonable degree. This is because block ciphers—and all symmetric
encryption schemes, for that matter—are susceptible to an exhaustive key-search
attack, in which an attacker enumerates every possible K ∈ KeySp until they find the
one that encrypts some known message to a known ciphertext. If we say k = |KeySp|,
this obviously takes O(k) time and requires on average 2k−1 checks, which is why k
must be large enough for this to be infeasible.

Fun Fact: Historical Key Sizes

Modern block ciphers like AES use at least 128-bit keys (though 192 and
256-bit options are available) which is considered secure from exhaustive
search.
The now-outdated block cipher DES (invented in the 1970s) had a 56-bit key
space, and it had a particular property that could speed up exhaustive search
by a factor of two. This means exhaustive key-search on DES takes ≈ 254
operations which took about 23 years on a 25MHz processor (fast at the
time of DES’ inception). By 1999, the key could be found in only 22 hours.
The improved triple-DES or 3DES block cipher used 112-bit keys, but it

Kudrayvtsev 25
CHAPTER 3: Block Ciphers

too was abandoned in favor of AES for performance reasons: doing three
DES computations proved to be too slow for efficient practical use.

Obviously a block cipher is not necessarily secure just because exhaustive key-search
is not feasible. We now aim to define some measure of security for a block cipher.
Why can’t we just use IND-CPA? Well a block cipher is deterministic by definition,
and we saw in Theorem 3.1, a deterministic scheme cannot be IND-CPA secure. Thus
our definition is too strong! We need something weaker for block ciphers that is still
lets us avoid all possible information leaks: nothing about the key, nothing about the
plaintexts (or some property of the plaintexts), etc. should be revealed.
We will say that a block cipher is secure if its output ciphertexts “look” random; more
precisely, it’d be secure if an attacker can’t differentiate its output from a random
function. Well. . . that requires a foray into random functions.

3.2.4 Random Functions

Let’s say that F(l, L) defines the set of ALL functions that map from l-bit strings to
L-bit strings:
∀f ∈ F(l, L) f : {0, 1}l 7→ {0, 1}L
$
A random function g is then just a random function from that set: g(·) ←− F(l, L).
Now because picking a function at random is the same thing as picking a bitstring at
random,4 we can define g in pseudocode as a deterministic way of picking bitstrings
(see algorithm 3.4).

Algorithm 3.4: g(x), a random function.

Define a global array T
if T [x] is not defined then
$
T [x] ←− {0, 1}L
end
return T [x]

A function family is a pseudorandom function family (a PRF) if the input-output

behavior of a random instance of the family is computationally indistinguishable from
a truly-random function. This input-output behavior is defined by algorithm 3.4 and
is hidden from the attacker.
4
Any function we pick will map values to L-bit strings. Concatenating all of these output bitstrings
together will result in some nL-bit string, with a L2L bitstring being longest if the function maps
to every bitstring. Each chunk of this concatenated string is random, so we can just pick some
random L2L -length bitstring right off the bat to pick g.

Kudrayvtsev 26
APPLIED CRYPTOGRAPHY Symmetric Cryptography

PRF Security
The security of a block cipher depends on whether or not an attacker can differentiate
between it and a random function. Like with IND-CPA, we have two experiments. In
the first experiment, the attacker gets the output of the block cipher E with a fixed
K ∈ KeySp; in the second, it’s a random function g chosen from the PRF matching
the domain and range of E.
Experiment 1 (“real”) Experiment 0 (“random”)

A EK A g

b b

The attacker outputs their guess, b, which should be 1 if they think they’re being
fed outputs from the real block cipher and 0 if they think it’s random. Then, their
“advantage” is how much more often the attacker can guess correctly.

Definition 3.4: Block Cipher Security

A block cipher is considered PRF secure if an adversary’s PRF advan-

tage is small (near-zero), where the advantage is defined as the difference
in probabilities of the attacker choosing

Advprf (A) = Pr [A returns 1 for experiment 1] −

Pr [A returns 1 for experiment 0]

For AES, the PRF advantage is very small and its conjectured (not proven) to be
PRF secure. Specifically, for running time t and q queries,
ct
Advprf
AES (A) ≤ · 2−128 + q 2 · 2−128 (3.2)
TAES | {z }
| {z } birthday paradox
exhaustive key-search

We will use this as an upper bound when calling a function F PRF secure.
The second term comes from an interesting attack that can be applied to all block
ciphers known as the birthday paradox. Recall that block ciphers are permutations,
so for distinct messages, you always get distinct ciphertexts. The attack is simple: if
you feed the PRF security oracle q distinct messages and get q distinct ciphertexts,
you output b = 1; otherwise, you output b = 0. The only way you get < q distinct

Kudrayvtsev 27
CHAPTER 3: Block Ciphers

ciphertexts is from a g that isn’t one-to-one. The probability of this happening is the
probability of algorithm 3.4 picking the same bitstring for two xs, so 2−L .

Fun Fact: The Birthday Paradox

Suppose you’re at a house party with 50 other people. What’re the chances
that two people at that party share the same birthday? Turns out, it’s
really, really high: 97%, in fact!
The birthday paradox is the counterintuitive idea despite the fact that
YOU are unlikely to share a birthday with someone, the chance of ANY
two people sharing a birthday is actually extremely high.
In the context of cryptography, this means that as the number of outputs
generated by a random function g increases, the probability of SOME two
inputs resolving to the same output increases much faster.

Proving Security: CTRC Recall the CTRC—Stateful Counter Mode mode of

operation. Armed with the new definition of block cipher security, we can prove
that this mode is secure. We start by assuming that the underlying cryptographic
primitives are secure (in this case, this is the block cipher). Then, we can leverage
the contrapositive to prove it. Starting with the implication:
If a scheme T is y-secure,
then a scheme S is x-secure.
(for some fill-in-the-blank x, ys like “IND-CPA” or “PRF”), we instead aim to prove
the contrapositive:
If a scheme S is NOT x-secure,
then a scheme T is NOT y-secure.
To bring this into context, we will show that our mode of operation S being insecure
implies that the block cipher T is not PRF-secure. More specifically, using our
definitions of security, we’re trying to show that: there existing an x-adversary A
that can break S implies that there exists a y-adversary B that can break T :
• We assume A exists, then construct B using A.
• Then, we show that B’s y-advantage is not “too small” if A’s x-advantage is not
“too small” (≈ 0).

Kudrayvtsev 28
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Logic Review: Contrapositive

The contrapositive of an implication is its inverted negation. Namely, for

two given statements p and q:

if p =⇒ q
then ¬q =⇒ ¬p

With that in mind, let’s prove CTRC’s security. To be verbose, the statements we’re
aiming to prove are:

the underlying blockcipher is secure =⇒ CTRC is a secure mode of operation

| {z } | {z }
P Q

However, since we’re approaching this via the contrapositive, we’ll instead prove

CTRC is not a secure mode of operation

| {z }
¬Q

=⇒ only when the underlying blockcipher is not secure

| {z }
¬P

Theorem 3.2. CTRC is a secure mode of operation if its underlying block cipher
is secure.
More formally, for any efficient adversary A, ∃B with similar efficiency such
that the IND-CPA advantage of A under CTRC mode is less than double the
PRF advantage of B under a secure block cipher F :

Advind-cpa prf
CTRC (A) ≤ 2 · AdvF (B)

where we know an example of a secure block cipher F =AES that any B’s advan-
tage will be very small (see (3.2)).

Proof. Let A be an IND-CPA-cg adversary attacking CTRC. Then, we can present

the PRF adversary B.
• We construct B so that it can act as the very left-right oracle that A uses to
query and attack the CTRC scheme.

Kudrayvtsev 29
CHAPTER 3: Block Ciphers

$
b ←− {0, 1}

m0 , m1 mb
A LR (m0 , m1 , ·) EK (·) g or FK
? ?

C
b0

adversary B 1 iff b0 = b else 0

• Namely, B lets A make oracle queries to CTRC until it guesses b correctly. This
is valid because B still delegates to a PRF oracle which is choosing between a
random function g and the block cipher FK (where K is still secret) for the
actual block cipher; everything else is done exactly as described for CTRC in
Figure 3.5.
• This construction lets us leverage the fact that A knows how to break CTRC-
encrypted messages, but we don’t need to know how. For the pseudocode
describing this process, refer to algorithm 3.5.
Now let’s analyze B, expressing its PRF advantage over F in terms of A’s IND-CPA
advantage over CTRC.5 The ability for B to differentiate between F and some random
function g ∈ Func(`, L) depends entirely on A’s ability to differentiate between CTRC
with an actual block cipher F and a truly-random function g. Thus,
h i h i
AdvF (B) = Pr B → 1 in ExpF
prf prf-0
− Pr B → 1 in ExpF prf-1
definition
h i h i
B depends
= Pr Expind-cpa-cg
CTRC[F ] → 1 − Pr ExpCTRC[g] → 1
ind-cpa-cg
only on A

1 1 1 1 IND-CPA is equal
= · Advind-cpa
CTRC[F ] (A) + − · Advind-cpa
CTRC[g] (A) −
to IND-CPA-cg
2 2 2 2 via (3.1)

Next, we’ll show that Advind-cpa

CTRC[g] (A) = 0. That is, we will show that A has absolutely
no advantage in breaking the scheme when using g—a truly-random function—as the
block cipher. Consider the visualization of the CTRC scheme again:

5
The syntax X → n means the adversary X outputs the value n, and the syntax Expnm refers to
the experiment n under some parameter or scheme m, for shorthand.

Kudrayvtsev 30
APPLIED CRYPTOGRAPHY Symmetric Cryptography

ctr + 1 ctr + 2 ctr + m

g g ... g

M [1] ⊕ M [2] ⊕ M [m] ⊕ ctr += m + 1

ctr = 0n C[1] C[2] C[m]

Notice that the inputs to g are all distinct points, and by definition of a truly-random
function its outputs are truly-random bitstrings. These are then XOR’d with mes-
sages. . . sound familiar? The outputs of g are distinct one-time pads and thus each
C[i] is Shannon-secure, meaning an advantage is simply impossible by definition.
The theorem claim can then be trivially massaged out:

1 1 1 1
Advprf
F (B) = · Advind-cpa
CTRC[F ] (A) + − · Advind-cpa
CTRC[g] (A) −
2 2 2 | {z } 2
=0
1
= · Advind-cpa
CTRC (A)
2
2 · Advprf ind-cpa
F (B) = AdvCTRC (A)

Algorithm 3.5: Constructing an adversary B that uses another adversary A

to break a higher-level symmetric encryption scheme.
Input: An adversary A that executes oracle queries.
Result: 1 if A succeeds in breaking the emulated scheme, 0 otherwise.
$
Let g ←− F (`, L) where F is a PRF, which B will use as a block cipher.
Let Ef (·) be an encryption function that works like A expects (for example, a
CTRC scheme).
$
Choose a random bit: b ←− {0, 1}1
repeat
Get a query from A, some (M1 , M2 )
$
C ←− Ef (Mb )
return C to A
until A outputs its guess, b0
return 1 iff b = b0 , 0 otherwise

Kudrayvtsev 31
CHAPTER 3: Block Ciphers

Proving Security: CTR Recall that the difference between CTRC (which we
just proved was secure) and standard CTR is the use of a random IV rather than a
counter (see Figure 3.4). It’s also provably PRF secure, but we’ll state its security
level without proof:6

Theorem 3.3. CTR is a secure mode of operation if its underlying block cipher is
secure. More formally, for any efficient adversary A, ∃B with similar efficiency
such that:
µ2A
Advind-cpa
CTR (A) ≤ 2 · Advprf
F (B) +
`2`
where µ is the total number of bits A sends to the oracle.

It’s still secure because ` ≥ 128 for secure block ciphers, making the extra term near-
zero. Proving bounds on security is very useful: we can see here that CTRC mode is
better than CTR mode because there is no additional constant.
There is a similar theorem for CBC mode (see Figure 3.2), the last mode of operation
whose security we haven’t formalized.

Theorem 3.4. CBC is a secure mode of operation if its underlying block cipher is
secure. More formally, for any efficient adversary A, ∃B with similar efficiency
such that:
µ2A
Advind-cpa
CBC (A) ≤ 2 · Advprf
F (B) +
n2 2n
where µ is the total number of bits A sends to the oracle.

We can see that n2 > ` when comparing CBC to CTR, meaning the term will be
smaller for the same µ. Thus, CTRC is more secure than CBC is more secure than
CTR. The constant again comes from the birthday paradox.

3.2.5 IND-CCA: Indistinguishability Under Chosen-Ciphertext

Attacks
Is the intuition behind a scheme being both IND-CPA and PRF secure sufficient?
Does IND-CPA take into account all of the possible attack vectors? Well, it limits
attackers to choosing plaintexts and using only their ciphertext results to make learn
information about the scheme and see ciphertexts. What if the attacker could instead
attack a scheme by choosing ciphertexts and learn something about the scheme from
the resulting plaintexts?

6
Feel free to refer to the lecture video to see the proof. In essence, the fact the value is chosen
randomly means it’s possible that for enough Rs and M s there will be overlap for some Ri + m
and Rj + n. This will result in identical “one-time pads,” though thankfully it occurs with a very
small probability (it’s related to the birthday paradox).

Kudrayvtsev 32
APPLIED CRYPTOGRAPHY Symmetric Cryptography

This isn’t a far-fetched possibility,7 and it has historic precedent in being a viable
attack vector. Since IND-CPA does not cover this vector, we need a stronger definition
of security: the attacker needs more power. With IND-CCA, the adversary A has
access to two oracles: the left-right encryption oracle, as before, and a decryption
oracle.

m0 , m1 mb
A LR (m0 , m1 , b) EK (·)
? ?

C0
d
DK (·)
M0

Figure 3.8: A visualization of the IND-CCA security definition. The adversary

A submits two messages, (m0 , m1 ), to an encryption oracle that (consistently)
chooses one of them based on a bit b and returns mb ’s ciphertext. The adversary
can also submit any C 0 that hasn’t been submitted to LR to a decryption oracle
and see the resulting plaintext.

The only restriction on the attacker is that they cannot query the decryption ora-
cle on ciphertexts returned from the encryption oracle (obviously, that would make
determining b trivial) (in Figure 3.8, this means C 6= C 0 ). As before, a scheme is
considered IND-CCA secure if an adversary’s advantage is small.

Definition 3.5: IND-CCA

A scheme SE is considered secure under IND-CCA if an adversary’s IND-
CCA advantage—the difference between their probability of guessing cor-
rectly and guessing incorrectly—is small (≈ 0):

Advind-cca (A) = Pr [A guessed 0 for experiment 0] −

Pr [A guessed 0 for experiment 1]

Note that since IND-CCA is stronger than IND-CCA, the former implies
the latter. This is trivially-provable by reduction, so we won’t show it here.

Unfortunately, none of our IND-CPA schemes are also secure under IND-CCA.
7
Imagine reverse-engineering an encrypted messaging service like iMessage to fully understanding
its encryption scheme, and then control the data that gets sent to Apple’s servers to “skip” the
encryption step and control the ciphertext directly. If you control both endpoints, you can see
what the ciphertext decrypts to!

Kudrayvtsev 33
CHAPTER 3: Block Ciphers

Analysis of CBC
Recall from Figure 3.2 the way that message construction works under CBC with
random initialization vectors.
Suppose we start by encrypting two distinct, two-block messages. They don’t have
to be the ones chosen here, but it makes the example easier. We pass these to the
left-right oracle:
$
IV k c1 k c2 ←− EK LR(02n , 12n )

From these ciphertexts alone, we’ve already shown that the adversary can’t determine
which of the input messages was encrypted. However, suppose we send just the first
chunk to the decryption oracle?

m = DK (IV k c1 )

This is legal since it’s not an exact match for any encryption oracle outputs. Well
since our two blocks were identical, and c2 has no bearing in the decryption of IV k c1
(again, refer to the visualization in Figure 3.2), the plaintext m will be all-zeros in
the left case and all-ones in the right case!
It should be fairly clear that this is an efficient attack, and that the adversary’s
advantage is optimal (exactly 1). For posterity,

CBC (A) = Pr A → 0 for Exp

Advind-cca − Pr A → 0 for Expind-cca-1
ind-cca-0
   

=1−0= 1

The attack time t is the time to compare n bits, it requires qe = qd = 1 query to each
oracle, and message lengths of µe = 4n and µd = 2n. Thus, CBC is not IND-CCA
secure. 
Almost identical proofs can be used to break both CTR and CTRC, our final bastions
of hope in the Modes of Operation we’ve covered.

Analysis of CBC: Anotha’ One (or, Kicking ‘em While They’re Down)

We can break CBC (and the others) in a different way. This is included here to jog
the imagination and offer an alternative way of thinking about showing insecurity
under IND-CCA.
In this attack, one-block messages will be sufficient:
$
IV k c1 ←− EK (LR(0n , 1n ))

This time, there’s nothing to chop off. However, what if we try decrypting the ci-
phertext with a flipped IV?

m = DK IV k c1

Kudrayvtsev 34
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Well, according to Figure 3.2, the output from the blockcipher will be XOR’d with
the flipped IV, and thus result in a flipped message, so m = 0n = 1n in the left case,
and m = 0n in the right case!
Again, this is trivially computationally-reasonable (in fact, it’s even more reasonable
than before) and breaks IND-CCA security. 

3.3 What Now?

We started off by enumerating a number of ways to create ciphertexts from plaintexts
using block ciphers. It was critical to follow that with several definitions of what
“security” means, and we showed that some of the modes of operation (namely ECB
and CBCC) were not secure under Definition 3.2, IND-CPA security. Then, we
dug deeper to study the underlying block ciphers and what it meant for those to
be PRF secure: it must be hard to differentiate them from a random function (see
Definition 3.3). Finally, we gave the attacker more power under the last, strictest
metric of security: IND-CCA, and showed that our remaining modes of operation
(that is, CBC, CTR, and CTRC) broke under this adversarial scheme.
We definitely want a way to achieve IND-CCA security. Does hope remain? Thank-
fully, it does, but it will first require a foray into the other realms of cryptography:
integrity and authenticity.

Kudrayvtsev 35
Message Authentication Codes

When in doubt, use brute force.

— Ken Thompson

ata privacy and confidentiality is not the only goal of cryptography, and a
D good encryption method does not make any guarantees about anything beyond
confidentiality. In the one-time pad (which is perfectly secure), an active attacker
Mallory can modify the message in-flight to ensure that Alice receives something
other than what Bob sent:
C =K ⊕M C0 = C ⊕ M 0
Mallory
receives M ⊕ M 0
Bob Alice
instead

If Mallory knows that the first 8 bits of Bob’s message corresponds to the number of
dollars that Alice needs to send Bob (and she does, according to Kerckhoff’s principle),
such a manipulation will have catastrophic consequences for Alice’s bank account.
Clearly, we need a way for Alice to know that a message came from Bob himself.
Let’s discuss ways to ensure that the recipient of a message can validate that the
message came from the intended sender (authenticity) and was not modified on the
way (integrity).

4.1 Notation & Syntax

A message authentication code (or MAC) is a fundamental primitive in achieving
data authenticity under the symmetric cryptography framework. Much like in an
encryption scheme, a well-defined MAC scheme covers the following:
• a message space, denoted as the MsgSp or M for short, describes the set of
things which can be authenticated.

36
APPLIED CRYPTOGRAPHY Symmetric Cryptography

• a key generation algorithm, K, or the key space spanned by that algorithm,

KeySp, describes the set of possible keys for the scheme and how they are
created.
• the MAC algorithm itself, Mac (also called a tagging or signing algorithm)
defines the way some m ∈ MsgSp is authenticated and returns a tag.
• the MAC’s corresponding verification algorithm, Vf, describes how a mes-
sage should be validated, given a (supposedly) authenticated message and its
tag, outputting a Boolean value indicating their validity.
Succinctly, we say that Π = (K, Mac, Vf), and by definition

∀k ∈ KeySp, ∀m ∈ MsgSp : Vf(k, m, Mac (k, m)) = 1

If a MAC algorithm is deterministic, then Vf does not need to be explicitly defined,

since running the MAC on the message again and comparing the resulting tags is
sufficient.

An important thing to remember in this chapter is that we don’t care

about confidentiality: the messages and their tags are sent in the clear.
Our only concern is now forging—can Mallory pretend that a message
came from Bob?

4.2 Security Evaluation

As before, with the Security Evaluation of a block cipher or its mode of operation,
we need a way to model practical, strong adversaries and their attacks on MACs.
To start, we can imagine that an adversary can see some number of (message, tag)
pairs. To mimic IND-CCA, perhaps s/he can also force the tagging of messages and
check the verification of specific pairs. Obviously, they shouldn’t be able to compute
the secret key, but more importantly, they should never be able to compose a message
and tag pairing that is considered valid.

Attack Vector: Pay to (Re)Play

A replay attack is one where an adversary uses valid messages from the
past that they captured to duplicate some action.
For example, imagine Bob sends an encrypted, authenticated message “You
owe my friend Mallory $5.” to Alice that everyone can see. Alice knows this
message came from Bob, so she pays her dues. Then, Mallory decides to
just. . . send Alice that message again! It’s again deemed valid, and Alice

Kudrayvtsev 37
CHAPTER 4: Message Authentication Codes

again pays her dues.

Protection against replay attacks requires some more-sophisticated con-
struction of a secure scheme, so we’ll ignore them for now as we discuss
MAC schemes.

4.2.1 UF-CMA: Unforgeability Under Chosen-Message Attacks

Let’s formalize these intuitions: the adversary A is given access to two oracles that
run the tagging and verification algorithms respectively, and s/he must output a
message-tag pair (M, t) for which t is a valid tag for M (that is, Vf(K, M, t) = 1)
and M was never an input to the tagging oracle.1

Mac (K, ·)
A
Vf(K, ·, ·)

(M, t)

Definition 4.1: UF-CMA

A message authentication code scheme Π is considered to be UF-CMA
secure if the UF-CMA advantage of any adversary A is near-zero, where
the advantage is defined by the probability of the oracle mistakenly verifying
a message:

Advuf-cma (A) = Pr Vf(k, m, t) = 1 and m was not queried

 
to the oracle

The latter part of the probability lets us ignore replay attacks and trivial
breaks of the scheme.

A Toy Example
Suppose we take a simple MAC scheme that prepends each message block with a
counter, runs this concatenation through a block cipher, and XORs all of the cipher-
texts (see Figure 4.1).
This can be broken easily if we realize that XORs can cancel each other out. Consider
tags for three pairs of messages and what they expand to

T1 = Mac (X1 k Y1 ) −→ EK (1 k X1 ) ⊕ EK (2 k Y1 )
T2 = Mac (X1 k Y2 ) −→ EK (1 k X1 ) ⊕ EK (2 k Y2 )
1
This lone restriction on the adversary is exactly like the one for IND-CCA, where its trivial to get
a perfect advantage if you’re allowed to decrypt messages you’ve encrypted.

Kudrayvtsev 38
APPLIED CRYPTOGRAPHY Symmetric Cryptography

1 k M [1] 2 k M [2] m k M [m]

EK EK ...... EK

⊕
T
Figure 4.1: A simple MAC algorithm.

T3 = Mac (X2 k Y1 ) −→ EK (1 k X2 ) ⊕ EK (2 k Y1 )

If we combine these three tags, we can actually derive the tag for a new pair of
messages!

T1 ⊕ T2 ⊕ T3 = EK (1 k X1 ) ⊕ EK (2 k Y1 ) ⊕
EK (1 k X1 ) ⊕ EK (2 k Y2 ) ⊕
EK (1 k X2 ) ⊕ EK (2 k Y1 )
cancel duplicate XORs
= EK (2 k Y2 ) ⊕ EK (1 k X2 ) (highlighted)

= Mac (X2 k Y2 )

Since we haven’t queried the tagging algorithm with this particular message, it be-
comes a valid pairing that breaks the scheme. It’s also trivially a reasonable attack,
requiring only qt = 3 queries to the tagging algorithm, µ = 3 messages, and the time
it takes to perform 3 XORs (if we don’t count the internals of Mac).

4.3 Mode of Operation: CBC-MAC

We state an important fact without proof; it acts as our inspiration for this section:

Theorem 4.1. Any PRF function yields a UF-CMA secure MAC.

This means that any secure blockcipher (like AES) can be used as a MAC. However,
they only operate on short input messages. Can we extend our Modes of Operation
to allow MACs on arbitrary-length messages?
Enter CBC-MAC, which looks remarkably like CBC mode for encryption (see sub-
section 3.1.2) but disregards all but the last output ciphertext. Given an n-bit block
cipher, E : {0, 1}k ×{0, 1}n 7→ {0, 1}n , the output message space is MsgSp = {0, 1}mn ,
fixed m-block messages (obviously m ≥ 1).

Kudrayvtsev 39
CHAPTER 4: Message Authentication Codes

0n M [1] M [2] M [m]

⊕ ⊕ ⊕

EK EK ...... EK

C[m]

Figure 4.2: The CBC-MAC authentication mode.

To reiterate, this scheme is secure under UF-CMA only for a fixed message length
across all messages. That is, we can’t send messages that are longer or shorter than
some predefined multiple of n bits.

Theorem 4.2. The CBC-MAC authentication scheme is secure if the underlying

blockcipher is secure.
More specifically, for any efficient adversary A, there exists an adversary B with
similar resources such that A’s advantage is worse than B’s:

prf m 2 qA
2
Advuf-cma
CBC-MAC (A) ≤ AdvE (B) +
2n−1
(the last term is an artifact of the birthday paradox)

This is an important limitation, and it will be enlightening for the reader to determine
why variable-length messages break the CBC-MAC authentication scheme. There
are, however, ways to extend CBC-MAC to allow variable-length messages, such as
by prepending the length as the first message block.

Kudrayvtsev 40
Hash Functions

Realize you won’t master data structures until you are working
on a real-world problem and discover that a hash is the solution
to your performance woes.
— Robert Love

essential part of modern cryptography, hash functions is transforms arbitrary-

A nlength input data to a short, fixed-size digest:
64
H : {0, 1}<2 7→ {0, 1}n

Some examples of modern hash functions include those in Table 5.1. They should
be pretty familiar: SHA-1 is used by git and SHA-3 is used by various cryptocur-
rencies like Ethereum.1 They are used as building blocks for encryption, hash-maps,
blockchains, key-derivation functions, password-storage mechanisms, and more.

Function Digest Size Secure?

MD4 128 ×
MD5 128 ×
SHA-1 160 ×
SHA-256 256 
SHA-3 224, 256, 384, 512 
Table 5.1: A list of some modern hash functions and their output digest length.

1
Technically, Ethereum uses the Keccak-256 hash function, which is the pre-standardized ver-
sion of SHA-3. There are some interesting theories on the difference between the two: though
the standardized version changes a padding rule—allegedly to allow better variability in digest
lengths—its underlying algorithm was weakened to improved performance, casting doubts on its
general-purpose security.

41
CHAPTER 5: Hash Functions

5.1 Collision Resistance

Not all hash functions are created equal. For example, here’s a valid hash function:
just output the first n bits of the input as the digest. A good hash function tries to
distribute its potential inputs uniformally across the output space to minimize hash
collisions. In fact, most of the functions in Table 5.1 above are considered broken
from a cryptography perspective: collisions have been found.
Formally, a collision is a pair of messages from the domain, m1 6= m2 , such that
H(m1 ) = H(m2 ). Obviously, if the domain is larger than the range, there must be
collisions (by the pigeonhole principle), but from the perspective of security, we want
the probability of creating a collision to be very small. This is called being collision
resistant.
As we’ve done several times before, let’s formalize the notion of collision resistance
with an experiment. If we try to approach this in the traditional way—define an
oracle that outputs hashes, and defined some “collision resistance advantage” as the
probability of finding two inputs that output the same hash—we immediately run
into problems:
1. Since hash algorithms are public, there isn’t really a key to keep secret and thus
no oracle to construct.
2. Hash functions have collisions by definition, so the probability of finding one is
always one. Even if we, as humans, don’t know how to find the collision, this
is a separate issue.
To get around this, we’ll instead consider experiments on families of hash functions,
where a “key” acts as a selector of specific instances from the family.
This is unfortunate in some ways, because it distances us from concrete hash
functions like SHA1. But no alternative is known.
— Introduction to Modern Cryptography (pp. 141)

Formally, we define a family of hash functions as being:

H : {0, 1}k × {0, 1}m 7→ {0, 1}n

$
Then, the key is chosen randomly (k ←− {0, 1}k ) and provided to the adversary (to
enable actually running the hash functions), who tries to find two inputs that map
to the same output.

Definition 5.1: Collision Resistance

A family of hash functions H is considered collision resistant if an adver-
sary’s cr-advantage—the probability of finding a collision—on a randomly-

Kudrayvtsev 42
APPLIED CRYPTOGRAPHY Symmetric Cryptography

chosen instance Hk is small (≈ 0).

Advcr
H (A) = Pr [Hk (x1 ) = Hk (x2 )] where x1 6= x2

This avoids the aforementioned problem of adversaries hard-coding a priori-known

collisions to specific instances. There’s still a bit of a gap between this theoretical
security definition and practice, since hash functions still typically don’t have keys.

Practice: Find a Collision Do blockciphers make good hash functions? By

their very nature (being a permutation), their output is collision resistant. How-
ever, they don’t accept arbitrary-length inputs, and a mode of operation will still
render arbitrary-length outputs while we need a fixed-size digest as a result.
Consider a simple way of combining AES inputs: XOR the individual output blocks.
For simplicitly, we’ll limit ourselves to two AES blocks, so our function family is:

H : {0, 1}k × {0, 1}256 7→ {0, 1}128

Is H collision resistant?
Obviously not. It’s actually quite trivial to get the exact same digest, since x1 ⊕x1 = 0.
That is, we pass the same 128-bit block in twice:
$
Let x ←− {0, 1}128 and m = x k x :
Hk (m) = Aes(x) ⊕ Aes(x)
=c⊕c=0

Notice that this is extremely general-purpose, finding 2128 messages that all collide
to the same value of zero.

5.2 Building Hash Functions

Suppose we had a hash function that compressed short inputs into even-shorter out-
puts:
Hs : {0, 1}k × {0, 1}b+n 7→ {0, 1}n
where b is relatively small. We can use a technique called the Merkle-Damgård
transform to create a new compression function that operates on much larger inputs,
on an arbitrary domain D:

H` : {0, 1}k × D 7→ {0, 1}n

The algorithm is straightforward and is formalized in algorithm 5.1. It’s used by

many modern hash function families, including the MD and SHA families. Visually,

Kudrayvtsev 43
CHAPTER 5: Hash Functions

M [1] M [2] M [m] hmi

h h ... h h
0n

Figure 5.1: A visualization of the Merkle-Damgård transform, where h is any

compression function.

Algorithm 5.1: The Merkle-Damgård transform, building an arbitrary-length

compression function using a limited compression function.
Input: h(·), a limited-range compression function operating on b-bit inputs.
Input: M , the arbitrary-length input message to compress.
Result: M compressed to an n-bit digest.
m := kM kb // the number of b-bit blocks in M
M [m + 1] := hM i // the last block is message size
V [0] := 0n
for i = 1, . . . , m + 1 do
V [i] := h (M [i] k V [i − 1])
end
return V [m + 1]

it looks like Figure 5.1: each “block” of the input message is concatenated with the
hashed version of its previous block, then hashed again.
The good news of this transform is the following:

Theorem 5.1. If a short compression function Hs is collision resistant, then a

longer compression function H` composed from the Merkle-Damgård transform
will also be collision resistant.
This means we can build up complex hash functions from simple primitives, as long
as those primitives can make promises about collision resistance. Can they, though?

Birthday Attacks Recall the birthday paradox: as the number of samples from
a range increases, the probability of any two of those samples being equal grows
rapidly (there’s a 95% chance that two people at a 50-person party will have the
same birthday).
A hash function is regular if every range point has the same number of pre-images
(that is, if every output has the same number of possible inputs). For such a function,
the “birthday attack” finds a collision in ≈ 2n/2 trials. For a hash function that is not
regular, such an attack could succeed even sooner.

Kudrayvtsev 44
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Thorough research into the modern hash functions (for which n ≥ 160, large-enough
to protect against birthday attacks) suggests that they are “close to regular.” 2 Thus,
we can safely use them as building blocks for Merkle-Damgård.

Attacks in Practice: SHAttered A collision for the SHA-1 hash was found in
February of 2017, breaking the hash function in practice after it was broken theo-
retically in 2005: two PDFs resolved to the same digest. The attack took 263 − 1
computations; tthis is 100,000 faster than the birthday attack.

Figure 5.2: The two PDFs in the SHAttered attack and their resulting, identical
digests. More details are available on the attack’s site (because no security attack
is complete without a trendy title and domain name).

Quick Maffs: Function Nomenclature

Because mathematicians like to use opaque terminology, it’s worth expand-

ing upon the nomenclature for clarity.
The domain and range of a function should be familiar to us: the domain
is a set of inputs and the range (also confusingly called the codomain
sometimes) is the set of possible outputs for that input. Formally,

R = {f (d) : d ∈ D}

2
Much like the conjecture that AES is PRF secure, this is thus far unproven. As we’ll see later,
neither are the security assumptions behind asymmetric cryptography (e.g. “factoring is hard”).
Overall, these conjectures on top of conjectures unfortunately do not inspire much confidence in
the overall state of security, yet it’s the best we can do.

Kudrayvtsev 45
CHAPTER 5: Hash Functions

Example If the domain of f (x) = x2 is all real numbers (D = R), its

range is all positive reals R = R+ (we’ll treat 0 as a positive number for
brevity).
These terms refer to the function as a whole; we chose the input domain, and
the range is the corresponding set of outputs. However, it’s also useful to
examine subsets of the range and ask the inverse question. That is, what’s
the domain that corresponds to a particular set of values?

Example Given f (x) = x (the diagonal line passing through the origin),
for what subset of the domain is f (x) > 0? Obviously, when x > 0.
This subset is called the preimage. Namely, given a subset of the range,
S ⊆ R, its preimage is the set of inputs that corresponds to it:

P = {x | f (x) ∈ S}

In summary, a preimage of some outputs of a function is the set of inputs

that result in that output.

5.3 One-Way Functions

Hash functions that are viable for cryptographic use must being one-way functions:
they must be easy to compute in one direction, but (very) hard to compute in reverse.
That is, given a hash, it should be hard to figure out what input resulted in that hash.
Informally, a hash function is one-way if, given y and k, it is infeasible to find y’s
preimage under hk .
As usual, we’ll define this notion formally with an experiment. Given a hash function
family, H : {0, 1}k × D 7→ {0, 1}n , we’ll have an oracle randomly-select a key and an
input value, providing the adversary with its resulting hash and the key (so they can
run hash computations).
$ $
Let k ←− {0, 1}k and x ←− D :
y = Hk (x)
Now, the adversary wins if they can produce a x0 for which Hk (x0 ) = y. Note that x0
does not need to be x, only in the preimage of y, so this security definition somewhat-
includes being collision resistant.

Definition 5.2: One-Way Function

A family of hash functions H is considered one-way if an adversary’s ow-

advantage—the probability of finding the randomly-chosen input, x, from

Kudrayvtsev 46
APPLIED CRYPTOGRAPHY Symmetric Cryptography

its digest y—on a randomly-chosen instance Hk is small (≈ 0).

Advow 0
H (A) = Pr Hk x = y



Given our two security properties for a hash function, do either of them imply the
other? That is, are either of these true?
collision resistance =⇒ one-wayness
one-wayness =⇒ collision resistance

CR =⇒ OW For functions in general (not necessarily hash functions), collision

resistance does not imply one-wayness. Consider the trivial identity function: since
it’s one-to-one, it’s collision resistant by definition, but it’s obviously not one-way.
However, for functions that compress their input (e.g. hash functions), it does imply
it!

OW =⇒ CR This implication does not hold in all cases. We can easily do

a “disproof by counterexample”: suppose we have a one-way hash function g. We
construct h to hash an n-bit string by delegating to g, sans the last input bit:
h(x1 x2 · · · xn ) = g(x1 x2 · · · xn−1 )

Since g was one-way, h is also one-way. However, it’s obviously not collision resistant,
since we know that when given any n-bit input m
h(m1 m2 · · · mn−1 0) = h(m1 m2 · · · mn−1 1)

5.4 Hash-Based MACs

We’ve come full-circle. Can we use a cryptographically-secure hash function—
a hash function that is both collision resistant and one-way—to do authentication?
Obviously, we can’t use hash functions directly since there is no key.
However, can we somehow include a key within our hash input? More importantly,
can we devise a provably-secure hash-based message authentication code? Enter the
aptly-named HMAC, visualized below in Figure 5.3.
First, some definitions. H is our hash function instance that maps from an arbitrary
domain to an n-bit digest:
H : D 7→ {0, 1}n
Then, we have a secret key K, and we denote B ≥ n/8 as the byte-length of the
message block3 The HMAC is computed using a nested structure, mixing the key
3
Typically, B = 64 for modern hash functions like MD5, SHA-1, SHA-256, and SHA-512.

Kudrayvtsev 47
CHAPTER 5: Hash Functions

with some constants. Namely, we define

Ko = opad ⊕ K k 08B−n Ki = ipad ⊕ K k 08B−n

where opad and ipad are hex-encoded constants:

opad = 0x |5C5C5C
{z . .}. ipad = 0x |363636
{z . .}.
repeated B times repeated B times

Then, the final tag is a simple combination of the transformed keys:

HmacK (K) = H (Ko k H(Ki k M ))

The specific constants are chosen to simplify the proof of security, having no bearing
on the security itself.

Ki k M h h h ... X

Ko k X h h h ... HmacM (M )

Figure 5.3: A visualization of the two-tiered structure of HMAC, the standard

keyed message authentication code scheme.

HMAC is easy to implement and fast to compute; it is a core part of many standard-
ized cryptographic constructs. Its useful both as a message authentication code and
as a key-derivation function (which we’ll discuss later in asymmetric cryptography).

Theorem 5.2. HMAC is a PRF assuming that the underlying compression func-
tion H is a PRF.

Kudrayvtsev 48
Authenticated Encryption

If privacy is outlawed, only outlaws will have privacy.

— Philip Zimmermann

n an ideal world, we would be able to ensure message confidentiality, message

I integrity, and sender authenticity all at once. This is the goal of authenticated
encryption (AE) within the realm of symmetric cryptography. Until this point,
we’ve seen how to achieve data privacy and confidentiality (IND-CPA and IND-CCA
security) as well as authenticity and integrity (UF-CMA security) separately.
The syntax and notation for authenticated encryption schemes is almost identical to
those we’ve been using previously; simply refer to section 4.1 to review that. We have
a message space, a key generation algorithm, and encryption/decryption algorithms.
The only difference is that now it’s possible for the decryption algorithm to reject an
input entirely. We’ll use this symbol: ⊥, in algorithms and such to indicate this.

6.1 INT-CTXT: Integrity of Ciphertexts

Though the confidentiality definitions from before still apply, we’ll need a new UF-
CMA-equivalent for encryption, since MACs make no guarantees about encryption.
The intuition will still be same, except there’s the additional requirement that the
adversary produces a valid ciphertext.

Definition 6.1: INT-CTXT Security

A scheme SE = (KeySp, E, D) is considered secure under INT-CTXT if an

adversary’s INT-CTXT advantage—the probability of producing a valid,
forged ciphertext—is small (≈ 0):

Advint-ctxt
SE (A) = Pr [A → C : DK (C) 6=⊥ and C wasn’t received from EK (·)]

49
 CHAPTER 6: Authenticated Encryption

EK (·)In one sentence, in the INT-CTXT experiment the ad-

A versary A is tasked with outputting a valid ciphertext
C C that was never received from the encryption oracle.
An authenticated encryption scheme will thus be secure
from forgery under INT-CTXT (integrity) and secure
from snooping under IND-CCA (confidentiality).
Module 7 Thankfully, we can abuse the following fact to make constructing such a scheme much
easier:

Theorem 6.1. If a symmetric encryption scheme is secure under IND-CPA and

INT-CTXT, it is also secure under IND-CCA.

Bellare & We can build a secure authentication encryption scheme by composing the basic
Namprempre, ‘00 encryption and MAC schemes we’ve already seen.

6.2 Generic Composite Schemes

Wikipedia Given a symmetric encryption scheme and a message authentication code, we can
combine them in a number of ways:
• encrypt-and-MAC, in which you encrypt the plaintext and then MAC the
original plaintext; this is done in SSH.
• MAC-then-encrypt, in which you first MAC the plaintext, then encrypt the
combined plaintext and MAC; this technique is used by the SSL protocol.
• encrypt-then-MAC, in which you encrypt the plaintext and then MAC the
resulting ciphertext; this is done by IPSec.
Analyzing the security of these approaches is a little involved. Ideally, much like the
Merkle-Damgård transform guarantees collision resistance (see Theorem 5.1), it’d be
nice if the security of the underlying components of a composite scheme made guar-
antees about the scheme as a whole. More specifically, can we build a composite
authenticated encryption scheme AE when given an IND-CPA symmetric encryp-
tion scheme SE = (K0 , E 0 , D0 ) and a PRF F that can act as a MAC (recall from
Theorem 4.1 that PRFs are UF-CMA secure).

Key Generation Keeping keys for confidentiality and integrity separate is incred-
ibly important. This is called the key separation principle: one should always use
distinct keys for distinct algorithms and distinct modes of operation. It’s possible to
do authenticated encryption without this, but it’s far more error-prone.1
1
The unique keys can still be derived from a single key via a pseudorandom generator, such as
by saying K1 = FK (0) and K2 = FK (1) for a PRF secure F . The main point is to keep them
separate beyond that.

Kudrayvtsev 50
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Thus our composite key generation algorithm will generate two keys: Ke for encryp-
tion and Km for authentication.
$
K : Ke ←− K0
$
Km ←− {0, 1}k
K := Ke k Km

6.2.1 Encrypt-and-MAC
In this composite scheme, the plaintext is both encrypted and authenticated; the full
message is the concatenated ciphertext and tag.

Algorithm 6.1: The encrypt- Algorithm 6.2: The encrypt-

and-MAC encryption algorithm. and-MAC decryption algorithm.
Input: SE = (EKe , DKm ) Input: SE = (EKe , DKm )
0
$0
C 0 ←− EK (M ) M = DK e
(C 0 )
e
T = FKm (M ) if T = FKm (M ) then
return C 0 k T return M
end
return ⊥

We want this scheme to be both IND-CPA and INT-CTXT secure. Unfortunately,

it provides neither. Remember, PRFs are deterministic: by including the plain-
text’s MAC, we hurt the confidentiality definition and can break IND-CPA (via The-
orem 3.1).2

6.2.2 MAC-then-encrypt
In this composite scheme, the plaintext is first tagged, then the concatenation of the
tag and the plaintext is encrypted.
How’s the security of this scheme? There’s no longer a deterministic component, so
it is IND-CPA secure; however, it does not guarantee integrity under INT-CTXT.
We can prove this by counterexample if there are some specific secure building blocks
that lead to valid forgeries.

2
Specifically, consider submitting two queries to the left-right oracle: LR(0n , 1n ) and LR(0n , 0n ).
The tags for the b = 0 case would match.

Kudrayvtsev 51
CHAPTER 6: Authenticated Encryption

Algorithm 6.3: The MAC-then- Algorithm 6.4: The MAC-then-

encrypt encryption algorithm. encrypt decryption algorithm.
Input: SE = (EKe , DKe ) Input: SE = (EKe , DKe )
0
T = FKm (M ) M k T = DK e
(C 0 )
$
C 0 ←− EK
0
(M k T ) if T = FKm (M ) then
e
0 return M
return C
end
return ⊥

The counterexample for this is a little bizzare and worth exploring; it gives us insight
into how hard it truly is to achieve security under these rigorous definitions. We’ll
first define a new IND-CPA encryption scheme:
SE 00 = {K0 , E 00 , D00 }

Then, we’ll define SE 0 as an encryption scheme that is also IND-CPA secure, that
uses SE 00 , but enables trivial forgeries by appending an ignorable bit to the resulting
ciphertext:
SE 0 = {K0 , E 0 , D0 }
0 00
EK (M ) = EK (M ) k 0
0 00
DK (C k b) = DK (C)

Obviously, now both C k 0 and C k 1 decrypt to the same plaintext, and this means
that an adversary can easily create forgeries. Weird, right? This example, silly as
though it may be, is enough to demonstrate that MAC-then-encrypt cannot make
guarantees about INT-CTXT security in general.

6.2.3 Encrypt-then-MAC
In our last hope for a generally-secure scheme, we will encrypt the plaintext, then
add a tag based on the resulting ciphertext.

Caveat: Timing Attacks

Notice the key, extremely important nuance of the decryption routine in

algorithm 6.6: the message is decrypted regardless of whether or not the
tag is valid. From a performance perspective, we would ideally check the
tag first, right? Unfortunately, this leads to the potential for an advanced
timing attack: decryption of invalid messages now takes less time than

Kudrayvtsev 52
APPLIED CRYPTOGRAPHY Symmetric Cryptography

valid ones, and this lets the attacker to learn secret information about the
scheme. Now, they can differentiate between an invalid tag and an invalid
ciphertext.

With this scheme, we get both security under IND-CPA and INT-CTXT, and by
Theorem 6.1, also under IND-CCA.

Theorem 6.2. Encrypt-then-MAC is the only generic composite scheme that

provides confidentiality under IND-CCA as well as integrity under INT-CTXT
regardless of the underlying cryptographic building blocks provided that they are
secure. Namely, it holds as long as the base encryption is IND-CPA secure and
F is PRF secure.

A common combination of primitives is AES-CBC (which we proved to be secure

in Theorem 3.4) and HMAC-SHA-3 (which is conjectured to be a cryptographically-
secure hash function).

Algorithm 6.5: The encrypt- Algorithm 6.6: The encrypt-

then-MAC encryption algorithm. then-MAC decryption algorithm.
Input: SE = (EKe , DKe ) Input: SE = (EKe , DKe )
Input: M , an input plaintext Input: C, an input ciphertext
message. message.
$ 0
C ←− EK0
(M ) M = DK e
(C)
e
T = FKm (C) if T = FKm (C) then
return C k T return M
end
return ⊥

6.2.4 In Practice. . .
It’s important to remember that the above results hold in general ; that is, they hold
for arbitrary secure building blocks. That does not mean it’s impossible to craft a
specific AE scheme that holds under a generally-insecure composition method.

6.2.5 Dedicated Authenticated Encryption

Rather than using generic composition of lower-level building blocks, could we craft
a mode of operation or something that has AE guarantees in mind from the get-go?
The answer is yes, and the offset codebook mode is such a scheme. It’s a one-pass,

Kudrayvtsev 53
CHAPTER 6: Authenticated Encryption

Protocol Composition Method In general. . . In this case. . .

SSH3 Encrypt-and-MAC Insecure Secure
SSL MAC-then-encrypt Insecure Secure
IPSec Encrypt-then-MAC Secure Secure
WinZip Encrypt-then-MAC Secure Insecure
Table 6.1: Though EtM is a provably-secure generic composition method, that
does not mean the others can’t be used to make secure AE schemes. Furthermore,
that does not mean it’s impossible to do EtM wrong! (cough WinZip)

heavily parallelizable scheme.4

6.3 AEAD: Associated Data

The idea of associated data goes hand-in-hand with authenticated encryption. Its
purpose is to provide data that is not encrypted (either because it does not need to be
secret, or because it cannot be encrypted), but must be authenticated. Schemes are
technically deterministic, but they are still based on initialization vectors and thus
provide similar guarantees in functionality and security.

6.3.1 GCM: Galois/Counter Mode

This is probably the most well-known
AEAD scheme. It’s widely used and is N M AD
most famously used in TLS, the back-
bone of a secure Web.
The scheme is made up of several CTR-ENCK
building blocks. The GCM-HASH is
a polynomial-based hash function and C
the hashing key, KH , is derived from
the “master” key K using the block ci-
EK encode
pher E. It can be used as a MAC and
is heavily standardized; its security has
GCM-HASHKH
been proven under the reasonable as-
sumptions we’ve seen for the building
⊕ T
blocks.
Figure 6.1: A visualization of the Galois/-
Counter mode (GCM) of AEAD encryption.

4
It was designed by Phillip Rogaway, one of the authors for the lecture notes on cryptography.

Kudrayvtsev 54
Stream Ciphers

his chapter introduces a paradigm shift in the way we’ve been constructing
T ciphertexts. Rather than encrypting block-by-block using a specific mode of op-
eration, we’ll instead be encrypting bit-by-bit with a stream of gibberish. Previously,
we needed our input plaintext to be a multiple of the block size; now, we can truly
deal with arbitrarily-length inputs without worrying about padding. This will actu-
ally be reminiscent of one-time pads: a pseudorandom generator (or PRG) will
essentially be a function that outputs an infintely-long one-time pad, and a stream
cipher will use that output to encrypt plaintexts.

7.1 Generators
$
In general, a stateful generator G begins with some initial state St=0 ←− {0, 1}n
called the seed, then uses the output of itself as input to its next run. The sequence
of outputs over time, X0 X1 X2 · · · should be pseudorandom for a pseudorandom gen-
erator: reasonably unpredictable and tough to differentiate from true randomness.

St+1
St G
Xt

We’ll use the shorthand notation:

(X0 X1 · · · Xm , St ) = G (S0 , m)

to signify running the generator m times with the starting state S0 , resulting in an
m-length output and a new state St . This construction is the backbone of all of the
$
instances where we’ve used ←− previously to signify choosing a random value from a
set. Pseudorandom generators (PRGs) are used to craft initialization vectors, keys,
oracles, etc.

55
CHAPTER 7: Stream Ciphers

7.1.1 PRGs for Encryption

Using a PRG for encryption is very easy: just generate bits and use them as a one-
time pad for your messages. The hard part is synchronization: both you and your
recipient need to start with the same seed state to decrypt each others’ messages.
This is the basis behind a stream cipher.

7.2 Evaluating PRGs

Creating a generator with unpredictable, random output is quite difficult. Functions
build on linear congruential generators (LRGs) and linear feedback shift reg-
isters (LFSRs) have good distributions (equal numbers of 1s and 0s in the output)
but are predictable given enough output. However, stream ciphers like RC4 (the 4th
Rivest cipher) and SEAL (software-optimized encryption algorithm) can make these
unpredictability guarantees.
As is tradition, we’ll need a formal definition of security to analyze PRGs. We’ll
call this INDR security: indistinguishability from randomness. The adversarial
experiment is very simple: an oracle picks a secret seed state, S0 and generates an
m-bit output stream both from the PRG and from truly-random source:
(X1 , St ) = (X01 X11 · · · Xm
1
, St ) = G (S0 , m)
$
X0 = X00 X10 · · · Xm
0
←− {0, 1}m
It then picks a challenge bit b and gives Xb to the attacker. If s/he can output their
guess, b0 , such that b0 = b reliably, they win the experiment and G is not secure under
INDR.

Definition 7.1: INDR Security

A pseudorandom generator G is considered INDR secure if an efficient ad-

versary’s INDR advantage—that is their ability to differentiate between
the PRG’s bitvector X1 and the truly-random bitvector X0 —is small (near-
zero). The advantage is defined as:

Advindr
 0  0
G (A) = Pr b = 1 for Exp1 − Pr b = 1 for Exp0
 

7.3 Creating Stream Ciphers

Since pseudorandom functions (and hence block ciphers) output random-looking data
and can be keyed with state, they are an easy way to create a reliable, provably-secure
pseudorandom generator. All we need to do is continually increment a randomly-
initialized value.

Kudrayvtsev 56
APPLIED CRYPTOGRAPHY Symmetric Cryptography

Theorem 7.1 (the ANSI X9.17 standardized PRG). If E is a secure pseudoran-

dom function:
E : {0, 1}k × {0, 1}n 7→ {0, 1}n
then G is an INDR-secure pseudorandom generator as defined:

Algorithm 7.1: G(St ), a PRG based on the CTR mode of operation.

Input: St , the current PRG input.
Result: (X, St+1 ), the pseudorandom value and the new PRG state.
K k V = St /* extract the state */
X = EK (V )
V = EK (X)
return (X, (K, V ))

Interestingly-enough, though this construction is provably-secure under INDR, it’s

not immune to attacks. The security definition does not capture all vectors.

7.3.1 Forward Security

The idea behind forward secrecy (also called forward security) is that past infor-
mation should be kept secret even if future information is exposed.

S0 S1 S2 S3
G G G

X1 X2 X3

Suppose an adversary somehow gets access to S2 . Obviously, they can now derive X3 ,
X4 , and so on, but can they compute X1 or X2 , though? A scheme that preserves
forward secrecy should say “no.”
The scheme presented in algorithm 7.1, though secure under INDR does not preserve
forward secrecy. Leaking any state (K, Vt ) lets the adversary construct the entire
chain of prior states if they have been capturing the entire history of generated X0..t
values.
Consider a simple forward-secure pseudorandom generator: regenerate the key anew

Kudrayvtsev 57
CHAPTER 7: Stream Ciphers

on every iteration.

Algorithm 7.2: G(K), a forward-secure pseudorandom generator.

Input: St , the current PRG input.
Result: (X, St+1 ), the pseudorandom value and the new PRG state.
X = EK (0)
K = EK (1)
return (X, K)

K0 K1 K2
0 1 0 1

E E E E

X1 X2

Figure 7.1: A visualization of a PRG with forward secrecy.

Nomenclature: Forward Secrecy

In the cryptographic literature and community, perfect forward secrecy

is when even exposing the very next state reveals no information about
the past. Often this is expensive (either in terms of computation or in
communicating key exchanges), and so forward secrecy generally refers to a
regular cycling of keys that isolates the post-exposured vulnerability interval
to certain (short) time periods.

7.3.2 Considerations
To get an unpredictable PRG, you need an unpredictable key for the underlying PRF.
This is the seed, and it causes a bit of a chicken-and-egg problem. We need random
values to generate (pseudo)random values.
Entropy pools typically come from “random” events from the real world like keyboard
strokes, system events, even CPU temperature. Then, seeds can be pulled from this
entropy pool to seed PRGs.
Seeding is not exactly a cryptographic problem, but it’s an important consideration
when using PRGs and stream ciphers.

Kudrayvtsev 58
Common Implementation Mistakes

Nowadays most people die of a sort of creeping common sense,

and discover when it is too late that the only things one never
regrets are one’s mistakes.
— Oscar Wilde, The Picture of Dorian Gray

ow that we’ve covered symmetric cryptography to a reasonable degree of rigor,

N it’s useful to cover many of the common pitfalls, missed details, and other im-
plementation mistakes that regularly lead to gaping cryptographic security holes in
the real world.

Primitives There are far more primitives that don’t work compared to those that
work. For example, using block ciphers with small block sizes or small key spaces
are vulnerable to exhaustive key-search attacks, not even to mention their vulnera-
bility to the birthday paradox. Always check NIST and recommendations from other
standards committees to ensure you’re using the most well-regarded primitives.

(Lack of ) Security Proofs Using a mode of operation with no proof of security—

or worse, modes with proofs of insecurity—is far too common. Even ECB mode is
used way more often than it should be. The fact that AES is a secure block cipher is
often a source of false confidence.

Security Bounds Recall that we proved that the CTR mode of operation (see
Figure 3.4) had the following adversarial advantage:

q2
Advind-cpa prf
CTR (A) ≤ AdvE (B) +
2L+1

Yet if we use constants that are far too low, this becomes easily achievable. The
WEP security protocol for WiFi networks used L = 24. With q = 4096 (trivial to

59
CHAPTER 8: Common Implementation Mistakes

do), the advantage becomes 1/2! In other words, the IVs are far too short1 to provide
any semblance of security from a reasonably-resourced attacker.

Trifecta Just because you have achieved confidentiality, you have not necessarily
achieved integrity or authenticity. Not keeping these things in mind leads to situations
where false assumptions are made.

Implementation Given a provable scheme, you must implement it exactly to achieve

the security guarantees. This simple rule has been broken many times before: Diebold
voting machines using an all-zero IV, Excel didn’t regenerate the random IV for every
message (just once), and many protocols use the previous ciphertext block as the IV
for the next one. These mistakes quickly break IND-CPA security.

Security Proofs As we’ve seen, we often need to extend our security definitions
to encompass more sophisticated attacks (like IND-CCA over IND-CPA). Thus, even
using a provably-secure scheme does not absolve you of an attack surface. For exam-
ple, the Lucky 13 attack used a side-channel timing attack to break TLS. The security
definitions we’ve recovered did not consider an attacker being able to the difference
between decryption and MAC verification failures, or how fragmented ciphertexts
(where the received doesn’t know the borders between ciphertexts) are handled.

1
It’s so easy to break WEP-secured WiFi networks; I did it as a kid with a $30 USB adapter and
15 minutes on Backtrack Linux.

Kudrayvtsev 60
PART II
Asymmetric Cryptography

his class of algorithms is built to solve the key distribution problem. Here,
T secrets are only known to one party; instead, a key (pk, sk) is broken into two
mathematically-linked components. There is a public key that is broadcasted to the
world, and a secret key (also called a private key) that must is kept secret.

Eve

pkB , (pkA , skA ) Alice Bob pkA , (pkB , skB )

Asymmetric cryptography is often used to mutually establish a secret key (without

revealing it!) for use with faster symmetric key algorithms. It’s a little counterintu-
itive: two strangers can “meet” and “speak” publicly, yet walk away having established
a mutual secret.

Contents
9 Overview 63

10 Number Theory 65

11 Encryption 77

12 Digital Signatures 95

13 Secret Sharing 106

61
CHAPTER 8: CONTENTS

14 Epilogue 114

Kudrayvtsev 62
Overview

e need to translate some things over from the world of symmetric encryption
W to proceed with our same level of rigor and analysis as before, this time applying
our security definitions to asymmetric encryption schemes.

9.1 Notation
An asymmetric encryption scheme is similarly defined by an encryption and decryp-
tion function pair as well as a key generation algorithm. Much like before, we denote
these as AE = (E, D, K).
The key is now broken into two components: the public key (shareable) and the
private key (secret). These are typically composed as: K = (pk, sk).

9.2 Security Definitions

Our definitions of IND-CPA and IND-CCA security will be very similar to the way
they were defined previously; the main difference is the (obvious) introduction of the
private- and public-key split, as well as the fact that we can be more precise about
what “reasonable” attacker resources are. Just to be perfectly precise, we’ll reiterate
the new definitions here.

Asymmetric IND-CPA The following figure highlights IND-CPA security for

asymmetric schemes (see Figure 3.6 for the original, symmetric version).
Notice that the encryption is under the public key pk; however, since E should be non-
deterministic, this does not cause problems for the security definition. The scheme
is IND-CPA secure if any adversary A’s advantage is negligible with resources poly-
nomial in the security parameter (typically the length of the key). This latter differ-
entiation is what makes the definition more specific than for symmetric encryption
schemes: our sense of a “reasonable” attacker is limited to polynomial algorithms.

63
CHAPTER 9: Overview

pk

m0 , m1 mb
A LR (m0 , m1 , b) Epk (·)
? ?

Asymmetric IND-CCA For chosen ciphertext attacks, we keep the same restric-
tion as before: the attacker cannot query the decryption oracle with ciphertexts s/he
acquired from the encryption oracle.

pk

m0 , m1 mb
A LR (m0 , m1 , b) Epk (·)
? ?

C0
d
Dsk (·)
M0

Much like before, a scheme being IND-CCA implies it’s also IND-CPA (recall the
inverse direction of Theorem 6.1).

Theorem 9.1. Let AE = (E, D, K) be an asymmetric encryption scheme. For

an IND-CPA adversary A who makes at most q queries to the left-right oracle,
there exists another adversary A0 with the same running time that only makes
one query. Their advantages are related as follows:

Advind-cpa
AE (A) ≤ q · Advind-cpa
AE (A0 )

Essentially, this theorem states that a scheme that is secure against a single query
is just as secure against multiple queries because the factor of q does not have a
significant overall effect on the advantage.

Kudrayvtsev 64
Number Theory

odular arithmetic and other ideas from number theory are the backbone of
M asymmetric cryptography. Like the name implies, the foundational security
principles rely on the asymmetry of difficulty in mathematical operations. For ex-
ample, verifying that a number is prime is easy, yet factoring a product of primes is
hard.

The RSA and modular arithmetic discussions in this chapter are ripped
from my notes for Graduate Algorithms which also covers these topics; these
sections may not align perfectly with lectures in terms of overall structure.

Measuring Complexity We’re going to be working with massive numbers. Typi-

cally in computer science, we would compute the “time complexity” of something as
simple as addition as taking constant time. This presumes, though, that the numbers
in question fit within a single CPU register (which might allow up to 64-bit numbers,
for example). Since this is no longer the case, we’re actually going to need to factor
this into our calculations.
Specifically, we’ll be measuring complexity in terms of the number of bits in our
numbers. For example, adding two n-bit numbers will have complexity O(n).

Notation
• Z+ is the set of positive integers, {0, 1, . . .}.
• ZN is the set of positive integers up to N : {0, 1, . . . , N − 1}.
• Z∗N is the set of integers that are coprime with N , meaning their greatest com-
mon divisor is 1:
Z∗N = {x ∈ ZN : gcd(x, N ) = 1}

• ϕ (N ) = |Z∗N | is Euler’s totient function, measuring the size of the set of

relatively prime numbers under N .

65
CHAPTER 10: Number Theory

10.1 Groups
A group is just a set of numbers on which certain operations hold true. Let G be a
non-empty set and let · be some binary operation. Then, G is a group under said
operation if:
• closure: the result of the operation should stay within the set:
∀a, b ∈ G : a · b ∈ G

• associativity: the order of operations should be swappable:

(a · b) · c = a · (b · c)

• identity: there should be some element in the set such that binary operations
on that element have no effect:
∀a ∈ G : a · 1 = 1 · a = a

The 1 here is a placeholder for the identity element; it doesn’t need to be the
actual positive integer 1.
• invertibility: for any value in the set, there should be another unique element
in the set such that their result is the identity element:
∀a ∈ G, ∃b ∈ G : a · b = b · a = 1
This latter element b is called the inverse of a.
For example, ZN is a group under addition modulo N , and Z∗N is a group under
multiplication modulo N . The order of a group is just its size.

Property 10.1. For a group G, if we let m = |G|, the order of the group, then:

∀a ∈ G : am = 1

where 1 is the identity element. Furthermore,

∀a ∈ G, i ∈ Z : ai = ai mod m (10.1)

Example These properties let us do some funky stuff with calculating seemingly-
impossible values. Suppose we’re working under Z∗21 :
Z∗21 = {1, 2, 4, 5, 8, 10, 11, 13, 16, 17, 19, 20}
Note that |Z∗21 | = 12. What’s 586 mod 21? Simple:
586 mod 21 = 586 mod 12 mod 21

= 52 mod 21 = 25 mod 21
= 4

Kudrayvtsev 66
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Subgroups A subset S ⊆ G is called a subgroup if it’s a group in its own right

under the same operation that makes G a group. To test if S is a subgroup, we only
need to check the invertibility property:

∀x, y ∈ S : x · y −1 ∈ S

Here, y −1 is the inverse of y. If S is a subgroup of G, then the order of S divides the

order of G: |G| mod |S| = 0.

Exponentation We define exponentiation as repeated application of the group

operation. Note that this doesn’t necessarily mean multiplication. For example, if we
operate under the group ZN with addition, then exponentiation is repeated addition
not repeated multiplication: 23 = 6 in such a group. This nuance won’t really
come up in our discussion since we are often concerned with the group Z∗N under
multiplication, but it’s worth noting.

10.2 Modular Arithmetic

For any two numbers, x ∈ Z and N ∈ Z+ , there is a unique quotient q and remainder r
such that: N q + r = x. Modular arithmetic lets us isolate the remainder: x mod N =
r. Then, we say x ≡ y (mod N ) if x/N and y/N have the same remainder.
An equivalence class is the set of numbers which are equivalent under a modulus.
So mod 3 has 3 equivalence classes:

. . . , −6, −3, 0, 3, 6, . . .
. . . , −5, −2, 1, 4, 7, . . .
. . . , −4, −1, 2, 5, 8, . . .

10.2.1 Running Time

Under modular arithmetic, there are different time complexities for common opera-
tions. The “cheat sheet” in Table 10.1 will be a useful reference for computing the
overall running time of various asymmetric cryptography schemes.
We will consider a scheme to be secure if any adversary’s advantage is negligible
relative to the security parameter (which is typically the number of bits in N ).

Definition 10.1: Negligibility

A function g : Z+ 7→ R is negligible if it vanishes faster than the reciprocal

of any polynomial. Namely, for every c ∈ Z + , there exists an nc ∈ Z such

Kudrayvtsev 67
CHAPTER 10: Number Theory

Algorithm Inputs Running Time

integer division N > 0; a O(|a| · |N |)
modulus N > 0; a O(|a| · |N |)
extended GCD a; b; (a, b) 6= 0 O(|a| · |b|)
mod addition N ; a, b ∈ ZN O(|N |)

mod multiplication N ; a, b ∈ ZN O |N |2

mod inverse N ; a ∈ Z∗N O |N |2
mod exponentiation N ; n; a ∈ Z∗N O |n| · |N |2

exponentiation in G n; a ∈ G O(|n|) G-operations

Table 10.1: A list of runtimes for common operations in asymmetric cryptog-
raphy. Note that the syntax |x| specifies the number of bits needed to specify x,
so you could say that |x| = log2 x.

that g(n) ≤ n−c for all n ≥ nc .

This will become clearer with examples, but in essence we’re looking for inverse
exponentials, so an advantage of 2−k is negligible.

10.2.2 Inverses
The multiplicative inverse of a number under a modulus is the value that makes
their product 1. That is, x is the multiplicative inverse of z if zx ≡ 1 (mod N ). We
then say x ≡ z −1 (mod N ).
Note that the multiplicative inverse does not always exist (in other words, ZN is not
a group under multiplication); if it does, though, it’s unique. They exist if and only
if their greatest common divisor is 1, so when gcd(x, N ) = 1. This is also called being
relatively prime or coprime.

Greatest Common Divisor

The greatest common divisor of a pair of numbers is the largest number that divides
both of them evenly. Euclid’s rule states that if x ≥ y > 0, then

gcd(x, y) = gcd(x mod y, y)

This leads directly to the Euclidean algorithm.

Extended Euclidean Algorithm

Bézout’s identity states that if n is the greatest common divisorof both x and y,
then there are some “weight” integers a, b such that:

ax + by = n

Kudrayvtsev 68
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

These can be found using the extended Euclidean algorithm and are crucial in
finding the multiplicative inverse. If we find that gcd(x, n) = 1, then we want to find
x−1 . By the above identity, this means:
ax + bn = 1
taking mod n of both sides
ax + bn ≡ 1 (mod n) doesn’t change the truth
ax ≡ 1 (mod n) bn mod n = 0

Thus, finding the coefficient a will find us x−1 .

10.2.3 Modular Exponentiation

We already know how exponentiation works; why do we need to talk about it? Well,
because of time complexity. . . we need to be able to exponentiate fast. With big
numbers repeated multiplication gets out of hand quickly.
Equivalence in modular arithmetic works just like equality in normal arithmetic. So
if a ≡ b (mod N ) and c ≡ d (mod N ) then a + c ≡ a + d ≡ b + c ≡ b + d (mod N ).
This fact makes fast modular exponentiation possible. Rather than doing xy mod N
via x · x · . . . or even ((x · x) mod N ) · x) mod N ) . . ., we leverage repeated squaring:
xy mod N :
x mod N = a1
x2 ≡ a21 (mod N ) = a2
x4 ≡ a22 (mod N ) = a3
...

Then, we can multiply the correct powers of two to get xy , so if y = 69, you would
use x69 ≡ x64 · x4 · x1 (mod N ).

10.3 Groups for Cryptography

First, we need to define some more generic group properties.

Group Elements The order of a finite group element, denoted o(g) for some
g ∈ G, is the smallest integer n ≥ 1 fulfilling g n = 1 (the identity element).
For any group element g ∈ G, we can generate a subgroup of G easily:
hgi = {g 0 , g 1 , . . . , g o(g)−1 }
Naturally, its order is the order o(g) of G. Since we established above that the order
of a subgroup divides the order of the group, the same is true for group elements. In
other words, ∀g ∈ G : |G| mod o(g) = 0.

Kudrayvtsev 69
CHAPTER 10: Number Theory

Generator These are a crucial part of asymmetric cryptography. A group element

g is a generator of G if hgi = G. This means that doing the exponentiation described
above just shuffles G around into a different ordering.
For example, 2 is a generator for Z∗11 :
i 0 1 2 3 4 5 6 7 8 9
i
2 ≡ a (mod 11) 1 2 4 8 5 10 9 7 3 6
An element is a generator if and only if o(g) = |G|, and a group is called cyclic if it
contains at least one generator.

10.3.1 Discrete Logarithm

If G = hgi is cyclic, then for every a ∈ G, there is a unique exponent i ∈ {0, . . . , |G|−
1} such that g i = a. We call i the discrete logarithm of a to base g, denoting it by:
dlogG,g (a). As you’d expect, it inverts exponentiation in the group.
To continue with our example group G = Z∗11 , we know 2 is a generator (see above),
so the dlogG,2 (·) of any group element is well-defined.
a 1 2 3 4 5 6 7 8 9 10
dlogG,2 (a) 0 1 8 2 4 9 7 3 6 5

Algorithm How do we compute the discrete logarithm? Here’s a naïve algorithm:

just try all of the exponentiations. This is a simple algorithm
p but is exponential.
There are better algorithms out there, but are still around O |G| at best. There
are no polynomial time algorithms for computing the discrete logarithm.
This isn’t proven, but much like the AES conjecture (see (3.2)), it is the foundation
of asymmetric security.

Fun Fact: The State of the Art

If the group is based on some prime p, so G = Z∗p , the most efficient known
algorithm is the general number field sieve which (still) has exponential
complexity of the form:
 1/3 2/3 
O e1.92(ln p) (ln ln p) (10.2)

If we have a prime-order group over an elliptic curve, the best-known algo-

√

rithm is O p , where p = |G|.

We need to scale our security based on the state of the art for the groups in question: a
1024-bit prime p is just as secure on Z∗p as a 160-bit prime q on an elliptic curve group.

Kudrayvtsev 70
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Obviously, smaller is preferable because it means our exponentiation algorithms will

be much faster.

10.3.2 Constructing Cyclic Groups

As we already mentioned, cyclic groups are important for cryptography. How do we
build these groups and find generators within them efficiently.

Finding Generators
Thankfully, there are some simple cases that let us create such groups:
• If p is a prime number, then Z∗p is a cyclic group.
• If the order of any group G is prime, then G is cyclic.
• If the order of a group is prime, then every non-trivial element is a generator
(that is, every g ∈ G \ {1} where 1 is the identity element).
However, if G = Z∗p , then its order is p − 1 which isn’t prime. Though it may be hard
to find a generator in general, it’s easy if the prime factorization of p − 1 is known.
A prime p is called a safe prime if p − 1 = 2q, where q is also a prime. Safe primes
are useful because it means that  ∗equally-hard to factor pq into either p or q.1 Here,
though, they’re useful because Zp  factors into (2, q) for safe primes.


Property 10.2. Given a safe prime p, the order of Z∗p can be factored into (2, q),
where q is a prime. Then, a group element g ∈ Z∗p is a generator if and only if
g 2 6≡ 1 and g q 6= 1.

Now, there a useful fact that Z∗p will have q − 1 generators, so a simple randomized
$
algorithm that chooses g ←− G \ {1} until g is a generator (checked by finding g 2
and g q ) will fail with only 1/2 probability. This becomes negligible after enough runs
and will take two tries on average, letting us find generators quickly.
We just found a way to find a generator g in the group Z∗p ; the end-goal is to work
over hgi. Thus, our difficulty has transferred over to choosing safe primes.

Generating Primes
Because primes are dense—for an n-bit number, we’ll find a prime every n runs on
average—we can just generate random bitstrings until one of them is prime. Once we
have a prime, making sure it’s a safe prime does not add much complexity because
they are also dense.

1
For example, factoring 4212253 (into 2903 · 1451) is much harder than factoring 5806 (into 2903 · 3)
because both of the former primes need around 11 bits to represent them.

Kudrayvtsev 71
CHAPTER 10: Number Theory

Given this, how do we check for primality quickly? Fermat’s little theorem gives us
a way to check for positive primality: if a randomly-chosen number r is prime, the
theorem holds. However, checking all r − 1 values √against the theorem is not ideal.
Similarly, checking whether or not all values up to r divide r is not ideal.
It will be faster to identify a number as being composite (non-prime), instead.
Namely, if the theorem doesn’t hold, we should be able to find any specific z for
which z r−1 6≡ 1 (mod r). These are called a Fermat witnesses, and every composite
number has at least one.
This “at least one” is the trivial Fermat witness: the one where gcd(z, r) > 1.
Most composite numbers have many non-trivial Fermat witnesses: the ones where
gcd(z, r) = 1.
The composites without non-trivial Fermat witnesses called are called Carmichael
numbers or “pseudoprimes.” Thankfully, they are relatively rare compared to normal
composite numbers so we can ignore them for our primality test.

Property 10.3. If a composite number r has at least one non-trivial Fermat

witness, then at least half of the values in Zr are Fermat witnesses.

The above property inspires a simple randomized algorithm for primality tests that
identifies prime numbers to a particular degree of certainty:
$
1. Choose z randomly: z ←− {1, 2, . . . , r − 1}.
?
2. Compute: z r−1 ≡ 1 (mod r).
3. If it is, then say that r is prime. Otherwise, r is definitely composite.
Note that if r is prime, this will always confirm that. However, if r is composite (and
not a Carmichael number), this algorithm is correct half of the time by the above
property. To boost our chance of success and lower false positives (cases where r is
composite and the algorithm says it’s prime) we choose z many times. With k runs,
we have a 1/2k chance of a false positive.

Property 10.4. Given a prime number p, the number 1 only has the trivial
square roots ±1 under its modulus. In other words, there is no other value z such
that: z 2 ≡ 1 (mod p).

The above property lets us identify Carmichael numbers during the fast exponentia-
tion for 3/4ths of the choices of z, which we can use in the same way as before to check
primality to a particular degree of certainty.

Kudrayvtsev 72
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

10.4 Modular Square Roots

Finding the square roots under a modulus is considered to be just as “hard” as fac-
toring. We say that a is a square (or quadratic residue) modulo p if there’s a b
such that b2 ≡ a (mod p). We could also say that √b is the square root of a under
modulo p, though we don’t really use the notation a ≡ b (mod p).
Under modular arithmetic, square roots don’t always exist. They’re specifically de-
fined when there are two (distinct) roots under a prime. For example, 25 has two
square roots under mod 11. Since 25 mod 11 ≡ 3, we’re looking for values that are
also ≡ 3 under modulo 11:

52 = 25 ≡ 3 (mod 11)
62 = 36 ≡ 3 (mod 11)

Thus, the square root of 25 is both 5 and 6 under modulo 11 (weird, right?). Weird,
right? Well, not so much when you consider that −5 ≡ 6 (mod 11).
Again, not every value has a square root: for example, 28 doesn’t under mod 11
(note that 28 mod 11 = 6). We can verify this by trying all possible values2 under
the modulus:

12 =1 (mod 11)
22 =4 (mod 11)
32 =9 (mod 11)
42 = 16 ≡ 5 (mod 11)
52 = 25 ≡ 3 (mod 11)
62 = 36 ≡ 3 (mod 11)
72 = 49 ≡ 5 (mod 11)
82 = 64 ≡ 9 (mod 11)
92 = 81 ≡ 4 (mod 11)
102 = 100 ≡ 1 (mod 11)

However, it does under mod 19: 28 mod 19 = 9, and 32 mod 19 = 9.

2
Also, notice that there are no other values that are equivalent to 25 ≡ 3 (mod 11), confirming
that there are only two roots under this modulus.

Kudrayvtsev 73
CHAPTER 10: Number Theory

10.4.1 Square Groups

The Legendre symbol (also called the Jacobi symbol) is a compact way of indi-
cating whether or not a value is a square:

1
 if a is a square mod p,
Jp (a) = 0 if a mod p = 0, (10.3)
−1 otherwise



With that, we can define sets of squares (or quadratic residues) in a group as:
QR Z∗p = {a ∈ Z∗p : Jp (a) = 1} (10.4)

= {a ∈ Z∗p : ∃b such that b2 ≡ a (mod p)}

For example, for Z∗11 , we have the following:

x 1 2 3 4 5 6 7 8 9 10
2
x (mod 11) 1 4 9 5 3 3 5 9 4 1
J11 (x) 1 -1 1 1 1 -1 -1 -1 1 -1
Thus, QR(Z∗11 ) = {1, 3, 4, 5, 9}. There are exactly five squares and five non-squares,
and each of the squares has exactly two square roots (this isn’t a coincidence). Note
that generators are never squares.
Recall that 2 is a generator of Z∗11 . Let’s map the discrete log table with the Jacobi
table, now:
x 1 2 3 4 5 6 7 8 9 10
dlogZ∗11 ,2 (x) 0 1 8 2 4 9 7 3 6 5
J11 (x) 1 -1 1 1 1 -1 -1 -1 1 -1
Notice that x is a square if dlogZ∗11 ,2 (x) is even. This makes sense, since for any
generator g, if it’s raised to an even power (i.e. some 2j), then it’s obviously a square:
2
g 2j = (g j ) . It generalizes well:

Property 10.5. If p ≥ 3 is a prime and g is a generator of Z∗p , then the set of

quadratic residues (squares) is g raised to all of the even powers of p − 2:

QR Z∗p = {g i : 0 ≤ i ≤ p − 2 and i mod 2 = 0}

Now previously, we defined the Legendre symbol as a simple indicator function (10.3);
conveniently, it can actually be computed for any prime p ≥ 3:
p−1
Jp (a) ≡ a 2 (mod p) (10.5)

This is a cubic-time algorithm (in |p|) to determine whether or not a number is a

square. From this, we have another useful property.

Kudrayvtsev 74
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Property 10.6. If p ≥ 3 is a prime and g is a generator of Z∗p , then Jp (g xy mod

p) = 1 if and only if either Jp (g x mod p) = 1 or Jp (g y mod p) = 1 (that is, at
least one of them is a square), for all x, y ∈ Zp−1 .
The corollary from this is that QR Z∗p  = p−1


2
.

The Legendre symbol has the property multiplicity: Jp (ab) = Jp (a) · Jp (b) for any
a, b ∈ Z. It also has an inversion property: the Legendre symbol of a value’s inverse
is the same as the value’s. That is, Lp (a−1 ) = Lp (a). Both of these apply only for
non-trivial primes: p ≥ 3.

The following are “bonus” sections not directly related to the lecture content.

10.4.2 Square Root Extraction

A secondary, key fact of square-root extraction is the following: if square roots exists
under a modulus, there are two for each prime in the modulus. For example, we
found that 5 and 6 are the roots of 25 under modulus 11, but what about under 13?
We know 25 mod 13 = 12, so let’s search:

12 =1 (mod 13)
22 =4 (mod 13)
32 =9 (mod 13)
42 = 16 ≡ 3 (mod 13)
52 = 25 ≡ 12 (mod 13)
62 = 36 ≡ 10 (mod 13)
72 = 49 ≡ 0 (mod 13)
82 = 64 ≡ 12 (mod 13)
92 = 81 ≡ 3 (mod 13)
102 = 100 ≡ 9 (mod 13)
112 = 121 ≡ 4 (mod 13)
122 = 144 ≡ 1 (mod 13)

Looks like 5 and 8 are the roots of 25 under mod 13. Thus, if we look for the roots
under the product of 11 · 13 = 143, we will find exactly four values:3

52 = 25 ≡ 25 (mod 143)
602 = 3600 ≡ 25 (mod 143)
3
These were found with a simple Python generator:
filter(lambda i: (i**2) % P == v % P, range(P))

Kudrayvtsev 75
CHAPTER 10: Number Theory

832 = 6889 ≡ 25 (mod 143)

1382 = 19004 ≡ 25 (mod 143)

The key comes from the following fact: by knowing the roots under both 11 and 13
separately, it’s really easy to find them under 11 · 13 without iterating over the entire
space. To reiterate, our roots are 5, 6 (mod 11) and 5, 8 (mod 13). We can use the
Chinese remainder theorem to find the roots quickly under 13 · 11.

Finding Roots Efficiently In our case, we have the four roots under the respective
moduli, and we can use the CRT to find the four roots under the product. Namely,
we find ri for each pair of roots:

r1 ≡ 5 (mod 11) r2 ≡ 5 (mod 11)

r1 ≡ 5 (mod 13) r2 ≡ 8 (mod 13)

r3 ≡ 6 (mod 11) r4 ≡ 6 (mod 11)

r3 ≡ 5 (mod 13) r4 ≡ 8 (mod 13)

Finding each ri can be done very quickly using the extended Euclidean algorithm
in O((|n| + |m|)2 ) time (where |x| represents the
bit count of each prime), which is
much faster than the exhaustive search O 2|m||n| necessary without knowledge of 11
and 13. In this case, the four roots are 5, 60, 83, and 138 (in order of the ri s above).
Square root extraction of a product of primes pq is considered to be as
difficult as factoring it.

10.5 Chinese Remainder Theorem

The Chinese remainder theorem states that if you have a series of coprime values:
n1 , n2 , . . . , nk , then there exists a single value x mod (n1 n2 · · · nk ) (the product of the
individual moduli) that is equivalent to a series of values under each of them:

x ≡ a1 (mod n1 )
x ≡ a2 (mod n2 )
...
x ≡ ak (mod nk )

Kudrayvtsev 76
Encryption

How long do you want these messages to remain secret? I want

them to remain secret for as long as men are capable of evil.
— Neal Stephenson, Cryptonomicon

hen we studied symmetric encryption schemes, we relied on block ciphers as a

W fundamental building block for a secure mode of operation. With asymmetric
schemes, we no longer have that luxury since we have no shared symmetric keys.
However, we still need computationally-difficult problems (like the PRF conjecture of
AES) to base our security on.
The problems we’ll use are the discrete logarithm problem (whose difficulty we alluded
to in this aside) as well as the RSA problem, later.

11.1 Recall: The Discrete Logarithm

Let G be a cyclic group, m = |G| be the order of the group, and g be a generator
of G. Then discrete logarithm function dlogG,g (a) : G 7→ Zm takes a group element
a ∈ G and returns the integer i ∈ Zm such that g i = a.
There are several computationally-difficult problems associated with this function,
each of which we’ll examine in turn:
• The straightforward discrete log problem, in which you must find x given g x .
• The computational Diffie-Hellman problem, in which you’re given g x and
g y and must find g xy .
• The decisional Diffie-Hellman problem, in which you’re given g x , g y , and g z
?
and must figure out whether or not z ≡ xy (mod m).

can solve DL =⇒ can solve CDH =⇒ can solve DDH

77
CHAPTER 11: Encryption

Though these problems all appear different, they boil down to the same fact: if you
can solve the initial discrete log problem, you can solve all of them:

11.1.1 Formalization
In each case, suppose again that we’re given a cyclic group G, the order of the group
m = |G|, and a generator g. The adversary knows all of this (fixed) information.

DL Problem The discrete logarithm problem is described by an adversary A’s

ability to efficiently determine an original, randomly-chosen exponent:

$
Expdl
G, g (A) : x ←− Zm
x0 = A(g x )
0
if g x = g x , A wins

As usual, we define the discrete problem as being “hard” if any adversary’s dl-
advantage is negligible with polynomial resources.

Definition 11.1: Discrete-Log Advanatage

We can define the dl-advantage of an adversary as the probability of win-

ning the discrete logarithm experiment:
h i
Advdl
G, g (A) = Pr Expdl
G, g (A) wins

CDH Problem The computational Diffie-Hellman problem is described by an ad-

versary A’s ability to efficiently determine the product of two randomly-chosen ex-
ponents:

$
Expcdh
G, g (A) : x, y ←− Zm
z = A(g x , g y )
if z = g xy , A wins

The cdh-advantage and difficulty of CDH is defined in the same way as DL.

DDH Problem The decisional Diffie-Hellman problem is described by an adversary

A’s ability to differentiate between two experiments (much like with the oracle of
IND-CPA security and the others we saw with symmetric security definitions):

Kudrayvtsev 78
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

$
Expddh-1
G, g (A) : x, y ←− Zm
$
Expddh-0
G, g (A) : x, y ←− Zm
$
z = xy mod m z ←− Zm key
difference
d = A(g x , g y , g z ) d = A(g x , g y , g z )
return d return d
The difficulty of DDH is defined in the usual way based on the ddh-advantage of any
adversary with polynomial resources.

Definition 11.2: DDH Advantage

The ddh-advantage of an adversary A is its ability to differentiate between

the true and random experiments:
h i h i
Advddh
G, g (A) = Pr ExpG, g (A) → 1 − Pr ExpG, g (A) → 1
ddh-1 ddh-0

11.1.2 Difficulty
Under the group of a prime Z∗p , DDH is solvable in polynomial time, while the others
are considered hard: the best-known algorithm is the general number field sieve whose
complexity we mentioned in (10.2).
In contrast, under the elliptic curves, all three of the aforementioned problems are
√
harder than their Z∗p counterparts, with the best-known algorithms taking p time,
where p is the prime order of the group.

DL Difficulty

Note that there is a linear time algorithm for breaking the DL problem, but it relies
on knowing something that is hard to acquire. The algorithm relies on knowing the
prime factorization of the order of the group. Namely, if we know the breakdown
such that
p − 1 = pα1 1 · pα2 2 · . . . · pαnn

(where each pi is a prime), then the discrete log problem can be solved in

n
X √
αi · ( pi + |p|)
i=1

time. Thus, if we want the DL problem to stay difficult, then at least one prime
factor needs to be large (e.g. a safe prime) so the factorization is difficult.

Kudrayvtsev 79
CHAPTER 11: Encryption

Breaking DDH is Easy

Let’s take a look at the algorithm for breaking the decisional DH problem under
the prime group Z∗p . Remember, the goal of breaking DDH essential comes down to
differentiating between g xy and a random g z6=xy .
The key lies in a fact we covered when discussing Groups: we can easily differentiate
squares and non-squares in Z∗p (see Property 10.5). There’s an efficient adversary who
can have a ddh-advantage of 1/2: the idea is to compute the Legendre symbols of the
inputs. Recall Equation 10.5 or more specifically Property 10.6: the Legendre symbol
of an exponent product must match the individual exponents.

Algorithm 11.1: An adversarial algorithm for DDH in polynomial time.

Input: (X, Y, Z), the alleged Diffie-Hellman tuple where X = g x , Y = g y , and Z
is either g xy or a random g z .
Result: 1 if Z = g xy and 0 otherwise.
if Jp (X) = 1 or Jp (Y ) = 1 then
s=1
else
s = −1
end
return 1 if Jp (Z) = s else 0

Since g x or g y will be squares half of the time (by Property 10.5—even powers of g
are squares), and g xy can only be a square if this is the case, this check succeeds with
1/2 probability, since:

Expddh-0
G, g A = 1

Expddh-1
G, g A = /2
1

∴ Advddh
G, g (A) = 1 − /2 = /2
1 1

The algorithm only needs two modular exponentiations, meaning it takes O |p|3

time (refer to Table 10.1) at worst and is efficient. 

Making DDH Safe Since the best-known efficient algorithm relies on squares, we
can modify the group in question to avoid the algorithm. Specifically, DDH is believe

to be difficult (i.e. a minimal ddh-advantage for any polynomial adversary) in QR Z∗p
where p = 2q + 1, a safe prime.

Kudrayvtsev 80
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

11.2 Diffie-Hellman Key Exchange

This algorithm, designed for two parties to derive a mutual secret without exposing
it, relies on the difficulty of the computational Diffie-Hellman problem for its security.
The Diffie-Hellman key exchange is defined as follows: we first let G = hgi be
a cyclic group of order m, where both g and m are public parameters known to
everyone. Alice and Bob derive a mutual secret key by communicating as follows:
1. Alice and Bob choose their private keys randomly which are simply random
$ $
exponents: a ←− Zm and b ←− Zm , respectively.
2. From these values, they can derive their respective public keys by raising the
generator to the relevant power: A = g a and B = g b .
A

3. Then, Alice sends Bob her public key and vice-versa: Alice Bob

4. Alice derives the mutual secret from Bob’s public key:

a
s = B a = g b = g ab

5. Bob similarly derives the same key: s = Ab = (g a )b = g ab .

Because it’s computationally difficult for an attacker to find either a or b (since that
would involve finding the discrete log: a = dlogG,g (A)), this shared secret is derived
without revealing any insecure information. The attacker is tasked with finding g ab
while only knowing g a and g b —exactly the computational Diffie-Hellman problem.

11.3 ElGamal Encryption

With ElGamal encryption, which extends Diffie-Hellman to do encryption, we com-
pute a ciphertext with a temporary key exchange. The parameters stay the same,
with G = hgi having order m. This time, Alice is a recipient of a message from Bob,
and the message space is the group itself (so M ∈ G):
$
1. Alice chooses a random exponent as a secret just like before: a ←− Zm .
2. Alice again broadcasts her public key the same way: A = g a .
3. Bob wants to send Alice a message, M , encrypting it as follows:
$
(a) He chooses a private exponent as before: b ←− Zm .
(b) He encrypts M under the to-be-shared secret Ab = g ab via the group

Kudrayvtsev 81
CHAPTER 11: Encryption

operation:1 c = M · g ab and sends (g b , c) to Alice.

4. Alice can obviously derive the same secret s = g ab and can find M by finding
the inverse of the secret: M = c · s−1 = (M · s) · s−1 = M .
This scheme relies on the property that every shared secret s = g ab has an inverse
s−1 which is guaranteed by the invertibility property of groups.

11.3.1 Security: IND-CPA

Since this is an encryption scheme, knowing that the secret cannot be found efficiently
because of CDH is insufficient. We want to know if ElGamal is IND-CPA secure under
specific groups.
Unfortunately, it’s not secure under Z∗p for the same reasons as before: ElGamal
boils down to the decisional Diffie-Hellman problem which we broke earlier with
algorithm 11.1. By the very definition of IND-CPA, an attacker should be unable to
infer anything about the plaintext from the ciphertext, but under Z∗p , they can easily
determine whether or not it’s a square via the Legendre symbol. Specifically, when
given a ciphertext (B, c) for a message M , an adversary can compute Jp (M ); the full
attack is formalized in algorithm 11.2.

Algorithm 11.2: An efficient adversary breaking ElGamal encryption under

Z∗p .
Input: A public key, pk.
Input: The ElGamal parameters: G = Z∗p = hgi , m.
Result: 1 if the left message is encrypted, 0 otherwise.
Let M0 be chosen such that Jp (M0 ) = 1 (for ex. M0 = 1).
Let M1 be chosen such that Jp (M1 ) = −1 (for ex. M1 = g).
(X, c) = EP (LR(M0 , M1 ))
if Jp (X) = 1 or Jp (pk) = 1 then
s = Jp (c)
else
s = −Jp (c)
end
return 1 if s = 1 else 0

There is good news, though: ElGamal encryption is IND-CPA secure for a group if
the DDH problem on the same group is hard. As a reminder, such groups include
prime-order subgroups of Z∗p or elliptic curve prime order groups.
1
Recall that a group is defined by a set and a specific operation (see section 10.1 for a review)
which we have been denoting as · (as opposed to · for multiplication).

Kudrayvtsev 82
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Claim 11.1. If the decisional Diffie-Hellman problem is computationally hard for

a group G, ElGamal encryption is IND-CPA under the same group.

Proof. We proceed by showing that if ElGamal is not IND-CPA, then the DDH
problem is not hard (this is the contrapositive technique we used when proving the
IND-CCA security of the CBC mode of operation; see Theorem 3.2).
Assume A is an IND-CPA attacker for ElGamal. We will use A to construct an DDH
adversary B. Simply put, B will pass along the Diffie-Hellman tuple it receives as part
of the DDH challenge and let A differentiate between “real” and “random” tuples.
Recall that the DDH Problem is to differentiate a value g z where z is chosen randomly
from a g z where z = xy mod m when given g x and g y .
?
 
Our adversary B is given g, X = g , Y = g , Z = g
x y z ≡xy
and will use A as follows:
$
1. Flip a coin as an oracle, choosing b ←− {0, 1}.
2. Run A with the ElGamal parameters g and public key X.
3. When A makes a query (with, say, (m0 , m1 )), return (Y, mb · Z), exactly as
specified by ElGamal encryption—Y here is the one-time public key of the
“sender” and mb · Z is the ciphertext.
4. Let d be A’s result—its guess of b.
5. If d = b, return 1 (this is a real DDH tuple, Z = g xy ); otherwise, return 0 (this
is a random DDH tuple).
The rationale is that because Z is an invalid ciphertext construction in the case of
a random DDH tuple, A should fail at breaking the scheme since its invalid. Let’s
justify the ddh-advantage. By definition,

G, g (B) = Pr ExpG, g (B) → 1 − Pr ExpG, g (B) → 1

Advddh ddh-1 ddh-0
   

Let’s break this down into its component parts. Notice that the first probability
(differentiating real tuples correctly) is simply dependent on A’s ability to break
ElGamal encryption under the IND-CPA-cg variant (in other words, B acts exactly
?
like an IND-CPA-cg oracle by choosing b randomly and comparing d = b):
h i
Pr ExpG, g (B) → 1 = Pr ExpEG
ddh-1 ind-cpa-cg
 
(A) → 1
1 1
= + Advind-cpa
EG (A) from the proof of
Definition 3.3
2 2

On the other side, we have B’s chance of failing to differentiate random tuples. By
construction, B outputs 1 when A is correct; because A receives a random group

Kudrayvtsev 83
CHAPTER 11: Encryption

element in this case (some random g z , by definition of a generator), there’s no way

A can make any sense of it. Thus, it cannot do better than a random guess at b:
 1
Pr Expddh-0

G, g (B) → 1 ≤
2

Combining these, we see:

G, g (B) = Pr ExpG, g (B) → 1 − Pr ExpG, g (B) → 1

Advddh ddh-1 ddh-0
   

1 1 1
≥ + Advind-cpa
EG (A) −
2 2 2
1 ind-cpa
≥ · AdvEG (A)
2

As desired, we see that if A is successful, then B is successful. Thus, by the con-

trapositive, if a group’s DDH problem is hard, the corresponding ElGamal scheme is
IND-CPA secure. 

11.3.2 Security: IND-CCA

Regardless of the security of the underlying DDH problem, ElGamal is not IND-CCA.
It’s trivially breakable by passing a message inverse.
For example, the ciphertext is
(B, c) = EA (LR(m0 , m1 )). Then, what is DB c · m−11 ?

DB c · m−1 = c · m−1 ab −1


1 1 · (g )
= mb · m−1 ab ab −1
1 · g · (g )
= mb · m−1
1

If b = 1 (the right message was chosen), then this simply evaluates to the identity
element 1! In the other case, it does not, so this is a sufficient check for always
correctly differentiating which plaintext was encrypted.

11.4 Cramer-Shoup Encryption

With ElGamal failing to provide ideal security properties, can we even construct
an asymmetric scheme that is IND-CCA secure? Yes: the Cramer-Shoup scheme
invented in ‘98 provides this level of security.
It’s far more involved, and defined formally as follows: let G be a cyclic group of
order q, and g1 , g2 are random, distinct generators of G.
First, key generation is defined as follows:
$
Key generation K : x1 , x2 , y1 , y2 , z ←− Zq

Kudrayvtsev 84
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

c = g1x1 · g2x2
d = g1y1 · g2y2
h = g1z

Notice that there are five secret exponents.

Kudrayvtsev 85
CHAPTER 11: Encryption

The encryption algorithm requires many more (expensive) exponentiations:

$
Encryption E(G,q,g1 ,g2 ,c,d,h) (M ) : k ←− Zq
u1 = g1k
u2 = g2k
e = hk · M
α = H(u1 , u2 , e)
v = ck · dkα
return (u1 , u2 , e, v)

Here, H is a cryptographically-secure hash function. Finally, decryption uses the

secret exponent as follows:
Decryption D(x1 ,x2 ,y1 ,y2 ,z) (u1 , u2 , e, v) :
α = H(u1 , u2 , e, v)
if (ux1 1 · ux2 2 · (uy11 · uy22 )α = v)
e
return z
u1
return ⊥

Property 11.1. If the decisional Diffie-Hellman problem for the group G is hard
and H is a cryptographically-secure hash function, then Cramer-Shoup is IND-
CCA secure.
Despite its strong security, this scheme is not used in practice because far more
efficient IND-CCA secure asymmetric algorithms exist, though they do not rely on
the difficulty of the discrete logarithm problem.

11.5 RSA Encryption

The RSA cryptosystem does not rely on the difficulty of the discrete logarithm.
Instead, it relies on a different, but similar problem: factorization. Given a product
of two prime numbers, N = pq, it’s considered computationally difficult to find the
original p and q.
With our basic understanding of group theory, the math behind RSA is very simple.
Recall that xa = xa mod m , if m is the order of the group. Well when given N = pq and
working in Z∗N we have order ϕ (N ) = (p − 1)(q − 1) (this is Euler’s totient function
and it’s proved below). Given a choice of e such that we can find de ≡ 1 (mod ϕ (N ))
(that is d is the multiplicative inverse of e), we have the following property:
mde ≡ mde mod ϕ(N ) (mod N )

Kudrayvtsev 86
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

≡ m1 ≡ m (mod N ) recall (10.1)

This means that raising a message m to the de power simply returns the original
message. The RSA protocol thus works as follows. A user reveals their public key
to the world: the exponent e and the modulus N . To send them a message, m, you
send c = me mod N . They can find your message by raising it to their private key
exponent, d:

= cd mod N
= (me mod N )d = med mod N
= m mod N

This is secure because you cannot determine (p − 1)(q − 1) from the revealed N and e
without exhaustively enumerating all possibilities2 (i.e. “factoring is hard”); thus, if p
and q are large enough, it’s computationally infeasible for an adversary to factor N .

Quick Maffs: Proof of Euler’s Totient Function

We claimed above that given N = pq, then ϕ (N ) = (p − 1)(q − 1).

The proof of this is straightforward. Which values can divide pq? Obviously
any multiple of p: 1p, 2p, and so on up to (q − 1)p, and likewise for q. We
can calculate the total number of these directly:
     
     
     
ϕ (N ) = ϕ (pq) = {1, 2, . . . , N − 1} − {ip : 1 ≤ i ≤ q − 1} − {iq : 1 ≤ i ≤ p − 1}
     
| {z } | {z } | {z }
 the entire set, ZN   multiples of p   multiples of q 
= (N − 1) − (q − 1) − (p − 1) = N − 1 − q + 1 − p + 1
= pq − q − p + 1
= (p − 1)(q − 1) 

11.5.1 Protocol
With the math out of the way, here’s the full protocol. Note that pk = (e, N ) is the
public key information, and sk = (d, N ) is the private key information (where d is
the only real “secret,” but both values are needed).

K : ed ≡ 1 (mod ϕ (N )) (e, d ∈ Z∗ϕ(N ) )

Epk (m) = xe mod N (Z∗N 7→ Z∗N )

2
Notice that if an adversary knew both N and ϕ (N ), they could use this information to form a
simple quadratic equation which can obviously be solved in polynomial time. If they knew ϕ (N )
and e, then d is just the modular inverse of e under mod ϕ (N ).

Kudrayvtsev 87
CHAPTER 11: Encryption

Dsk (c) = cd mod N

The RSA encryption function f (defined with E above) is a one-way permutation

with a trap door: without the special “trap door” value d, it’s hard to find f −1 .

Receiver Setup To be ready to receive a message:

1. Pick two n-bit random prime numbers, p and q.
2. Then, choose an e that is relatively prime to (p − 1)(q − 1) (that is, by ensuring
that gcd(e, (p − 1)(q − 1)) = 1. This can be done quickly by enumerating the
low primes and finding their GCD; an exponent of e = 3 is fairly common for
computational efficiency.
3. Let N = pq and publish the public key (N, e).
4. Your private key is d ≡ e−1 (mod (p − 1)(q − 1)) which we know exists and can
be found with the extended Euclidean algorithm.

Sending Given an intended recipient’s public key, (N, e), and a message m ≤ N ,
simply compute and send c = me mod N . This can be calculated quickly using fast
exponentiation (refer to subsection 10.2.3).

Receiving Given a received ciphertext, c, to find the original message simply cal-
culate cd mod N = m (again, use fast exponentiation).

11.5.2 Limitations
For this to work, the message must be small: m ∈ Z∗N . This is why asymmetric
cryptography is typically only used to exchange a secret symmetric key which is
then used for all other future messages. There are also a number of attacks on plain
RSA that must be kept in mind:
• We need to take care to choose ms such that gcd(m, N ) = 1. If this isn’t
the case, the key identity med ≡ m (mod N ) still holds—albeit this time by
the Chinese remainder theorem rather than Euler’s theorem—but now there’s a
fatal flaw. If gcd(m, N ) 6= 1, then it’s either p or q. If it’s p, then gcd(me , N ) = p
and now N can easily be factored (and likewise if it’s q).
• Similarly, m can’t be too small, because then it’s possible to have me < N —the
modulus has no effect and directly taking the eth root will reveal the plaintext!
• Even though small e are acceptible, the private exponent d cannot be too small.
Specifically, if d < 31 · N 1/4 , then given the public key (N, e) one can efficiently
compute d.

Kudrayvtsev 88
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

• Another problem comes from sending the same message multiple times via
different public keys. The Chinese remainder theorem can be used to recover the
plaintext from the ciphertexts; this is known as Haståd’s broadcast attack.
Letting e = 3, for example, the three ciphertexts are:

c1 ≡ m 3 (mod N1 )
c2 ≡ m 3 (mod N2 )
c3 ≡ m 3 (mod N3 )

The CRT states that c1 ≡ c2 ≡ c3 (mod N1 N2 N3 ), but these would just

√ be m3
“unrolled” without the modulus, since m3 < N1 N2 N3 ! Thus, m = m3 , and
3

finding m3 can be done quickly with the extended Euclidean algorithm.

RSA: Alternative Derivation

In much of the literature surrounding RSA, the fundamentals of group the-
ory are not discussed prior, making the derivations of the math a little more
confusing. Because the theorems used are still very important to know and
recognize, I cover them here.
Rather than relying on our well-known property that xa = xa mod m for a
group of order m, we will instead use Fermat’s little theorem and its
older brother, Euler’s theorem to understand the math in RSA. Both of
these theorems are simply special cases of the generic exponentiation fact
we showed when covering Groups (again, see Equation 10.1).

Theorem 11.1 (Fermat’s little theorem). If p is any prime,

then
ap−1 ≡ 1 (mod p)
for any number 1 ≤ a ≤ p − 1.

Intuition via Fermat

Suppose we take two values d and e such that de ≡ 1 (mod p − 1). By
the definition of modular arithmetic, this means that: de = 1 + k(p − 1)
(i.e. some multiple k of the modulus plus a remainder of 1 adds up to de).
Notice, then, that for some m:

mde = m · mde−1
= m · mk(p−1)

k
≡ m · mp−1 (mod p)
≡ m · 1k (mod p) by Fermat’s little theorem

Kudrayvtsev 89
CHAPTER 11: Encryption

∴ mde = m (mod p)

We’re almost there; notice what we’ve derived: Take a message, m, and
raise it to the power of e to “encrypt” it. Then, you can “decrypt” it and
get back m by raising it to the power of d.

Intuition via Euler

Unfortunately, for the above to work, we need to reveal p, which obviously
reveals p − 1 and lets someone derive the “private” key d. We’ll hide this
by using N = pq and Euler’s theorem which relates the totient function to
multiplicative inverses.

Theorem 11.2 (Euler’s theorem). For any N, a that are

relatively prime (that is, where gcd(a, N ) = 1), then:

aϕ(N ) ≡ 1 (mod N )

where ϕ (N ) is Euler’s totient function.

If N = pq, then this theorem tells us that:

a(p−1)(q−1) ≡ 1 (mod N )

The rationale for “encryption” is the same as before: take d, e such that
de ≡ 1 (mod ϕ (N )). Then,

mde = m · mde−1
= m · m(p−1)(q−1)k def. of mod
 k
≡ m · m(p−1)(q−1) (mod N )
≡ m · 1k (mod N ) by Euler’s theorem
de
∴ m ≡m (mod N )

11.5.3 Securing RSA

By its very nature, RSA is a deterministic protocol, so it cannot be IND-CPA secure

(see Theorem 3.1). There is a protocol called RSA-OAEP that is conjectured to be
IND-CCA secure.
It relies on two hash functions, H and G, and random inputs to pad the message in
a non-deterministic way to derive the final ciphertext. This scheme has been proven
to be IND-CCA secure if RSA is secure (obviously) and if G and H are modeled as

Kudrayvtsev 90
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

M 0...0 $
Algorithm:
⊕ G
m = M k {0 . . . 0}
H ⊕ $
r ←− {0, 1}k
left = G(r) ⊕ m
k
right = H(left) ⊕ r
return RSAN,e (left k right)
RSAN,e (·) C

Figure 11.1: A visualization of the RSA-OAEP encryption algorithm.

random oracles.
The random oracle model assumes that all parties involved must access an oracle
that acts as a truly-random function. This does not match reality, since hashes can
be computed locally without consulting an oracle; furthermore, the hash functions
often imitate pseudorandom functions. However, it’s still a useful construction and
key to many security proofs.

For more on the random oracle model (which we’ll be leveraging many
times throughout this part of the text), take a glance at chapter 17 in the
Advanced Topics section.

11.6 Hybrid Encryption

As already mentioned, asymmetric encryption schemes are often used to exchange
keys for symmetric schemes, because the latter class of algorithms is much more
performant. Fortunately, the security of these combined schemes is guaranteed:

Property 11.2. If the components of a hybrid encryption scheme are IND-CPA,

then the associated hybrid encryption is overall also IND-CPA. This property also
holds also for IND-CCA.

11.7 Multi-User Encryption

The setting of one user sending messages to another user is getting rarer by the day;
more often than not, we have one-to-many relationships with our messages, from
dozen-member group chats to thousand-member channels. To evaluate our schemes
under these multi-user scenarios, we need to reconsider our security definitions.

Kudrayvtsev 91
CHAPTER 11: Encryption

11.7.1 Security Definitions

In both IND-CPA and IND-CCA, adversaries were trying to break communications
between a single user and oracle. Recall Haståd’s broadcast attack on RSA: sending
the same message to many users is completely broken, despite the fact that we can’t
recover plaintexts under single-user RSA. Similarly, we know that RSA-OAEP is
IND-CCA secure (with the random oracle assumpion) with just one pair of users, but
again, what about the multi-user setting? Thus, we need a new setting in which a
user communicates with many distinct oracles.

pk1. . . pkn $
b ←− {0, 1}
m1 , m2

Epk1 (LR(·, ·, b))

c1
..
A m2n , m2n+1
.
Epkn (LR(·, ·, b))
cn

b0
Figure 11.2: A visualization of the IND-CPA adversary in the multi-user setting,
where A knows n public keys and must output their guess, b0 , corresponding to
the left-right oracles’ collective choice of b.

The adversarial scenario for the n-IND-CPA experiment is visualized in Figure 11.2
and should be relatively intuitive: instead of a single oracle and public key, there are
n oracles and n public keys. All of them use the same b (that is, if they choose b = 0,
they will always encrypt the left message), and the adversary’s goal is to differentiate
between left and right messages to output b0 , their guess.

Definition 11.3: n-IND-CPA Advantage

An asymmetric encryption scheme AE is considered secure under n-IND-

CPA if its n-IND-CPA advantage is negligible, where the advantage is
defined similarly to the IND-CPA case:
h i h i
n-ind-cpa n-ind-cpa-0 n-ind-cpa-1
AdvAE (A) = Pr ExpAE (A) → 0 − Pr ExpAE (A) → 0

We can define multi-party, n-IND-CCA security in a similar way: we now have n

decryption oracles, and the attacker is (only) restricted from decrypting ciphertexts
from the corresponding encryption oracle.

Kudrayvtsev 92
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

11.7.2 Security Evaluation

The good news is that strong security in the single-user setting implies strong security
in the multi-user setting: there is an upper bound on the advantage gained in the
multi-user setting.

Theorem 11.3. For an asymmetric encryption scheme AE, for any adversary
A there exists a similarly-efficient adversary B that only uses one query to the
left-right oracle such that:

Advn-ind-cpa
AE (A) ≤ n · qe · Advind-cpa
AE (B)

where n is the number of users and qe is the number of queries made to the
encryption oracles.

An identical definition exists relating n-IND-CCA to IND-CCA security.

The fact that we have asymptotically similar security is good, but these factors (n and
qe ) are significant: security degrades with more users and more messages. For
example, allowing 200 million users to intercommunicate and encrypt 230 messages
under each key (these are large numbers, but far from unreasonable to a dedicated
attacker), the n-IND-CPA advantage is only 0.2 (pretty high!) if the original IND-
CPA advantage was 2−60 (very low!).
Thankfully, this definition is a universal upper bound: we can do better with specific
schemes that have multiple users in mind. For example, ElGamal encryption makes
better guarantees:

Theorem 11.4 (Multi-User ElGamal). For any adversary A under multi-user

ElGamal encryption, there exists a similarly-efficient adversary B that only makes
one query such that:
Advn-ind-cpa
EG (A) ≤ Advind-cpa
EG (B)

This is obviously much stronger than the generic guarantees of the previous theorem.
Unfortunately, no such improvements exist for RSA. For Cramer-Shoup encryption,
a better bound exists but only drops one of the linear terms.

11.8 Scheme Variants

There are some alternative approaches to asymmetric cryptography that don’t rely
on our so-called “hard math problems” to work:
identity-based encryption Recall the linchpin of public key encryption: the sender
needs to be able to find the receiver’s public key somewhere, typically looking it

Kudrayvtsev 93
CHAPTER 11: Encryption

up from some central, trusted authority. With IBE, senders don’t need public
keys to encrypt; instead, they can use an arbitrary string owned by the receiver
(such as an email address) and provide it to a central authority to get a secret
key.
Nothing is free, of course, and this last point is its fundamental flaw: the central
authority must be extremely trustworthy and safe in order to store secret keys
(rather than public keys, which are much more innocuous).
attribute-based encryption In this variant, the secret key and ciphertext of a
message are associated with attributes about the recipient, such as their age,
title, etc. Decryption is only possible if the attributes of the recipient’s key
match that of the ciphertext.
Of course, this implies a bit of a chicken-and-egg problem much like in key
distribution: how does the sender learn the supposedly-hidden attributes of the
recipient without anyone else knowing them, and doesn’t that mean they can
decrypt any ciphertexts now intended for that recipient since they know that
secret information?
homomorphic encryption This is an active area of research, especially among folks
aiming to do machine learning on encrypted data. A homomorphic encryption
scheme allows mathematical operations to be done on encrypted data securely
while also guaranteeing that a corresponding operation is done on the underlying
plaintext. More specifically, the encryption of an input x can be turned into
the encryption of an input f (x).
Interestingly-enough, RSA is homomorphic under multiplication. Consider two
messages encrypted under the same public key:

c1 = me1 mod N c2 = me2 mod N

Calculating their product also calculates the product of their plaintexts:

c1 · c2 ≡ me1 · me2 ≡ (m1 · m2 )e (mod N )

Recently, there has been a fully-homomorphic encryption scheme designed to

work with arbitrary f s, but it is still impractical for general, applied usage.
searchable encryption In this variant, clients can outsource their encrypted data
to remote, untrusted servers to perform search queries efficiently without re-
vealing the underlying data.

Kudrayvtsev 94
Digital Signatures

e need to discuss providing authenticity and integrity in the world of asym-

W metric schemes just like we did in the the symmetric key setting. As before,
we’ll ignore confidentiality and focus on these goals instead. In the symmetric world,
we used message authentication codes and hash functions; now, we’ll use signatures.

Notation Much like before, digital signatures schemes are described by a tuple
describing the way to generate keys, sign messages, and verify them:

DS = (K, Sign, Vf)

The sender runs the signing algorithm using the their private key, and the receiver
runs the verifying algorithm using the sender’s public key.
Correctness — For every message in the message space, and every key-pair that can
be generated, a signature can be correctly verified if (and only if) it was output by
the signing function. Formally,
$
∀m ∈ MsgSp and ∀(pk, sk) ←− K :
s = Sign (m, sk) ⇐⇒ Vf (m, s, pk) = 1

The signing algorithm can be randomized or stateful, but doesn’t have to be for
security. The message space is typically all bit-strings: MsgSp = {0, 1}∗ .

Comparison Interestingly, signatures offer a security advantage over MACs in one

specific case: non-repudiation. In the MAC case, the sender and receiver need to
share a secret key, meaning the receiver can now impersonate the sender. In the
signature case, however, there is no secret to share, so there is no impersonation risk.

12.1 Security Definitions

The idea behind security for digital signatures is similar to that of message authen-
tication codes, as we’ve already noted. There, we had the UF-CMA definition: an

95
CHAPTER 12: Digital Signatures

adversary shouldn’t be able to create a MAC that verifies a message unless it was
received from the oracle.
For signatures, we want to ensure the same principle: an adversary should not be
able to craft a valid signature for a message (that is, one verifiable by the oracle’s
public key) without the oracle signing it with its secret key.

pk

A Sign (sk, ·)

(m, s)

The only difference is that we no longer need a verification oracle, since anyone with
the signature, message, and knowledge of the public key should be able validate the
sender. Above, (m, s) is a message-signature pair such that m was never queried to
the signature oracle. The UF-CMA advantage is defined in the same way.

12.2 RSA
Fascinatingly, the math behind RSA allows it to be used nearly as-is for creating
digital signatures.

12.2.1 Plain RSA

Initially, all we do is apply the definition of encryption and decryption to correspond
to verifying and signing, respectively. In other words,

Algorithm Sign (M, (N, d)) : Algorithm Vf (M, s, (N, e)) :

if M 6∈ Z∗N if M, s 6∈ Z∗N ∨ M 6= se mod N,
return ⊥ return 0
return M d mod N return 1
Though this simple scheme appears effective, it is not secure under UF-CMA by
simple properties of modular arithmetic:
• Consider M = 1: the signature is 1d mod N = 1; thus, we can always return
(1, 1) as an adversary without querying the signing oracle whatsoever.
• Consider an arbitrary signature s. By the RSA property that mde = m, we can
recover the original message since we know that se mod N = m. Thus, we can
choose any signature s ∈ Z∗N , calculate its source message, and output the pair

Kudrayvtsev 96
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

as a forgery—no oracle needed.

• Finally, consider the multiplicative property of RSA. It’s useful for homomorphic
encryption, but is the kryptonite of signatures. Given two queried signatures
s1 , s2 for two distinct messages m1 , m2 , we can derive a novel message-signature
pair (m1 m2 mod N, s1 s2 mod N ) since:

s1 · s2 ≡ md1 · md2 ≡ (m1 · m2 )d (mod N )

All of these could be formalized into proper UF-CMA adversaries, but they are omit-
ted here for brevity; they should be very straightforward.

12.2.2 Full-Domain Hash RSA

What are the main pain points of plain RSA? Well, the flaws above were based
in modular arithmetic itself. To fix them, improving the previous simple scheme
and ensuring UF-CMA security, we will hash the messages before they’re signed to
eliminate these relationships.
Let H : {0, 1}∗ 7→ Z∗N be a hash function mapping arbitrary bit strings to our group
Z∗N . Then, FDH-RSA is defined as follows:

Algorithm Vf (M, s, (N, e)) :

Algorithm Sign (M, (N, d)) : y = H(M )
y = H(M ) if y e mod N 6= s,
return y d mod N return 0
return 1

Theorem 12.1. The FDH-RSA scheme is UF-CMA secure under the random
oracle model.
Specifically, let Krsa be a key generating algorithm for RSA and DS be the FDH-
RSA signature scheme. Then, let F be a forging adversary making at most qH
queries to its hash oracle and at most qS queries to its signing oracle. Then, there
exists an adversary I with comprable resources such that

Advuf-cma
DS (F) ≤ (qS + qH + 1) · Advowf
Krsa (I)

where owf refers to the strength of RSA as a one-way function—the ability to find
m given me without knowing the trap door d.

The intuition behind this result is worth understanding since it uses the random
oracle model which we’ve largely only alluded to previously. The proof proceeds by
leveraging the contrapositive as we’ve seen before: if an adversary F exists that can

Kudrayvtsev 97
CHAPTER 12: Digital Signatures

break UF-CMA on with FDH-RSA, then another adversary I can use F to break
RSA’s one-wayness. Let’s walk through how this happens.

Security Proof
In I’s case, it receives three values—the public key tuple (N, e) and the ciphertext
y = me mod N —and its goal is to find x. It models itself as the both the signing
and hash oracle for F. Given that F can crack UF-CMA security, it will return some
(M, H(M )d ), where M was never queried to the signing oracle. This means that we
know for a fact that F needs to make at least one query to the hash oracle (to hash its
forged M ); when this occurs, I will instead provide y as the hash value rather than
some “true” H(M ).1 The returned signature is then y d mod N , which is the original
message that was given as a challenge to I!
This devious plan has a little bit of resistance, though: it’s quite likely that F needs
to make legitimate queries to the signing and hashing oracles in order to form its
forgery M , yet I cannot emulate valid signatures! Or can it. . . ?
Recall the second trick we used to break UF-CMA for plain RSA: given an arbitrary
signature, we can derive its original message. Now, I will simply output random
signatures for queries to the oracle and track which messages resulted in which random
signatures. This way, it can respond with the same signature when given the same
message. Furthermore, this means it can respond with the correct legitimate hash
for a message: for a message m, its signature should be H(M )d mod N , so I uses
se = H(M ), since sed ≡ s (where s is the randomly-chosen signature for m).

Implication
Because of these additive factors, one needs many more bits to ensure the same level of
security. For example, to achieve the same security as a 1024-bit RSA key, one needs
3700 bits for FDH-RSA (assuming the GNFS is the best algorithm). In practice, this
advice is rarely followed because despite the theoretical bound, no practical attacks
exist.

12.2.3 Probabilistic Signature Scheme

To do better than the additive factors impacting FDH-RSA’s security, we can intro-
duce some randomness to the hash function; this is PSS. Specifically, we concatenate
the message with S bits of randomness before signing:

1
This is the key of the random oracle model: rather than computing the hash “locally” (i.e. using a
known hashing algorithm), the adversary F must instead consult the oracle which is controlled by
I, which doesn’t necessarily need to provide it with values consistent with the properties expected
by a scheme.

Kudrayvtsev 98
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Algorithm Sign (M, (N, d)) : Algorithm Vf (M, s, (N, e)) :

$
r ←− {0, 1}S Parse s as (r, x) where |r| = S
y = H(r k M ) y = H(r k M )
if y e mod N 6= s,
return y d mod N
return 0
return 1
This variant makes much stronger guarantees about security, adding only a small,
relatively-insignificant factor given a large-enough choice of S:

Theorem 12.2. The PSS scheme is UF-CMA secure under the random oracle
model with the following guarantees (where the parameters are the same as in
Theorem 12.1, and S is the number of bits of randomness):

(qH − 1) · qS
Advuf-cma
pss (F) ≤ Advowf
Krsa (I) +
2S

12.3 ElGamal

We can build a signature scheme from discrete log-based encryption schemes like
ElGamal just like we can with factoring schemes like RSA.
Recall that in the ElGamal scheme, we start with a group G = Z∗p = hgi where p
$
is a prime, and the secret key is just any group element x ←− Z∗p−1 . The public
key is then its corresponding exponentiation: pk = g x mod p. Then, we also need
a bitstring to group hash function as before, H : {0, 1}∗ 7→ Z∗p−1 . With that, the
signing and verification algorithms are as follows:

Algorithm Sign (M, x) : Algorithm Vf (M, (r, s), pk) :

m = H(M ) m = H(M )
$
k ←− Z∗p−1 if r 6∈ G ∨ s 6∈ Z∗p−1
r = g k mod p return 0
s = k −1 (m − xr) (mod p − 1) if pk r · rs ≡ g m (mod p)
return (r, s) return 1
return 0

Kudrayvtsev 99
CHAPTER 12: Digital Signatures

Correctness This likely isn’t immediately apparent, but when we recall that p − 1
is the order of Z∗p , it emerges cleanly:

pk r · rs ≡ g xr · g ks (mod p)
≡ g xr · g ks mod p−1 (mod p) see (10.1)
k(k−1 (m−xr)) now we can
≡ g xr · g mod p−1
(mod p) substitute for s
xr m−xr mod p−1
≡g ·g (mod p) cancel inverse
m
≡g (mod p) combine exponents

Security The security of ElGamal signatures under UF-CMA has not been proven,
even when applying the additional random oracle assumption that the other schemes
made. There are proofs for variants of the scheme that are not used in practice, but
(apparently?) they are “close enough” to grant ElGamal legitimacy.

12.4 Digital Signature Algorithm

The DSA scheme appears similar to the ElGamal scheme on the surface in the way
it signs messages, but it increases security by using a second prime q rather than
leveraging p − 1 and Property 10.1 as we did above.
First, it requires two primes p and q configured such that q divides p − 1 (we don’t
restrict q to be exactly half of p − 1, but safe primes are a popular choice). Then, we
p−1
have the group G = Z∗p = hhi and let g = h q so that g ∈ G has order q.2
$
As before, the private key is a random exponent, x ←− Z∗p , and the public key comes
from the generator, pk = g x mod p. With that, the scheme is defined as follows:

Algorithm Sign (M, x) : Algorithm Vf (M, (r, s), pk) :

m = H(M ) m = H(M )
$
k ←− Z∗q w = s−1 mod q
u1 = mw mod q
r = (g k mod p) mod q
u2 = rw mod q
s = k −1 (m + xr) mod q
v = (g u1 · pk u2 mod p) mod q
return (r, s)
if v = r
return 1
return 0

2
Recall that the order of a group element a is the smallest integer n fulfilling an = 1 (see para-
graph 10.3). In this case, it means g q ≡ 1 (mod p).

Kudrayvtsev 100
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Correctness As before, we can work through the math:

?
r=v
?
g k mod p ≡ (g u1 · pk u2 mod p) (mod q)
?
≡ (g mw mod q · pk rw mod q mod p) (mod q)
? −1 −1
≡ (g ms mod q
· pk rs mod q
mod p) (mod q)
? ms−1 mod q xrs−1 mod q
≡ (g ·g mod p) (mod q) pk = g x mod p
? −1 +xrs−1
≡ (g ms mod q
mod p) (mod q) combine exponents
? −1 (m+xr)
≡ (g s mod q
mod p) (mod q) factor out s−1
? −1 (m+xr))−1 (m+xr)
≡ (g (k mod q
mod p) (mod q) substitute s
? −1 )−1 a(ab)−1 = b−1 ,
≡ (g (k mod q
mod p) (mod q) here, a = mx + r
and b = k−1
?
≡ g k mod q mod p (mod q)
since k ∈ Z∗q , mod q
≡ g k mod p (mod q)  has no effect

This version of DSA works only with groups modulo a prime, but there is a version
called ECDSA designed for elliptic curves.

Security The security of DSA under UF-CMA was not proven until 2016 under the
hardness of discrete log and random oracle assumptions. The proof also confirmed
DSA’s superiority in terms of efficiency: a 320-bit signature has security on-par with
a 1024-bit signature in ElGamal.

12.5 Schnorr Signatures

There is yet another class of digital signature schemes called Schnorr signatures.
They are very similar to PSS, using both randomness and hashing for security.
We once again start with G = hgi, a cyclic group of prime order p. We have a bit-
string to integer hash function: H : {0, 1}∗ 7→ Zp , and our secret and public keys are
$
x ←− Z∗p and g x ∈ G (note the lack of mod here).

Kudrayvtsev 101
CHAPTER 12: Digital Signatures

Algorithm Sign (M, x) : Algorithm Vf (M, (R, s), pk) :

$
r ←− Zp m = H(M )
R = gr if R 6∈ G
c = H(R k M ) return 0
s = (xc + r) mod p c = H(R k M )
return (R, s) if g s = R · pk c
return 1
return 0

Correctness Notice the odd difference in this scheme: many values (like R) are
not calculated under a modulus. This makes correctness trivial to verify:

R · pk c = g r · (g x )c = g xc+r = g s 

Security The Schnorr signature scheme works on arbitrary groups as long as they
have a prime order. It has been proven to be secure under UF-CMA with the random
oracle and discrete log assumptions for modulo groups,3 and is as efficient as ECDSA
with a 160-bit elliptic curve group.

12.6 Scheme Variants

As with asymmetric encryption schemes (see section 11.8), there are a number of
variants on digital signatures schemes that are worth highlighting.
multi-signatures In this variant, several signers create a signature for a single mes-
sage in a way that is much more efficient than repeatedly using a generic signa-
ture scheme that isn’t meant for multiple signatures.
These schemes are used frequently in cryptocurrencies like Bitcoin to have multi-
party consensus on complex transactions.
aggregate signatures These are similar to multi-signatures, but the parties are all
signing different messages. These purpose of these schemes is still to do this in
a way that is more efficient than with standard one-user-one-message schemes.
threshold signatures This variant is designed to provide a method for group con-
sensus. A group of n users shares a public key, and each of them only has a
piece of the secret key. In order to sign a message, at least t ≤ n users need to
cooperate. We’ll allude to similar ideas later when discussing key distribution.

3
It’s worth noting that this security proof is pretty “loose.”

Kudrayvtsev 102
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

group signatures A group of users holds a single public key. Each user can anony-
mously sign messages on behalf of the group; their identity is hidden except
from the manager of the group who controls the joining and revocation of group
“members.” A similar variant called ring signatures drops the manager and
allows members to always be anonymous.
blind signatures This variant allows users to obtain signatures from a signer with-
out the signer knowing what it was that they signed. This may seem odd,
but is actually very useful in many applications like password strenghtening or
anonymizing digital currency (through a centralized bank, not cryptocurrency).

12.6.1 Simple Multi-Signature Scheme

Recall that the purpose of a multi-signature scheme is for many users to be able to sign
the same message efficiently. For this scheme, we will operate under the assumption
that we’re working in a group G = hgi for which the DDH problem is easy, and there’s
an efficient algorithm for it. Namely, Vddh [g, g x , g y , g z ] outputs 1 if z ≡ xy (mod |G|).
Our secret key in this context will be x ∈ Z|G| and the public key will be pk = g x .
To sign a message, we hash it and raise it to the x power (much like in FDH-RSA):
Sign (M, x) = H(M )x . To verify a message, we’ll run the DDH verification algorithm
as follows: Vf (M, s, pk) = Vddh (g, pk, H(M ), s).
Notice that pk = g x , H(M ) results in some g y since g is a generator, and s is g xy for
a valid signature based on the definition of Sign.
Now we’ll apply this to the multi-signature context. For demonstration, suppose we
have three users, each with their own key pair: (x1 , g x1 ), (x2 , g x2 ), (x3 , g x3 ). Given a
message m, each user signs the message as described above: we get s1 = H(m)x1 ,
s2 = H(m)x2 , and s3 = H(m)x3 .
The multi-signature is then the product of the individual signatures:
Y P
s∗ = si = H(m) i xi
i

Concretely for our example, s∗ = H(m)x1 +x2 +x3 . Our verification algorithm for multi-
signatures is:

Vf (M, s1 , s2 , s3 , pk1 , pk2 , pk3 ) = Vddh (g, pk1 pk2 pk3 , H(M ), s∗ )

Notice that the DDH scenario is fulfilled for a valid signature:

pk1 pk2 pk3 = g x1 +x2 +x3

H(M ) = g y
s∗ = g y(x1 +x2 +x3 )

Kudrayvtsev 103
CHAPTER 12: Digital Signatures

The efficiency of the multi-signature signing and verifying algorithms is apparent:

for n users, rather than n verifies, we only need to do a single verify (note that we
still need n + 1 signs). The cumulative verification only requires some additional
multiplications which are much faster than exponentiations.

12.6.2 Simple Blind Signature Scheme

Recall that the purpose of a blind signature scheme is for users to be able to get
signatures from an authority without the authority knowing what they signed.
Our authoritative signer will be S, with the RSA public key pk = (N, e) and the
secret key d. We’ll also have a hash function H as we’ve been using in this chapter:
it maps from arbitrary bit-strings to a value in the group ZN .
$
Our user U wants to get a message m signed. They choose a random value r ←− Z∗N
and submit (H(M ) · re ) mod N to the signer S. The signer will follow normal RSA
signing algorithm and return the signature s = (H(M ) · re )d mod N . Notice, though,
that red ≡ r (mod N ), so the user can obtain a signature on the original message by
applying the inverse r−1 :

r−1 · s = r−1 · (H(M ) · re )d mod N )

= r−1 · (H(M )d · r mod N )
d
= H(M ) mod N

Neither M nor H(M ) was revealed to the signer at any point: r is a random number,
and a meaningful value multiplied by a random number still looks like a random
number. Further, this scheme can be proven to be unforgeable.

12.7 Signcryption
Our final asymmetric construction—a primitive called signcryption—will achieve all
three of our security goals: message confidentiality (contents are private), integrity
(contents are unchanged), and authenticity (contents are genuine).
To fulfill these requirements, a simple asymmetric scenario is not enough: now, both
the sender and the recipient must have public key pairs. As such, signcryption must
be considered in the multi-user setting. Our notions of integrity from symmetric
cryptography (see INT-CTXT) and privacy (IND-CCA and friends) transfer over in
a similar fashion.
Though additional attacks need to be considered (one called “identity fraud” that
wasn’t present in the separate encryption or signature worlds), the security result is
reminiscent of the one for Hybrid Encryption:

Kudrayvtsev 104
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Property 12.1. If an encryption scheme is IND-CPA secure and a signature

scheme is SUF-CMA secure, then the encrypt-then-sign signcryption scheme
is IND-CCA and INT-CTXT secure in the two-user model.

This new SUF-CMA security notion (S = strongly) is stronger than UF-CMA. It’s
satisfied by all practical schemes, and is equivalent to UF-CMA for deterministic
schemes. The encrypt-then-sign construction is exactly what it sounds like: first, we
do encryption (see schemes in the previous chapter), then sign the result.
To achieve security in the multi-user model, users need to take extra precautions: add
the public key of the sender to the message being encrypted, and add the public
key of the receiver to the message being signed.

Kudrayvtsev 105
Secret Sharing

n this final chapter, we’ll discuss the various nuances in how crucial information
I that we’ve been relying upon in the previous chapters is distributed. This includes
things of authenticating public keys, securely sharing secrets among groups, and using
session keys. We’ll also briefly discuss some potpourri topics like passwords and PGP.

13.1 Public Key Infrastructure

The big assumption in the world of asymmetric encryption is that there’s a trusted
public key infrastructure (or PKI) that somehow securely provides everyone’s
authentic public keys. Without this assumption, we’re back at the key distribution
problem: how do we obtain Bob’s key in the first place, and furthermore, how do we
know that what we obtained truly is Bob’s public key? In this section, we’ll discuss
how PKI is designed and utimately see the unfortunate fragility of cryptography in
the real world.
Public key infrastructure relies on a trusted third party as a “starting point” for
verifying key authenticity. This is called the certificate authority or CA for short.
The first “gotcha” of this design is immediately apparent: we must start by assuming
that the public key of the CA is known and trusted by everyone. Though this can
generally be guaranteed1 simply by hard-coding a list of public keys in the software
itself.

13.1.1 Registering Users

Suppose a user, who knows the CA’s public key pkCA , wants to register their own
public key pkU with the CA so that others can send them message. They first need
some sort of identity—this could be an email, a domain name, a username, etc.—
which we’ll call idU to associate with their public key. They also need a secure
1
. . . by a small leap of faith that your software download is genuine, which can usually be made
easily, since you start with a browser provided by your operating system, and since you (hopefully)
installed it from a disk OR somehow got it from a source that installed it from a disk. . . The
chain of trust can be very, very deep, but regardless, at some point we are relying on the physical
distribution of genuine data to fully guarantee authenticity.

106
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

communication channel with the CA, which can be achieved by any asymmetric
scheme since pkCA is known. Registration is then done as follows:
• The user sends (idU , pkU ) to the CA.
• The CA needs to verify that the user truly knows the associated secret key, so
it generates and send a random challenge R for the user to sign.
• The user signs and sends the challenge, s = Sign (skU , R).
?
• Finally, the CA checks the validity of the signature: Vf (pkU , s) = 1.
After the CA determines that this is a genuine user, it issues a certificate: a collection
of information about the user that is signed by the CA itself:

certU = Sign (skCA , (idU , pkU , expiration, . . .))

The user can obviously verify the validity of the certificate as a sanity check. Now,
they can present the certificate to anyone who requests their public key to show that
it is genuine and authentic: the recipient simply independently verifies the certificate
against pkCA .

13.1.2 Revocation
The certificate authority does more than act as an authentic repository of public
keys. It also handles key revocation: if a user’s key is compromised, rotated, or
otherwise no longer trusted before its expiration date, they can notify the CA who
will update its certificate revocation list (CRL) accordingly. This list is public, and
anyone verifying a certificate should ideally cross-reference it against this list.
Practically, though, users will instead download a copy of the CRL periodically. Nat-
urally, this human-dependent element has a flaw: between the time of key compro-
mise, revocation, and updated CRL, the attacker wreak havoc impresonatingn the
user, signing and encrypting malicious messages.
Shockingly, 8-20% of all issued certificates are revoked. This means CRLs can grow
very large and unweildy; recovation is one of the biggest pain points of widespread
PKI adoption.

OCSP The on-line certification status protocol, or OCSP, is a method to enable

realtime checks of whether or not a certificate has been revoked. To verify certalice ,
Bob passes it along to the CA immediately. Of course, this kind of defeats the purpose
of certificates in the first place, since Bob simply could’ve acquired Alice’s public key
from the CA directly.

Kudrayvtsev 107
CHAPTER 13: Secret Sharing

13.1.3 Scaling (or, as I like to call it, the CA house of cards)

In order to avoid overwhelming a single centralized authority with certificate requests

and CRL queries, in practice we have a hierarchy of certificate authorities. At the top
is the “root” CA, and it delegates responsibility (and trust) to “local” CAs to handle
issuing and revoking certificates. The verification process then involves following and
validating the chain of trust up until the final root CA signature. The X.509 protocol
is the industry standard for this process.
Naturally, if any of these “trusted” CAs (of which there are hundreds, see the study
by Fadai et al.) is breached or its algorithms compromised, it has massive implications
for: anyone who had their certificates signed by the CA, any downline CAs that were
“ordained” by the CA, and any new certificates that are maliciously signed by the
CA after the compromise.

13.1.4 An Alternative: Pretty Good Privacy

The PGP protocol is an attempt at building PKI without relying on centralized
certificate authorities. In this model, there is a web of trust: when you get Alice’s
key from Carol, its authenticity is directly correlated with your trust in Carol.
This model obviously requires user involvement, and is just as fallible to compromise
as the CA-based approach. The difference is in the implicit trust of hundreds of CAs
that your browser and OS “approve” versus the explicit trust of members of your web.

13.2 Secret Sharding

We briefly discussed signatures in the multi-user setting (refer to most of the methods
in section 12.6). Consider now the idea of splitting and distributing a single secret
among a group of users with the following goals:
• only a consensus of some minimal collection of users results in the derivation of
the original secret, and
• no partial information about the secret is gained from collusion without full
participation.
In other words, given a secret k shared among n users, any consensus of less than t
users results in no information about k, while consensus of at least t users enables
derivation of k. This prevents the secret from being compromised even if t − 1 devices
/ users / etc. are compromised and conspire maliciously.
We’ll denote this as a (t, n) sharing scheme.

Kudrayvtsev 108
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

13.2.1 Shamir’s Secret Sharing

Recall from geometry that a line is uniquely defined by two points. When given
just one point, there’s an infinite number of lines that pass through it; the single
point gives you no information. A parabola can be uniquely defined by three points:
we get a system of three equations for each of the three unknowns in the parabola
ax2 +bx+c = y. Any number of parabolas could be designed to pass through just two
of the points. For a third-degree polynomial, we’d need four points for uniqueness,
and so on. . .
This is the intuition behind Shamir’s secret sharing scheme:2 we can achieve a
(t, n) sharing scheme by forming an (t − 1)th -degree polynomial and distributing n
evaluations of it to the participants. Any t points will uniquely describe the polyno-
mial.

Protocol
Let’s describe the (t, n) scheme formally. We first choose p to be a large prime, and
our secret is any z ∈ Zp . Then,
• Choose t − 1 random elements: a1 , a2 , . . . , at−1 ∈ Zp .
• The secret will be denoted a0 = z.
• Now, view these elements as coefficients of a polynomial:
f (x) = a0 + a1 x + a2 x2 + . . . + at−1 xt−1

• Create n shares by evaluating f (x):

yi = f (i)
For simplicity, we can evaluate them on i = 0, 1, . . . , n, but we can also choose
random locations, instead.
To recover the secret, we use Lagrange interpolation from the set S of any t points:
!
X Y −i X
z = a0 = f (0) = yi · = y i ci
i∈S j∈S,j6=i
i − j i∈S

This scheme is unconditionally secure: given any t − 1 shares, we gain no information

about the secret, yet with t shares we recover z in its entirety.

Weakness
Unfortunately, there’s a fundamental flaw in this scheme: if any parties cheat during
reconstruction, the true secret cannot be recovered and there’s no way to detect
cheating; verifiable secret sharing schemes are designed to get around this problem.
2
This is the same Shamir who is the “S” in RSA!

Kudrayvtsev 109
 CHAPTER 13: Secret Sharing

13.2.2 Threshold Schemes

It may be desireable to allow the group to perform operations involving the secret
key without holding it in its entirety. We alluded to this when discussing thresh-
old signatures, but a similar principle can be applied to encryption. The party can
combine partial shares, encrypted with their respective partial keys, to form a full,
properly-encrypted ciphertext using the full secret key without ever actually recon-
structing it. For example, you can easily create a thresholded secret sharding scheme
Lipmaa, ‘04 from ElGamal encryption that we’ll call threshold ElGamal.

Remember, you First, let’s briefly recall how ElGamal works. If the public keys of the sender and
can usually click receiver are S = g s and R = g r , respectively, and m is the intended message, then
a term to jump the sender sends the pair (v, c) = (S, m · Rs ). The recipient then decrypts via the
back to its first
usage. inverse (v r )−1 , since c · (g rs )−1 = m.
For the thresholded case, we craft our secret using Shamir’s scheme, above. Namely,
we denote α as our secret, create a polynomial, and distribute its n distinct evaluations
as the
Pnsecret shards s1 through sn . Thus, the Lagrange interpolation tells us that
α = i=1 ci si for some set of ci s.
The secret is broadcasted by masking it as a public key: h = g s . This is now the
entire group’s public key, but they don’t know s. Each member then commits to their
share of s by broadcasting hi = g si .
The group can now collaborate to decrypt secrets encrypted by s without ever learning
it. Specifically, consider the pair (v, z) = (g r , mhr ), some message m encrypted under
an arbitrary g r for the group.
Each member Ai broadcasts wi = vis . Then, one of the servers3 (or some trusted third
party) can combine these pieces to recover the plaintext as follows:
z z
m = Qn ci =
i=1 wi w1c1 · w2c2 · . . . · wncn

Again, here the ci s are the coefficients from Lagrange interpolation. Notice that at
no point in time was it possible to derive the original secret, s, only the “safe” value
h = g s is possible to derive (see the correctness proof, below).

3
We’ll proceed by assuming that all of the members are trustworthy, but at this point, they could’ve
used a zero-knowledge proof to demonstrate that dlogg (hi ) = dlogv (wi ). This would prove to the
other participants that we used the share si rather than some other value to generate wi .

Kudrayvtsev 110
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Quick Maffs: Proof of Correctness

We can show that the decryption method in ElGamal thresholding really

does result in the original plaintext P
by reducing it down to the underlying
Lagrange interpolation: remember, ni=1 ci si = s by construction.
z z z
Qn = = Pn s
i=1 wi v s1
· v s2
· ... · s vn
v i=1 i
mh r mg sr
= r Pn s = r Pn s = m 
g i=1 i g i=1 i

13.3 Man-in-the-Middle Attacks

Consider as a case study the Diffie-Hellman key exchange protocol we discussed ear-
lier. Alice and Bob want to communicate securely: Alice sends Bob a public key
A = g a , while Bob sends her B = g b . Together, they can form the mutual secret
k = g ab without revealing the private exponents a and b (neither to the world nor to
each other).
If we presume the computational Diffie-Hellman and decisional Diffie-Hellman prob-
lems to be hard, this is secure against passive, eavesdropping attackers.4
All of the asymmetric schemes we’ve discussed thus far are unfortunately only secure
against passive attackers: attackers who can eavesdrop on, but not modify, messages
between parties.
However, consider what happens when the messages are routed through an active
attacker, Mallory, who can modify messages as she sees fit. She could take the form
of a compromised server, a hacked Internet service provider, a government wire-tap,
etc. When she sees Alice transmitting g a , she instead transmits to Bob a malicious
g m1 . Similarly, she transmits g m2 to Alice instead of Bob’s g b .
A = ga A0 = g m 1

Alice Mallory Bob

B 0 = g m2 B = gb

Now, Bob forms the secret g bm1 , and Alice forms the secret g am2 . It seems like they
can’t communicate effectively: attempting to decrypt Alice’s messages with Bob’s
secret would result in gibberish or failure! However, if Mallory continues to facilitate
communication, she can ensure that Alice and Bob receive valid ciphertexts while

4
Note that even though the DDH problem is not hard under Z∗p , it’s still often used in practice.
This is because of a small modification that enables provable security of the secret: the true mutual
secret is instead the hashed g xy .

Kudrayvtsev 111
CHAPTER 13: Secret Sharing

also reading the plaintexts in-transit.

When Alice sends Bob a message encrypted under g am2 , Mallory decrypts it, then
re-encrypts it using g bm2 (and vice-versa for Bob’s messages to Alice). This is called
a man-in-the-middle attack, and it leads to an unfortunate conclusion:

Property 13.1. Asymmetric key exchange schemes cannot be made secure against
active attackers when starting from scratch.

An a priori information advantage against Mallory is required, and it often comes

in the form of long-term keys: the hope is that Mallory is not ever-present on the
communication channel.

13.4 Passwords
Despite all of the fantastic, provably-secure cryptographic methods and schemes we’ve
studied in the last 112 pages, human-memorable passwords remain the weakest link
in many security architectures.
Dictionary attacks—brute force methods that simply compare dictionary-like pass-
words against the hashes of a compromised server—are still very effective.5 Studies
show that despite of efforts to complicate requirements (which are in and of them-
selves largely ineffective, see Figure 13.1), many passwords are still just words in the
dictionary.
The key to a secure future is simply to move away from passwords: the Fast ID Online
alliance is moving towards an ambitious idea of secure authentication based on secure
devices (“something you have”) and biometrics (“something you are”) rather than on
passwords (“something you know ”).

5
Note that “salting” a password hash—appending and storing a random value so that identical
passwords have different hashes, H(p k r1 ) 6= H(p k r2 )—only helps against mass cracking of
compromised passwords. They have no bearing on the time it takes to crack a specific user’s
password.

Kudrayvtsev 112
APPLIED CRYPTOGRAPHY Asymmetric Cryptography

Figure 13.1: The classic XKCD comic demonstrating the futility of memorizing
“complex” passwords which have low entropy relative to the ease of long passwords
that are far harder to guess.

Kudrayvtsev 113
 Epilogue

hough we’ve covered many foundational concepts in applied cryptography at

T length—ways to ensure confidentiality, integrity, and authentication in both the
symmetric and asymmetric setting; security definitions; proofs of correctness and
security; and more—there are still many advanced topics we’ve left out:
• secure multi-party computation: this primitive allows two or more parties to
mutually compute some information while keeping their independent inputs
private.
Wikipedia The classic example of MPC is Yao’s millionaire problem, in which two
rich people want to determine which of them is richer without revealing their
net worth to the other. There is also the simpler, more-intuitive socialist
millionaire problem, in which two rich people simply want to see if they have
the same net worth.
• zero-knowledge proofs: this related primitive allows someone (the “Prover”) to
prove that they have a solution to a particular problem to someone else (the
“Verifier”) without revealing anything about the solution itself.
• Merkle trees and the blockchain: these are the founding cryptographic primi-
tives powering many cryptocurrencies.
• post-quantum cryptography: if quantum computers continue to increase in
their computational capability, they will completely break asymmetric schemes
that rely on the hardness of the discrete log problem by turning it into a
polynomial-time operation.
Many innovations have rised to combat this threat: novel, quantum-resistant
cryptographic schemes are often based on lattices, which are a mathematical
construct that I don’t (yet) understand.
I cover most of these topics in Part III, but the content comes from independent
research rather than professionally-curated content.
At the end of the day, the content we’ve learned in this course should let you analyze
the efficacy of security protocols you encounter in the wild, though it’s still universally-
advised that rolling your own low-level cryptographic primitives is not a good idea.

114
PART III
Advanced Topics

his part of the guide is dedicated to advanced topics in cryptography that I’ve
T been researching myself recently out of interest. It has no relation to the official
course content. It’s worth noting that log n in this section refers to the discrete
logarithm under base 2, so log 8 = log2 8 = 3.

Creation of this entire set of notes was powered exclusively by

caffeine in its many forms. If you found it useful and are gener-
ously looking to fuel my stimulant addiction, feel free to shoot me
a donation on Venmo @george_k_btw or PayPal kudrayvtsev@
sbcglobal.net with whatever this guide was worth to you.

Happy studying!

Contents
15 Secure Cryptographic Primitives 116

16 Commitments 124

17 Random Oracle Model 127

18 Zero-Knowledge Proofs 130

19 Multi-Party Computation 139

20 Elliptic Curves 141

115
Secure Cryptographic Primitives

hough we’ve covered the fundamental primitives of cryptography—things like

T block ciphers, pseudorandom functions, hash functions, and one-way functions—
at length in the “main” portion of this text, in this chapter we’ll go over the founda-
tions in more formal detail. Specifically, we’ll start with a very important, specific
fact: one-way functions (OWFs) are the fundamental primitives that pro-
vide security. In other words, the very existence of one-way functions is equivalent
to the existence of cryptography. From OWFs, we can derive the chain of primitives
we’ve been using via transformations:

OWFs ; PRGs ; PRFs ; PRPs =⇒ Authenticated

Encryption

It’s worth noting that even though the transformations from one primitive to another
exist (and we’re about to go over them) and are efficient (i.e. polynomial-time),
they’re largely impractical and unweildy. Their purpose is to fundamentally prove
that security is possible: if OWFs exist, then PRPs exist, which means we can
build schemes that have extremely high levels of security. In practice, we craft specific
primitives for our needs. Instead of actually deriving pseudorandom permutations
from one-way functions, we directly assume that AES is a valid PRP (see the AES
security bounds described much earlier in (3.2)). Still, the following are important
derivations for a deepening our theoretical understanding of cryptography.

As always, this is a synthesis of other resources, so feel free to refer to the Refer-
ences themselves (organized in a subjective order of “easy-to-read”ness) for further,
alternative explanations.

15.1 Step 1: OWFs ; PRGs

Here are a handful of candidates for one-way functions, some of which we’ve seen and
studied at length:
• f (x, y) = x · y, where x and y are equal-length primes (factoring, RSA).
• fp,g (x) = g x mod p, where g is a generator of Z∗p (discrete log, Diffie-Hellman).

116
APPLIED CRYPTOGRAPHY Advanced Topics

• The subset-sum problem1 —finding a subset of values that sum to a target

value—can also be formed into a OWF:
X
f (x1 , . . . , xn , S) := (x1 , . . . , xn , xi )
i∈S

From a one-way function f , we can create a one-way permutation (OWP) by con-

struction. For any natural number, using f to map bits:

∀n ∈ N : f : {0, 1}n 7→ {0, 1}n

will be a one-way permutation. Given an OWP, our goal is going to be to create a

pseudorandom function (PRF).

15.1.1 Extension by 1 Bit

The “plan of attack,” so to speak, to derive an OWP is as follows:

OWP ; stretch 1 PRG ; stretch n PRG ; PRF

What does “stretch 1” mean? It quite literally means extending the OWP to contain
one more bit of (pseudo)randomness:

S =⇒ f (S) b(S)
| {z } | {z } | {z }
n bits n bits 1 bit

The first n output bits will be uniformally (“truly”) random, while the latter appended
bit b(S) should “look” random.2
How can we acquire such a bit? It’s entirely possible to have a OWF with a predictable
bit—consider the trivial construction of just appending the first bit to a true OWF:

f (x1 , . . . , xn ) = x1 k g(x2 , . . . , xn )

But this obviously can’t be done for all OWFs or all bits of its output. It’d be helpful
for us to first define which bits of the OWF are “hard” or “easy” to predict:

Definition 15.1: Hardcore Predicate

We say that the Boolean function b : {0, 1}∗ 7→ {0, 1} is a hardcore pred-
icate of a function f : {0, 1}∗ 7→ {0, 1} if:

?
1
This is a computational problem often discussed in the context of P 6= NP; see my notes on the
topic for a deeper discussion if you’re interested.
2
“Looking random” means being computationally indistinguishable from truly random output, as
we’ve discussed at length when talking about Random Functions given f (S).

Kudrayvtsev 117
CHAPTER 15: Secure Cryptographic Primitives

• b(x) can be computed efficiently (in polynomial time) given x, and

• for all PPTa adversaries A, the chance of “guessing” b’s output when
given f (x) is negligible:
1
Pr [A (f (x)) = b(x)] ≤ + negl(n)
$
x←−{0,1}n
2
a
PPT algorithms take probabilistically-polynomial time, so basically are usu-
ally done in polynomial time. Examples include things we’ve already studied,
like the randomized algorithm for Generating Primes.

To put it simply, a “hardcore bit” in an OWF’s output is one that cannot be reliably
predicted. Under the contrived f and g above, the first bit x1 would not be a hardcore
bit; the other bits provide a reliable source of unpredictability.

Theorem 15.1 (Goldreich-Levin). Every one-way function f has a hardcore

predicate bit.

Proof. The full proof can be found online, [14,13] but its basic idea is that a random
linear combination of the bits of x should be hard to compute. First, we can extend
the function to be
g(x, r) = (f (x), r) where |x| = |r|

Under this extension, g is still one-way. Then, we can derive a b that fits the definition
of a hardcore predicate as follows:
n
X
b(x, r) = hx, ri = xi · ri mod 2
i=n

That is, we take the inner product modulo 2 for any bitstrings x, r ∈ {0, 1}n . This
predicate will always be hardcore. 

With the Goldreich-Levin theorem guaranteeing the existence of a hardcore bit, we

can now easily fulfill our goal of a “1-bit stretch” PRG by simply appending said bit.

Theorem 15.2. Let f be a one-way permutation with the hardcore bit b. Then,

G(S) := f (S) k b(s)

is a 1-bit stretch PRG.

Proof. We proceed by contradiction.

Kudrayvtsev 118
APPLIED CRYPTOGRAPHY Advanced Topics

(This is a long and arduous proof; understanding it is

recommended simply for edification but isn’t required.)

Suppose there exists a PPT adversary A and a non-negligible E(n) such that
 
 
 Pr [A(G(S)) = 1] − Pr [A(r) = 1] ≥ E(n) (15.1)
 
$ n $
r←−{0,1}n
S ←−{0,1} 

That is, the adversary can reliably differentiate between random bits and bits gener-
ated by the PRG.

Claim 15.1. We first claim the following is true:

1  

· Pr [A (f (S) k b(S)) = 1] − Pr A f (S) k b(S) = 1  ≥ E
2 S S

$
where b := 1 − b (e.g. the flipped bit) and S ←− {0, 1}n as before (e.g. random
n-bit string).

Proof. We prove this by first rewriting the distribution of random bit strings,
$
r ←− {0, 1}n :
( ( $
)
n
$ n+1
o r1 ←− {0, 1}n
r : r ←− {0, 1} ≡ r ← r1 k r2 : $
r2 ←− {0, 1}
( ( $
)
S ←− {0, 1}n
≡ r ← f (S) k r2 : $
r2 ←− {0, 1}
( ( $
)
S ←− {0, 1}n
≡ r ← f (S) k r2 : $
r2 ←− {b(S), b(S)}
≡ {r ← f (S) k b(S)} or r ← f (S) k b(S)

w/ prob. 1/2 each

Thus, the adversary’s chance of a correct guess can be expressed as the sum of
the chance of the two individual guesses:
1 1
Pr [A(r) = 1] = · Pr [A(f (S) k b(S)) = 1] + · Pr A(f (S) k b(S)) = 1
 
r 2 S 2 S

Plugging this into (15.1) proves the claim:

 
E ≤ Pr [A(G(S)) = 1] − Pr [A(r) = 1]
 
S r

Kudrayvtsev 119
CHAPTER 15: Secure Cryptographic Primitives

 
1 1
≤ Pr [A(G(S)) = 1] − · Pr [A(f (S) k b(S)) = 1] − · Pr A(f (S) k b(S)) = 1 
  

S 2 S 2 S
 
1 1
≤ Pr [A(G(S)) = 1] − · Pr [A(G(S)) = 1] − · Pr A(f (S) k b(S)) = 1 
  
S 2 S 2 S
 
 1 1
≤ − Pr [A(f (S) k b(S)) = 1] − Pr A(f (S) k b(S)) = 1 
 
2S 2S
1   
≤ · Pr [A(f (S) k b(S)) = 1] − Pr A(f (S) k b(S)) = 1 

2 S S


With this claim proven, we can now construct an adversary B that can break the
hardcore bit b (that is, predicts b(S) from f (S)). Given the input y = f (S) ∈ {0, 1}n ,
$
• Choose a random bit, c ←− {0, 1}.
• Run A(y k c), then:
– If A outputs 1, we output c.
– Otherwise, output c.
What’s the success rate of our constructed adversary B?
1
Pr [B(f (S)) = b(S)] = · Pr [B(f (S)) = b(S)) | c = b(S)] +
S 2 S,c
1
· Pr B(f (S)) = b(S)) | c = b(S) Law of Total
 
Probability
2 S,c
1  
· Pr [A(f (S) k b(S)) = 1] + Pr A(f (S) k b(S)) = 0

=
2 S S
by con-
struction
1  
= · Pr [A(f (S) k b(S)) = 1] + 1 − Pr A(f (S) k b(S)) = 1

2 S S
by
definition
1 1  
= + · Pr [A(f (S) k b(S)) = 1] − Pr A(f (S) k b(S)) = 1

2 2 S S
1 by Claim
≥ +E 15.1
2

Thus, we’ve constructed an adversary B that can reliably break the hardcore bit b,
which contradicts the definition of b being a hardcore bit. By this contradiction, the
efficient adversary A cannot exist. 

Whew. That was really something. If your eyes glazed over the minute you read
the word Proof., don’t worry. The important part was the theorem itself: we can
stretch a PRG by one bit using the hardcore bit that Goldreich-Levin has
guaranteed to exist.

Kudrayvtsev 120
APPLIED CRYPTOGRAPHY Advanced Topics

15.1.2 Arbitrary Extension

With that crucial result, this section will be far simpler. Once we can stretch by
a single bit, stretching by an arbitrary number of bits (also called a “polynomial
stretch”) is trivial. This is done in the Blum-Micali pseudorandom generator as
follows:
• Let G : {0, 1}n 7→ {0, 1}n+1 be a PRG, and `(n) be a polynomial.
• From this, we construct G0 : {0, 1}n 7→ {0, 1}`(n) on the input S ∈ {0, 1}n like
so:
– Set S0 = S.
– Then, for i = 1, 2, . . . , `(n), let Si bi = G(Si−1 ).
– Finally, output b1 b2 · · · bn .
To put it simply, we preserve the single stretched bit every time we call the PRG.
Visually, it would look like this:

S0 S1 S2 ··· S`−1 S`
G G G

b1 b2 b`−1

It should come as no surprise that this diagram is nearly identical to the stateful
generator visualized in chapter 7 when we discussed how PRGs are used. Our use of
Si makes sense now: it’s the state of the generator, and bi are obviously the output
bits.

15.2 Step 2: PRGs ; PRFs

Given our construction of a secure pseudorandom generator, we now move on to
the next step of our theoretical framework which is creating a secure pseudorandom
function.
Suppose we have a length-doubling PRG (perhaps securely constructed by Blum-
Micali, above),
G : {0, 1}` 7→ {0, 1}2`

We can also write G(s) → (s0 , s1 ) as the pair (G0 (s), G1 (s)). That is, when operating
on the input s, G0 is the “first half” of the output and G1 is the “second half.”

Kudrayvtsev 121
CHAPTER 15: Secure Cryptographic Primitives

Claim 15.1. Under this construction, G can be viewed as a secure PRF in the
following form:
F : {0, 1}` × {0, 1} 7→ {0, 1}`
| {z } | {z } | {z }
key single-bit range
domain

In other words, F (s, 0) would treat s as the key and 0 as the input bit, mapping to
an `-bit (pseudo)random bitstring: G0 (s), and likewise for F (s, 1) = G1 (s).
Obviously, having a single-bit domain is not an ideal limitation. The key question is
then: how do we generalize this to an arbitrary domain?
The answer can be found by looking outside: trees! Our construction will look some-
thing like this:


F (s, x1 x2 · · · xn ) = Gxn Gxn−1 (. . . Gx1 (s) . . .)
| {z }
input bits

This is known as the Goldreich-Goldwasser-Micali construction (or GGM); for

n = 2, it visually breaks down into single-bit compositions as follows:

S0 = G0 (S) S1 = G1 (S)

S00 = G0 (S0 ) S01 = G1 (S0 ) S10 = G0 (S1 ) S11 = G1 (S1 )

F (S, 00) F (S, 01) F (S, 10) F (S, 11)

The proof that this results in a secure PRF can be found in Ch. 4.6 of Boneh &
Shoup’s book. [3]

15.3 Conclusion
Almost every larger cryptographic construct in Part 1 relies on the existence of a
secure PRF, which we just showed how to create from nothing but a secure one-way
function. We know that functions that are “hard to invert” exist (and we’ve shown
various bounds for them), but fundamentally proving that there’s no algorithm that
can achieve a non-negligible advantage remains an open question.

Kudrayvtsev 122
APPLIED CRYPTOGRAPHY Advanced Topics

To reiterate, in practice we don’t use the transforms described above to go from OWF
; PRF, and instead rely on the security of AES to be a PRF (largely for efficiency
reasons), but the idea that if all else failed we could still construct secure primitives
is an assuring one.

15.3.1 References
1. Eskandarian, S., Kogan, D., and Tramèr, F. Basic primitives; From OWFs to PRGs
and PRFs. In Topics in Cryptography. ch. 1–2. [Online]
2. Trevisan, L. One-way functions. In CS 276. ch. 11. [Online]

3. Trevisan, L. Goldreich-Levin. In CS 276, J. Sherman, Ed. ch. 12. [Online]

4. Boneh, D., and Shoup, V. A Graduate Course in Applied Cryptography. January 2020.
[Online]

Kudrayvtsev 123
Commitments

aking commitments can be hard for humans, but actually pretty easy in cryp-
M tography. It’s a fundamental necessity in a lot of applications, such as zero-
knowledge proofs. In this (short) chapter, we’ll formalize the notion of a commitment
and work through some implementations.
A commitment allows one to commit to a particular message without revealing it,
like putting it into a locked box. Once committed, they can announce the key to
unlock the box and reveal the hidden message. Obviously, it should be impossible to
reveal a different message than the one committed. Similarly, the “locked box” should
reveal nothing about the message without the secret. Let’s formalize this.

16.1 Formalization
Define a function commit : M × R 7→ C, that is, a function that maps a message
space and some randomness to some commitment space. Then, commit(m, r) → c
commits m with the secret r to the commitment c. We “open” the commitment by
revealing (m, r).
A good commitment scheme holds the following properties:
• hiding: Whoever sees c learns nothing about m.
Much like with perfect security (2.1), we’ll use a statistical notion of hiding: the
commitment for m0 should be equally likely to have occurred for m1 . Specifi-
cally,

$
∀m0 , m1 ∈ M; r ←− R :
Pr [commit(m0 , r) = c] ≈ Pr [commit(m1 , r) = c]

• binding: After committing to c, it should be impossible to change m.

In contrast with hiding, this is a computational notion reminiscent of a hash
function being collision resistant. No PPT adversary should be able to produce

124
APPLIED CRYPTOGRAPHY Advanced Topics

m0 , m1 ∈ M and r0 , r1 ∈ R such that

commit(m0 , r0 ) = commit(m1 , r1 ) (where m0 6= m1 )

A couple of off-hand schemes that may come to mind that are are not commitments
include:
• just using a plain hash function H(x). Since the message space is public, the
hiding property isn’t preserved as someone could just enumerate all m ∈ M
and find the matching hash.
• just using AES directly by treating r as the key:
commit(m0 , r0 ) = AESr (m)

This is not a valid commitment scheme either, because despite fulfilling the
hiding property, it does not necessarily provide binding: you can have secure
schemes decrypt the same ciphertext to different messages depending on the
key.1

16.2 Pedersen Commitments

This scheme is a simple and efficient commitment scheme. The public parameters of
a Pedersen commitment are a group G with a prime order p. There are also two
group members, g, h ∈ G that are also public.2 The Pedersen commitment is then
defined as:
commit(m, r) := g m hr (where m, r ∈ Zq )

An interesting property of this scheme is that it is additively homomorphic: com-

mitments can be added together!
commit(m0 , r0 ) · commit(m1 , r1 ) = g m0 hr0 · g m1 hr1
= g m0 +m1 · hr0 +r1
= commit(m0 + m1 , r0 + r1 )

16.2.1 Proof of Properties

We can prove that this scheme has the hiding and binding properties formally.

Claim 16.1. The Pederson commitment scheme provides hiding because the com-
mitments are uniformally distributed in the group G.
1
https://crypto.stackexchange.com/a/72199
2
The discrete log between g and h should not be known, though I’m not entirely sure what that
means.

Kudrayvtsev 125
CHAPTER 16: Commitments

Proof. For any value m ∈ M, there is exactly one r such that c = g m hr . First, define
c = g a , h = g b (this is valid by the definition of the generator g); then,

c = g m hr =⇒ g a = g m · (g b )r = g m+br
=⇒ a = m + br
a−m
=⇒ r =
b

Since r is chosen uniformally at random, c could commit to any m. 

Claim 16.2. The Pederson commitment scheme provides binding under the hard-
ness assumption of the discrete log problem in the group G.
That is, given h ∈ G, it’s hard to find x such that h = g x .

Proof. As usual, we proceed by the contrapositive, showing that if we had an adver-

sary that could break binding on A, we could break the discrete log problem.
Consider the discrete log connection under binding:

g m0 hr0 = c = g m1 hr1
g m0 (g x )r0 = g m1 (g x )r1
m1 − m0
m0 + xr0 = m1 + xr1 =⇒ x =
r0 − r1

If A can break binding, by definition it would give us (m0 , r0 ) and (m1 , r1 ) that
generate identical commitments. Plugging them into the above relationship breaks
the discrete log challenge.
Thus by the contrapositive, if the discrete log problem is hard in the group G, the
Pederson commitment scheme is binding. 

Kudrayvtsev 126
Random Oracle Model

ur use of this security model has been prolific throughout the main text, but
O we never really dove into its intricacies and implications. Its general gist was
basically buried in a footnote, summarizing the basic idea into a single sentence: in
the random oracle model, the attacker controls hash function outputs. This
is generally unrealistic in practice, but forms a (controversial) theoretical framework
for evaluating a scheme’s security.
We build security models that are supposed to reflect reality; if we can prove some-
thing within that model (like a security bound), then it should hold true in the real
world. However, often we miss things in our model: consider the difference between
being IND-CCA secure and IND-CPA secure. We typically adjust models to better-
reflect the real world (often in response to the discovery of new security holes). Many
of our security proofs relied on the “standard model,” but others relied on the random
oracle model to prove security.
Fundamentally, as we already stated, the thing that differentiates the random oracle
model is that an oracle answers queries to hash function evaluations. In practice, we
replace the random oracle with a suitable hash function and call it secure. Otherwise,
imagining a cryptographic application calling out to an API server for hash function
evaluations feels. . . a little unrealistic.

17.1 An Amazing PRF

To (once again) demonstrate how the random oracle model works, and how it’s some-
times necessary to use in order to prove security, we’ll demonstrate that the following
hash function is a PRF:
f (K, x) = H(x)K

We’ll prove that f is PRF secure under the random oracle model assuming the hard-
ness of the decisional Diffie-Hellman problem. Recall the DDH assumption: for a
cyclic group G of order q and a generator g,
computationally
x y xy $ indistinguishable from $
g, g , g , g : x, y ←− Zq ←−−−−−−−−−−−→ g, g x , g y , g z : x, y, z ←− Zq

127
CHAPTER 17: Random Oracle Model

Our proof proceeds by the contrapositive: if an adversary A that breaks f exists,

it can be used by another adversary B to break DDH. Since this would violate the
hardness assumption of DDH, f must be PRF secure. Recall that being PRF secure
means differentiating between outputs from f and from a truly-random function.
Under this construction, B needs to respond to queries to f and/or H by A (note
that A is not given the secret, K). The trick of the random oracle model is that it
doesn’t need to actually use f or H: it can “program” the RO to respond completely
arbitrarily:

f (K, ·), H(·)

A oracle DDH params:
??? ?
X = g x , Y = g y , Z = g z=xy

Namely, the ??? above can be whatever B wants, and that’s exactly what B will
leverage to break DDH: B redefines the hash function:

H(m) :
$
α ←− Zq
return X α

It subsequently remembers the mapping of H(m) 7→ X α so that repeat calls work as

expected. Since this is still uniformally distributed across the group G, A cannot tell
it’s not from a “true” random hashing oracle. Similarly, B redefines f to set this fake
hash function accordingly:

f (K, m) :
$
α ←− Zq
H(m) := X α
return Z α

(Obviously, if you called H(m) before f (K, m), f would use the α from the H(m) call rather than
generating a new one.)

Notice that now for some arbitrary n, f (K, n) = g zα , and H(n) = g xα . If we’re given
z = xy, then evaluating f is equivalent to calculating g xyα , whereas if z is chosen
randomly, then evaluating f is equivalent to choosing a random group member, since
$
g zα ≡ γ ←− G.

Kudrayvtsev 128
APPLIED CRYPTOGRAPHY Advanced Topics

By definition, A breaks PRF security: it can differentiate between PRF outputs

and random outputs; in this case, that’s the difference between f outputting g xyα
with K = y (meaningful) versus γ (random). Regardless of how A actually makes
this distinction, B simply “passes along” this knowledge to break DDH. By the con-
trapositive, then, f is PRF secure.
In fact, this PRF is used extensively in the real world; we’ve already seen a slight
variant of it used in the FDH-RSA signature scheme. Furthermore, it makes for a
great commitment scheme.

17.2 Conclusion
The random oracle model is a heuristic model that often gives us simpler / faster
schemes than what we have in the standard model. Despite that, it’s possible to
craft some (contrived) schemes that are secure in the random oracle model but are
completely broken in the standard model regardless of the hash function being used.
The “trick” we used above in “programming” the oracle to return specific results
is controversial among cryptographers: such a model does not really reflect reality.
However, it’s undoubtedly a useful framework, and in some sense the best we can do
for certain schemes.
Remember that in practice, the oracle is just replaced with a specific hash function;
just don’t use SHA256! It (and any hash function reliant on the Merkle-Damgård
transform, actually) is vulnerable to length extension attacks (see this and this for
more on that).

17.2.1 References
1. Eskandarian, S., Kogan, D., and Tramèr, F. Commitments & the random oracle model.
In Topics in Cryptography. ch. 3. [Online]
2. Boneh, D., and Shoup, V. Random oracles: a useful heuristic. In A Graduate Course in
Applied Cryptography. January 2020, ch. 8.10.2, pp. 322—325. [Online]

Kudrayvtsev 129
Zero-Knowledge Proofs

he beauty of a zero-knowledge proof (or ZKP) is that one party can prove
T something to another without revealing any concrete information about the ac-
tual thing they’re proving. In other words, they prove knowledge of some fact without
revealing it.

This is a complicated concept from a mathematical standpoint, so this sec-

tion will have a lot of examples gathered from all over the Internet to entice
the development of an intuition about the topic.
Typically, resources on ZKPs take steps to extensively formalize the ideas
using concepts from computational complexity theory. We’ll be trying to
prove a statement from a language, x ∈ L, where the language is a par-
ticular set of strings, L ⊆ {0, 1}∗ . Though it’s convenient for purposes of
mathematical formality and precision, it requires a little too much outside
knowledge; I’ll try to avoid this kind of language whenever possible to keep
things simple.

18.1 Knowledge Proof

First, it’s worth covering the basic concept of a “knowledge proof.” In a proof of
knowledge, Alice is a prover aiming to demonstrate a solution to a problem, while
Bob is a verifier that can validate whether or not this is a valid solution.
The fundamental underpinning of this method is to use a problem that is difficult to
solve “on-the-fly.” Typically, we use something from the NP-complete complexity
class: by definition, these problems are computationally-expensive to solve yet cheap
to verify (polynomial-time algorithms for finding the solution don’t exist, but do for
verifying a solution’s validity).1 The prover claims to have solved a particular NP-
complete problem; then, the verifier chooses inputs to the problem at random. The

1
For a review of some of the problems within the NP-complete complexity class, I recommend both
the Computational Complexity chapter in my notes for Graduate Algorithms as well as Chapter 8
of the textbook, Algorithms, on which it’s based.

130
APPLIED CRYPTOGRAPHY Advanced Topics

key is that the prover can’t think of a valid solution on the spot without having truly
actually solved the problem already. It’s been shown, in fact, that any NP-complete
problem has a zero-knowledge proof formulation. [10]
In other words: the “knowledge” must be hard to compute but easy to verify.
This is what prevents “cheating” on Alice’s part.

18.1.1 Example: Factorization

The basis of a knowledge proofs is incredibly simple; we’ve seen plenty already.
As we know, finding the factorization of a number is considered “hard;” we’ve es-
tablished this as the very foundation of asymmetric cryptography. Suppose, then, a
Prover claims that she knows the factorization of some large RSA public key, N = pq.
The Verifier knows that this is a hard problem, and neither he nor the Prover should
be able to find p or q within a reasonable amount of time if they didn’t know something
about them a priori.
The proof of knowledge on the Prover’s behalf is simple: just reveal p and q. The
?
Verifier can then easily validate whether or not pq = N . This is the basis for any
knowledge proof: the solution is provided, and a simple algorithm verifies it.2

18.1.2 Formalization
Knowledge proofs are pretty easy to define formally. Let’s refer to a prover, Alice,
that actually has knowledge A∗ and prover-Alice that is faking the knowledge as A.
In general, the prover is A and can be either of the Alices. Our verifier, Bob, will just
be B.
The “problem” in question is the predicate P (Q, S), where Q is a challenge query
proposed by B and S is the solution output by A.
Formally, then, a verifier should act as follows:
1. If A = A∗ , B should accept its proofs with overwhelming probability for all q
for which P (q, S) is satisfiable.
2. If A = A, B should accept its proofs with negligible probability for all q.
To put it simply, B should accept all valid proofs from A∗ and reject all proofs from
A.

2
Note that problems within the NP-hard class don’t fall into this category: by their very definition,
it’s just as difficult to verify a solution as it is to find it. The asymmetry of NP-complete problems
are exactly what make these (non-)interactive knowledge proofs possible.

Kudrayvtsev 131
CHAPTER 18: Zero-Knowledge Proofs

18.2 Zero-Knowledge
A knowledge proof might reveal details about what Alice knows. In the above exam-
ple, obviously the secret information was revelaed to the prover. However, wouldn’t
it be nice if we could avoid divulging the secrets while simultaneously proving that we
know them? That would be a zero-knowledge proofs! In general, Bob should learn
nothing at all from Alice about her “truth” claim in a ZKP.

18.2.1 Example: Factorization

As before, an example of a knowledge proof could be Alice claiming to know the
factorization (p, q) of some number N = pq. The challenge comes from this: how can
Alice convince Bob that she really does know the factorization without revealing the
factors?
The solution comes from a correlated problem: finding Modular Square Roots. This is
considered to be equally-hard to factorization. The key is that Bob can “challenge”
Alice with arbitrary numbers in the group, and Alice must quickly return their roots.
Alice wouldn’t be able to find the roots of arbitrary values efficiently without knowing
the factorization.
The example from Modular Square Roots used small primes that are easy to brute
force, but it’ll suit our purpose for demonstration since all we need to do to make it
computationally-infeasible is use bigger primes.
Suppose Alice, the prover, claims to Bob to know a factorization for n = 143 (into
p = 13, q = 11). Bob, as the verifier, submits to Alice the following test:
If you know some pq = N = 143, what are the roots of 25, 100, 1000, and 2000?

Alice must compute these quicker than Bob can brute-force them. Alice calculates
the partial roots of each prime using brute force on the factors (not their product),
then of N via the Chinese remainder theorem. This can be done in polynomial time,
whereas brute force takes exponential time in the number of digits in N . Bob can
validate the roots trivially.
Of course, Bob may be suspicious of Alice’s ability to provide roots for just these 4
numbers (after all, she may have gotten lucky: there are only 143 possible values).
Bob can then test Alice again, over and over until he’s satisfied of her knowledge.
More formally, though there may some small chance that Alice can cheat and fake
her knowledge, with enough trials this chance gets closer and closer to zero. At no
point in time does Alice actually reveal p or q, yet Bob is satisfied that Alice knows
them simply because there’s no way for Alice to do this so efficiently without knowing
them.

Kudrayvtsev 132
APPLIED CRYPTOGRAPHY Advanced Topics

18.2.2 Example: Graph Coloring

The k-color problem is well known in computer science. Given a graph, it’s considered
difficult to find a way to label each node with one of k colors such that no neighboring
nodes share a color. For example, the following is a valid 3-coloring of the graph:

Finding the coloring is hard,3 but verifying it is easy. However, it seems like Alice
would need to reveal the entire graph coloring to prove to Bob that it’s valid, no?
Fortunately not. Because we are making probabilistic guarantees, we can use a scheme
that reveals nothing about the true coloring of the graph yet also guarantees its
validity.
Alice first commits to a coloring using a commitment scheme like Pedersen commit-
ments. Bob then presents a simple challenge: “Show me the colorings of edge e.”
Alice then reveals the colors she chose for that edge. What’s the probability of Alice
lying about having a valid coloring? Well, in the worst case, Alice’s graph coloring
was perfectly colored except for a single edge. The chance that Bob did not choose
this invalid edge is pretty high: E−1
E
, where E is the number of edges in the graph.
For the above 8-edge graph, there’s an 87.5% chance that Alice is full of it.
How does Bob get more certainty? Run it again! Now, critically, Alice shuffles the
colors she used before presenting the colored graph; notice that the validity of the
above coloring does not change if we swap reds and greens, for example. We do the
E−1 2
challenge and reveal again, and this time there’s a E chance of cheating (a 76.6%

chance for our example). That’s progress. . . In general, the probability of cheating
E−1 n
after n runs is E , so if we wanted, for example, 99% certainty that Alice isn’t

lying, we can solve for n:

 n
E−1
< 0.01
E
 n
7
< 0.01
8
 n
7
< 0.01
8
log7/8 0.01 ≥ n
34.5 ' n
3
Again, when we say “hard,” we mean that “no polynomial-time algorithm exists.” Obviously for
the toy examples presented here, finding a valid coloring does not seem difficult, but the number
of possibilities explodes quickly as the graph grows.

Kudrayvtsev 133
 CHAPTER 18: Zero-Knowledge Proofs

You can try out So after 35 rounds (shuffle, challenge, reveal), Bob can be pretty dang sure that Alice
an interactive isn’t lying about her graph coloring, and since Alice always shuffled and did not reveal
version of the
a full coloring, the full solution is still a secret.
3-color ZKP
from MIT here.
18.2.3 Formalization
Formally, a zero-knowledge proof must satisfy the following key properties:
1. Completeness: For all valid queries or challenges to the problem that the
verifier Bob can present, Alice must respond with a valid solution. This is point
(1) from above. Colloquially, if Alice is honest, then she will eventually
convince Bob.
2. Soundness: For all invalid queries, the verifier must reject Alice’s solution
with a ≥ 12 probability; this is point (2). Colloquially, lying should be near-
impossible: Alice can only convince Bob if the statement is true.
3. Perfection (also called zero-knowledge-ness [yeah, seriously]): There must exist
a realistic PPT algorithm that can simulate knowledge of the solution rather
than actually know it.
Colloquially, Bob learns no information from Alice beyond the fact that
the statement is true. If such a simulator as described above (which doesn’t
actually know the solution) can exist, Bob wouldn’t know the difference and
thus learn nothing additional.
The last point is the oddest and bears a bit of clarification; perfection is such a weird
definition mostly because defining it formally is difficult.
Simply imagine that the prover doesn’t actually have a solution but picks things
randomly. Whenever the verifier catches them lying (i.e. reveals an invalid partial so-
lution), the prover turns back time, randomizes the solution until the lie is fixed, then
“resumes” the proof; the verifier then continues as if nothing happened. Critically,
the prover doesn’t actually have a solution, and thus it’s impossible for the verifier
to learn anything about it, ensuring that zero knowledge is revealed.
In essence, it must be possible for a false prover to get away with lying for every single
challenge if they knew the challenges up front without actually having a solution.4
This means that the verifier couldn’t learn anything by the simple fact that the prover
didn’t actually know anything.

4
In the literature, this is expressed as a “simulator” producing a “transcript” of an interaction with
the verifier, allowing it to internally retry as many times as it needs to fulfill challenges.

Kudrayvtsev 134
APPLIED CRYPTOGRAPHY Advanced Topics

18.3 Schnorr’s Protocol

The protocol we’re about to describe—Schnorr’s protocol—is a zero-knowledge
proof of knowledge about the discrete log problem. We’ve actually seen it before
when discussing Schnorr signatures in section 12.5. In this context, we’ll adapt it to
an interactive protocol and prove that it’s a ZKP.
To refresh our memory of Schnorr, we first fix some parameters: G is a cyclic group of
order q, with g as a generator. The Prover knows some x ∈ Zq and calculates h = g x .
They provide the Verifier with h and want to prove that they know x.
The protocol then proceeds as follows:
$
• First, the Prover commits to a random group element: she chooses r ←− Zq
and commits to u = g r .
$
• The Verifier likewise commits to a random group element: he chooses c ←− Zq
and presents it as a challenge to the Prover.
• The Prover responds with z = r + cx, which, obviously, they can only do by
knowing x.
?
• The Verifier can now validate g z = u · hc .

Claim 18.1. Schnorr’s protocol is a zero-knowledge proof of discrete log knowl-

edge under groups in which the discrete log is hard.

The Schnorr protocol is a specific type of sigma protocol; to put it succinctly, these
protocols only take a single “round” of commit / challenge / respond to sufficiently
prove something to the Verifier. Crucially, the challenge that the Verifier presents
must be chosen at random.

18.4 Interactivity
It’s worth noting a key foundation of the ZKPs we’ve discussed thus far: they’re
interactive. The Prover and the Verifier enter several “rounds” of commit / challenge
/ respond to give the Verifier an arbitrary degree of certainty in the existence of the
Prover’s knowledge.
This limitation begs the question: can we avoid this interactivity and enable the
Prover to present a self-contained proof of knowledge?
Obviously since we’re asking this question, the answer is “yes.” This “yes” comes with
restrictions, though. In the standard model, this is only true for simple problems:
by “simple,” we mean problems in the BPP (bounded-error probabilistic polynomial
time, basically just P with randomness) complexity class. However, if we operate in

Kudrayvtsev 135
CHAPTER 18: Zero-Knowledge Proofs

P (x) V (x)

P (x) V (x)
P (x) V (x)
...

accept or accept or accept or

reject reject reject
(a) interactive (b) Sigma protocol (c) non-interactive

Figure 18.1: The two types of ZKPs (since a ΣP is a subset of all interactive
ZKPs.

the random oracle model (now you see why chapter 17 came first), we can expand
our problem space.
In fact, we can convert any sigma protocol (ΣP) into a non-interactive zero-knowledge
proof (NIZK). Because the Verifier chooses challenges randomly and keeps no secret
state, we can essentially replace them with a random oracle. This is the idea behind
the Fiat-Shamir heuristic: the challenge c is chosen randomly from a hash function
$
c ←− H(x, t) ∈ Zq

where x is some input (like the graph in the 3-color problem) and t is the Prover’s
commitment (like a particular coloring).
Specifically, the Prover sends the verifier its commitment, t, its self-generated chal-
lenge, c (as above), and finally its response to the challenge, z. Then, the Verifier can
choose to either accept or reject the proof as a deterministic function of (x, t, c, z).
Of course, being security-minded, we should consider the possibility that the Prover’s
choice of (x, t) (and thus the resulting commitment) were maliciously crafted to prove
something that she doesn’t actually know. Just like before, though, we can increase
our confidence in the proof by including many generated commitments that follow a
random distribution.5

18.5 Succinctness
In the previous section, we discussed making a zero-knowledge proof not require
interactivity; minimizing communication rounds was the main goal. Now, our goal is
to minimize both communication and verifier complexity.
5
The notes I’ve been following don’t actually dive into this, but I believe this is one viable way to
alleviate this concern. Perhaps I’m misunderstanding something in the formal inner workings of
a NIZK (there’s a lot of detail I’m glossing over here for the sake of a more-digestible overview).

Kudrayvtsev 136
APPLIED CRYPTOGRAPHY Advanced Topics

Definition 18.1: Succinct

A non-interactive proof system for a language LC (where C is the possible

commitment space) is succinct if:

• the proof π is of length |π| = poly(λ, log |C|).

• the verifier runs in time poly(λ, |x| , log |C|).

Honestly, this definition doesn’t matter much, but it’s included here for the sake of
completeness and precision. In general, we can just say that a knowledge proof is
succinct if it doesn’t take very much information to communicate it.
With succinctness comes a new slew of acronyms. Specifically, a SNARG is succinct,
non-interactive argument of knowledge; a SNARK additionally includes a proof of
knowledge; and a zk-SNARK means this proof zero-knowledge.

18.5.1 Why Succinct Proofs?

The main motivator behind succinct knowledge proofs is verifiable computation: it
allows clients to outsource the computation of f (x) to other machines, but verify the
validity of the result. Obviously, verifying the result must be cheaper than computing
f (x) itself.
To give these constructs more concrete-ness, they are crucial to cutting edge cryp-
tocurrency technology: they’re involved in compressing blockchains (the Coda proto-
col), anonymous transactions (ZCash), and private smart contracts (Arbitrum).
It has additional dimensions of interests, as well in post-quantum cryptography, trust
assumptions, and universality.

18.5.2 Construction
TODO: wow, things get wild here; try this link instead

18.6 References
1. Green, M. Zero Knowledge Proofs: An illustrated primer. In A Few Thoughts on Crypto-
graphic Engineering. November 2014
2. Barak, B. Zero Knowledge Proofs. In COS 433: Cryptography. November 2007, ch. 15
3. Boneh, D. Zero-Knowledge Proofs. In Notes on Cryptography. Stanford University, 2002

4. Ray, S. What are Zero Knowledge Proofs? In Towards Data Science. Medium, April 2019
5. Cossack Labs. Explain Like I’m 5: Zero Knowledge Proof, October 2017

Kudrayvtsev 137
CHAPTER 18: Zero-Knowledge Proofs

6. Feige, U., Fiat, A., and Shamir, A. Zero-Knowledge Proofs of Identity. Journal of
Cryptology (1988), 77–94
7. Feige, U., and Shamir, A. Zero knowledge proofs of knowledge in two rounds. In Advances
in Cryptology, CRYPTO ‘89 (Berlin Heidelberg, 1990), G. Brassard, Ed., Springer-Verlag
8. Boneh, D., and Shoup, V. Schnorr’s identification protocol. In A Graduate Course in
Applied Cryptography. January 2020, ch. 19.1, pp. 724—731. [Online]

Kudrayvtsev 138
Multi-Party Computation

his chapter will discuss secure computation, specifically multi-party compu-

T tation (MPC), where many different parties all hold secret inputs, but they can
compute a function on all of their inputs without revealing them to each other.

19.1 Two-Party Computation

We’ll start off with a special case of MPC, limiting ourselves to just two users. To
make things formal, let’s start by outlining the 2PC context:
• Alice knows x ∈ {0, 1}∗ (an particular, arbitrary-length bitstring),
• Bob knows y ∈ {0, 1}∗ , and
• they both know some function f : {0, 1}∗ × {0, 1}∗ 7→ {0, 1}∗ , a function that
takes two bitstrings as input and outputs some other bitstring (in other words,
a generic computation from two inputs).
In a perfect 2PC, Bob and Alice will learn f (x, y) and nothing else.1
Two-party computation is a pretty broad abstraction that includes many, many dif-
ferent classes of problems. For example,
• We’ve already alluded to Yao’s millionaire problem in chapter 14, where two
people want to determine who is richer without revealing their net worth.
• Contact discovery in secure messaging services falls under 2PC, where a user
wants to use a centralized server to determine which of his contacts use the
service, without neither actually revealing their contact databases (in crypto-
graphic literature, this is called private set intersection).
• Online advertising is another domain, in which an ad provider (like Google)
and a retailer (like Macy’s) may want to analyze the efficacy of an ad campaign
(measuring the “conversion rate” from seeing the ad to buying the product)

1
More generally, we could even have two separate functions and have Alice learn fA (x, y) while
Bob learns fB (x, y), but that’s additionally complexity we don’t need right now.

139
CHAPTER 19: Multi-Party Computation

without revealing who the ads were shown to or who made purchases.
The security of a particular two-party computation scheme can be expressed with
two variants: in the first, we have semi-honest participants—both Bob and Alice
promise to follow the protocol precisely (akin to a honest Verifier in zero-knowledge
proofs)—while in the second, we may have malicious participants—Bob and/or Alice
can deviate from the protocol.
We’ll focus on the former version for simplicity, but the latter is also possible. We
need to ensure two properties of our interactive protocol:
• correctness: for every possible input, the protocol’s output must match the
function’s output. Formally, if we say that hA(x), B(y)i is an execution of the
protocol with x and y as defined above, then correctness is when

∀x, y ∈ {0, 1}∗ : Pr [hA(x), B(y)i = f (x, y)] = 1

• privacy: for both of the hidden inputs, there must exist “simulators” that
emulate what both A and B see in the protocol. This is similar to “zero-
knowledgeness” (see item 3), in that the existence of such a simulator provdes
that neither participant learns anything valueable from the transcript of the
protocol.

19.1.1 Oblivious Transfer

19.1.2 Yao’s Garbled Circuits

19.2 Extending to More Parties

Kudrayvtsev 140
Elliptic Curves

ude, literally just read this incredible series of blog posts on this topic that
D explain things far more elegantly than I ever could.
The fundamental beauty of an elliptic curve is that it’s a group, meaning it can
literally replace all of the instances of Zp that we’ve been using throughout the pre-
vious 141 pages. Elliptic curves are a drop-in replacement for modulus-based groups;
they increase security, reduce key size, and improve efficiency all in one go.

141
Index of Terms

Symbols confidentiality . 8, 36, 37, 49, 50, 60, 95,

n-IND-CCA . . . . . . . . . . . . . . . . . . . . . . . . . 92 104, 114
n-IND-CPA . . . . . . . . . . . . . . . . . . . . . . . . . 92 cr-advantage . . . . . . . . . . . . . . . . . . . . . . . . 42
Cramer-Shoup . . . . . . . . . . . . . . . . . . . 84, 93
A cryptographically-secure hash function . .
AEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 47, 53, 86
AES . 16, 25, 27, 39, 59, 70, 77, 116, 125
aggregate signatures . . . . . . . . . . . . . . . 102 D
associated data . . . . . . . . . . . . . . . . . . . . . . 54 ddh-advantage . . . . . . . . . . . 79, 79, 80, 83
asymmetric cryptography . . . . . . . . 10, 70 DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 25
asymmetric encryption . . . . . . . . . . . . . 106 Diffie-Hellman key exchange 81, 111, 116
attribute-based encryption . . . . . . . . . . . 94 Diffie-Hellman, computational . . . 77, 81,
authenticated encryption . . . . . . . 49, 116 83, 111
authentication . . . . . . . . . . . . . . . . . . . . . . 114 Diffie-Hellman, decision . . . . . . . . . . . . . 103
authenticity . . . 8, 35, 36, 49, 60, 95, 104 Diffie-Hellman, decisional . . . . 77, 82, 86,
111, 127
B dl-advantage . . . . . . . . . . . . . . . . . . . . . 78, 78
Bézout’s identity . . . . . . . . . . . . . . . . . . . . 68 DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
binding . . . . . . . . . . . . . . . . . . 124, 125, 126
birthday paradox . . . . . 28, 32, 40, 44, 59 E
Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 ECDSA . . . . . . . . . . . . . . . . . . . . . . . 101, 102
blind signatures . . . . . . . . . . . . . . . . . . . . 103 ElGamal . . . . . . . . 81, 84, 93, 99–101, 110
block cipher . . 16, 25, 27, 28, 31, 35, 37, ElGamal, threshold . . . . . . . . . . . . . . . . 110
54, 56, 59, 77, 116 elliptic curve . . . . . . . . . . . . . . . 70, 79, 141
blockchain . . . . . . . . . . . . . . . . . . . . . . 41, 114 encrypt-and-MAC . . . . . . . . . . . . . . . . . . . 50
Blum-Micali . . . . . . . . . . . . . . . . . . 121, 121 encrypt-then-MAC . . . . . . . . . . . . . . . . . . 50
both . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 encrypt-then-sign . . . . . . . . . . . . . . . . . . 105
Euclidean algorithm . . . . . . . . . . . . . . . . . 68
C Euclidean algorithm, extended . . 69, 76,
cdh-advantage . . . . . . . . . . . . . . . . . . . . . . . 78 88, 89
certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Euler’s theorem . . . . . . . . . . . . . . 88, 89, 90
certificate authority . . . . . . . . . . . . . . . . 106 exclusive-or . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chinese remainder theorem . . 76, 76, 88, exhaustive key-search . . . . . . . . . . . . 25, 59
89, 132
collision resistant 42, 42, 44, 46, 47, 124 F
commitment . . . . 124, 129, 133, 136, 137 FDH-RSA . . . . . . . . . . . . . . . . . 97, 103, 129

142
Index of Terms

Fermat witness . . . . . . . . . . . . . . . . . . . . . . 72 key-derivation function . . . . . . . . . . . . . . 48

Fermat’s little theorem . . . . . . . 72, 89, 89
Fiat-Shamir heuristic . . . . . . . . . . . . . . 136 L
forward secrecy . . . . . . . . . . . . . . . . . . . . . 57 Legendre symbol . . . . . 74, 74, 75, 80, 82

G M
MAC-then-encrypt . . . . . . . . . . . . . . . . . . 50
general number field sieve . . . . 70, 79, 98
man-in-the-middle attack . . . . . . . . . . 112
generator . . . . . . . . . . . . . . . . . . 55, 116, 121
Merkle tree . . . . . . . . . . . . . . . . . . . . . . . . . 114
Goldreich-Goldwasser-Micali . . . . . . . 122
Merkle-Damgard transform . . 43, 44, 50,
Goldreich-Levin . . . . . . . . . . . . . . . 118, 120
129
greatest common divisor . . . . . . . . . . . . . 65
message authentication code . 36, 47, 48,
group signatures . . . . . . . . . . . . . . . . . . . 103
50, 95
H mode of operation 17, 23, 25, 37, 43, 53,
hardcore predicate . . . . . . . . . . . . 117, 118 55, 59, 77, 83
hash function . . 41, 90, 95, 97, 116, 124, multi-party computation . . . . . . 114, 139
127 multi-signatures . . . . . . . . . . . . . . . . . . . . 102
Hastad’s broadcast attack . . . . . . . 89, 92 N
hiding . . . . . . . . . . . . . . . . . . . . . . . . 124, 125 negligible . . . . . . 67, 67, 78, 118, 119, 122
HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 NP-hard . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
homomorphic encryption . . . . . . . . . 94, 97
homomorphic, additive . . . . . . . . . . . . . 125 O
OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
I offset codebook . . . . . . . . . . . . . . . . . . . . . 53
identity-based encryption . . . . . . . . . . . . 93 one-time pad . . . . . . . . . 12, 19, 31, 36, 55
impossibility result . . . . . . . . . . . . . . . . . . 14 one-way . . . 46, 47, 88, 98, 116, 118, 122
IND-CCA . 33, 35, 37, 38, 49, 53, 60, 63, ow-advantage . . . . . . . . . . . . . . . . . . . . . . . 46
83, 84, 86, 90–92, 104, 105, 127
IND-CCA advantage . . . . . . . . . . . . . . . . 33 P
IND-CPA . 21, 22, 26, 27, 32, 33, 35, 49, Pedersen commitment . . . . . . . . . 125, 133
53, 60, 63, 78, 82–84, 90–92, 105, perfect security . . . . . . . . . . . . . 12, 36, 124
127 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . 106, 108
IND-CPA advantage . . . . . . . . . 21, 23, 29 post-quantum cryptography . . . . . . . . 114
IND-CPA-cg . . . . . . . . . . . . . . . . . 23, 29, 83 PRF advantage . . . . . . . . . . . . . . . . . . 27, 29
IND-CPA-cg advantage . . . . . . . . . . . . . 24 PRF secure . . . . . . 27, 32, 35, 45, 50, 53,
INDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 127–129
INDR advantage . . . . . . . . . . . . . . . . . . . . 56 prime factorization . . . . . . . . . . . . . . . . . . 79
initialization vector . . . 17, 22, 34, 54–56 private key . . . . . . . . . . . . . . . 61, 63, 81, 87
INT-CTXT . . . . . . . . . . . . 50, 53, 104, 105 private set intersection . . . . . . . . . . . . . 139
INT-CTXT advantage . . . . . . . . . . . . . . . 49 probabilistically-polynomial time . . . 118
integrity . . 8, 35, 36, 49, 50, 60, 95, 104, prover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
114 pseudorandom function . . 26, 31, 50, 57,
77, 91, 116, 117, 121, 127
K pseudorandom generator . . . . 50, 55, 121
Kerckhoff’s principle . . . . . . . . . . . . . 15, 36 PSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98, 101
key distribution . . . . 10, 61, 94, 102, 106 public key . . 61, 63, 81, 83, 87, 106, 111
key separation principle . . . . . . . . . . . . . 50 public key infrastructure . . . . . . . . . . . 106

143
Index

R succinct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
random function . . . . . . . . . . . . . . . . . 35, 91 SUF-CMA . . . . . . . . . . . . . . . . . . . . . . . . . 105
random oracle . . 91, 91, 92, 97–102, 127, symmetric key . . . . . . . . . . . 10, 77, 88, 95
136
RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 T
relatively prime . . . . . . . . . . . . . . . . . . . . . . 90 threshold signatures . . . . . . . . . . . 102, 110
replay attack . . . . . . . . . . . . . . . . . . . . 37, 38 timing attack . . . . . . . . . . . . . . . . . . . . 52, 60
revocation . . . . . . . . . . . . . . . . . . . . . . . . . 107 totient function . . . . . . . . . . . . . . 65, 86, 90
ring signatures . . . . . . . . . . . . . . . . . . . . . 103 trap door . . . . . . . . . . . . . . . . . . . . . . . . 88, 97
RSA . . . . . . . 77, 86, 96, 99, 104, 109, 116 U
RSA-OAEP . . . . . . . . . . . . . . . . . . . . . 90, 92 UF-CMA . . . . . . . 38, 40, 49, 95–102, 105
UF-CMA advantage . . . . . . . . . . . . . 38, 96
S
safe prime . . . . . . . . . . . . . . . . 71, 71, 79, 80 V
Schnorr . . . . . . . . . . . . . . . . . . . . . . . 101, 135 verifiable secret sharing . . . . . . . . . . . . 109
Schnorr’s protocol . . . . . . . . . . . . . 135, 135 verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
searchable encryption . . . . . . . . . . . . . . . 94
secret key . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 W
seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 58 web of trust . . . . . . . . . . . . . . . . . . . . . . . . 108
session key . . . . . . . . . . . . . . . . . . . . . . . . . 106
Shamir’s secret sharing . . . . . . . . 109, 110 X
X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Shannon-secure . . . . . . . 12, 15, 20, 31, 36
sigma protocol . . . . . . . . . . . . . . . . 135, 136 Y
signature . . . . . . . . . . . . . . . . . . 95, 102, 108 Yao’s millionaire problem . . . . . 114, 139
signcryption . . . . . . . . . . . . . . . . . . . 104, 105
SNARG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Z
SNARK . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 zero-knowledge proof . . . . . 110, 114, 124,
socialist millionaire problem . . . . . . . . 114 130, 135, 137, 140
stream cipher . . . . . . . . . . . . . . . . . . . . 55, 56 zk-SNARK . . . . . . . . . . . . . . . . . . . . . . . . 137

144