1

Lecture Notes on “Introduction to Modern

Cryptography”
Yuzhe Tang
Syracuse University, NY, USA, Email: ytang100@syr.edu
N O V E M B E R 11, 2021

C ONTENTS

I Modern cryptography: an informal introduction 4

I-A The case of private key encryption or SKE (§ 1.2 in [1];) 08/29/19 . . . . . . . . . . . . . . . . . . . . 4
I-B Other security goals and cryptographic primitives 08/29/19 . . . . . . . . . . . . . . . . . . . . . . . . . 4
I-C Principles of modern cryptography (§ 1.4) 09/03/19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I-D Security definition 09/03/19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I-E Precise assumption 09/03/19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I-F Real-world security and provable security 09/03/19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

II Perfectly-secret encryption 6
II-A Describing encryption scheme in probability 09/05/2019 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
II-B Formulating Perfect Secrecy 09/05/2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
II-B1 Perfect secrecy as conditional probability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
II-B2 Perfect secrecy as perfect indistinguishability . . . . . . . . . . . . . . . . . . . . . . . . . . 7
II-C One-time pad 09/10/19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
II-C1 Security of OTP: Is OTP perfectly secret? 09/10/19 . . . . . . . . . . . . . . . . . . . . . . . 7
II-D Are OTP and Perfect Secrecy Useful? (Their Practical Limitations) 09/10/19 . . . . . . . . . . . . . . . 8
II-D1 One-time use of OTP key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
II-D2 Key Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

III Private-key encryption 8

III-A Computational security (§ 3.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
III-A1 Motivation: Attack a Practical Scheme? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
III-A2 Formalizing Computational Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
III-B Computationally secure encryption (§ 3.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
III-C Stronger security notion (CPA) § 3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
III-C1 Multi-encryption security (09/12/19) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
III-C2 CPA security (09/17/19) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
III-D Constructing an encryption scheme §3.3 09/17/19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
III-D1 PRG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
III-D2 Construction OTP-PRG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
III-E Constructing CPA-secure encryption (§3.5) 09/19/2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
III-E1 PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
III-E2 OTP-PRF: a CPA-secure construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

IV Modes of operation (09/26/19) 12

IV-A Stream cipher mode of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
IV-A1 Stream cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
IV-A2 Synchronized mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
IV-A3 Unsynchronized mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
IV-B Block cipher mode of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
IV-B1 ECB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
IV-B2 CBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
V Message Authentication Code (MAC) 10/03/2019 14
V-A The Scheme of MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
V-B Security definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
V-C Constructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
V-C1 Fixed-length MAC by PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
V-C2 Variable-length MAC by CBC-MAC (§ 4.11) . . . . . . . . . . . . . . . . . . . . . . . . . 16
V-D Authenticated Encryption (10/08/2019) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
V-D1 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
V-D2 Security Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
V-D3 Constructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
V-D4 Beyond Data Integrity: Replay and reorder attacks . . . . . . . . . . . . . . . . . . . . . . . 16

VI Hash Functions (10/08/2019) 17

VI-A Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-B Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-B1 Collision Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-B2 Weaker Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-C Generic Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-C1 Brute-force Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-C2 Birthday Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-D Hash-based Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-D1 MAC domain-extension: Hash-and-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VI-D2 Hash domain-extension (from h to H): Merkle-Damgard and Merkle trees . . . . . . . . . . 18
VI-E Hash Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

VII Key Exchange (§ 10) 20

VII-A Definitions: Schemes and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
VII-B Construction (DHKE) and Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
VII-B1 Background: Group theory (Chapter 8 in textbook) . . . . . . . . . . . . . . . . . . . . . . . 20
VII-B2 Group-theoretic Problems and Hardness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VII-B3 DHKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VII-C Key-Distribution Center (KDC) for 3-Party Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 21

VIII Public-Key Encryption 21

VIII-A Introduction: Public-Key Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
VIII-B Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
VIII-C Security Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
VIII-D Domain extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
VIII-E Construction: El Gamal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

IX Digital Signatures (§ 12) 23

IX-A Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
IX-B Benefits and Distinction of Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
IX-C Security Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
IX-D Construction: Domain Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
IX-E Construction (Fix-length): Schnorr Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
IX-E1 Identification scheme: Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
IX-E2 Fiat-Shamir transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
IX-E3 Construction: Schnorr Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
IX-F Challenge-response protocols for user authentication (Chapter 6 in Book [2]) . . . . . . . . . . . . . . . 26
IX-F1 Case: Two-factor authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
IX-F2 Case: Public-key based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

X TLS (§ 12.7/8) 27
X-A Overview: TLS-HS and TLS-RL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
X-B TLS-HS Design Iteration 1: DHKE under MitM Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 27
X-C TLS-HS Design Iteration 2: DHKE + Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . 27
X-D TLS-HS Design Iteration 3: PKI and CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
X-E PKI in practice (Nov. 12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
X-F Certificate Transparency (CT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2
XI Summary 30

References 31

Appendix A: Review: Discrete probability (§ A) 32

A-A Introduction and Random Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A-B Statistical Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A-C Advanced statistical properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Appendix B: Basic logic operations 32

B-A XOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3
 I. M ODERN CRYPTOGRAPHY: AN INFORMAL INTRODUCTION
Crypt-o-graphy, as defined in the dictionary, is “the art of writing or solving codes.” In Greek, crypt(o) means “secret”,
graphy means “writing”, logy (as in cryptology) means “study”. This dictionary definition only applies to classic cryptography.
Modern cryptography is different from classic cryptography in two senses: 1. classic cryptography as an art versus modern
cryptography as a science (in a formal treatment), 2. classic cryptography is used in military settings, while modern cryptography
is used in daily life.
The focus of this course is formal study of modern cryptography. To start with, let’s give an informal introduction to the
topic. In the following, we will set up the stage by introducing Private Key Encryption, and focus on introducing the formal
treatment of security in modern cryptography.

A. The case of private key encryption or SKE (§ 1.2 in [1];) 08/29/19

A motivating scenario: Hosting files in Dropbox: User Alice stores her personal photo on Dropbox.com. User Bob, being
a friend of Alice, gets the photo by downloading it from Dropbox.com. Eve, a thief, wants to get a copy and sell the photo.
Model of SKE: The model of private-key encryption is three parties: Alice sends messages to Bob, and Eve can eavesdrop
the communication between the two users.
An encryption scheme is historically called cipher, codes. An encryption scheme, denoted by Π, is defined by key k, message
m, ciphertext c, and three algorithms for key generation, encryption and decryption. Formally, a private-key encryption Π
(G EN,E NC,D EC) is defined by k ←G EN, c ←E NC(k, m), m :=D EC(k, c).
What is private in the scheme to Alice/Bob includes: key, message. What is released in public (exposed to Eve) includes:
ciphertext, and the three algorithms G EN,E NC,D EC. Kerckhoff’s principle (in 19th century) states “the cipher method must
not be required to be secret” (easy to fall into the hands of enemy). In modern-crypt terms, it means the three algorithms are
public. There are three reasons (practical reasons) behind the principle: easier to keep the secrecy of shorter keys than that of
an algorithm, easier to change keys upon leakage than changing algorithms, better to have the same encryption algorithm for all
users than custom algorithms. Cryptography emphasizes the use of standard cryptographic algorithms which have gone through
rigorous reviews. It is strongly against the design to use any “home-brewed” encryption algorithms! Note that Kerckhoff’s
principle implies the security fully relies on key secrecy, with algorithms being public.
Security formalization:
Correctness: Given a message, encrypting the message and decrypting the ciphertext should produce the original message.
Given an SKE scheme Π and key k, the correctness of Π is that for any m, it has to hold that D EC (k, E NC(k, m)) ≡ m.
Message confidentiality: The confidentiality of the message states, intuitively, that other than Alice and Bob, no one including
Eve, can know the message. Informally, “In an SKE scheme Π, knowing c,G EN,E NC,D EC, Eve cannot know anything about
m and k.”
The security goal of an SKE scheme is to state the confidentiality property in a formal and measure-able way. This brings
challenges: Security is a negative goal (like one cannot do something), rather than a positive goal (like Alice can do something).
To evaluate a negative goal it is much more difficult. To be more specific, consider evaluating the correctness and security.
Correctness is that Bob can recover the original message from a ciphertext that Alice encrypts to. It is easy to test the
correctness by simply asking Bob to decrypt a ciphertext and to check its equality with the original message. That is, given
?
m,Π (G EN,E NC,D EC), the correctness of Π can be tested by m =D EC(k, E NC(k, m)).
However, the security of the same scheme is Eve’s inability to recover the original message from a ciphertext that Alice
encrypts to. It is much harder to test. The designer must check that all the ways that Eve might be able to recover it are blocked.
That is, given m,Π (G EN,E NC,D EC), the security of Π can only be tested by proving that there is no such algorithm, say
BROKEN DEC(), that c ←E NC(k, m); BROKEN DEC(c) = m. To test this, the designer has to consider all possible algorithms,
which have infinite possibilities.
There are two canonical applications (paradigms) of private-key encryption: Scenario 1. Secure storage where Alice and
Bob are separated by time, and 2. secure communication where Alice and Bob are separated by space.
In secure storage, e.g., encrypted disk, Alice and Bob are the same user active at different times. The communication channel
is the encrypted disk. Eve is someone looking to the disk. Sharing the key (on the same user) is trivial in secure storage.
In secure communication, Alice and Bob are two people in two different places (NY versus CA), Eve is an eavesdropper
looking into the communication channel between Alice and Bob (e.g., network). Private-key encryption assumes Alice and
Bob have the same private key in the beginning.Sharing a key can be done through off-the-band communication (e.g., Alice
flies to Bob to share key). In some cases where off-the-band communication is impossible, sharing the key can be done by
key exchanges.

B. Other security goals and cryptographic primitives 08/29/19

For data confidentiality, there are schemes of private-key encryption to do bulk communication (in sessions). We often
use public-key encryption to exchange and establish the shared key. We usually use the scheme of certificate and public-key
encryption to associate users with (public) keys.

4
 TABLE I: Security properties and cryptographic primitives
Scenarios Security goals Primitives Security assumption (or source of
security)
“Record-layer” communication on shared secret keys Message confidentiality Private key encryption (SKE) Info-theoretic hardness
Record-layer communication on shared secret keys Message integrity Message authentication code (MAC) Info-theoretic hardness
Record-layer communication on shared secret keys Message confidentiality and integrity Authenticated encryption (AE) Info-theoretic hardness
Sharing secret keys (hand-shaking) Confidentiality of secret keys DH key exchange (DHKE) Computational hardness
Sharing secret keys (hand-shaking) Confidentiality and integrity of secret TLS (MAC) Info-theoretic hardness
keys
Sharing public keys (hand-shaking) Integrity of public keys shared PKI (Digital signatures and CA) Computational hardness and trust to
CA

For data integrity, there are schemes of message authentication code MAC to do record-layer communication (in session).
We can use digital signatures to ensure the authenticity in key-exchange.
For the support of both confidentiality and authenticity, we can use authenticated encryption.

C. Principles of modern cryptography (§ 1.4) 09/03/19

Provable security is the core principle of modern cryptography. A cryptographic scheme defines the “interface” through
which parties interact. A cryptographic construction provides the “function body” of the scheme. Provable security refers to the
requirement of a rigorous proof that a construction is secure. Here, there are two core concepts: 1) security definition (§ I-D)
that defines what security means in the context of the cryptographic scheme, 2) security assumption (§ I-E). A cryptographic
scheme is often constructed based on some unproven assumption about algorithmic hardness.

D. Security definition 09/03/19

As mentioned, the concept of security is about what an adversary cannot achieve (a negative goal). To formally define
security, it requires two elements, 1) what is the adversary allowed to do (or threat model), 2) in the context of a threat model,
what is it the adversary cannot achieve? (i.e., the security goal). A threat model states what attacks are in scope or what
capabilities an attacker has. The security goal states what the construction guarantees under the attacks in scope.
Next, in the setting of private-key encryption, let’s explore the design of a formal security definition. That is, how can one
convert “an intuitive idea of security” to a formal security definition?
First, let’s consider the case of a single message/ciphertext pair, where Eve is given one ciphertext but tries to guess what
the original message is. Note that this the ciphertext-only attack as will be introduced. In this setting, one way to formulate
the security goal is “no recovery of key”, that is, Eve cannot recover key k from the observed ciphertext c. To show the
insufficiency of this security goal, a counterexample is E NC 1 (k, m) = m where the key is perfectly protected in c =m, as it
has nothing to do with key k. However, such encryption is obviously not good, as it discloses the message m. A better security
goal needs to include the secrecy of message in it.
Then, one can revise the security goal to be “no recovery of key and entire message.” Then, a counterexample is
E NC2 (k, 1024) = 10 ∗ ∗, which clearly is insecure as it does disclose partial information of the message. A better formulation
is “no recovery of any digits in the message,” even better, “no recovery of any information about the message,” such as whether
the number is larger than 1000.
In future lectures, we will talk about how to express this statement, more formally, in a mathematical language.
Second, let’s consider what an adversary can do or the threat model. In the above analysis, we assumed the “ciphertext-only
attack (COA)” where Eve is given only one ciphertext. In practice, Eve may have more capabilities by observing multiple
ciphertexts. In addition, Eve can know a common message and observe its ciphertext, such as message “hello” hardcoded in
secure-channel software and whose ciphertext can be identified as the very first text exchanged in a handshake protocol. This
more demanding attack is called known-plaintext attack or KPA. In COA, Eve knows one or multiple ciphertexts. In KPA,
Eve additionally know a given pair of plaintext and ciphertext.
More advanced attacks include CPA (chosen-plaintext attacks) and CCA (chosen-ciphertext attacks), which model some
real-world attacks to private-key encryption. CPA is the standard attacks that any standard SKE construction has to defend. In
CPA, Eve gets to choose the message she want to know the ciphertext of. This choice in choosing the message is termed as
Oracle access.
Note that a threat model may refer to both what an attack can know about (i.e., attacker’s knowledge), and what she can do
about it (i.e., attack strategy). An attack strategy is about how Eve can leverage her knowledge to mount a successful attack
that breaks the security. Specific attack strategies or algorithms are out of scope to security definition. In general, they are just
assumed to be “efficient” algorithms that are not hard. In practice, various attack strategies are used, e.g., frequency attack
works by Eve analyzing the frequency of ciphertext to infer the message.
In summary, the security definition consisting of security goal and threat model will be formally described in terms of
adversarial games.

5
E. Precise assumption 09/03/19
Cryptographic constructions are often built on assumptions about computational hardness. For instance, cryptographic hashes
are based on the assumption that the best algorithm to find a hash collision is to brute force scan the hash-input space, which
is hard. We do not know if there is a better algorithm than brute force, but believe there is none. RSA pubic key encryption, or
its security, is based on the assumption that prime factorization is hard or there is no known P algorithm to solve the problem.
The assumptions in a cryptographic construction is a statement that is conjectured to be true but is not proven. In general, a
construction is secure because the only possible algorithms to break the security are assumed to be high computation complexity
(NP). And whether a NP algorithm is really hard to compute relies on the unproven assumption that P 6= N P .
Having the assumption explicitly specified is necessary, as it keeps users aware that the assumption may be proven true/false
in the future which may affect the security (as in the case of MD5). Also, one can compare different constructions (of the same
scheme) built on different assumptions – one should prefer the construction based on a “weaker” and well studied assumption.

F. Real-world security and provable security 09/03/19

Provable security versus real-world security: In a real-world security system stack, application-specific code calls into
cryptographic libraries. The application-level security indicates whether the cryptographic primitives are used correctly. For
instance, is the choice of CPA-secure scheme proper for the target application (in other words, does CPA capture the real-world
attacker’s capability in the target application?) For another example, does Facebook.com encrypt users’ passwords when storing
them on disk? This course is not about application-level security.
Inside the cryptographic library, given the same cryptographic construction, there can be different implementations. The
implementation- or system- level security refers to whether a particular implementation of cryptographic construction is secure.
Related attacks include side-channel attacks. They are also out of scope in this course.
So the security in scope is the security of cryptographic construction (at the protocol specification layer). Such security
is provable in that one can present a formal proof that the construction is secure or satisfying the security definition of the
scheme.
In software development cycle, one can consider security after the fact or from the very beginning. Today, mostly security is
considered after the fact, a software system is developed and released to be operational first, and is then patched after a security
hole is discovered (e.g., by blackhat hackers or whitehat). In the latest wave of software engineering, say for IoT applications,
it is advocated that security should be taken as the first class citizen and be addressed before the system is designed.

II. P ERFECTLY- SECRET ENCRYPTION

Perfect secrecy is a security definition put down in the language of discrete probability. We give a background introduction
of discrete probability as in § A-A. Here, we first present the SKE scheme in the language of probability. Then, we formulate
the definition of perfect secrecy.

A. Describing encryption scheme in probability 09/05/2019

Key, message and ciphertext are all modeled as random variables. Formally, a key is denoted by its random variable K,
value k and key space K. A message is by random variable M , value m, and message space M. A ciphertext is by random
variable C, value c, and space C. Any encryption scheme can be formally described:

k ← G EN(K)
c ← E NC(k, m)
m := D EC(k, c)
Correctness: ∀k ∈ K, m ∈ M, D EC(k, E NC(k, m)) ≡ m

B. Formulating Perfect Secrecy 09/05/2019

1) Perfect secrecy as conditional probability: The security of an encryption scheme can be naturally conveyed by the
following: “knowing the ciphertext does not give Eve any additional information about the message.” In the above scheme,
message is treated as a random variable M . Eve’s prior knowledge about the message is modeled by the probability distribution
about the event that M takes different values in M. Intuitively, the more the distribution is fixed and is close to the actual
value of the message, the more knowledge Eve has. In a ciphertext-only attack, Eve’s posterior knowledge about the message
is the posterior probability P r[M = m|C = c]. Thus, the additional knowledge Eve obtained through observing the ciphertext
in a ciphertext-only attack is P r[M = m|C = c] − P r[M = m]. The idea of perfect secrecy (§ Def-2.3) is that by observing
the ciphertext Eve does not gain any extra knowledge about what value a message may take. This idea can be formalized by:

P r[M = m|C = c] − P r[M = m] = 0 (1)

6
 2) Perfect secrecy as perfect indistinguishability: The idea of indistinguishability is to consider a message domain of two
values m0 , m1 and to formulate the security by Eve’s inability to distinguish the case that the message (a random variable)
takes one value (m0 ) from the case that it takes the other value (m1 ). By considering two message values m0 , m1 , it simplifies
the setting and security analysis. Informally, one can convey the idea of indistinguishability of perfect secrecy as following:

Fixing c, ∀m0 , m1 , P r[E NC (K, m0 ) = c] = P r[E NC (K, m1 ) = c] (2)

It is proven in the textbook (§ Eqn-2.1) that the above perfect indistinguishability is equivalent to perfect secrecy as conditional
probability.
More fundamentally, perfect indistinguishability gives us a standard and generalizable way of defining security through
security games/experiments (for describing threat model) and indistinguishability (describing the security goal).
Security game for private-key encryption, P RIV K, is defined as an interaction between a challenger C and adversary A:

P RIV K EAV :
C A
m0 , m1 ←M
k ←G EN(K)
b ←{0, 1}
c ←E NC(k, mb )
b′ ←A(c)
The success of a game is defined to be b = b′ , namely
P RIV K = 1.
def
Adversarial advantage is A DV = P r[P RIV K = 1] − 21
Perfect indistinguishability is defined by requiring a zero adversarial advantage, namely A DV = 0.

C. One-time pad 09/10/19

One-time pad is a simple construction of private-key encryption that satisfies: 1. K has the same size with M, 2. G EN
generates k by following a uniform distribution in K, 3. E NC and D EC algorithms are bitwise XOR.

c := E NC(k, m) = k ⊕ m (3)
m := D EC(k, m) = k ⊕ c
The preliminary of XOR operation is described in § B-A.
1) Security of OTP: Is OTP perfectly secret? 09/10/19:
Theorem 2.1 (Thm §2.9): OTP is perfectly secure. ∀c ∈ C, m ∈ M, P r[M = m|C = c] = P r[M = m]
Proof
P r[C = c|M = m] = P r[E NC (K, m) = c]
= P r[K ⊕ m = c]
1
= P r[K = c ⊕ m] =
2|K| X
P r[C = c] = P r[E NC (K, M ) = c] = P r[E NC (k, m′ ) = c]
∀m′ ∈M,∀k∈K
X X X
= P r[E NC (k, m′ ) = c] = P r[E NC (K, m′ ) = c]
∀m′ ∈M ∀k∈K ∀m′ ∈M

Event E NC(K, m′ ) = c can be expressed in a different form: P r[C = c ∧ M = m′ ]. Therefore,

X
P r[C = c] = P r[C = c ∧ M = m′ ] (4)
∀m′ ∈M
X
= P r[C = c|M = m′ ] · P r[M = m′ ]
∀m′ ∈M
1 X 1
= P r[M = m′ ] =
2|K| 2|K|
∀m′ ∈M

7
 P r[C=c|M=m]
Due to Bayes’ theorem, P r[M = m|C = c] = P r[C=c] · P r[M = m]

1
2|K|
∴ P r[M = m|C = c] = 1 P r[M = m] = P r[M = m] (5)
2|K|

(Takeaway intuition: P r[M = m|C = c] is about cracking D EC; given C =c, find a k s.t. M =m. And P r[C = c|M = m]
is about E NC; given M =m, find a k s.t. C =c. )

D. Are OTP and Perfect Secrecy Useful? (Their Practical Limitations) 09/10/19
Real-world application: Red phone: During the Cold War, the “red phone” links US president and USSR chairman using
OTP. Stage 1) Before the phone call, a trusted courier working for the US government flies to a preset location to meet a
courier working for the USSR government. During the meeting, they shared the “pad” or one-time key which is usually a long
string printed on papers in a briefcase. Stage 2) Then, during the phone call, the audio stream is encrypted using the shared
pad in the OTP scheme.
1) One-time use of OTP key: An OTP key can only be used for encrypting one message. In other words, OTP with fixed
key is not secure in ciphertext-only attacks with multiple messages.
More specifically,

m1 ⊕ k = c1 (6)
m2 ⊕ k = c2
∴ m1 ⊕ m2 = c1 ⊕ c2
Observing c1 and c2 , Eve can know about m1 ⊕ m2 . Further more, observing c1 , c2 and m1 (e.g., “hello” message in a
handshake), Eve can know about m2 .
2) Key Length:
Theorem 2.2 (Thm §2.10): In any perfectly secure encryption scheme, |K| ≥ |M|.
Proof Fix c, consider a message subspace M (c) where ∀m ∈ M(c), ∃k ∈ K s.t. D EC (c,k)=m. Therefore, |M(c)| ≤ |K|.
To prove the theorem by contradiction, assume |K| < |M|. Thus, |M(c)| < |M|. That is, ∃m′ ∈ M ∧ m′ 6∈ M(c).
P r[M = m′ ] 6= 0 = P r[M = m′ |C = c]

Fig. 1: Perfect secrecy implies a large key space.

The takeaway (or intuition) here is that if m′ ∈ M − M(c) exists, Eve observing c can know, with certainty and high
confidence, that the original message m (=D EC (k,c)) cannot take value m’.

III. P RIVATE - KEY ENCRYPTION

A. Computational security (§ 3.1)
1) Motivation: Attack a Practical Scheme?: A practical encryption scheme is built on a key space smaller than message
space (K| ≤ |M|).
def
For such schemes, regardless the specific algorithms in E NC/D EC, it immediately follows that ∃m′ ∈/ M(c) = {m|∀k, m =
D EC(k, c)}. Intuitively, knowing c gives the adversary extra information about the message distribution (like the message that
c decrypt to cannot be m’, although the adversary may not know what m’ is). This extra information can be turned into actual
attacks.
To design such attacks, we consider KPAattacks (where the adversary has the prior knowledge about some pairs of messages
and ciphertexts, say mi , ci under the key unknown to her).

8
 First, Eve can mount exhaustive-search attack: 1) In the offline phase, Eve brute-forces the key space K and for each key
encountered say k, she tests if ∀i, E NC(k, mi )? = ci . If so, she stops and claims to find the key. 2) In the online phase, Eve
uses the found key k to decrypt an observed ciphertext c.
In this exhaustive-search attack, Eve runs an algorithm of complexity O(|K|) with success rate 100%.
Second, Eve can make one guess by randomly picking one key, k, from the key space and test the same, that is,
∀i, E NC(k, mi )? = ci .
1
In this one-guess attack, Eve runs a constant-time algorithm with success rate |K| .
As long as we have a small key space |K| ≤ |M|, the scheme is subject to these two attacks. To design a practical and
secure encryption scheme, the idea is to make these two attacks “difficult” to succeed in practice. More specifically, we want
to make it hard to exhaust the key space in the first attack. We also want to make the success rate very small (but not equal
to zero ... ) in the second attack.
More generally, to bypass the limitation of perfect secrecy, we consider two relaxations that are needed: 1. A is
computationally bounded in that she can only run “efficient” algorithms (in the relaxed threat model), and 2. allow a small
adversarial advantage (as the relaxed security goal).
2) Formalizing Computational Security: Security parameter n is the key concept to formalize the notion of the two
relaxations. An efficient adversary can only run a PPT algorithm with respect to n as input length to the algorithm. Note
that PPT stands for probabilistic polynomial-time algorithms; probabilistic algorithms are use to generate keys and model A’s
strategy. Polynomial-time algorithms are those have polynomial-time complexity w.r.t. the input length.
It allows a small adversarial advantage (over the random guess in succeeding the game), formulated as a negligible function
w.r.t. security parameter, NEGL (n). A function NEGL(·) is negligible when ∀x, ∀p(·) where p() is a polynomial function,
NEGL(x) < 1/p(x). For example, NEGL(x) = 1/2x .
Fact: The two relaxations are necessary for the key space to be smaller than message space (|K| < |M|). Why (Exercise
3.12)

B. Computationally secure encryption (§ 3.2)

Encryption scheme Π (G EN,E NC,D EC) consists of three PPT algo-
rithms:
k ← G EN(1n )
c ← E NC(k, m)
m := D EC(k, c)
← (:=) denotes probabilistic (deterministic) assignment.
Correctness: ∀k ∈ K, m ∈ M, D EC(k, E NC(k, m)) ≡ m
Security definition(IND-EAV):

The threat model of ciphertext-only attack is formulated by running P RIV K EAV (n),
parameterized with security parameter n (for PPT A) and challenger’s choice of bit b.
Game (computational security) P RIV K EAV (n)

P RIV K EAV (n):

C A
m0 , m1 ←M
n
k ←G EN(1 )
b ←{0, 1}
c ←E NC(k, mb )
b′ ←A(c)

Successful game: b = b′ , denoted by P RIV K EAV (n).

Security goal: The security of indistinguishability requires that the adversarial advantage
def
A DV = P r[P RIV K(n) = 1] − 12 is negligible, or A DV ≤ NEGL(n).

C. Stronger security notion (CPA) § 3.4

1
1) Multi-encryption security (09/12/19): Multi-encryption security is defined by P r[P RIV K EAV-MUL (n) = 1] − 2 <
NEGL(n) where the game is below:

9
 P RIV K EAV-MUL (n):
C A
{m0,1 , . . . , m0,t } ←Mt
{m1,1 , . . . , m1,t } ←Mt
k ←G EN(n)
b ←{0, 1}
c1 ←E NC (k, mb,1 )
...
ct ←E NC (k, mb,t )
b′ ←A({c1 , . . . , ct })

Theorem 3.1 (Thm §3.2): Any deterministic encryption scheme can not be indistinguishable (secure) under the multi-
encryption ciphertext-only attacks.
Proof Consider a concrete game P RIV K EAV-MUL : 1. A outputs two message vectors: m ~ 0 = {0l , 0l }, m
~ 1 = {0l , 1l }. 2. upon
′ ′
receiving ~cb = {c0 , c1 }, A’s strategy is that b = 0 when c0 = c1 ; otherwise b = 0. This concrete game always succeed
with probability 1 because deterministic encryption will encrypt 0l and 0l to the same ciphertext, yet 1l and 0l to different
ciphertext (otherwise it can’t decrypt). That is, P r[P RIV K EAV-MUL = 1] = 1.
Message length is assumed to be public information in private-encryption schemes. In practice, message length may be
disclosing sensitive information, like an employee salary being a 5-digit number or a 6-digit number or the number of records
in a patient database may disclose the patients have cough or cancer. In this case, developers are responsible to pad the
messages to the same length.
Here, we use indistinguishability to describe the security. However, the same security can be equivalently defined in a
more semantic way, that is, reflecting the intuition that disclosing ciphertext does not disclose any partial information about
the message. This is called semantic security. Here, semantic security to indistinguishability is like perfect secrecy to perfect
indistinguishability. It is proven semantic security is equivalent to indistinguishability in most encryption/authentication schemes
mentioned in the textbook. Indistinguishability is used as the working definition in this course.
2) CPA security (09/17/19): CPA attacks in the real world: In a shared terminal, Alice uses the computer with her secret
key to send encrypted messages over to the Internet. Alice left without logging herself out. The shared terminal is used by
Eve, where Eve can send messages to the encryption engine (algorithm), yet cannot directly observe Alice’s secret key.
During the Battle of Midway, Japanese military base encrypted message (”Midway”) and telegraphed the ciphertext (”AF”)
to their battleships. US navy intercepts the ciphertext telegram (”AF”) and had an initial guess that ”AF” corresponds to
”Midway”. To confirm the guess (and to convince white house to deploy aircraft carrier), US intelligence sends out a fake
message ”Water shortage on Midway”, intended to be visible to Japanese. By observing ”AF” is mentioned in the next round
of communication, US intelligence now confirms that ”AF” maps to ”Midway.” In this process, US, the eavesdropper, decided
(or influenced) what message got encrypted and can observe the ciphertext.
In both examples, the eavesdropper has the capability in influencing or deciding what message can be encrypted and in
observing the corresponding ciphertext. This ability is formalized in the concept of oracle. In an encryption oracle, A invoke
E NC () function under message m of her choice, yet A cannot know the private key k. Formally stated, A has an “oracle” access
to an encryption scheme iff 1) A can encrypt an arbitrary number of messages, m2 , m3 . . . , and observe their corresponding
ciphertexts. The access to the oracle is adaptive in that A can access it as many times as it wants. 2) A does not directly
observe the private key.
CPA security definition: CPA security (IND-CPA) is defined by P r[P RIV K CPA (n) = 1] − 12 < NEGL(n) where the game
is:
P RIV K CPA (n):
C A
def
m0 , m1 ←AE NC (M) = A ←{(m2 , c2 ), (m3 , c3 ), . . . } ←O(E NC )
k ←G EN(n)
b ←{0, 1}
c ←E NC(k, mb )
b′ ←AE NC (c)

Facts: CPA (for the single message) is equivalent to CPA for multiple encryption (Thm §3.24).

10
 Fixed-length CPA-secure encryption can be extended easily to result in an arbitrary-length CPA-secure scheme. Given
a 1-bit CPA-secure encryption E NC, the arbitrary-length encryption, E NC’, is constructed by E NC′ (m1 km2 km3 . . . ) =
E NC(m1 )kE NC(m2 ) . . . . More efficient extension constructions are through the mode of operation (in §3.6).

D. Constructing an encryption scheme §3.3 09/17/19

1) PRG: Motivation: How can one test if a string of two bits, say b1 b2 , is randomly selected? One way is to run a series
of statistical tests, for instances, 1) if b1 has 50% chance to take value 1, 2) if b2 has 50% chance to take value 1, 3) if b1 ⊕ b2
has 50% chance to take value 1, etc. From a security perspective, a truly random string has to pass all possible such statistical
tests. In other words, a string is truly random from the eyes (view points) of statistical tester.
PRF definition: A generator G({0, 1}n ) = {0, 1}l is a deterministic, extension function (l > n) that extends a short string
to a long string.
A pseudorandom generator PRG({0, 1}n) = {0, 1}l is such a generator that extends a short, truly random string to a longer,
random-looking string. The short input is called seed (in space 1n ).
A distinguisher D(·) is a PPT algorithm that given a long bit string (in space 1l ) determines (or produces a binary decision)
if the string is truly random or not.
In one trial, D(·) takes as input the output string of PRG(s) with s uniformly distributed. That is, D(PRG(s)).
In another trial, D(·) takes as input a bit string r truly randomly (uniformly) picked from the space of 1l . That is, D(r).
Informally, PRG(·) is pseudorandom iff D(PRG(s)) is indistinguishable from D(r). That is, it is hard to distinguish the
l-bit string of r uniformly picked from space 1l from the l-bit string produced by PRG(s) where s is uniformly picked from
space 1n . Formally, the difference of the likelihoods of the two events, P r[D(PRG(s)) = 1] − P r[D(r) = 1], is negligible.
Definition 3.2: Generator G is a pseudorandom generator PRG if ∀ PPT DG(·) (·), P r[D(G(1n )) = 1] − P r[D(1l ) = 1] <
NEGL(n)
Intuition: An exponential-time D can iterate through the output domain (all 2l values) and observe if they are concentrated
1
in a very small subspace of the output domain (i.e., 2l−n of space 2l ). Alternatively, D checks r ∈ S2 . If so, D outputs 1
(meaning not random). If the input of D is PRG (x), P r[D(PRG(x)) = 1] = 1. If the input of D is a random number picked
n n
from 1l , P r[D(r) = 1] = 21 . Thus the probability difference is this: P r[D(PRG(x)) = 1] − P r[D(r) = 1] = 1 − 12 , which
is a large percentage close to 1.
In other words, the distribution of pseudorandom numbers in S2 (PRG) is not equal to the distribution of truly random
numbers (in S1 (PRG)) from the perspective of exponential-time D, but looks sufficiently like the uniform distribution from
the perspective of polynomial-time D. .
Discussion: The output domain of a generator G (or extension function) has three interesting sets: S1 (PRG): the output
domain itself {0, 1}l of 2l numbers, S2 (PRG): the set of all outputs of G, {G(s)|∀s ∈ {0, 1}n} of 2n numbers, and S3 (PRG):
the observable set of numbers by D or the oracle of G, O(G(·)) of polynomial numbers w.r.t n. Obviously, |{0, 1}l| >
|{G(s)|∀s ∈ {0, 1}n}| > |O(G(·))|.
In this setting, G is pseudorandom if the distribution of numbers in S2 (PRG) (generated by G) looks like a uniform
distribution in S1 (PRG) from D’s perspective (who can only see S3 (PRG)). Formally, “looks like” is formalized by
“indistinguishability” as above.
Facts: Generator by appending XOR sum of the bits is not PRG (Example §3.15); D can be simply checking if ml ? =
mi ⊕ m2 . . . ⊕ ml−1 which results in 1/2 probability advantage.
2) Construction OTP-PRG: : PRG can be used to construct a fixed-length encryption scheme: k ←G EN(1n ), c :=G(k)⊕m,
m :=G(k) ⊕ c. Here, m, c ∈ {0, 1}l(n) . It is EAV-secure, but not EAV-MUL-secure (deterministic). To make the construct
CPA secure, PRG is not sufficient.

E. Constructing CPA-secure encryption (§3.5) 09/19/2019

1) PRF: A function f is a mapping: {0, 1}n → {0, 1}n. A function can be stored in a table of 2n rows of n-bit output
strings. There are n · 2n bits.
A function generator (or keyed function) is a mapping from a key (of n bits) to a function f . By analogy, a key in
PRF is a seed in PRG. A keyed function is F : {0, 1}n(key) → f (generated function),1 where A generated function is
F k : {0, 1}n(block) → {0, 1}n(block).
PRF: Intuitively, a function generator is pseudorandom if it maps a short, random key to a long, random-looking function.
A “random-looking” function means the following: If the distribution a generated function over the choice of k (i.e., PRF k (·))
n
is close enough to the (uniform) distribution of a random function (i.e., randomly picked from the space of 2n·2 possibilities).
In other words, this indistinguishability:
PRF(·) is a function generated by PRF with random k. f (·) is a random function uniformly picked from its space. D
interacts with a blackbox which can encapsulates either a generated function or a random function. D interacts with the
1 This differs the format in textbook.

11
blackbox through adaptively sending an arbitrary number of input message {m} and observing their outputs {O(m)}. The
distinguisher D produces a binary result about what is in the oracle is a generated function (PRF k (·)) or a random function
(f (·)).
Definition 3.3: A keyed function is PRF if ∀ PPT D PRF(·,·),PRF k (·) (1n ), P r[D PRF k (·) (1n ) = 1] − P r[D F(·) (1n ) = 1] <
NEGL(n)
Fact: One-time pad is not a PRF (details see Example §3.26): OTP PRF(k, x) = k⊕x generates function PRF k (·) given a key
k. Suppose an oracle O encapsulating either generated function PRF k (·) or randomly chosen function f (·). Given this oracle,
a distinguisher D(x1 , x2 , y1 = O(x1 ), y2 = O(x2 )) works by returning x1 ⊕ x2 == y1 ⊕ y2 ?1 : 0. Thus, D PRF k (·) (...) ≡ 1
n
with 100% probability, and Df (·) (...) = 1 at probability 1/2 . (The latter can be worked out by an example with n = 1 and
x1 , x2 are one-bit strings). Their difference is 1 − 21n which is not negligible.
Block cipher/Pseudorandom permutation: A permutation is a bijective function (one-to-one mapping). Its input domain is
the same to its output domain. If a PRF generates permutations, it is a pseudorandom permutation generator (or block cipher).
It is defined as PRP : {0, 1}lk , {0, 1}l → {0, 1}l (lk is key length). The security of PRP follows PRF.
Block cipher is a term used in practice for PRP with fixed key length.
Facts: PRF can be used to construct PRG and stream cipher; PRG(s) = F s (1)kF s (2) · · · F s (l). Vice versa, PRG can be
used to construct a PRF with small block length (polynomial number of rows); result of PRG (k) is interpreted as a table of
n rows, thus log(n) block length.

2nn

S1=F(*,*)

n
Key S2=PRF({0,1}n,*)
space

poly(n)
n2^n S3=O(Fk),
2n PRF(*,*)
2 O(F) poly(n)
Fk(*)
Distinguisher

n
Fig. 2: Intuition of PRF: There are two spaces: a space of 2n functions called S1 , and a space of 2n·2 called S2 . S1 is the
space of generated function by PRF(·) and S2 is the space of any function mapping n-bit input to n-bit output.A pseudorandom
function generator requires the distribution of generated function in S1 “looks like” the distribution of random function in S2 ,
through the lens of a PPT distinguisher who can only observes the subset of both S1 and S2 ).
2) OTP-PRF: a CPA-secure construction:
Construction (OTP-PRF): CPA-secure encryption with fixed-length message n:
n n
• G EN(1 ): choose uniform k ∈ {0, 1} and output it.
n n
• E NCk (m ∈ {0, 1} ): choose uniform r ∈ {0, 1} and output the ciphertext

def
c :=hr, c′ = F k (r) ⊕ mi (7)
• D ECk (c = hr, si): output
m :=F k (r) ⊕ c′ (8)

Correctness can be easily established. Security proof (see Thm §3.31).

Take away points: OTP+PRG is insecure under CPA attacks because of deterministic encryption. In other words, there is
only one source of randomness in OTP+PRG. To add another source of randomness (for probabilistic encryption), PRF is a
mapping that takes two random numbers as inputs. PRF(·, ·). Using PRF in encryption scheme, the private key is used as the
first random input. The second random input is generated each time encryption is invoked.

IV. M ODES OF OPERATION (09/26/19)

Motivating problem: In real-world scenarios, there are needs to encrypt messages of long and abitrary length. Think about
live broadcasting (TV or radio) as an example, where the audio/video message to encrypt is “streamed” and its length is long

12
and cannot be known in advance. So far, we just talked about fixed-length encryption schemes, like OTP+PRG and OTP+PRF.
They cause problems in the scenario with arbitrary-length long messages.
For instance, consider OTP-PRG (c :=PRG(k) ⊕ m) where PRG is defined as a mapping from 1n to 1l where l is fixed.
It requires l or message length to be fixed before E NC is invoked, which is impossible in the streaming scenarios. Supporting
streamming message is the problem tackled by stream cipher mode of operations (§ IV-A).
For another instance, consider OTP-PRF (c ←PRF k (r) ⊕ mkr) where the ciphertext c has double the length with plaintext
m. For a long message, it is not a good news (for a message of 2 GB, this means the ciphertext of 4 GB). Supporting shorter
ciphertext is the problem tackled by block cipher mode of operations (§ IV-B).

A. Stream cipher mode of operation

1) Stream cipher: Stream cipher is a specialized PRG generating random numbers of abitrary length. In other words, it
provides a continuous source of randomness.

✥
✞✦✜✜✧☞

✝ ✮✯✰ ✮✯✱ ✮✯✲

✌✍ ✌✍ ✌✍ ★★★ ✌✍
✞✟✠✡☛☞ ✎✏✑✒✓✔✒✕✖

✗✘
✞✟✠✡☛✡✙✚ ✛✜✢☛✣✤☞
✁✂✄☎✆ ✩✪ ✩✫ ✩✬ ★★★ ✩✭

Fig. 3: Stream cipher

The scheme consists of two deterministic algorithms (I NIT,G ET B ITS). The cosntruction is below and is also illustrated in
Figure 3.
Algorithm 1 PRGByStreamCipher(seed s, initialization vector IV )
1: st0 :=I NIT(s, IV )
2: for all i ∈ [1, l] do
3: (yi , sti ) :=G ET B ITS(sti−1 )
4: return y1 . . . yl
5: end for

Fact: In OTP +prg, PRG handles key extension (into the pad) and the mode of operation is about extending fixed-length
message to abitrary length.
2) Synchronized mode: What it is?: For one message m of message blocks m1 m2 . . . mi , it produces a stream of ciphertext
blocks c1 c2 . . . ci :

PAD1 PAD 2 . . . PADi := PRG − sc(k)

c1 := PAD1 ⊕ m1
c2 := PAD2 ⊕ m2
...
ci := PADi ⊕ mi
Use case and why it’s called Synchronized mode: Alice and Bob maintain a scynchronized state about what index i it
is to encrypt/decrypt the current block of message/ciphertext. Given mi , Alice needs to know i to get the correct PADi for
encryption. Given ci , Bob needs to know i to get the correct PAD i for descrpytion. It is applicable in scenarios with online
Alice and Bob, where Alice and Bob can synchronously maintain this dynamic state. It is also called stateful.
3) Unsynchronized mode: What it is?: For message m of message blocks m1 m2 . . . mi , it produces a stream of ciphertext
blocks c1 c2 . . . ci :

PAD 1 :=PRG − sc(k, IV 1 ); c1 :=PAD 1 ⊕ m1 kIV 1

PAD 2 :=PRG − sc(k, IV 2 ); c2 :=PAD 2 ⊕ m2 kIV 2
...
PADi :=PRG − sc(k, IV i ); ci :=PADi ⊕ mi kIV i

13
 Use case and why it’s called Unsynchronized mode: Alice/Bob encrypting/decrypting mi /ci can just do so by knowning
k, IV i , without any dependency with j 6= i (e.g., no need to know IV j or cj ). In other words, there is no state need to be
maintained across blocks. It is called stateless mode of operation.

B. Block cipher mode of operation

Recall that Block cipher is a permutation selected by key k, whose input and output strings have the same length. In OTP
+prf, it produces the ciphertext of double length with the message.
Block cipher mode of operation supports encryption with shorter ciphertext.
1) ECB: ECB is the most basic. c :=hPRF(m1 )kPRF k (m2 ) . . . kPRF k (ml )i. ECB is deterministic.
2) CBC: CBC or cipher block chaining. Mode of encrypting a single variable-length message in CBC is: c :=IV kPRF(IV ⊕
m1 )kPRF(c1 ⊕ m2 ) . . . kPRF(cl−1 ⊕ ml )
CBC is CPA-secure if PRF is pseudorandom function.
For encrypting multiple (variable-length) messages, CBC can use different IV for different messages. But there is another
stateful approach, where the IV for the second message is (or reuses) the last ciphertext block in the first message. This
stateful approach is called chained CBC. It is illustrated as in Figure 3.8 in the textbook.
Fact: chained CBC is not CPA-secure (one can construct a successful CPA-attack: mB A A B
1 = IV ⊕ cl ⊕ m1 ⇒ c1 = c1
A
A B
where m and m are two separate messages).
Summary: Modes of operation in encryption E NC (m) are about encrypting multiple messages of variable length. Given a
CPA-secure encryption is probabilistic, there are per-key randomness (as in s) and per-message randomness (as in IV ). When
encrypting a message of variable length, the randomness (s and IV ) is fixed, and modes of operation deal with mapping
variable-length messages to the block interface of block cipher. When encrypting multiple messages (under the same key),
modes of operation deal with how to manage per-message randomness across different message? Two strategies: to reuse the
randomness (stateful) or to simply get a fresh random IV for each message (stateless). For stateful, it can be reuse state of
stream cipher, last ciphertext block, etc.

V. M ESSAGE AUTHENTICATION C ODE (MAC) 10/03/2019

Application scenario: Imagine Alice, a computer user, updates her OS by downloading software patches from Bob, the
software-distribution server. In this scenario, Alice downloads software security patches in plaintext message m from Bob via
the Internet. There is a malicious router A on the Internet which relays the message m from Bob to Alice. A can simply
modify or forge a different software patch, say malware m’, and relays that to Alice. Alice may end up running a malware
m’, instead of security patch m, on her computer.
To avoid this, question is how can Alice be rest-assured that the message Alice receives is identical to the message Bob
sends? In other words, how can one detect the message-forging adversary A?

A. The Scheme of MAC

Scheme: Π (G EN,MAC,V RFY)
t ← MACk (m)
1, 0 := V RFY k (m, t)
Using the scheme in our scenario, Alice runs t ←MACk (m) and sends out m, t to Bob. Adversary A may want to produce
m′ , t′ and fool Bob to run V RFY k (m′ , t′ ) = 1 successfully.
Correctness: Fixing k, ∀m, Π is correct iff V RFYk (m, MAC k (m)) ≡ 1.

B. Security definition
First, let’s look at an example construction of MAC that, intuitively, is not secure. After that, we will describe how to
formulate the security of MAC scheme.
In this example construction, we attempt to use the OTP-PRG encryption for providing authenticity. That is, given
?
c :=PRG(k) ⊕ m, c is (ab)used as t. In V RFYk (m, t), it runs PRG(k) ⊕ t =m. Clearly, this scheme is correct. But intuitively,
it isn’t secure: Flipping a bit in m and c/t results in a valid message,tag pair that passes V RFY. Also, the message-forging A
can work out PRG (k) by t ⊕ m, and then for any forged message m’, forge t′ = (t ⊕ m) ⊕ m′ . This pair of m′ , t′ will pass
V RFY ().
Side-note: In this counter-example, it also says authenticity is not confidentiality. A EAV-secure encryption construction
may not be a good candidate for MAC.
MAC Security: Given Π, A, n, the adaptive chosen-message attack game M AC F ORGE ACMA is

14
 ACMA
M AC F ORGE A,Π (n):

C A
n
k ←G EN(1 )
m, t ←AQ(MAC k (·)) (1n )
?
V RFYk (m, t) =1
Note that the oracle in this game O(MAC k ) is the following: Adversary A sends chosen
messages {mi } to the oracle service Q(MACk ) which hides the key k. Given {mi },
Q(MAC k (·)) returns tags {ti }. Given {mi , ti }, A runs a PPT algorithm to produce m and to
forge a tag t.
def
The success of the game is defined as M AC F ORGE ACMA = 1 = V RFYk (m, t) = 1 ∧ m 6∈ Q.
A MAC scheme is existentially unforgeable under the ACMA game M AC F ORGE ACMA when
ACMA
P r[M AC F ORGE Π,A (n) = 1] ≤ NEGL(n) (9)

Fact1: message authentication versus user authentication: message authentication ensures the message Bob receives is the
same with what Alice sends. user authentication means Bob is convinced that the message received is indeed from Alice “the
person”.
Fact2: MAC versus error-correction code (ECC): 1) MAC detects while ECC both detects and recover. 2) MAC handles
malicious message change while ECC handles random change of a small portion of the message. (Exercise XXX)
Fact3: timing attack on V RFY implementation. through side-channel timing info., one can gain advantage in guessing
“correct” tag.
Fact4: MAC is not secure under replay attack.

C. Constructions
1) Fixed-length MAC by PRF:
MAC : t :=PRF k (m)
?
V RFY : t =PRF k (m)
Fact1: Canonical implementation of V RFY: When MAC is deterministic, one can reuse MAC for V RFY.
Security proof
To prove the MAC construction is ACMA-unforgeable, the key technique is to construct a simulation where the distinguisher
D’s view in PRF is simulated by C interacting A in M AC F ORGE ACMA . The simulation is a type of reduction techniques used
to proof security. Figure 4 illustrate the construction.

Fig. 4: Intuition of proving MAC security

Then, the general “template” for proving the security of a PRF-based construction is 1) proving the security (negligible
probability of the game) given a truly random function, 2) use the simulation technique to prove the probability of the game
given PRF is “indistinguishable” with that given truly random function (case 1).

15
 2) Variable-length MAC by CBC-MAC (§ 4.11): Consider variable-length message m = m1 , . . . , ml where each mi is a
block of length n. The CBC-MAC construction is:

(10)
MAC : t0 :=0n
ti :=PRF k (ti−1 ⊕ mi )
t :=tl
?
V RFY : kmk = l ∧ t =MACk (m)
Fact1: CBC-MAC versus CBC-mode encryption: The former uses zero IV (or t0 ) while the latter uses random IV; the
former outputs only tl while the latter outputs all PRF results.
Fact2: arbitrary-length MAC is by using m′ = l, m1 , m2 , . . . ml as the input of fixed-length MAC.

D. Authenticated Encryption (10/08/2019)

1) Scheme:
c ← E NC k (m)
{m, ⊥} := D ECk (c)
2) Security Definition:
AUTH KCPA (n):
C A
n
k ←G EN(1 )
c ←AE NCk (·) (1n )
def
∗Q = All messages queried in O
m :=D ECk (c)
* Footnote: We use red text to denote the part of security definition relevant to oracle.
def
The success of the game is defined to be AUTH K CPA (n) = 1 = m 6= ⊥ ∧m 6∈ Q.
The private-key encryption scheme Π is unforgeable when

P r[AUTH K CPA (n)] ≤ NEGL(n) (11)

3) Constructions: Construction: enc-then-auth. Given two keys k e and k m , the encryption algorithm is
?
E NCke (m)kMACkm (c). Decryption algorithm is V RFYkm (c, t) =1?D ECke (c) : ⊥.
Fact1: Conceptually, there are other two alternatives: auth-then-enc, and enc-and-auth. It can be easily seen that enc-and-auth
is not secure as tag is revealed which leaks confidentiality.
Fact2: Two keys (k m and k e ) must be independent! Counterexample: E NC is PRF k (mkr) and MAC is PRF −1 k (c).
Fact3: Using authenticated encryption as it is without any state is vulnerable to replay, reorder, reflection attacks.
Maintaining a message counter is the solution.

{m1,m2} Replay {m1,m1,m2}

Reorder {m2,m1}
Alice Mallory Bob

Fig. 5: Mallory attacking on message ordering by reordering and replay messages between Alice and Bob.
4) Beyond Data Integrity: Replay and reorder attacks: Consider Alice sends a sequence of messages to Bob, as in Figure 5.
Bob wants the messages are received in the correct “order” as sent by Alice.
Even the messages are AE-encrypted, Mallory A can forge the order among messages and pass the verification. Given
messages m1 , m2 , a reorder attacker forwards the messages in different order, say m2 , m1 . In applications of video streaming,
reordering attacks may lead to Bob playing video frames out of order.
Given message m1 , a replay attacker forwards multiple copies of the message m1 , m1 to Bob. In applications such as web
shopping, replaying messages may lead to Bob (amazon.com) charges Alice’s (amazon user) account twice.
AE does not defend replay or reorder attacks. Instead, maintaining a stateful monotonic counter synchronously on Alice and
Bob will fix the problem. Alice will send out E NC(m1 , mcAlice + +); to Bob who runs D EC(c1 , mcBob + +);.

16
 VI. H ASH F UNCTIONS (10/08/2019)
A. Scheme
Definition 6.1 (Fixed-length hash h): A fixed-length hash h is a compression function of its input space (called preimage
space) larger than its output space (called digest space).
Definition 6.2 (Variable-length hash H): A variable-length hash H is a compression function: H : {0, 1}∗ → {0, 1}l.
Formally, a variable-length hash function is a scheme of two algorithms, Π (G EN, H):

s ← G EN(1n )
y := H s (x)
Fact1: s is different from encryption key k in: 1) s is not private, 2) s is not chosen uniformly (and generated by G EN ()):
There are “invalid” hash keys where H s (·) is not legitimate.

B. Security
1) Collision Resistance: Collision resistance: collision exists (as long as l′ > l), but it is difficult to find one. Formally,
collision resistance is defined by H ASH C OLL (n):
Security game H ASH C OLL (n) is
C A
n
s ←G EN(1 )
m0 , m1 ←AO(H) (1n )
?
H(m0 ) =H(m1 )

def
H ASH C OLL(n) = 1 = H(m0 ) = H(m1 ) ∧ m0 6= m1
H is a collision-resistant hash function (CR-H ASH) iff. the following holds:

∀A, P r[H ASH C OLL(n) = 1] ≤ NEGL(n)

2) Weaker Security: There are weaker security notions that collision resistance.
Second preimage collision resistance: informally, given the first preimage x, it is difficult to find the second preimage x′ ,
s.t., H(x) = H(x′ ).
Onewayness: informally, given the digest y, it is difficult to find a preimage x, s.t., H(x) = y.

C. Generic Attacks
1) Brute-force Attack: Instantiating the adversary in H ASH C OLL gives us collision-finding attacks.
One attack strategy is to iterate through the space of digests 1l (Recall H : {0, 1}L → {0, 1}l). If we try N = 2l + 1 distinct
preimages, 100% chances are that there is at least one collision. This is due to pigeonhole principle (If we put N + 1 pigeons
into N holes, at least one hole will end up with at least two pigeons.)
√ if we want 50% chances to find a collision, how many samples of preimages does an attacker need to try? The answer
But
is N . It leads to birthday attacks. √ l
2) Birthday Attack: In a Birthday attack, the adversary tries just N = 2 / 2 + 1 hash preimages, high chances (50%) are
that she will find a collision among these preimages.
We can play a game in classroom: The teacher wants to find “Birthday collision” among students, that is, two students
having the same day of their Birthdays √ (just the same day in a month). If the teacher samples 32 students, he will find one
for certainty. But if he sample just 32 ≈ 6 students, high chances are he will find students having birthday collisions.

D. Hash-based Primitives
1) MAC domain-extension: Hash-and-MAC: A variable-length MAC, (G EN’,MAC’,V RFY’) is constructed by a fixed-length
MAC, (MAC,V RFY) and a variable-length hash function, (G EN,H). The construction is called Hash-and-MAC:

(12)
′ n n n
G EN (1 ) : k ←{0, 1} , s ←G EN(1 )
t :=MAC′ (m) : MACk (H s (m))
V RFY′ (t, m) : V RFY(t, H s (m))

17
 Fact1: In Hash-and-MAC, the resultant MAC’ is a secure variable-length MAC, when H is collision resistant and MAC’
is an MAC.
Fact2: In hash-and-MAC, the “hash” is a var-length hash for domain extension, and the “MAC” is a fixed-length MAC.
2) Hash domain-extension (from h to H): Merkle-Damgard and Merkle trees: Merkle-Damgard construction: arbitrary-
length hash (G EN,H) has arbitrary input length bounded by L < 2n . Fixed-length hash (G EN,h) has input length 2n (w.l.o.g).
Both have output length n. Merkle-Damgard construction constructs (G EN,H) by (G EN,H) as below:
• input x :=x1 , x2 . . . , xB , where each xi is of block length n, and B = L/n.
•

H(x) : y0 :=IV
yi :=hs (yi−1 kxi )
y :=yB
Fact1: CBC vs Merkle-Damgard: in CBC, an iteration is using PRF with ⊕, while in Merkle-Damgard, an interaction is h
with concatenation.

✁✂✄☎
✙✚✛✜✢✣✤✥✦✧★
✆✝ ✞✟ ✠✡
☛☞ ✌ ✫ ✬ ✩✭ ✪
✏ ✑ ✒✓ ✍✎ ✮✯ ✴✵✶
✔✕✖ ✗ ✲✳
✘ ✷
✰✱ ✸

Fig. 6: Comparing Merkle-Damgard with CBC-MAC

Merkle hash tree or MHT is a construction paradigm that can be applied to different applications. One canonical
application of Merkle tree paradigm, similar to Merkle-Damgard paradigm, is hash domain extension, constructing an
arbitrary-length hash out of compression function. That is, G ENH , d ←MT t (b1 kb2 k...kbt ), and the implicit verification is
{1, 0} :=V RFY (b1 k...kbt , d) (Note that b1 k...kbt is a message of t blocks).
def
MT 2 (b1 , b2 ) = h(b1 kb2 )
Another application of Merkle tree paradigm is for multi-message (set-membership) MAC where the above scheme is
extended with an interactive verification sub-protocol (i.e. query and verify of individual messages). Here, we only consider
the first application of Merkle tree (i.e. hash domain-extension) to describe its security.
def
MT 2 (m1 , m2 ) = h(h(m1 )kh(m2 ))
The security definition (collision resistant) of Merkle tree is formulated in similar way to that of hash (collision-finding
game).
Theorem 6.3: The security of Merkle tree relies on the security of underlying hash. Formally, if (G ENH , H) is collision
resistant and t is fixed, (G ENH , MT t ) is collision resistant.
Proof We prove by contradiction. If MT H is not collision resistant, H H is not collision resistant. W.l.o.g., we consider t = 2.
MT H (·) is not collision resistant, thus a PPT A can easily find ma1 kma2 , mb1 kmb2 s.t. MT (ma1 kma2 ) = MT (mb1 kmb2 ).
MT (ma1 kma2 ) = H(H(ma1 )kH(ma2 )).
∴ H(H(ma1 )kH(ma2 )) = H(H(mb1 )kH(mb2 ))
∴ H(ma1 )kH(ma2 ) = H(mb1 )kH(mb2 ). (Otherwise, we find a collision for H(·)).
∴ H(ma1 ) = H(mb1 ). ∴ ma1 = mb1 . (Otherwise, we find a collision for H(·))
Similarly, ma2 = mb2 .
Therefore, ma1 ma2 = mb1 mb2 which contradicts the assumption ma1 ma2 6= mb1 mb2 .
This proves that for MT 2 , the equality of the parent node implies the equality of the two children nodes. More generally,
with t = 2x > 2, one can apply the proved recursively. Thus, the equality of the root node implies the equality of all t children
nodes, hence m1 k...kmt , contradiction.
Theorem 6.4: Merkle tree of variable-length t is not collision resistant. Specifically, one can find two sets of inputs m1 k...kmt
and m′1 k...km′2t , such that M Tt (m1 k...kmt ) = M T2t (m′1 k...km′2t ).
Proof ∀z = H(xky), MT 2 (zkz) = H(zkz) = H(H(xky)kH(xky)) = MT 4 (xkykxky)

18
E. Hash Applications
Fingerprinting or hash pointer: using H(·) to digest message m, where m can be virus ID (for virus detection), cloud file
(for de-duplicated cloud storage), P2P file (for P2P file lookup)
Merkle tree: MT (m1 , m2 ..., mt ) as domain-extension of H for hashing multiple messages. The application is to digest
multiple files while allowing client to access individual files in cloud storage.
Using hash for fingerprinting and Merkle tree requires the collision resistance of hash functions.
key derivation and password hashing: key derivation is a mapping of non-uniform, high min-entropy distribution to a
uniform distribution. One application is to derive (uniform) key, required by private-key encryption, from non-uniform strings,
such as passwords, bio-metric data, etc.
Using hash for key derivation requires the random-oracle model of hash functions.

19
 VII. K EY E XCHANGE (§ 10)
A problem left pending in private-key schemes is how Alice and Bob can establish the private key initially? The first
baseline is that Alice directly sends the generated secret key to Bob. However, this may disclose the secret key to Eve (over
the insecure channel). The second baseline is that Alice distributes the secret key to Bob over an encrypted channel; say with
the key encrypted (but what is the key used for encrypting the key?).
Secure key distribution over an insecure channel is handled by key-exchange protocols. Conceptually, key distribution over
a secure channel (e.g., meet in person) is trivial and has limited applications (only in military settings).
We will talk about two constructions of key exchange; a two-party protocol, DHKE (§ VII-B) and a three-party protocol,
KDC and Needham-Schroeder (§ VII-C). The latter handles key exchange among multiple parties in an open system with
transient interactions.

A. Definitions: Schemes and Security

KE Scheme (Protocol): A KE scheme is an interactive protocol: Given Alice and Bob, a protocol Π consists of a set
of instructions and is executed by A and B, resulting in a transcript of messages exchanged between them. The following
describes the KE-protocol execution.
1 Initially, A and B hold 1n .
2 Π is interactively executed between A and B, with messages exchanged in multiple rounds. The trace of messages being
exchanged is called transcript.
3 Finally, the protocol execution produces key k A on A and k B on B.
def
Protocol correctness is defined as k A = k B .
EAV
Protocol security is defined in the security game KEA,Π below. This game runs between challenger C and an eavesdropping
A. C models the protocol execution between two running parties, C A , C B .
EAV
KEA,Π :

C A
def
C A , C B joinly run protocol Π, producing transcript T RANS and k = k A = kB
(
k ′ = k , if b = 0
Random bit b ←{0, 1}, Another “key”
k ′ ←1n , if b = 1
b′ ←AP P T (T RANS, k ′ )
EAV def
Success of game KEA,Π = b = b′ .
EAV 1
Security of a KE protocol is defined as P r[KEA,Π ]− 2 < NEGL(n)

Example: The baseline key-exchange by sending out secret key in the clear is unsecured. In this baseline construction,
transcript T RANSis key k. Adversary can then easily have non neglibability adversarial advantage that breaks the KE security
definition.

B. Construction (DHKE) and Security Analysis

1) Background: Group theory (Chapter 8 in textbook): A group defines a set of numbers and an operation, associated
with a bunch of rules. The set of numbers are commonly {0, 1, . . . , N − 1} modulo N . The operation can be addition or
multiplication. There are common rules on the operation such as closure, identity, invertible, associativity. There are derived
rules: commutativity and cancellation law.
Z∗ N denotes a multiplicative group of integers modulo N . N is group modulo base. The group contain number 1 as the
identity element and the numbers that are relatively prime to N . A multiplicative group does not contain number 0. For
instance, Z∗ 15 = {1, 2, 4, 7, 8, 11, 13, 14}.
Group order q is the number of elements in the group, |Z∗ N |. For instance, q of Z∗ 15 is 8. In general, q = Φ(N ).
∀e ∈ Z∗ , eq = 1 mod N .
Group generator: Each group element ∀e ∈ Z∗ has a per-element order q(e) which is the smallest value s.t. eq(e) = 1
mod N . Each group element g can generate a subgroup of Z∗ , by {g0 , g1 , g2 , . . . }. The order of an element is the order of
the subgroup generated by the element. And g is the generator of the subgroup.

20
 2) Group-theoretic Problems and Hardness: Discrete logarithm: Discrete log is defined by ∀h ∈ Z∗ , there is a unique
x ∈ Z∗ q , s.t. h = g x . x is the discrete log of h.
A DL problem, given Z∗ q with generator g, is to compute x = logq h for a uniform element h ∈ Z∗ .
Fact: A DL problem is a logarithm operation with elements defined in the domain of groups.
DH (Diffie-Hellman) problems: Computational DH, CDH(h1 , h2 , h3 ): Given h1 = gx and h2 = g y , it is hard to compute
h3 = gxy . Given group exponentiation is easy, the hardness of CDHrequires the hardness of DL (if DL is easy, one can obtain
x from g x and compute (g y )x ).
Decisional DH, DDH: Given h3 = CDH(h1 , h2 ), it is hard to decide if it is different from a uniform group element. DDHis
used to prove the security of DH protocol.
3) DHKE: Execution between Alice and Bob:

Alice Bob (13)

(G, q, g) ←G
x ∈ Zq
gx
→
y ∈ Zq
gy
←
y x
k A = (g ) k B = (g x )y

1 Alice runs PPT algorithm: (G,q,g)← G

2 Alice chooses uniform x ∈ Zq and computes hA :=g x .
3 Alice sends (G, q, g, hA ) to Bob
4 Bob receives (G, q, g, hA ). He chooses y ∈ Zq and computes hB :=g y . Bob sends hB to Alice and outputs key k B :=hyA
5 Alice receives hB and outputs key k A :=hxB .
Correctness: k A :=hxB = (g y )x = (g x )y = hyA = k B .
Security: Proof of security depends on the hardness of decisional DH problem (DDH). DDHfurther relies on the hardness
of DL problem (given h and y find x s.t. hx = y).
Concretely, suppose a DL problem involving a cyclic group Z∗ N = {g0 , g1 , . . . , g q−1 }, where q is group order, g is a
generator and N is modulo (which may be prime number). DH protocol works efficiently because group exponentiation is
easy. DH protocol is secure because CDH(hA , hB , k) is hard.
Fact1: basic DH construction is not secure against active adversary, including impersonation attacker who plays the role of
Alice to Bob, and man-in-the-middle attacker who modifies the messages exchanged between Alice and Bob.

C. Key-Distribution Center (KDC) for 3-Party Key Exchange

We consider extending the two-party DHKE into three-party KE. That is, given shared key k A between A and KDC (as B)
and k C between KDC and C, how can A and C exchange keys? This is useful in real applications in P2P networks.
Needham-Schroeder protocol based on KDC: a key-distribution protocol using KDC in the Kerberos authentication service.
0 Alice joins the network: running key exchange to share kA between Alice and KDC.
1 Bob joins the network: running key exchange to share k B between Bob and KDC.
2 Alice wants to communicate with Bob: running Needham-Schroeder to share session key between them.
1 Alice to KDC: “Alice wants to talk with Bob”
2 KDC: k ←{0, 1}n
3 KDC to Alice: E NC kA (k), E NCkB (k)
4 Alice to Bob: “Let’s talk, E NCkB (k)”. E NC kB (k) sent by Alice is called ticket in the protocol of Needham-Schroeder
and Kerberos. It is an encrypted session key and serves as a credential.

VIII. P UBLIC -K EY E NCRYPTION

A. Introduction: Public-Key Cryptography
Suppose a website conducts a survey among its users by collecting private user information. Assume there are N users.
For private-key encryption schemes, it requires setting up N secret keys. Using public key cryptography, it allows the website
posts one public key and all N users using the public key to send encrypted private information.
The benefits brought by PKC is 1) simplified (public) key distribution, 2) reduced number of secret keys the server needs
to maintain (one secret key in PKC versus N secret keys in SKC).
We will introduce public-key encryption (PKE) here and digital signature (DS) in § IX.

21
B. Schemes
Scheme: similar to P RIV KE scheme, except that pk, sk ←G EN(1n ).

PKEscheme ΠPKE (G EN, E NC , D EC) consists of three PPT algo-

rithms:
pk, sk ← G EN(1n )
c ← E NCpk (m)
m := D ECsk (c)

Execution between Sender and Receiver

Sender Receiver (14)

n
pk, sk ←G EN(1 )
pk
←
c ←E NCpk (m)
c
→
m′ :=D ECsk (c)

C. Security Definition
PKE schemes is different from those of PrivKE in that its EAVgame is defined the same to CPAgame.
Security definition(IND-EAV):

Game P RIV K EAV (n):

C A
m0 , m1 ←A(pk)
b ←{0, 1}
c ←E NC(pk, mb )
b′ ←A(pk, c)
Successful game: b = b′ , denoted by P RIV K EAV (n).
Security definition: P r[P RIV K(n) = 1] − 12 ≤ NEGL(n).

Game P RIV K CPA (n):

C A
{mi0 , mi1 |∀i} ←A(pk)
b ←{0, 1}
c ←E NC(pk, {mib |∀i})
b′ ←AQ() (pk, c)
Q is defined by adversary can query cb ←Q(m0 , m1 ), but without knowing b. In other words, b is hidden
in the public-key encryption oracle.

D. Domain extension
The ciphertext of multiple message blocks is the concatenation of ciphertext blocks, each produced by encrypting one
message block.
E NC′pk (m1 km2 k...ml ) = E NCpk (m1 )kE NC pk (m2 )k...E NCpk (ml )

22
E. Construction: El Gamal

(15)
n
pk, sk ←G EN(1 ) : G, q, g ←G(n)
def
x ←Zq ( = {1, g1 , g2 , ...g q−1 })
sk = x, G, q, g
def
pk = h( = gx ), G, q, g
c ←E NCpk (m) : pk = h, G, q, g
y ←Zq
def def
c = gy ( = c1 ), hy · m( = c2 )
m′ :=D ECsk (c) : m′ = c2 /c1 x
def
Note that G and (g,q) are two groups. The second group Zq = {1, g, g 2 , ...g q−1 }. The first group G is a subgroup of Zq .
Correctness: m′ = c2 /c1 x = hy · m/(gy )x = (g x )y · m/(gy )x = m.
Security (informal and intuitive): transcript pk = h, G, q, g and c1 = g y , c2 = hy · m is disclosed to Eve. Informally, discrete
log problem prevents Eve from knowing x, y from h = g x , c1 = g y . (Otherwise, knowing x, y, Eve can infer g x ).
Example 11.17: Let q =83 and p = 2q+1 = 167. Let Zq = {1, 2, 3, 4, ...82}. Let G denote the group {h2 mod p|∀h ∈ Zq };
this group is called quadratic residues module p. G is a subgroup of Zp .
Take g = 22 = 4 mod 167 to be the generator. Say the secret key 37 ∈ Z83 . The public key is pk = p, q, g, h =
167, 83, 4, 437 mod 167 = 167, 83, 4, 762
We use p to represent G and g, q to represent Zq .
Say a sender encrypts message m = 65 ∈ G (note 65 = 302 mod 167). If y = 71, ciphertext is 471 mod 167, 7671 · 65
mod 167 = 132, 44.

IX. D IGITAL S IGNATURES (§ 12)

A. Scheme
Scheme:
S IGscheme ΠSIG (G EN, S IGN , V RFY) consists of three PPT algo-
rithms:
pk, sk ← G EN(1n )
δ ← S IGN sk (m)
{1, 0} := V RFY pk (m, δ)

Correctness is defined as ∀m, {pk, sk}, V RFYpk (m, S IGN sk (m)) ≡ 1.

Execution between Sender and Receiver:

Sender Receiver (16)

pk, sk ←G EN(1n )
pk
→
δ ←S IGN sk (m)
m,δ
→
b :=V RFYpk (m, δ)

Compare and contrast: Compare the execution of digital signature in Equation 16 with that of public-key encryption in
Equation ??. We can see that G EN in digital signature runs on the sender while G EN in public-key encryption runs on receiver.
In digital signature, it is like the sender pushes the message to the receiver, while in public-key encryption, it is more like the
receiver pulls the message from the sender.
2 One can write an efficient algorithm to do group exponentiation and calculate 4 ∗ 37 mod 167 = 76.

23
B. Benefits and Distinction of Digital Signatures
1. Easy key distribution and management: Distribute public key instead of private key.
In addition, the number of secret keys a sender maintains in digital signatures is one. Whereas, the number of secret keys
in MAC is N , where N is the number of receivers. The saving in the number of secret keys is significant, for applications
involving a large number of receivers (think about distributing Windows OS patches to millions of Windows users as an
example).
2. Public verifiability: Note that in digital signatures, receiver does not need any secret key to verify the integrity of
message. Using a public key suffices to verify the message authenticity. This property is called public verifiability. It implies
transferability, that is, one receiver who verifies can simply passes public information (i.e., {m, δ}) to the next “receiver” to
verify. There is no need of setting up secret keys in transferring verifiable information, which is unlike MAC.
3. Non-repudiation: The digital signature of message m can be used as an evidence that the sender has signed message m
in the past. In other words, with digital signature, the sender cannot deny the fact that he has signed the message. Because the
sender is the only one who knows the secret/signing key, the digital signature presents itself as a proof of the sender’s signing
action in the past.
By contrast, a MAC tag does not provide non-repudiation and cannot be used as an evidence. A counterexample is the
following: Consider the receiver uses a MAC tag (i.e., t =MAC (m))) as an evidence that the sender has authenticated
message m before. Such evidence is not trustworthy (and a judge cannot take it), because a malicious receiver, knowing the
secret/authentication key, can simply produce t on a message that the sender has not authenticated before.

C. Security Definition
Game S IG -F ORGE A,Π (n):
C A
def
m, δ ←AO(SIGN sk (·)) (pk) = A(pk, Q∗)
b :=V RFYpk (m, δ)
*: Q is defined as the set of message-signature pairs {m′ , δ ′ } where A sends each m′ to the signing oracle
and receives signature δ ′ . Q covers the case that adversary observes the transcript between sender and
receiver (that is, m,δas in the “execution of digital signature”).
def
Successful game: S IG -F ORGE (n) = 1 = b = 1 ∧ m ∈ / Q.
Security definition: P r[S IG -F ORGE (n) = 1] ≤ NEGL(n).

D. Construction: Domain Extension

Domain extension is to support the message of variable length.
Hash-and-sign paradigm for domain extension in digital signatures.

pk, sk ←G EN′ (1n ) : pk, sk ←G EN(1n )

s ←G ENH (1n )
δ ←S IGN ′sk (m) : δ ←S IGN sk (H s (m))
b :=V RFY ′pk (m, δ) : V RFY pk (H s (m), δ)

If the hash is collision resistant and fixed-length S IGis unforgeable, the variable-length S IGconstructed by hash-and-sign is
unforgeable.
Counterexample: If the hash is not collision resistant, construct an attack to break the digital signature (or the security
definition in S IG -F ORGE): Adversary observing {m,δ} will find hash collision with m easily. Name the colliding message by
m′ , such that H s (m) = H s (m′ ). Adversary can present {m′ , δ} as the forged message to the receiver. Verification will pass
because V RFY′ (m′ , δ) = V RFY (H s (m′ ), δ) = V RFY(H s (m), δ) = 1.

E. Construction (Fix-length): Schnorr Identification

Overall, a digital signature scheme can be constructed from an interactive identification protocol (through Fiat-Shamir
transform). We talk about the scheme definition of identification protocol (§ IX-E2), Fiat-Shamir transform (§ IX-E1), and a
DL based construction of identification (§ IX-E3).

24
 1) Identification scheme: Definition: Protocol execution between Prover (of her secret key sk) and Verifier (of Prover’s
public key pk.

Prover(sk) Verifier(pk) (17)

(I, st) ←P1 (sk)
Initial msg I
→
r ←Ωpk
Challenge r
←
s :=P (sk, st, r)
Response s
→
?
V (pk, r, s) =I

The security of identification scheme is, informally, that given the transcript (I, r, s), the adversary without knowing secret
key sk cannot generate s and use it to fool verifier into accepting.
2) Fiat-Shamir transform:

G EN′ (1n ) : sk, pk ←G ENID (1n )

δ :=S IGN sk (m) : I, st ←P1 (sk)
r :=H(I, m)
s :=P2 (sk, st, r)
δ = (r, s)
?
V RFYpk (m, δ) : V (pk, r, s) =I
?
H(I, m) =r

See Figure 7 about the transform.

Prover(sk) s=Sign(sk,m) Verifer(pk)

(I,st) P1(sk)
I
r ✁ pk

r r = H(I, m)

S V(pk, r, S) = I
S P2(sk, st, r)
H(I, m) == r

Vrfy(pk,m,s)

Fig. 7: Intuition of Fiat-Shamir transform

Fact: ID protocol is simpler, interactive; and digital signature is extensible (w.r.t. message) and non-interactive.
3) Construction: Schnorr Identification: Schnorr identification protocol execution: Secret key is x ∈ Zq and public key
is G, g, q, y. Here y = gx .

25
 Prover(sk) Verifier(pk) (18)
k
k ←Zq ; I = g
I
←
r ←Zq
r
→
s = [rx + k] mod q
s
→
?
Check gs · y −r =I

Correctness: gs · y −r = grx+k · (gx )−r = gk = I

Security proof: By security definition in § IX-E1, the adversary can do the following: Given public key pk, she can send
message I, receive r and send s such that g s · y −r == I.
If this is the case, then the adversary can do it twice with the same initial message I. She can obtain two transcripts like
this: I, r1 , s1 and I, r2 , s2 , such that g s1 · y −r1 == I and g s2 · y −r2 == I. Thus,

gs1 −s2 /(r1 −r2 ) = y

s1 −s2
One can simply calculate logg y to be r1 −r2 mod q which contradict the hardness assumption on DL .

F. Challenge-response protocols for user authentication (Chapter 6 in Book [2])

In this subsection, we take a different perspective: Instead of constructing a digital signature scheme based on an identification
protocol, we construct an identification/user authentication protocol from public-key cryptographic primitives including digital
signatures. The intuition is illustrated in Figure 8.

Authentication
protocol

Auth. Signature
constructed constructed by
by signatures identification

Digital
Signature

Fig. 8: Two perspectives: 1) Authentication protocol constructed by digital signature as primitive, and 2) digital signature
constructed by identification protocols (as in Fiat-Shamir transform)
1) Case: Two-factor authentication: In this game, the authentication server sends a passcode to a user’s registered phone,
as a challenge to the user. The user responds by sending the passcode to the server, as a proof that she has access to the
registered phone.
In general, authentication server sends a challenge and user sends a response. The server verifies the user response (as a
proof) against the challenge.
The response needs to be 1) something that only a legal user can generate and 2) also has to do with the challenge.
2) Case: Public-key based authentication: Public-key based challenge-response protocols are described in the identification
protocol (§ IX-E1).
Baseline design 1: To construct it, one baseline is using digital signature. Consider authentication server Bob and user Alice.
In the first round, the challenge is a random number r picked by Bob. In the second round, the response is a message signed
by Alice’s secret key: S IGN sk (“Alice′′ , r). The server Bob verifies by verifying the signature.
However, this design is not secure, if the man-in-the-middle attacker changes r and Alice, the legitimate user, end up with
signing r′ and get declined by the server.
Baseline design 2: Another baseline construction is using public key encryption. In the first round (for challenge), the
challenge is Bob sends a random number r encrypted by Alice’s public key, that is, E NC pk (r). In the second round, the
response is the plaintext of r sent by Alice. Because only Alice can decrypt the ciphertext challenge. The server simply checks
the equality.
This baseline is not secure, as the adversary can simply changes the plaintext response s = r to any other value, failing
legal user Alice’s authentication.
The secure construction: It uses both public-key encryption and digital signature.

26
 Prover(sk) Verifier(pk) (19)
r ←E NCpkA (S IGN skB (“A”,R))
r
←
s ←E NC pkB (S IGN skA (“A”,“B”,R))
s
→

X. TLS (§ 12.7/8)
A. Overview: TLS-HS and TLS-RL
Target scenario: A web browser wants to communicate securely with a web server (identified by its IP address). Using
HTTPS, the network traffic is encrypted by private-key cryptography schemes. TLS or transportation layer security is the
protocol underneath HTTPS: It consists of two phases: an initial hand-shake process (TLS-HS) that establishes shared secret
keys between browser and web server, and a record-layer process (TLS-RL) that uses shared keys to authenticated-encrypt
the messages issued by the applications/users. There are four secret shared keys, each two for communication in a direction.
Different keys are also used for message authentication and encryption, separately. For simplicity/educational purpose, we
consider TLS-HS establishes one shared key between browser and web server.

B. TLS-HS Design Iteration 1: DHKE under MitM Attacks

Our focus is to design TLS-HS protocol from scratch. We will go over several design iterations to refine the protocol.
To start with, the first design is use DHKE for TLS-HS. As we know DHKE provides the confidentiality of shared key
against passive adversary (i.e., an eavesdropper who passively observes the network traffic without changing it). However, in
practice, there are active adversaries who can forge the network traffic.
M IT M attacks: Man-in-the-middle attack (M IT M) is an “active” attack where the adversary actively modifies the messages
transmitted in the execution of a K EY E XCH protocol. Concretely, Adversary A intercepts the first-round DH message gx from
Alice A and replaces it by gxx before sending it to Bob B; g is group generator and xx, yy are generated by A. She also does
the same in the second round by replacing Bob B’s message (gy ) with gyy . The protocol execution is illustrated as below.
gx g xx
A→ A → B (20)
gyy gy
A← A←B (21)
With this attack, A can forge a shared key gx·yy with Alice A and a different shared key gxx·y with Bob B.

C. TLS-HS Design Iteration 2: DHKE + Digital Signatures

TLS-HS defends the M IT M attack by authenticating the transcript of the protocol execution. Concretely, A will check
whether the transcript she receives is identical to the authentic transcript B receives. B’s transcript is signed by B’s (or server
S) private key, which is certified by CA. As A can not forge a CA’s certification, M IT M will not succeed. See Equation 22
for details (in red is what TLS-HS adds to DHKE).

Alice Bob (22)

(G, q, g) ←G, pkA , sk A pkB , sk B
x ∈ Zq , δ A = S IGN skA ([g x , pk A ])
g x ,δ A
→
V RFYpkA ([g x , pk A ], δ A )
y ∈ Zq , δ B = S IGNskB ([gy , pk B ])
y
g ,δ B
←
V RFY pkB ([g x , pkB ], δ B )
kA = (g y )x kB = (g x )y

TLS-HS is secure under M IT M attack, as the adversary cannot forge the signature using A or B’s secret key. In the above
figure, A cannot forge S IGN skA (“g x , pkA ”) without secret key skA .

27
D. TLS-HS Design Iteration 3: PKI and CA
In TLS-HS, the underlying assumption is that A and B (or web browser and server) are identified by their public key. This
causes problems in practice: Consider a web browser connected to a web server for the first time. This web browser can only
receive the public key of the server from the server itself (assuming no other online trusted party). When the web server is
malicious (attempting to impersonate another domain), the web server can simply generate a public key and claims it is bound
to an impersonated domain. In other words, how can a web client establish trust about the server’s identity? Or how can a
client trust the binding between a public key and a web server.
The solution is Public Key Infrastructure (or PKI). In PKI, trusted third party, called certificate authority (CA), exists to issue
certificates on the binding between the domain name of a web server and its pubic key. Formally, a certificate, C ERTCA → S,
is a signed statement that binds the identity of server S to its public key pk S . The certificate is signed by CA’s private key
and verified by its public key. CA, the certificate authority, is fully trusted to the extent that whatever statement it issues is
trusted. A certificate is below:
def
C ERTCA→S = S IGN skCA (binding(“S identity”, “S public-key” pk S )
Fact: A certificate is like a ID card, where the ID card issued by the government (CA) certifies the binding between a
subject’s appearance (server S’s public key) and his identity (S’s identity).
Summary: Overall, bootstrapping trust for secure communications is realized by running three protocols among three parties:
certificate authority CA, server S, and client C. The whole process runs by three protocols at three stages: 1) At the very
beginning, it runs the general PKI protocol as three-party protocol (among S,CA,C) to securely set up environments (distribute
certificates and public keys) for the next stage, 2) At the second stage, it runs the TLS-HS protocol as two party protocol
between S and C to establish the trust and shared keys between them, 3) At the third stage, it runs the TLS-RL (record layer)
protocol between S and C to securely communicate between them using the shared secret keys. In particular, the record-layer
protocol runs private-key authenticated encryption, with sequence numbers and the four private keys (generated in TLS-HS
and used pairwise for encryption and authentication).

E. PKI in practice (Nov. 12)

Multi-level CA

Root CA R
✁ ✄ ✂
SignSKR( PKX belongs to Visa s office X
| X is a CA )

Regional CA Y Regional CA X
✁ ☎
SignSKX( PKA belongs to
name A | A is non-CA )

Bank A BankB Bank C

Fig. 9: Multi-level CA
Multi-level CA: Practical CAs are hierarchical: there is a root-level CA and multiple regional CAs. Consider Visa as an
example, illustrated as in Figure 9: 1) There are regional offices in Visa. The Visa office in CNY authenticates Niagara Bank.
This is done by issuing certificate like [pk NiagaraBank belongs to name ‘Niagara Bank’]; The certificate is signed by regional
CA’s secret key sk Visa CNY . 2) The job of the root CA is to certificate the authority of regional CAs. This is done by issuing
certificate like [pkVisa CNY belongs to regional CA named by ‘Visa CNY’]; The certificate is signed by root CA’s secret key
sk Visa root .
There are two kinds of “authorities”, CAs and non-CAs (like the bank). A classic attack in multi-level CA is to (mis)use
a non-CA’s secret key to certify another fake non-CA. For instance, in Microsoft’s IE under PKI, a misusing domain owner
signs a certificate of a normal domain name with a fake public key. The security fix for this is to distinguish whether the
public key in a certificate is CA or non-CA.
Organizational PKI: The concept of PKI, relying on authorities to certify users, goes much broader than web applications.
1) VPN is a PKI in the sense that the IT department plays the role of CA and users off campus can use their public keys
to get authenticated. 2) Credit card organization, like Visa, is a PKI that establishes trust between different banks and their
customers. Visa is the CA and banks are the users (so that buyer A in Bank 1 can do business with seller B with account in
Bank 2).
There is a dream of universal PKI that a single CA certifies everything for applications across the board. However, in
practice, the most successful models are organizational, domain-specific PKIs. Why?
Trust and authorities are essentially context-specific. You trust campus IT to the degree of revealing your SUID. But you
don’t trust IT when it comes to revealing your credit card number. You trust amazon.com for credit card. It is hard to find a
universal CA that everybody can place unlimited trust to.
Names: PKI certifies the binding between a public key and a name. But what about the binding between a name and an
actual physical entity (1)? There are other problems regarding names: 2) alias problem that one person has multiple (nick)

28
names, 3) common names in that different people share the same name. In a small town, problem 1) is solved by everybody
knows everybody else. And the name-person binding is solved by sight. Problem 2) and 3) are solved by gossiping. Villagers
can propagate names “Big John” and “Little John” to distinguish two Johns. In a large scale setting, we rely on authorities
to assign name. Like US government assigns SSN to identify different citizen. Email service provider assigns unique email
account for a user. Names and the use of names is context specific (at home he is called John, in workplace, he is called Mr.
Smith). This is another reason context-specific PKI is preferred over universal PKI.
PKI and authorization: PKI certifies the binding between names and public keys. ACL or access-control list stores the
binding between names and permissions. Indirect authorization couples PKI with ACL to solve the authorization based on
public keys. However, the alias problem in names makes it ineffective to join the PKI and ACL; what if the name in PKI is
“John” and name used in ACL is “Mr. Smith”?
Direct authorization directly binds public key with permissions. Without name, the alias problem goes away. However,
without human-readable names, it makes it difficult to audit.
Credential system is a direct authorization method where the binding between public key and permissions is signed. This
sort of certificate makes it easy to transfer permissions. For instance, a file user Alice who has read permission to file X can
transfer her “authority” (file read permission) to another user, Bob, by issuing the following certificate: [pkB is authorized to
read file X]; this certificate is signed with Alice’s secret key skA . The credential system verifies it by 1) verifying the signature
against pkA , 2) checking if user pkA (namely Alice) has read permission to file X.

Low-cost CA
(Let s Encrypt or Keybase)
Authentication
User
server(CA)

Challenge text

Response Web service Post

(twitter or github)

Fig. 10: Low-cost CA

Another example of cryptographically implemented access control is the blockchain. If you think about what happens on a
blockchain miner node, it maintains a list of key-value pairs, each with a public key, being the key, and a token/cryptocurrency
unit (e.g., Ether) being the value. The binding between the cryptocurrency and public key represents the ownership of
cryptocurrency. The key-cryptocurrency pair can be read by anyone (no access control for read) and can be modified only
by the secret key associated with the public key (i.e., access controlled for write). The modification here is to remove the
current binding and bind the cryptocurrency unit to another public key. In other words, Blockchain’s state, ownership of each
cryptocurrency unit is a KV pair with public key being the key and cryptocurrency unit being the value. The ownership can
also be viewed as an ACL (access control list). The transaction-validator in Blockchain is essentially an access-control engine
that enforces the ACL cryptographically; data bound to a public key PK can be updated only when the modify request comes
from the secret key SK of PK.
Low-cost CA: Modern CAs like Let’s Encrypt and Keybase support low cost. This is done by automation. Figure 10 shows
how low-cost CA can piggyback the trust in existing web services (e.g., twitter.com and github.com) to authenticate users.

F. Certificate Transparency (CT)

In a certificate transparency scheme,3 CA issues certificates and send them to update the log on the log servers. The CT log
is an append-only log of web certificates.
A web browser DU verifying a domain N using certificate C audits the CT log to see if C is included in the log. To do so,
the log auditor (i.e., web browser) retrieves a proof of inclusion pfinclude(C,ST H) from the log server. The proof can be used
to verify that C is/is not included in the log of ST H.
Meanwhile, domain N ’s owner DO(N ) downloads the entire CT log from the log server, say with ST H ′ . She checks 1) if
any certificate she requested before is included in the CT log copy under ST H ′, and 2) if any certificate she did not request
but still under name N is not there in the log copy under ST H ′.
To ensure no fork attack, domain owner and auditor need to periodically gossip their ST H. Consider domain owner DO
has log copy under ST H and web browser DU under ST H ′. DO and DU request a consistency proof from the log server
3 This subsection is summarized from MIT distributed systems course lecture note: http://nil.lcs.mit.edu/6.824/2020/notes/l-ct.txt

29
 Log server

Full log copy Proof of

inclusion

Log Gossip &

consistency
Log
monitor proof auditor

Fig. 11: CT model

Fig. 12: Forking attacks in CT

to prove that either ST H is a prefix of ST H ′ or ST H ′ is a prefix of ST H. Only when this consistency proof is verified,
there is no fork.
How can CT be attacked: 1. “there is window between when browser uses a cert and monitors check log.” 2. “there may
be no one monitoring a given name”. 3. “lack of gossip in current CT design/implementations”. 4. “privacy/tracking: browsers
asking for proofs from log server”.

XI. S UMMARY
TABLE II: Components in applied cryptography
Scheme/Execution Private-key enc. MAC Public-key enc. Digital sig. Protocols
Security definition EAV,EAV-MUL,KPA,CPA,CCA ACMA CPA ACMA
Construction 3.17, 3.30 PRF El Gamal Schnorr DHKE
Assumption DL DL DL

30
 R EFERENCES
[1] J. Katz and Y. Lindell, Introduction to Modern Cryptography . Chapman and Hall/CRC Press, 2007.
[2] R. B. Lee, Security Basics for Computer Architects, ser. Synthesis Lectures on Computer Architecture. Morgan & Claypool Publishers, 2013. [Online].
Available: https://doi.org/10.2200/S00512ED1V01Y201305CAC025

31
 A PPENDIX A
R EVIEW: D ISCRETE PROBABILITY (§ A)
A. Introduction and Random Variables
Introductory example: Weather forecast: Tomorrow’s weather is a random variable that takes different values in its domain
(e.g., “rainy”, “sunny”, “cloudy”, etc. This random variable is a distribution today – for each value, there is a probability that
the variable takes the value. But on the day after tomorrow, the variable becomes fixed and its value is determined – only one
value in the domain is bound with 100% chance.
In abstract, we talk about (discrete) random variable R. The random variable R has a domain R which is a finite set of
values r. The variable can take any value in the domain; for each “event” that random variable R takes a value r, denoted as
R ←r, it occurs at a certain probability, denoted as P r[R ←r]. In other words, a random variable is essentially a probability
distribution D defined over the choice of values r ∈ R. A special case is 0/1-random variable whose finite set is simple {0, 1}.
Bayes theorem: Bayes theorem describes the probability of an event E1 , based on prior knowledge of conditions E2 that
might be related to the event. That is, P r[E1 |E2 ] = P r[E 2 |E1 ]
P r[E2 ] ·P r[E1 ]. Here P r[E1 |E2 ] is a conditional probability, namely the
likelihood of event E1 occurring given that another event E2 is true (or occurred). P r[E2 |E1 ] is also a conditional probability,
namely the likelihood of event E2 occurring given that another event E2 is true (or occurred). P r[E1 ] is the probability of
observing event E1 .

B. Statistical Properties
There are several statistical properties describing the distribution of a random variable R. Those include expecta-
tion E XP P [R], variance VAR [R], and entropy E NTROPY [R]. Formally, the expectation of random variable R is
E XP[R] = r P r[R → r] · r. When E XP [R] is known, its bound of the random variable is given by Markov inequality:
P r[r ≤ b] ≤ E XP[R]/b for a given bound b. Note P that here P r[r ≤ b] is short for P r[R → r ∧ r ≤ b].
The variance of random variable R is VAR [R] = r∈R (r − E XP[R])2 , which can be further derived as VAR [R] = VAR [R] =
E XP[R2 ] − E XP[R]2 . Consider, for example, a 0/1 random variable R01 . We have VAR [R01 ] ≤ 1/4 (proof see book). When
VAR [R] is known, we can use Chebyshev bound to describe its probability bound: P r[|R − E[R]| ≥ δ] ≤ VARδ2[R] .
PThe entropy of random variable measures how much uncertain the variable is. Given R, its entropy is E NTROPY [R] =
r∈R −P r[R = r] · log P r[R = r].
Consider, for example, how to generate a random number? A random number is generated by following a uniform distribution.
A uniform distribution takes the same probability for each value in its domain, having the expectation being unbiased (being
the average) and having a high entropy value. Think about toss a biased coin to generate a random number. The random
number is with high entropy (as it is very uncertain which value it will take), but is not uniformly distributed because the
coin head is heavier than tail. A solution to this biased tossing is to toss the coin two times, the random variable takes value
0 when the result is head-tail, it takes value 1 when the result is tail-head. Otherwise, it continues.

C. Advanced statistical properties

There are advanced statistical properties, including Chernoff bounds and Birthday problem. A random variable can be best
understood in the imaginary experiment of tossing a ball into a set of bins (the balls-in-bins experiment). Those properties are
about a random variable taking multiple values or toss the same ball (with same probability) to the same set of bins, multiple
times. In this setting, Chernoff bounds are about the event that majority of random values is equal to a specific value.
In the multi-toss setting, Birthday problem is about the event that among the multiple values taken, there exist at least two
equal values (or collision). Formally, given R,

def
C OLL(q, N ) = P r[exist a collision in q-balls-in-N -bins]
q2
C OLL(q, N ) ≤
2N
q2
≥
4N
Consider, for example, the real-world
√ birthday problem that polling about 23 people suffices to find two having the same
birthday. That is, when N = 365, q = 365 ≈ 23, C OLL(q, N ) ≤ 12 .

A PPENDIX B
BASIC LOGIC OPERATIONS
A. XOR
The truth table of XOR is in Table III.
XOR has a property that m ⊕ m can be canceled out in an equation.

32
TABLE III: XOR truth table
0 ⊕ 0 0
0 ⊕ 1 1
1 ⊕ 0 1
1 ⊕ 1 0
x ⊕ x 0
0 ⊕ x x

33