COMP4109

Applied Cryptography

A course presented by: Jeremy W. Clark

Compiled & Typed by: Matthew Tucciarone
Term: Winter 2013
Carleton University
Compilation Date: April 4, 2013

Note: This course covers the following areas: Practical aspects of cryptography. Pseudo random num-
ber generation, symmetric cryptography (stream and block ciphers), modes of operation, hash functions,
message and entity authentication protocols, zero knowledge, pitfalls deploying public-key encryption and
digital signatures, key distribution, secret-sharing.
These notes were understood, compiled, and typed by Matthew Tucciarone. Please acknowledge the fact
that there may be errors or typos in these notes either done by the professor during the lecture or by the
note taker.
CONTENTS Applied Cryptography

Contents
1 Introduction 6
1.1 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Hash Functions 7
2.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Cryptographic Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Aside 1: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Aside 2: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Pre-image Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Collision Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Pre-image Resistance (Contd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 Collision Resistance (Contd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.9 Second Pre-Image Resistance (WCR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.10 Examples of where to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10.1 Password Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10.2 Torrenting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10.3 Signed Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10.4 Hash Tree (Merkle Tree) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.11 Example Hash Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.12 Addressing Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.13 Random Output (RO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.14 Non-Malleability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.15 Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.16 Markle-Damgard Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.16.1 Question 1: Input to f1 on first pass instance other than m1 ? . . . . . . . . . . . . . 12
2.16.2 Question 2: Padding? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.16.3 Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.17 Length Extension Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.18 Sponge Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.19 Internals of the Compression Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Pseudo-Random Number Generators 14

3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Extractors 16
4.1 Example of an Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Von Neumman Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Intro to Symmetric Key Encryption 18

6 One-Time Pad 19
6.1 Drawbacks of OTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 of 59
CONTENTS Applied Cryptography

7 Stream Ciphers 21
7.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2.1 Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2.2 Key Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Block Ciphers 23
8.1 Common Block Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1.1 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2.1 Electronic Codebook (ECB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2.2 Cipher-Block Chaining (CBC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2.3 Counter Mode (CTR/CM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

9 Security Definitions 26
9.1 One-Time Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2 Semantic Security (CPA-Secure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3 CCA-Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.3.1 Plaintext Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10 Message Authentication Codes (MACs) 29

10.1 Building a MAC from a hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1.1 Attempt 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1.2 Attempt 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1.3 Attempt 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1.4 Attempt 3 Revised (HMAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2 Block Cipher-Based CBC-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

11 Authenticated Encryption (AE) 30

11.1 MAC-then-Encrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.2 Encrypt-then-MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.3 Other AE Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

12 Number Theory 32
12.1 Algebraic Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.2 Integers mod p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.3 Exponentiation mod p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.4 Subgroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.5 Integers mod p Continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.5.1 Inverses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.5.2 Exponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.5.3 Inverse is an Exponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.6 Quadratic Residue Continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 of 59
CONTENTS Applied Cryptography

13 Diffie-Hellman Key Exchange 36

13.1 Decisional Diffie-Hellman (DDH) Assumption . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.2 Blinding in Gq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.3 Diffie Hellman Continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

14 Public Key Encryption (Asymmetric Key) 39

14.1 ElGamal Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1.1 First pass (modification of DH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1.2 Second pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1.4 Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.2 ElGamal Continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.3 Homomorphic (Malleability) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.5 Proof of CPA-Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.6 ElGamal non CCA-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

15 Zero-Knowledge Proofs (ZKPs) 42

15.1 Shnoor Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.2 3-move (Sigma) Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
15.3 Fiat-Shamir Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

16 Digital Signatures 45
16.1 Signature vs MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.2.1 Public Key Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.2.2 ZKPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.3 Schnorr Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
16.3.1 Sign Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.3.2 Schnorr-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.3.3 Schnorr Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

17 Building CCA-Secure 47
17.1 Naive Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
17.2 STS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

18 RSA Setting 49
18.1 Textbook:" RSA Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
18.1.1 Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
18.1.2 RSA Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
18.1.3 RSA Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
18.1.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
18.1.5 RSA Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
18.2 Strengthening RSA Encryption/Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

19 Fully Encrypted Protocol 52

4 of 59
CONTENTS Applied Cryptography

20 HTTP Over SSL/TLS 53

20.1 Sketch of TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
20.2 Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
20.3 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
20.4 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
20.4.1 Certificate Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
20.4.2 Misc. Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

21 HTTPS Protocol 55
21.1 Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
21.2 Change CipherSpec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
21.3 Application Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
21.4 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
21.4.1 Padding Oracle (Lucky 13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
21.4.2 BEAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
21.5 HTTPS - Real World Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
21.5.1 Issues in HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
21.5.2 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

22 Bitcoin 57
22.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
22.2 Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 of 59
 Applied Cryptography

1 Introduction
Info Security
1) Confidentiality (C)

2) Integrity (I)
3) Availability (A)
Cryptography helps in the areas of Confidentiality and Integrity.
Confidentiality Confidentiality consists of two concepts:

Definition 1.1 (Encryption). The idea of locking a message in a safe with a key.
Definition 1.2 (Modern). The idea of minimal disclosure, e.g. a digital drivers license

1.1 Integrity
Integrity consists of the following concepts:
Definition 1.3 (Unmodified). This is relative: Identify precious state (authentication).

Alice(m) (m m0 ) > Bob(m0 )

| {z }
Mallory intercepting

Something bad happens.

Definition 1.4 (Robustness or Fault Tolerance). Random/no intent, such as ECC (Error-correcting code)
Definition 1.5 (Security/Crypto). Intent, such as MAC, signature.

In this course, we will be looking at the following areas of Cryptography:

Name C I A Description Speed
Hash Functions x x No key
MACs x Tag and Verify Fast
Encryption (Symmetric) x Encrypt and Decrypt (same key) Fast
Signatures (Asymmetric) x Sign and Verify Slow
Encryption (Asymmetric) ie. Public Key Encryption x Encrypt and Decrypt (different key) Slow
Roles of keys:
secret, number
maintain confidentiality, integrity

key lets you do something (no key, cant do)

Note that Hybrid encryption can switch from slow to fast.

6 of 59
 Applied Cryptography

2 Hash Functions
In a Hash table we have the following functions:
sleep"

sleek"
dry"

2.1 Properties
Pre-image resistant (PR)
Collision resistant (CR)
Second-pre-image resistant / weak collision resistant (WCR)

Random Output
Non-Malleability
{0, 1} {0, 1}d , |{0, 1}d | = 2d

2.2 Cryptographic Hash Functions

Stronger than hash functions used for hash tables

y = H
|{z} ( x
|{z} )
|{z}
image/output {0, 1} d hash function pre-image, input {0, 1}

2.3 Aside 1:
First pass
x 
|{z} y
Hash / other primitive

Second pass internals

(Lesson in crypto: dont roll your own cryptographic methods)

2.4 Aside 2:
Deals with Computational Infeasability (the idea that things can be done but over a lifetime).
240 feasible
280 infeasible with no safety margin
2128 infeasible
According to NIST standards, they suggest all functions at 2112 .

7 of 59
2.5 Pre-image Resistance Applied Cryptography

2.5 Pre-image Resistance

Note that all the definitions are informal...
Definition 2.1 (One-Way Function). Given y (y is d-bits long), it is infeasible to find any (collisions must
occur: {0, 1} {0, 1}d ) x such that y = h(x). In other words, you cannot go from image (y) to
pre-image (x), however you can go from pre-image to image (see the above diagram). That is, a one-way
function (non-invertible).
Brute-force: try x, see if y1 = (x1 ) = y and repeat.
H = 2d = 2128 , d = 128 output of hash

2.6 Collision Resistance

Definition 2.2. Infeasible to find any x, x0 st. x 6= x0 and h(x) = h(x0 ) (this is easier to happen than
| {z }
collision
finding the pre-image -> refer to the Birthday Paradox)
Probability of finding a collision: If we hash x1 , x2 , . . . , xn , then

n2 d
 
X n d
E (# collisions) = Pr [h(xi ) = h(xj )] = 2 2 = n2 2(d+1) n2 2d
2 2
ij

Let n n
d/2
, E (#collisions) > 1
Were going to review our definitions thus far and improve on them:

2.7 Pre-image Resistance (Contd)

Balls and Bins analogy. All possible outputs as bins. Every time you have a value, its like throwing a ball in a
bin. Assume we have an ideal hash function, which means that the bin throw into has uniform distribution.
Were interested in how many balls we throw into we find a bin that has something interest. How many
balls does it take for one ball to fall into a specific bin. There are 2d bins. Well be using expected value
to find the answer. If we throw n balls, how many pre-images can we expect to find? The more balls we
throw, the higher probability that a ball ends up in our specific bin:

E (# of pre-images) = f (n)
1 = f (n)

The probability that a ball lands in any

P 1bin is /2 and the number of balls thrown is represented by the
1 d

summation operator. Thus we have 2d

. Set this equal to 1 and we have:
n

n
1=
2d
n = 2d
d is the output of the hash in bits and the output space is 2d . n represents the amount of work. In order
for this to be secure, we want n = 2128 and thus d = 128.

8 of 59
2.8 Collision Resistance (Contd) Applied Cryptography

2.8 Collision Resistance (Contd)

Balls and bins analogy once more where we have 2d bins and n balls. Were gonna throw a lot of balls and
eventually a bin will have 2 balls in it; this is called a collision. How many balls do I have to throw in order
for a collision to occur? We dont care what bin, but only that a bin has more than 1 ball in it. We want to
know the probability of two balls
being in the same bin, represented by Pr (h(x1 ) = h(x2 )) = 21d . How
many different pairs of balls? n2 balls. Thus the expected number of collisions is:
 
n 1
d = 2d1 (n 1)n = 2d n2
2 2
Setting this to 1 we have:
E ( # of collisions) = 2d n2
1 = 2d n2
n2 = 2d
d
n = 2d = 2 /2
Once again we want it to be secure so we set n = 2128 and thus d = 256.
To find the expectation (1) we want to have the
work (balls thrown) to be 2128 , the pre-image to be
(2 )(d = 128), and collision to be (2 ) = ( 2d )(d = 250).
d d/2

2.9 Second Pre-Image Resistance (WCR)

Its infeasible given some value of x = {0, 1} to find a second value which is not equal to the first value
(x0 6= x)st. h(x) = h(x0 ). We know now that CR implies WCR. PR doesnt imply CR and vice versa, and
PR doesnt imply WCR and vice versa. For example, let us consider the following weird hash function:
(
0||x |x| = n
h0 (x) =
1||H(x) otherwise

Where y = h(x) and |y| = 2n . Is h0 collision resistant? Its clear that as long as were feeding it x values
that are unique, well get unique x values out. If we put in a value that is not equal to n, then well get the
hash of x and prepend to 1. By definition, H(x) is collision resistant. Because this is so, any output that
falls in the otherwise category is collision resistant. Then the only hope is to find a collision between the
two cases. Since y 0 = h0 (x), |y 1 | = 2n+1 .
Corollary 2.1 (About Collisions). A naive approach takes a lot of memory but finding collision doesnt
have to take that long, so were gonna look at Floyds cycle-finding algorithm. Its not faster but its as
exhaustive as the naive approach. It stills has a run time of (2 /d ):
2

x gets hashed into h(x) and then gets hashed once more into h(h(x) arbitrarily long. Because the possible
values of x are limited (2d ), we know the chain cant go on forever. Eventually, well hit a number weve
seen before. We also know that it cant terminate. Given these two properties, we find the chain of values
eventually creates a cycle. There is a tail and a cycle for these and theres a high probability well end up in
the tail. At the value intersecting the tail and the start of the cycle, we have found a collision. The length
of the tail (O(2 /2 )) is roughly the same size as the cycle (2 /d ).
d 2

Intuition of this algorithm: 2 registers are all that you store.

9 of 59
2.10 Examples of where to use Applied Cryptography

1. start at x and move sequentially.

2. start at x and moves twice as fast.
Note the distance between a point on the tail and the point P on the cycle is exactly half. Lets try this
once more, given 2 registers:

1. start at x, move sequentially 1 step

2. start at p, move sequentially 1 step Eventually both x and p will both hit the intersecting value (where
the tail hits the cycle) because they both step in synchronization.

2.10 Examples of where to use

2.10.1 Password Storage
We have Alice and Google and Alice wants to send her password to Google. What does Google store about
her password? They could store her password in cleartext. A better solution is to store a hash of the
password. Now I just get the output of the hash function if I wanted to attack. Alice can still send her
password. The pre-image resistant property in this case says that given H(pwd) you cant find pwd. You
dont need collision resistance in this case.
Is an attack still possible? We have H(pwd) and we can try every pwd. This is something you cant prevent
but you can still make it tricky for one to figure out. Let us use strengthen resistance, which still
doesnt necessarily prevent:
1. Use a Rainbow table (uses lookup table with pwd and H(pwd))
(a) Salt" your hash (H(pwd) and the append (||) your salt, which is a random non-secret value)

2. Iterative Hashing (H(p||salt))

2.10.2 Torrenting
Let us assume Alice connects to The Pirate Bay (TBP) and she wants a movie. TBP sends her h(movie)
and then over time TBP sends her pieces (m1 , m2 , m3 , m4 ). Let us assume Eve sends m4 that is actually
a virus. How does Alice know that m4 isnt a valid movie file? She has to trust TBP. What property among
the three properties will ensure she wont get a virus? Weak collision resistance. Were given movie and if
Eve finds m0 h(m0 ) = h(movie). We must rely on WCR since CR is not dependent. What about PR?
That doesnt have any bearing on this scenario, so obviously not needed.

2.10.3 Signed Messages

Later in the course we will be talking about digital signatures. A property of these signatures is that
theyre able to sign short messages. If we want to sign something, then we do something called...

Definition 2.3 (Hash-then-Sign Paradigm). Signature = Sig(H(m))

Alice has m and sends it to a Certificate Authorities (Sign) and then the CA sends back Sig(H(m)).
We know that Digital Signatures are secure because of CR and WCR. We dont need PR.

10 of 59
2.11 Example Hash Functions Applied Cryptography

2.10.4 Hash Tree (Merkle Tree)

Think of it as a space saving storage mechanism but it has some security properties. Assume you have
four things (x1 , x2 , x3 , x4 ) you want to see. Assume theyre all 256 bits. You can input the first two things
into a hash function and then get some output (H1 ). Do the same for the other two (H2 ). Then together
(H1 and H2 ) you put into a hash function and then you finally hash that result (H3 ) and get a y as your
output which has 256 bits. This creates y as the root. Claim: If I send you y, then you cant change any
xi value. If x3 and x04 come to out to the same value (H(x3 ||x4 ) = H(x3 ||x04 ). Thus there is no way to
change xi without finding a collision.
Another good property of this hash tree is that there are subsets that exist where you dont need to know
the whole tree.

2.11 Example Hash Functions

Name Output Size CR
MD5 128 56
SHA1 160 80
SHA256 (SHA2 Family) 256 128
SHA512 (SHA2 Family) 512 256
SHA3 (3 months ago) 256/512 128/256
NIST says that you want something that is beyond 212bit secure, thus MD5 and SHA1 arent considered
secure.

2.12 Addressing Questions

Recall that Hash functions are deterministic. That is, with y = H(x) and a given x, H(x) = H(x)
always.

The MD5 hash function is no longer CR but has PR.

Given hash H which is secure and has output of d bits, construct hash H 0 which has output (d + 1)-bits
and is CR but not PR. Recall that:
(
0 0||x |x| = d
H (x) =
1||H(x) otherwise

This is trivially not PR because youre just concatenating a 0 with the input x in the first case. For CR, there
are two cases:
1. Let y = H 0 (x) = 0. If you get the same output, then it implies you get the same input.
2. Let y = 1 . . . z. This means that y = 1||H(x) and y = 1||H(x0 ). If x = x0 then by definition H is
CR and thus H 0 is also CR.

All of this above is to purely summarize that CR does not imply PR.

11 of 59
2.13 Random Output (RO) Applied Cryptography

2.13 Random Output (RO)

Given y = H(x), where y = 2d , it is unfeasible to distinguish y from a uniformly random value of
length d-bits. Random Output is a desired property and sometimes cryptographers assume RO which is
controversial. Whenever cryptographers make this assumption, they say its in the Random Oracle Model"
which assumes RO and much more. What people actually find in the real-world is that the ROM brings
forth the Fiat-Shamir Heuristic. Another one that comes up is OAEP which is a padding scheme and is
typically applied to RSA public key encryption.

2.14 Non-Malleability
This is something that you would think would hold, but sometime it doesnt. Given y, it is infeasible to
produce y 0 such that y 0 = H(f (x)). For example, y 0 = h(x + 1) or y 0 = h(2x). It turns out that most
hash functions are true except ones like y = h(x||m). These examples are called Length Extension
attacks.

2.15 Internals
Note that x can be any size. This makes it hard to define functions that work for all sizes. Youve got
a message m that is split into different blocks of fixed length. The first block would be the compression
function which is similar to a hash that it has CR and PR, however it takes a fixed input and maps
it to a fixed output ({0, 1}2d  {0, 1}d . With a general function we have an arbitrary length and were
compressing it to a known length d. So how do we get a fixed length output? We need a way to accumulate
the values produced from each block which should produce us a single block.
There are two common structures we will look at, and the first is:

2.16 Markle-Damgard Structure

Say d = 256 bits which is the output of a hash. We take our message and split it into blocks
(m1 , m2 , m3 , . . .), which are typically the same size as the output (d). We take m1 and run it through
a compression function f1 (CR, PR). The idea is to take the output of f1 and feed it into f2 alongside
the input of m2 . The output of f2 is put into the input of f3 alongside m3 , and so on. This gives us
{0, 1}2d  {0, 1}d . At the end of compression function chain, we eventually get an output that is d-bits.
Note that f1 only has 1 input which is m1 .

2.16.1 Question 1: Input to f1 on first pass instance other than m1 ?

Pick a random number that a designer once picked. These are usually called initialization vectors.

2.16.2 Question 2: Padding?

One thing that isnt used is zero-pad, which would just fill it with zeros (e.g. m1 m2 ||0000 = m).
This breaks CR. For example we had h(0101) = h(01010) = h(010100). This means trivial padding isnt
possible.

12 of 59
2.17 Length Extension Attacks Applied Cryptography

2.16.3 Padding
We have m which breaks up into blocks m1 and m2 . For the padding of m2 , we can reserve a set of bits
which is a fixed length. What we put in is the length of m. In practice {0, 1}  {0, 1}d where is very
high, such as 2 /2 . Between m2 and the padding, we can fill in with 100000... or 01111... with as many as
d

needed to fill up the block.

2.17 Length Extension Attacks

Assume we have x H y where H is the Markle-Damgard structure, y = H(x), and x is unknown.
We can say that we can create a y 0 = H(x||m) and the reason is that if you look the Markle-Damgard
structure, youll see that the output y is created from the last compression function fm which has a
previous fm1 and xn . We can take y and make that the input to a new compression function and our
chosen m1 to produce y 0 .
Note: Later on were gonna talk about MACs which are just a signed hash. Say Alice wants to send m to
Bob and they share a secret key k. What if Alice sends a message and does H(k||m).
Corollary 2.2. It turns out that MD5, SHA1, and the SHA2 family all use the Merkle-Damgard structure
and are vulnerable to Length Extension Attacks. SHA3 is not vulnerable to the LEA and in fact uses the
Sponge function instead of the Merkle-Damgard structure.

2.18 Sponge Function

You start with initialization vectors (IV) which are all defined as 0 at first. The first one is 1088, the second
is 512. Once again we have this compression function f1 (CR and PR) and both the two IVs go into f1 . This
gives us two outputs which are also of the same size as the IVs. Using m1 from a message m, of length
1088, you XOR m1 and the output of the 1088 IV and put that into another compression function f2 . The
output of the 512 IV from f1 goes into f2 . Once all of m is processed, you want to take 512 bits of the 1088
IV and the full 512 of the second output IV. This is basically SHA3.
Note: The point of showing the internals of these functions is to understand how complicated these things
are and which ones to use and when.

2.19 Internals of the Compression Function

Were going to look at the MD4 hash function, which is a simpler compression function. We have a
message block m and a previous compression output of f1 and we have f . The output of f goes into
four blocks, ABCD. We define t to be a temporary value and we take t = A g(B, C, D) + M + c,
where c is a constant. You let (A, B, C, D) = (D, t  c, B, C) where the values in the second function
changes every time you loop. All of this happens 15 times. You repeat these 15 time rounds 3 times and
during each change g changes. The full detail of this function can be found in Nigel Smarts textbook.

13 of 59
 Applied Cryptography

3 Pseudo-Random Number Generators

The number" implies generating a bitstream, so normally this is called PRG. There is also CS-PRNG which
is Cryptographically Strong PRGs. A PRG is a function, y = P RG(x), which takes one 1 input and doesnt
take any keys yet. The input, x (|x| = d-bits)is sometimes known as the seed, and y is the output. The big
difference between this and hash functions is were mapping from a fixed length {0, 1}d  {0, 1} , where
is the upper limit but it is generally not a concern in practice. We have a pre-image of {x1 , x2 , x2d }
which is 2d in size and x1 would be eventually mapped out to be a long length such as 011001100....
This is a deterministic process, where given the same x you get the same y. Say |x| = 128 bits and we
output a |y| = 256 bits, then the number of possible outputs is limited by the number of possible inputs.
Example 3.1. Let |x| = 2. Then:
(
P RG(0) = 0110101
P RG(x) =
P RG(1) = 11000010
As soon as we limit the number of outputs, then the number of inputs are also limited. This means that
theoretically, this can be distinguished from a truly random process. We would never see the output of
10001111.
Since were mapping from a fixed input d to an infinitely large output, then not every output is possible:
d .

3.1 Security
A PRG is secure (CS-PRG) if:
(1) Infeasible (something such as (2112 )) to distinguish the output y from a truly random bitstream of
the same length (|y|), if you dont know x. We expect the input size to be greater than 112 bits, such
as having |x| = 128 bits (|x| 112).
Example 3.2. Assume |y| > |x|, e.g. |y| = 2|x| where |y| = 256 and |x| = 128. Then theres less
randomness in y than 256 truly (uniformly) random bits. True randomness give equal probability to every
output where as PRGs would not.
Lemma 3.1 (Security Definition). It is infeasible to predict the next" bit if you dont know x.
Say Alice does P RG(seed) = b1 , b2 , b3 and Alice sends each bit to Bob (who doesnt know what the seed
is). Then even if he looks at every bit, it should be infeasible for him to predict the next bit.
Assume you know x (seed), then you can predict the next bit which is a consequence of the PRG being
deterministic. This would make it feasible to predict the next bit. If you know the seed then you can break
the lemma above and thus break the first infeasible rule of security (1).
Lemma 3.2. Infeasible to recover the seed (x) given output (y).

3.2 Internals
We will be looking at this a bit later, but well be talking about stream ciphers which make use of PRGs.
Well also be talking about Block ciphers. Once we know that, there is a way of converting that into a PRG
using a mode of operation. In practice, people who want PRGs can either rip them out of stream ciphers
or convert them from Block ciphers.

14 of 59
3.3 Examples Applied Cryptography

3.3 Examples
Linear Feedback Shift Registers (LFSRs): No longer secure. Mersenne Twister.
Cellular Automata: Insecure.
A5/1, A5/2 (stream ciphers): Insecure (mobile such as 3G). Monte Carlo sim.
RC4 (stream ciphers): Secure, but low security margin.

Counter Mode" (block cipher): Secure if block cipher is secure. Eg. AES.

For security to hold, the seed must be unpredictable.

In practice, this is a problem
Seeds should be truly random
Broken seeds:
* Early 90s, Netscape broke SSL
* Late 2000s, Debian broke SSL and SSH
* Last year, constrained devices and embedded systems broke SSL

15 of 59
 Applied Cryptography

4 Extractors
We have the following function which has 1 input, and technically there is a non-secret key (i) but we dont
care in this course: y = Exti (x). The input x is of size {0, 1} with y being of size {0, 1}d . If x has
min-entropy greater than d (typically H0 (x) > 2d), then it is infeasible to distinguish y from a d-bit true
random bitstring. This means that we can shrink" our input x and put it into a size of d for the output y.
How are they used? We have the following function y = P RG(Ext(x)), where y = {0, 1} and x has a
lot of semi-random bits, and Ext(x) is 128-bits in size. As long as there is enough randomness, then itll
crunch down inputs and sanitize" the randomness into pure randomness of 128-bits.

Example 4.1. Unix uses /dev/random and windows uses CryptGenRandom.

4.1 Example of an Extractor

Were given a biased coin and that it flips heads with p(0.6) and tails with p(0.4).
Definition 4.1 (Entropy). Entropy is a measure of unpredictableness". It is in units of bits. Entropy of
m bits has the same randomness as flipping a coin m times.
Our bias coin is more predictable and less random.

Definition 4.2 (Average Entropy).

X
H = (p1 , p2 , . . . , pn ) = pi log2 (pi ) = [0.6 log2 (0.6) + 0.4 log2 (0.4)] = 0.97

Where the weighted average is pi and the measure of information is the log. The 2 is the output in bits.
Say we flip our bias coin 20 times and we have the output x = HHHT HHHT HHHH . . .. Then we
know Entropy = 20(0.97). We also know that the min-entropy of this coin is 0.736, where we will define
min-entropy later.

4.2 Von Neumman Extractor

This is not ideal because it has less entropy. Given bi bj , output:


HH blank P r
= 0.6 0.6

HT H P r = 0.6 0.4
yk =
T H

T P r

= 0.4 0.6
TT blank Pr = 0.4 0.4

Exploits knowledge of x (or its distribution)

Non-deterministic output length

We use any x (H0 (x) > 2d) and always return d-bits.
Shannons average case is defined to be pi (log2 pi ).
P

16 of 59
4.2 Von Neumman Extractor Applied Cryptography

Definition 4.3 (Min-Entropy). This is defined to be the worst case:

X
H0 = p log2 (pmax ) = log2 (pmax )

And we know that pmax is the most predictable.

H0 (x) > 2d is built from later concepts, such as block ciphers and HMACs.
Name Input Output Properties
Hash {0, 1} {0, 1}1 PR, CR, RD (random input which isnt always assumed)
PRG {0, 1}d {0, 1}d Pseudo-Random output
Extractor {0, 1} {0, 1}d Pseudo-Random output
A little clearing up of entropy:
Entropy of a string of symbols/outputs is the entropy of the symbol multiplied by the length of the string.
We had an example of the bias coin above to demonstrate this.

17 of 59
 Applied Cryptography

5 Intro to Symmetric Key Encryption

We have Alice with a message m and a secret key k (number). Bob has the same secret key k. Then
Alice sends a ciphertext c to Bob by using c = Enck (m). Bob gets the message by using the function
m = Deck (c). How did they both get k? Were not concerned that they both have it hence symmetric
keys. The idea is that theres an adversary Eve who can grab c, but dont know the value k or m and their
goal is to get either. We have three classes of symmetric keys:

1. One-Time Pad: Impractical but perfectly secure

2. Stream Cipher: Practical but only" computationally secure good for steams of data (such as Skype)
3. Block Cipher: Practical and must common fast processing but impractical for streaming data

18 of 59
 Applied Cryptography

6 One-Time Pad
We have a message m of length l and a key that is made of l truly random bits:

Enc m= 0 1 1 0 0 1 0
b= 1 0 0 0 0 1 0
Enck (m) : Dec c= 1 1 1 0 0 0 0
k= 1 0 0 0 0 1 0
m= 0 1 1 0 0 1 0

Consider the first bit of c: (

0 if k1 = 1 50%
c1 = 1, m1 =
1 if k1 = 0 50%

Theorem 6.1. If k is truly random, then it is not merely infeasible (eg. requiring 2112 work) for Eve to
decrypt it is actually impossible.
Proof. We have Alice sends c to Bob and Eve is in her own closed world and does not get c (Scenario1).
In another scenario, Alice sends c to Bob and Eve manages to see the value c (Scenario2). If you cant
distinguish between these two worlds, then this encryption scheme is secure (ie. whether or not she sees
c doesnt mean anything). Denote Pr (m) that Eve guesses the message m in S1 and let Pr (m|C) be the
?
probability that she guesses m given c in S2. Pr (m) = Pr (m|C). What does Pr (m) mean? We cant say
what that is until we know the kind of messages sent to Bob. Assume its an election and shes sending
Bob the name of a candidate. Assume Alice is willing to vote 60% towards one more person. Things we
know about m would be thing such as:

Liberal 60%

m = Cons 10%

N DP 20%

We know that |m| = l and in general that every 2l bitstring is equally probable, but not in this case. Let
us look at the following which makes use of Bayes Theorem:
?
Pr (m) = Pr (m|C)
? Pr (C|m)Pr (m)
=
Pr (C)
?
Pr (C|m) = Pr (C)

Lets try to match the above equation sides:

Pr (C|m):
Say:
m= 0 0 0 0
k= 0 0 0 1
c= 0 0 0 1

19 of 59
6.1 Drawbacks of OTP Applied Cryptography

Once m is fixed, each unique k gives a unique c st. Pr (C|m) = Pr (k), where Pr (k) is truly random.
Therefore, Pr (C|m) = 1/2e .
P (C):
We know that |m| = |k| = |c| = e. Say that m = m0 and we let m0 is Pr (C|m) = 1/2k . m1 would be
Pr (C|m) = 1/2k and the same goes until mi . Thus we would have:
1 1
Pr (m0 ) ( e
) Pr (m1 ) ( e ) + . . .
2 2
1
= P r(m0 ) + Pr (m1 ) + . . .)
2e
1 1
= e (1) = e
2 2
The above states:
For any m, the probability of c given m is 1/2e

The expected value for for any c will be:

X 1 1 X 1
Pr (m) ( e
) = ( e) Pr (m) = e
2 2 2
all m all m

6.1 Drawbacks of OTP

1. k is large and both parties need it
2. k can be hard to generate
3. Cannot reuse the same k: m1 k = c1 , m2 k = c2 thus c1 c2 = m1 m2

4. Malleable: Given c but not m, we can construct Enc(m m0 ), where m0 is anything you want (this
can disappear with a better encryption function or addition of a MAC)
5. Leaks l, where l is the length of the message

20 of 59
 Applied Cryptography

7 Stream Ciphers
The OTP consists of: m l = c, where m = {0, 1}n and k = {0, 1}n . In general, l is a security sensitive
length. A Stream Cipher looks like : m P RG(k) = c where n is much larger than l and k = {0, 1}l and
P RG(k) = {0, 1}n (the keystream). We can assume l = 112 bits or 128 bits. The only difference between
OTP and SC is that k has the property of being impossible to distinguish from true randomness compared
to P RG(k) which has the property of being infeasible to distinguish from randomness.
Once more we have Alice sending c to Bob where c = m P RG(k) and Eve sees c and wants to know m.
She can solve m = c P RG(K) but unfortunately she doesnt know P RG(k). Now assume she knows
part of m. She knows the whole value of c and now she has a message m and knows the first part of the
message and not the last. If she s the first part of c and first part of m then she can obtain y which is
the output of P RG(k). Recall from P RG that its secure in that you cant predict the next bit. Youve got
y but theres no way of finding k. This means the last part of y and m are still unknown.

7.1 Properties
1. Solves the big key problem of OTP

2. Keystream can be independently (pre-) computed: Then it is as fast as you can , which is fast.
3. Cannot reuse keystream, its malleable which leaks |m| = n

Dont forget that Eve knows c, may know parts of m, and we can assume she knows specifications.
Recall that we have a key {0, 1}e and put it into a PRG we get back an output {0, 1}n and XOR that with
a message {0, 1}n and receive a cyphertext of {0, 1}n . Its possible that l is greater smaller than n. We
have two common stream ciphers:
A block cipher that is encased in counter mode
a PRG that is encased in a stream cipher (RC4, ie. Rons Code 4)

7.2 RC4
Think of it as an array consisting of bytes in order (00, 01, . . . , F F ) with no duplicates. You pass a key k
into a Key Schedule along with the sort array of Bytes and somehow, it outputs a shuffle that is dependent
on the key of the arrays; A3, 81, . . . , 03 (shuffled array). We then take our first byte A3 and put it into a
Generation function that outputs a reshuffled array (D7, E2, . . . 96). You can then take out A3 from this
reshuffled array. The grabbing of this element is a pseudo-random selection.

7.2.1 Generator
The input to this function is this array and were going to define two pointers, i, and j, and point them
both from the first element (i = 0, j = 0). The algorithm can be found below:

21 of 59
7.2 RC4 Applied Cryptography

Algorithm 1: Generator Algorithm

while outputting do
i = i + 1 mod 256
j = (j + S[i]) mod 256
Swap s[i] [j]
output byte
S[S[i] + S[j] mod 256]
end
Note that in the above we throw out the first 1024 bytes.

7.2.2 Key Schedule

Algorithm 2: Key Schedule Algorithm

i=0
j=0
One Pass (i) {
j = (j + S[i]) mod 256 + k[i mod l] mod 256
Swap S[i] S[j]
i++
}

22 of 59
 Applied Cryptography

8 Block Ciphers
We have the following formula: c = Enck (m) where c is the cipher text, c {0, 1}B , the key is {0, 1}l (l
can be 128 or 256) and m {0, 1}B . We also have m = Deck (c) where k is the same key. Alice knows k
and m and has c = Enck (m) and she passes along c to Bob. Bob knows k and c and has m = Deck (c).
Our B in the formulas are considered to be a block of a message, (eg. B = 128 bits). Note that in
Stream Ciphers we were encrypting our message bit-by-bit. In Block Ciphers, we have m = 011100 and
c = 101101 and we can see that every bit in c is dependent on every bit in m. That is, the first 1 in c
depends on the 0, 1, 1, 1, . . . in m. What would happen if we had a block that was too large? We would
need a way of chaining.
Recall in hash functions we had a fixed input and a compression function that we wanted to accept any size
input (arbitrary length). We saw that we could chain" these compression functions (ie. Markle-Damgard
and Sponge). In Block Ciphers, we would chain a Block cipher based off a mode of operation which
would give us Block ciphers once more. Some examples of a Block cipher would be DES, AES and for
modes of operation we have ECB, CBC, CM, GCM, and many more. For the output Block ciphers, we would
have something such as AES-CBC-128 which describes the specifics (AES with CBC mode of operation in 128
bits). To help with our knowledge of Block ciphers, there is something called Pseudo-random Permutations
(PRP). The input and output space are the same (input is all possible messages, with 2b same as output),
however the mapping between the two spaces depend on the key. Thus if we use a different key between
the spaces, we receive a different mapping. There are cases for this:
1. You cannot have two messages have the same output since you cannot decrypt.
2. You cannot have a message that goes to two outputs either (block cipher is deterministic)

3. You can encrypt any message

4. Every c is possible
All of the above denotes a Bijective function.

8.1 Common Block Ciphers

Name (Effective) Keylength
DES 40/56
3DES 112/168
AES 128/192/156 (block size: 128)
Recall the NIST standard of (2112 ), thus making AES secure (unlike DES and 3DES DES has too short of
keys and 3DES has better attacks than brute-forcing the key).
Aside: Kerckoffs Principal: A crypto-system should be secure even if everything about the system, except
the key, is public knowledge. In short, the enemy knows the system.

8.1.1 AES
Lets first consider AES-128 (128 bit key). AES-192/256 work the same way with the exception of having some
extra rounds. In AES-128, you can take your key and put it into a Key Schedule (function) and it will output

23 of 59
8.2 Modes of Operation Applied Cryptography

subkeys (10 subkeys/rounds for AES-128). In round 1, we have:

SubBytes |{z}
m |{z} Shf tRows |{z}
M ixColumns |{z}
AddSubkey
128bit 128bit 128bit 128bit

The input to AddSubkey is the mangled m with the subkey 1. The output of this is then the new m for
the next round. This happens ten times for each key and at each round level there is an output of 128 bits.
The output is then the ciphertext. Note that in the last round we omit M ixColumns.
SubBytes uses a thing called S-Box (Substitution-Box) which is a lookup table. The mappings are
random-ish and this S-Box is the same for everyone (public). This has the property of confusion".
ShftRows mixes up the bytes in each rows, or shuffling. Do nothing with the first row, shift the
second row to the left once, third row to the left twice, and last row to the left three times. This has
the property of diffusion" (dependency between bytes). Combines parts of stage with other parts.
MixColumns takes a column and runs it through a matrix. This has the property of diffusion".
Combines parts of stage with other parts.
AddSubKey is just taking the key and with the state, giving you state.

Recall that in order to decrypt, every function in the rounds must be reversible (since in order to get
the message back, we go through these rounds backwards), with exception of AddSubKey, which only
becomes reversible given a subkey. The KeySchedule function consists of many different rounds and ways
of getting the subkeys.

8.2 Modes of Operation

Allows encryption of any number of blocks.

8.2.1 Electronic Codebook (ECB)

We have a 256-bit key and feed that into an encryption block cipher alongside the first block of m (128
bits). The output of this is our c which is 128 bits. You continue to do this for every 128bits of the message
m to get blocks of c. For a good example, think of encryption an image per each pixel. Each pixel is
128-bits. Since our Encryption function on k is deterministic, we know that any blue pixel will have the
same exact random color for output. EBCs have the following properties:
1. Lets you encrypt messages longer than 1 block

2. Improves security.
Recall in ECB we had three blocks; m1 , m2 , m2 (where m3 may need padding). We can assume that for
this course itll be zero padding. m1 and k would be the input for Enc which then gives us c, and the
same applies for each c.

24 of 59
8.2 Modes of Operation Applied Cryptography

8.2.2 Cipher-Block Chaining (CBC)

We have the exact same structure as above, however, the output of the first m1 , well say c1 , is XORd with
m2 . This continues until the last block. This means c2 and c3 would then all be dependent on c1 . The
question that arises is that what do we XOR with m1 ? We use an IV (initialization vector).
Definition 8.1 (Initialization Vector). IVs should have the following properties:

Random, |IV | = |m| = |c|

Random with each encryption
Generate it after the message to be encrypted is supplied
The question then comes to mind is how to decryypt. This is means everything will be in reverse order.
That is, he takes c and puts it into Dec with the key and this gets back some value which we needs to XOR
with some IV . Then how does Bob get the IV? Alice sends it to him in cleartext. Thus, Eve can clearly see
what the IV is. Now what if we were doing AES with CBC? Our Enc function is thus the Block cipher (AES).

m1
Encrypt IV1 Enck (m1 , IV2 ), IV1

Encrypt IV2 Enck (m1 , IV2 ), IV2

8.2.3 Counter Mode (CTR/CM)

We have an IV, just like in CBC. Here, we encrypt IV with the key into the Enc function. Then take m1
and that output and XOR it to get c1 . In the second block, we have IV + + (add 1) and perform the same
operations. Hence, counter". We can show that this mode of operation is in its own way a stream cipher.
Note that the Enc is a PRP, meaning the output of k and IV is a pseudo-random number. This means the
firsr part of the encyption of the blocks (before you XOR the message block with the output of the Enc) is
just a big PRG.The end result is P RPk (IV )||P RPk (IV + +)|| . . . = P RGk (IV ).

25 of 59
 Applied Cryptography

9 Security Definitions
Definition 9.1 (One-time security). Defined as the lowest level.
Definition 9.2 (Semantic Security). Defined as the medium level, where it is secure against chosen
plaintext attacks (CPA-Secure).
Definition 9.3 (CCA Secure). Defined as the highest level, where it is secure against chosen ciphertext
attacks (CCA-Secure).

Steam Cipher (lowest level)

Block Cipher + ECB (lowest level)
Block Cipher + CBC (medium level)

Block Cipher + CTR (medium level)

Block Cipher + MAC (well this in a later lecture) (highest level)

9.1 One-Time Security

9.1.1 Background
This models the case where an encryption function is used just once. Its also considered to be at the
weakest level because we would like to use the function more than once.
Given c, can you find m? Shouldnt be possible.

Given c, can you find k? Shouldnt be possible.

Given c, some about about m, can you find k? Shouldnt be possible.
Given c and m, can you find k? You can then decrypt future cs. Shouldnt be possible.
There is a thing called a Security Game" to measure the security. Here, well use it for OTS.
We have participants and an adversary. Were given an Oracle (blackbox encryption function which has a
key, but cant recover it. You can supply inputs and get outputs. Lunchtime Attacks".) Below are the steps
of the game:
1. Adversary chooses any two messages: m0 and m1
2. Give {m0 , m1 } to Oracle (has chosen a key previously)
randomly
3. Oracle flips a coin, b {0, 1}. Encrypts mb : cb = Enck (mb )

4. Oracle gives the adversary cb

5. Adversary guesses value of b and guesses if cb encrypts m0 or m1

26 of 59
9.2 Semantic Security (CPA-Secure) Applied Cryptography

We say that an encryption is one-time secure (OTS) if the adversarys success rate is less than | 21 + |,
where  is negl(l). An example of negl would be something that decreases exponentially. Whats the
probability the adversary guesses right? Naive: Pr (correct) = 21 . We can define an advantage, Adv =
|1/2 Pr (correct)|. We can then say a crypto-system is secure if any adversaries advantage is negligible
(really small): negl(l) poly(l)
1
, where l is the key length. Thus negligible is an upper bound. This makes
it a very strong security definition. We would say that the adversary is polynomial-bounded (PPT-bounded
for probabilistic poly time).
An example of this would be: Pr (guess a random key) = 1
2l
= 1
exp(l) (AES = 1
2128 ).

9.1.2 Example
Lets look at an example where encryption clearly fails and we can look at how it fails in the game. An
adversary can decrypt the last bit: m0 = 0000 . . . 0 and m0 = 0000 . . . 1 where the numbers in front are
invariant. The adversary can get back cb (last bit 0? If so, m0 . Otherwise, m1 .
Another example is where we use the same scheme, except 1% of the time the adversary can decrypt the
last bit. Thus, Pr (success) = (0.01) 1 + (0.99)( 21 ) = 12 + 200
1
. 200
1
is not dependent on l. This means
its actually equal to 2 + (1) (O(1) > /poly(x)), which makes this equation larger than 1 + . Thus, this
1 1

is insecure.

9.2 Semantic Security (CPA-Secure)

Heres our security game:
1. Adversary chooses any message and receives encryption
2. Adversary chooses m0 , m1
3. Oracle encrypts one at random: cb
4. Adversary chooses any message and receives encryption
5. Adversary guesses
This type of model is for those that use encryption functions more than once. The game above is called
an adaptive" attack because of step 4 where the adversary can use this information of step 3. Recall ECB
mode it is not CPA-Secure (unless one used a 1 block message):
2) Adversary chooses m0 , m1
3) Oracle gives cb
4) Adversary asks to have m0 encrypted. Enc(m0 ) = cb guess m0 , otherwise m1
Corollary 9.1. No deterministic Encryption function is CPA-Secure
Lets look at CBC mode (or CTR):
2) Adversary chooses m0 , m1
3) Oracle gives cb

27 of 59
9.3 CCA-Secure Applied Cryptography

4) Adversary asks for encryption of m0 ...

Lets say cb is m0 . If you pass that into CBC mode itll give you c0 . However, if you do it again, we
know that our IV is different and thus the c0 will be completely different. With a lot more work, we can
prove that CBC is CPA-Secure. The proof involves assuming encryption function is ideal" (Pseudo-Random
Permutation). CTR mode is also CPA-Secure. Recall what we discussed in CBC mode for IV s: They are:
Random per encryption
Public
Generate IV after getting message (ignore this because it can create deterministic outputs (in some
ways) and thus no longer CPA-Secure. The TLS/SSL issue concerning this is now fixed)

9.3 CCA-Secure
Were gonna have a modified oracle blackbox which will now have access to a decryption function as well
as an encryption functiin (whereas before it could only encrypt). Were going to change the game we
mentioned above a little bit:
1. Adversary chooses any message and receives encryption, or any ciphertext and receives decryption
2. Adversary chooses m0 , m1
3. Oracle encrypts one at random: cb
4. Adversary chooses any message and receives encryption, or any ciphertext (except cb ) and receives
decryption
5. Adversary guesses
Due to these added tweaks, CBC (c.f. CCR) is not CCA-Secure. We would have an attack as follows:
2) Adversary chooses: m0 = ABCD where A is a block and m1 = W XY Z
3) Get back cb = 
4) Create c0b where c0b has blocks that are duplicated from cb but we flip the last bit. We then ask for
the decryption. We would then get back ABC where the last block is complete random and wed
also have W XY  and that last square is just garbage. Thus, succeed.
From the above game, whats missing in order to succeed with CCA-Secureness?

9.3.1 Plaintext Awareness

Any CPA-Secure (randomized) encryption scheme where it is infeasible to generate a valid ciphertext is
CCA-Secure. Note that if you have CCA youre also CPA and OTS. Thus we can analyze our modes of
operation:
ECB with multi-blocks is not OTS
ECB with a single block (block cipher) is OTS but not CPA/CCA
CBC and CTR is CPA-Secure but not CCA
Well see soon that Enc+MAC is CCA, CPA, and OTS Secure.

28 of 59
 Applied Cryptography

10 Message Authentication Codes (MACs)

Recall our security properties. Confidentiality is the use of encryption and message integrity is the use of
MACs. Thus, in this world, we dont care about encryption at the moment.
We have the following function: a = M ACk (m) where a is n-bits (tag/code) and k is symmetric with
l-bits, and m is our message which is {0, 1} . Alice sends Bob m and a to Bob, where both of them have
k. If we had Eve, she would see m and a and doesnt have k. It should be infeasible to replace the message
?
with a0 and m0 that is valid. We can then ask V erif y(m, a) = (a = M ACk (m)). In some way, we can
say that MACs are sort-of like keyed error-correcting codes, however theyre is no error correction, just
detection. Attacking a MAC is considered to be forgery. Thus, the security would have it that it is infeasible
to forge a tag/code on any (existential forgery or selective forgery) message without the key. So how do we
build these?
In general, there are two styles of MACS:
1. Hash-function based
2. Block-cipher based

10.1 Building a MAC from a hash

10.1.1 Attempt 1
Using a keyed hash function: a = H(k||m) (such as Merkle-Damgard). But this wont work because of
Length-Extension attacks (We dont need to know whats inside of the message is, but if were given given a
we can choose a message m0 and append it to the hash, giving us H(k||m||m0 ), which is M ACk (m||m0 ).
We could also do H(H(k||m)||m0 ) = H(k||m||m0 )).

10.1.2 Attempt 2
We would have ha = H(m||k), mi, which is just the reverse of the above. We could have H(m||k||k 0 )
which would give us m||k, but that cannot be computed. Thus, its secure against Length-Extension attacks.
We have an m that leads to a collision m0 , where H(m) = H(m0 ). If we used Merkle-Damgard, we would
have H(m||k) = H(m0 ||k). Thus we dont use because the hash needs to be collision resistant. That is, if
H becomes insecure to collision-resistance (easiest property to break) than MAC is not secure.
Recall Markle-Damgard: We have 2 blocks, where m and IV goes into a compression function which
outputs an x; H(m) = x. The output of x can go into another compression function with a key k
that is 1 block and that outputs a. Collision m0 is given by H(m) = H(m0 ), where H(m0 ) = x. If
we had the same setup and used m0 , we would get the output x which is then fed into the second
compression function and k which outputs a, since this is a deterministic process. If H(m) = H(m0 )
then a = M ACk (m) = M ACk (m0 ) = H(m||k) = H(m0 ||k).

10.1.3 Attempt 3
Were given ha = H(k||H(k||m)), mi. The inner H(k||m) value is part of attempt 1. Length-extension
because value is inside a hash, protected by pre-image resistance. The adversary can get y = H(m) =
H(m0 ) which is collision.

29 of 59
10.2 Block Cipher-Based CBC-MAC Applied Cryptography

10.1.4 Attempt 3 Revised (HMAC)

We have a = H(k1 ||H(k2 ||m)), where k1 is equal to the key k opad (outer padding, constant, 1 block).
k1 is exactly 1 block long (256-bit) and the key is shorter (128-bits). k2 is equal to the key k ipad (inner
padding). The size of a, the output of the hash, will be truncated (for example, we take the first 128 bits if
the opad is 256 bits).

10.2 Block Cipher-Based CBC-MAC

Recall we have c = Enck (m, IV ) (an abuse of terminology). We would like to take this and make it look
like a = M ACk (m), where k and m is the same. We can set IV to 0 in this example. From here, we
perform CBC encryption. Note that |m| = |c|, m = {0, 1} and that a is fixed. The difference is that
instead of outputting ciphertext from the blocks, you only output the last ciphertext block. Note that this
is secure only for fixed length messages (there exists tricks to fix this).

11 Authenticated Encryption (AE)

Both Alice and Bob has kenc , kmac . Alice encrypts her message, c = Enckenc (m) and then takes the MAC
of the result and produces a = M ACkmac (c) and sends hc, ai. Bob then does m = Deckenc (c) and
checks to see if a = M ACkmac (c). Eve cant recover m from c and cant change c and generate a valid
tag.

11.1 MAC-then-Encrypt
We can perform a = M ACkmac (m) and then perform c = Enckenc (m||a). This is in special cases secure.
The problem with this is that sometimes the Encryption function is malleable.

11.2 Encrypt-then-MAC
This was described above, where c = Enckenc (m, IV ) and a = M ACkmac (c, IV ). In general, this is
secure.
Note: Enc was CBC, and MAC was CBC-MAC (last block are same except using different IVs). In special
cases, same key can be used (If we used Enc with CTR and MAC with CBC-MAC, we obtain CCM proven
you can use the same key).

11.3 Other AE Modes

GCM (added to SSL/TLS)
OCB

Unless if you know better, you should always use AE. If in a flux and AE is not available, then perform
Encrypt-then-MAC. Should MAC the IV as well (you can never MAC too much information). Weve talked
about the following modes of operation thus far:

30 of 59
11.3 Other AE Modes Applied Cryptography

Mode of Operation Security

ECB not secure
Single AES (ECB-1 block) OTS
CBC CPA
CTR CPA
CCM (GCM, OCB) CCA
This concludes a key section in the course. Recall we have the following:
Keyless: Hash, PRNG, Extractors
Same key: Symmetric Encryption (stream and block which provide confidentiality), MACS (integrity),
AE (confidentiality and integrity)

Note that we have Hashes which are used in MACS, PRNGs are used in Streams, and Symmetric
Encryption is used in MACs and AEs.
Hashes are named PR functions and Streams are PR permutations.
Different Key: Asymmetric Encryption (ElGamal CPA, Cramer-Sharp CCA, RSA OTS, RSA+OAEP
CCA), Signature (DSA, RSA Signature)

Note that in symmetric key primatives (with exclusion of MACs) is considered to be a low-level application,
ie. logical operations, whereas Asymmetric key primatives (such as key exchange, Encryption, signature) is
considered to be low-level in mathematical equations.

31 of 59
 Applied Cryptography

12 Number Theory
12.1 Algebraic Structures
Algebraic structures consists of the following:
A set of elements (real numbers, integers, coordinates, polynomials, etc.)
A set of operations (addition, multiplication, exponentiation, etc.)

A set of rules about how operators apply to elements

What are the set of properties that youd want once you had a set of elements and operations? Define
some notation: Set a set of elements as S and an operation
1. , a, b S, a b S (Closure)

2. (a b) c = a (b c) (Associativity)
3. e S st. a e = a (Identity)
4. a S b S st. a b = e (Inverse)
5. a, b, a b = b a (Commutativity)

Properties 1-3 is a monoid

Properties 1-4 is a group

Properties 1-5 is an abelian group

We can have a structure which consists of 2 operations, such as + (abelian group) and (monoid). In
our case, multiplication would be the abelian group and exponentiation as the monoid. There are other
structures such as Finite Fields and Lattices that are important in the field of Cryptography, however we
will not be looking them.
If we define a cryptosystem generically in terms of algebraic structures, the details of what set/operation(s)
we use can be swapped out. In this course, well be looking at integers mod p (prime) and multiplication
(exponentiation). There exists a faster algebraic structure which makes use of an elliptic curve (coordinates)
and an operation called the Point-Doubling (point multiplication). This structure is used in the real world,
whereas the system well be looking at in this course which is easier to understand.

12.2 Integers mod p

Zp = {0, 1, 2 . . . , p 1}

Zp = {1, 2, . . . , p 1}
Note that p
= 0 mod p (congruency)
We see that Zp is an abelian group with multiplication exception 0, however Zp is generally an
abelian group.

32 of 59
12.3 Exponentiation mod p Applied Cryptography

The identity element is defined to be 1

If p is a prime, every element of Zp has an inverse
In this course, theres two settings" well be looking at. In Setting 2, we should note that integers
mod n where p q and p, q is a prime.

There is no division (multiplication by an inverse)

a b = c, b =?, b = c
a (this cannot be done)
1 1
a :aa = 1, b = c a1

Example 12.1. We have Exp mod 11 where rowcolumn mod 11.

0 1 2 3 4 5 6 7 8 9 10
1 1 1 1 1 1 1 1 1 1 1 1
2 1 2 4 8 5 10 9 7 3 6 1
3 1 3 9 5 4 1 3 9 5 4 1
4 1 4 5 9 3 1 4 5 9 3 1
5 1 5 3 4 9 1 5 3 4 9 1
6 1 6 3 7 9 10 5 8 4 2 1
7 1 7 5 2 3 10 4 6 9 8 1
..
.

Order of a set is the number of elements in it, e.g. ord(Zp ) = p 1 (abelian group). Note that for
setting 1 cryptography, the order of the set must be a prime number.

12.3 Exponentiation mod p

By Fermats Theorem, we have that gcd(a, p) = 1, where a S and p is mod p. Note that
ap1
=1
Exponents can be reduced: mod ord(S) eg. mod p 1, where S is Zp in mod p 1. We can
have g 5 g 20 = g 25 mod 10
Order of an element can be defined as the order of a S is the smallest t > 0 st. at = 1 mod p.
For example, ord(2) = 10, ord(3) = 5, ord(1) = 1, ord(10) = 2 in Z11 .

The order (t) of an element a divides the order of the set (p 1). For example, in mod 11, we
have a Z11 , a|p 1.
In general, if ord(a) = p 1, then a is a primitive root. That is, it generates every element in Zp .
For example, a = 2 in Z11 , ord(2) = 10 which makes 2 a primitive root. 2 generates, that is the the
integers that result from a being exponentiated by any value

Zp always has a generator

Zp always has a element with order of every divisor of p 1

33 of 59
12.4 Subgroups Applied Cryptography

12.4 Subgroups
The set generated by any element a is a group (e.g. closed under multiplication, with inverses, etc.). That
is, a (or g) is a generator of some group and the primitive root is the generator of Zp .
Example 12.2. Let g = 3. The generators are {1, 3, 9, 5, 4}.
Corollary 12.1. For all g with same ord(g), the generated set is the same.
Definition 12.1 (Quadratic Residue). a st. b2 = a, a is a quadratic residue. Note that half of Zp has
two roots and that half of Zp has zero.
Definition 12.2 (Safe Prime). A safe prime p is a prime st. p = 2q + 1 where q is also a prime. In
this course, q will always be multiplied by 2, however in the real world it can be a different factor. Given
a Zp , we have ord(a)|p 1 = {p 1, q, 2, 1} where p = 2q + 1 and p 1 = 2q. We say that p 1 is
the primitive root and that we use Gq for the q in the set mentioned earlier.
Recall we mentioned Settings:
1. Integers mod p where p = 2q + 1 for prime p and q - known as the Discrete Log Setting
2. Integers mod n where n = pq for prime p and q - known as the RSA Setting
3. Elliptic Curves (may cover this at the end of the course)

12.5 Integers mod p Continued

Recall we said we have p = 2q + 1 where p, q are primes and p is 2048 bits long. Recall we have Zp as seen
in the chart (http://people.scs.carleton.ca/~clark/courses/1301-4109/misc/groups.pdf).
We had generals g Zp where they generate a set of integers when exponentiated by the other integers in
g Zq . We also said that the order is defined to be ord(g) which is the size of the generated group (row
in the exp table).
Example 12.3 ( mod 23). We know that 23 is a safe prime (23 = 2 11 + 1). The generators are
g = 1, set= {1}, ord(1) = 1 (recall ord is the largest t > 0 st. g t = 1)
g = 2, ord{2} = 11, set= {1, 2, 4, 8, 16, 9, 18, 13, 3, 6, 12}
g = 5, ord(5) = 22 and thus set=Zp and is a primitive root
g = 22, ord(22) = 2, set= {1, 22}

12.5.1 Inverses
For mod p, every element in Zp is invertible.
Definition 12.3 (Invertible). a is invertible if b st. a b = 1, where b = a1

12.5.2 Exponents
Reduced mod ord(Zp ) = 22 where Zp = [1, 22]. We have g a g b = g a+b mod p
eg. g = 1, g 1 = 1 and
thus if we had g = 2, g 1 = 12 or g = 3, g 1 = 8.

34 of 59
12.6 Quadratic Residue Continued Applied Cryptography

12.5.3 Inverse is an Exponent

g 1
= g 1 mod p


= g ord(ZP )1

= g p2
With p = 23, then the inverse of g is g 21 = g 1 where we know that ord(Zp ) = p 1.
Example 12.4. Let g = 2, ord(2) = 11, set= {1, 2, 4, 8, 16, 9, 18, 13, 3, 6, 12}. Let this group be called
Gq . ord(Gq ) = q where q is prime.
If p = 2q + 1, groups of order q|p 1 q|2q is always a generator for Gq
Exponents reduced mod ord(Gq ) = mod q
We have that exponents (g a ) are in Zq = {0, 1, 2, . . . , q 1} where g Gq and Gq is a subset of
Zp
If we had g a g b = g (a+b mod q) = g (a+b mod p)
where g a Gq Note that if g a
/ Gq then g a g b 6=
g (a+b mod q) = g (a+b mod p) .
We know that g = 2 generates Gq . Lets look at g = 4. This has ord(q) therefore g = 4 generates Gq .
We can also see that g = 3 generates Gq . Were getting a pattern here. Notice that every number in the
set {1, 2, 4, 8, 16, 9, 18, 13, 3, 16, 12} all generate Gq . Therefore, anything in Gq is a generator of Gq with
exception of g = 1.

12.6 Quadratic Residue Continued

We have a Zp is QR if b Zp st. b2 = a. Similarly, a is NQR if 6 b st. b2
= a. We can define the QR
set as : {1, 4, 9, 16, 2, 13, 3, 18, 12, 8, 6} (in the running example weve been using). Notice that QR = Gq
and that |QR| = (p 21 ) = q and |N QR| = (p 12 ) = q.
Lets look at a way of encrypting using QRs: Given a number between [1, q] then we map (encode) it
into Gq or we map (decode) it back from Gq . Well havea Zq Encode(a) = a2 mod p = A
(encode). To decode, we have A Gq Decode(A) = a mod p = a. In our running example, we
have Encode(5) = 2 mod 23 and Decode(2) = 5, 18. We have 5 Zq and 18 / Zq (given that p = 23
and q = 11).
We have a bunch of Algorithms. Note that multiplication and exponentiation are efficient. Given x, y find
a:
y = xa mod p, y, x, a Gq is efficient since a = yx1 = yxq1
y = ax mod p, y, x, a Gq is efficient since a = yx1 = yxq1

y = ax mod p, y, a Gq , x Zq is efficient (only true for mod a prime) since x y which leads
to a concept called Discrete" Roots
y = xa mod p where y, x Gq , a Zq and we have a = logx y is the Discrete Logarithm, but it is
not efficient since in fact, it is infeasible for large p (where |p| 2048 bit prime and you can recall
the NIST standard of (2112 )
Note that elliptic curves is equivalent of the DLP (Discrete Logarithm Problem) where n 224.

35 of 59
 Applied Cryptography

13 Diffie-Hellman Key Exchange

We have the following Problem: Alice and Bob have never met but want to use AES-GCM to share messages.
They need to have the same key but have never met. Can they securely establish a shared key?
Recall we have Eve who can only eavesdrop. The setting for Alice is that she has p, q are primes and
g Gq . This is not a secret and she sends hp, q, gi. Alice chooses a Zq which is a secret and sends g a
mod p. Bob then takes b Zq where it is a random selection and then sends Alice g b mod p. Alice will
then take a, g b and compute (g b )a = g ab . Bob can also take b, g a and compute (g a )b = g ab . Suppose Eve
gets a hold of g, p, q, q a , g b . She cannot find g ab (unless she breaks the DLP).
Recall this is a key agreement protocol. Alice and Bob want to establish a shared secret key k and
communicate over a channel where Eve is listening. The protocol works a follows:
They need to establish which group to be in. Alice chooses p = 2q+1 where p, q are primes and |p| = 2048
bits. Note that Alice can use an existing p. Thus there is nothing secret about p since she can fetch it from
a database of safe primes.
1. Alice picks {p, q}
2. Alice picks a generator g st. g Gq . This gives her {p, q, g}

3. Alice randomly picks a number a st. a Zq r [0, q]. She then computes g a mod p and obtains
ya = g a mod p
4. Alice sends {p, q, g} to Bob and ya = g a mod p

1. Bob picks b r Zq . He also has yb = g b mod p and sends yb to Alice. Note that Alice cannot get b
from {g, yb } due to the DLP
2. Alice then gets k = yb a = (g b )a = g ab

3. Bob also does k = yab = (g a )b = g ab

What does Eve see?

{p, q, g}
g
ya = g a

yb = g b
Note that it is infeasible to compute g ab . Note that she doesnt know {a, b}. This leads to the Computational
Diffie-Hellman Problem (CDHP).

36 of 59
13.1 Decisional Diffie-Hellman (DDH) Assumption Applied Cryptography

13.1 Decisional Diffie-Hellman (DDH) Assumption

Given g, g a , g b and either g ab or g r where r is a random value, it is infeasible to distinguish them. It turns
out that while working in Gq , the DLP, CDHP, and DDH are all hard" problems. If you work in Zp then the
DLP and CDHP are hard", however DDH is not.
We have f (x) = g x mod p = y. The DLP is that given y, it is infeasible to compute x. Equivalently,
given f (x), it is infeasible to compute x. Note that if we let f (x) denote H, it looks very much like a
hash function. Thus f (x) is a one-way function. We have the DL-one-way function which works as follows:
ab = g a g b = g a+b = a + b. Also note that ab = (g a )b = g ab = ab. This is a Homomorphism.

Note that H(a) H(b) 6= H(a||b). Alice has a and sends a to Bob. Bob has a b and sends b to
a b
Alice. Alice does b which leads to ab and Bob takes a and gets ab from it. The CDH states that
a b 6= ab . DDH says given a , b , we cannot tell ab from r .

13.2 Blinding in Gq
Alice has a message m Gq where G is the group, with q elements in the group. Note that G is closed
under multiplication.
Aside: m0 [0, q 1] and m12 mod p = m, m Gq .
We can then say that m r mod p, where r is a random element of Gq , hides m. This is like an OTP. We
can say c = m r where for every possible value of r, there is a different value of m st. c is the same. r
is effectively a OTP (for true randomness). This makes it computationally blinded (pseudo-random).

13.3 Diffie Hellman Continued

Note that it is only secure against a passive (eavesdropping) adversary. It is not secure against an active
(modifying) adversary who can change values. We can say that Eve is the passive adversary and Mallory is
the active adversary. A man-in-the-middle attack is for systems where an active adversary can be exploited.
We have the following scenario:
Alice chooses a and sticks it in a box a and sends it to Bob. Mallory intercepts and instead creates
a0 and sends |a0 | (box notation)to Bob

Bob chooses b and sends b to Alice. Mallory intercepts and instead creates b0 and sends |b0 | to
Alice.
Alice then performs |b0 |a = |ab0 | = k1

Bob performs |a0 |b = |a0 b| = k2

0
Mallory then can do the following: |a0 | = |ba0 | = k2 and then |a|b = |ab0 | = k1
We have that Alice has message Enck1 (m) which sends to Mallory who can then do Deck1 (Enck1 (m)) =
m. Then she does Enck2 (m) and sends that to Bob who then performs Deck2 (Enck2 (m)) = m.
We need to fix the Diffie-Hellman to be secure against active attacks. This is done using signatures which
well see late.

37 of 59
13.4 Example Applied Cryptography

13.4 Example
Alice has the following parameters:
Safe prime p = 23 and thus q = p1
2 = 11
Generator of Gq :
1. Pick a random number gi and then ask if giq = 1 mod p. Note that gi1 6= 1 and gi2 6= 1.
2. Pick random gi and set g = gi2 mod p. If g = 3 then p, q, g = 23, 11, 3.
3. Alice chooses a random number a Zq = [0, q 1] = 19 = 8 mod 11. Then yA = g a
mod p = 319 mod 23 = 6. Note that Eve needs to find x within 6 = 3x mod 23 but thats
the DLP.
4. Bob sets b = 4 and generates yB = g b mod p = 12 mod 23. Thus Eve would have 12 = 3x
mod 23 to figure out.
5. Alice computes the secret key by doing k = yBa
= g ba = g ab . Bob performs k = yA
b
= (g a )b =
g . If we plug in numbers, Alice gets 12 mod 23 and Bob gets 6 mod 23. They both
ab 8 4

reduce to 8, which is their secret number.

38 of 59
 Applied Cryptography

14 Public Key Encryption (Asymmetric Key)

1. Alice generates a key pair: {pk, sk} where pk is a public key and sk is a secret key
2. Alice posts pk publicly
3. Given pk, infeasible to compute sk
4. Encryption: c = Encpk (m). Decryption: m = Decsk (c).
5. Anyone can send Alice a message by knowing pk
6. Only Alice can decrypt it

14.1 ElGamal Encryption

14.1.1 First pass (modification of DH)
Let Alice represent the recipient.
1. {p, q, g}
2. Alice chooses a Zq and computes ya = g a mod p where a is the secret key and g a is the public
key. Note that it is infeasible to compute sk from pk due to the DLP.
3. Bob has a message m Gq (encoded).
4. Bob chooses b Zq and computes yb = g b mod p
5. Bob sends yb to Alice
6. Bob and Alice know g ab = k
7. Bob computes m k mod p = c and sends c to Alice
8. Alice computes yb a = k. Alice then computes c k 1 mod p = m = mk k 1 mod p.
Note that from step 6 and upwards it is simply the Diffie-Hellman.

14.1.2 Second pass

Given (p, q, g) we can put them into a function keyGen(p, q, g) = {x, y}. The function is as follows: It
takes a secret key x Zq and create a public key y = g x .

14.1.3 Encryption
c = Ency (m, r) where m Gq . r is a random factor (similar to an IV). Thus c = {c1 , c2 } = {g r , m y r }
where r r Zq and m Gq . Note that if you encrypt a message twice then because r is a random factor
then the output will not be the same. Thus ElGamal is CPA-Secure. Also note it is homomorphic just like
the DH.

14.1.4 Decryption
my r
We have m = Decx (c) = c2 cx r r x
1 = (m y )(g ) = (my r )(g rx )1 = (my r )(y r )1 = yr = m.

39 of 59
14.2 ElGamal Continued Applied Cryptography

14.2 ElGamal Continued

Recall some of the DH notation: We have x which is the secret key and x as the public key. We have
a
y = f (x) = g x mod p where x a = x + a and x = ax . We have a KeyGen : st. it has x and
x . We also have an Encryption function (which is randomized) where we generated an r (random factor)
r
and put it in a box, r . Then we have c = { r , x m} = { r , xr m}. How do we get m back? We
have to know what the value of xr is. Thus the Decryption function is as follows: Given { r , xr m} we
x 1
can compute xr m r = xr m xr = xr m xr = xr xr m = 0 m = m. Note that 0 is
0
g mod p = 1.
We have Enc(m1 ) = hc11 , c21 i = c1 . We have Enc(m2 ) = hc12 , c22 i = c2 . Therefore Enc(m1 m2 ) =
hc11 c12 , c21 c22 i. We can also perform Enc(m1 )a = h(c11 )a , (c21 )a i.

14.3 Homomorphic (Malleability)

Ency (m1 ) Ency (m2 ) = Ency (m1 m2 )

Ency (m1 ) a = Ency (a m1 )
Ency (m1 )a = Ency (ma )

Recall that we have y = g x mod p where x [0, q 1] = Zq , y Gq , g Gq , and p = 2q + 1. This

is a one-way function. The DLP is that it is hard to find x given y, g, p. Here is a list of some DLP-based
primitives:
Diffie-Hellman: key establishment
ElGamal: Public key encryption (CPA) (confidentiality)
Cramer-Shoup/Twin ElGamal (CCA) (confidentiality)
DSA/Schnorr: Signatures that makes use of Zero-knowledge Proofs (integrity)

14.4 Properties
Multiplicatively Homomorphic: Enc(m1 ) = g r1 , m1 y r1 and Enc(m2 ) = g r2 , m2 y r2 where
Enc(m1 , m2 ) = g r1 g r2 , m1 m1 y r1 y r2 = g r1 +r2 , m1 m2 y r1 +r2 = Enc(m1 m2 , r1 + r2 )
Even with decryption key, cannot recover r
Randomized: Enc(m1 ) 6= Enc(m1 ) where LSH is g r1 , m1 y r2 and RHS is g r2 , m1 y r2 , however
r1 6= r2 and g r1 6= g r2 .
Every ciphertext hc1 , c2 i where c1 , c2 Gq will decrypt to something

14.5 Proof of CPA-Secure

Theorem 14.1. Elgamal is CPA-Secure:
Game 0: CPA-Secure Alice sends the Oracle a bunch of messages (m, m, m) and the Oracle sends
back to Alice a bunch of ciphertext (c, c, c). Note that the Orale knows y = g x where y is the public key

40 of 59
14.6 ElGamal non CCA-Security Applied Cryptography

and x is the secret key, whom sends it to Alice and thus Alice knows y, g, p. Alice sends m1 , m2 and then
the Oracle chooses a b [1, 2] and sends Alice cb . Alice then sends a bunch of messages again and the
Oracle sends some ciphertext. What is cb ? cb = g r , mb y r . Alice tries to guess whether b = 1 or b = 2.
Whats the probability that her guess is correct?
There are two proofing techniques:
1. Game Hopping (Hybrid Arguments)
2. Simulation
Proof. Were using the Game Hopping proof for this. Were making a Game 1 where we change some things:
Oracle gives Alice y, g, p. Alice sends some messages and the Oracle sends some cipertext. Then Alice sends
m1 , m2 . The Oracle picks a b [1, 2]. This is where its different. The oracle does g r , g R = cR
where R is a random number. The Oracle then sends cr to Alice and then the two exchange messages and
ciphertext. Alice now guesses if b = 1 or b = 2? Whats the probability that Alice will guess correctly?

Pr (guess correctly) = 50%

Lets look at the difference between Game 0 and Game 1 and the different of the probabilities. Thus we
can say:
|Pr (win G0) Pr (win G1)|
What does Alice know in G0?
p, g, y, g r , my r = p, y, g x , g r , mg xr
What does Alice know in G1?
p, g, y, g r , g R = p, g, g x , g r , g R
Recall the Decisional Diffie-Hellman: g, g a , g b where g ab is indistinguishable to g R . It turns out that
in both of the above games, you cant distinguish the things she knows in Game 0 and Game 1 cant be
distinguished from each other. Thus we can say:

|Pr (win G0) Pr (win G1)| = 

where  is negligible (DDH).

Pr (G0) = Pr (G1) + |Pr (G0) Pr (G1)| = |Pr (G0)| = 50% + 

since Pr (G1) =  and Pr (G0) = 50%.

Note: Technically there are different definitions of CPA, such as IND-CPA (indistinguishable ElGamal),
NM-CPA (non-malleable ElGamal is not).

14.6 ElGamal non CCA-Security

The Oracle has x, y = g x and sends Alice y. Alice sends m1 , m2 to the Oracle and the Oracle selects a
random b [1, 2]. The Oracle sets up cb = y rb , mb y rb and then sends cb to Alice. Alice tries to guess.
What if she does cb Enc(1)? She gets back c. Now she does cb = hcb1 , cb2 i = hcb1 g r2 , cb2 y r2 i, where
r2 Zq . She then Decrypts c and sends it to the Oracle. The Oracle then sends Alice mb .

41 of 59
 Applied Cryptography

15 Zero-Knowledge Proofs (ZKPs)

We have a Prover (Peggy) and Verifier (Victor).
Definition 15.1 (Soundness). Soundness: The Verifier wants to ensure the proof" actually proves what it
is supposed to.
Definition 15.2 (Zero-Knowledge). Zero-Knowledge: Prover wants to make sure the secret stays secret.

15.1 Shnoor Protocol

Proof that you know x st. y = g x mod p for y, g, p without revealing any knowledge about x. Recall the
box notation: y = x = g x mod p.
Prover Direction Verifier
knows x Zq knows x = g x mod p
a
Pick random number: a Zq Flip a coin c = {0, 1}
c

(
a c=0
Sends d=
a+x c=1
( ?
c=0 d = a
?
c=1 d = a x = a+x
Zero-Knowledge: c = 0 then zero-knowledge. If c = 1 then a + x( mod q) where a is a random
value which is a blinding factor. Only thing we know about x has to come from knowing something about
a, which is negligible.
Soundness: We have a Malicious Prover, denoted Pe (doesnt know x).
Step 1: send A (which should be a ) where I have two ways to choose it:
1. a Zq , a = g a mod p = A, a Gq .
2. A Gq , A = ? .

Step 2:
c = 0 If Pe did 1a then its okay.
c = 1 If Pe did 1a then hes caught.
c = 0 If Pe did 1b then hes caught.
c = 1 If Pe did 1b then its okay.

Heres what Pe will do: He chooses d Zq and put that in a box, d (which is okay). He will then
?
do A = x d = d x and sends. The Verifier will know take d and go d = A x =
dx x = dx+x = d .

42 of 59
15.2 3-move (Sigma) Protocol Applied Cryptography

Thus the Pr (cheating) = 1 1

2t where t is the number of plays of the game.
Recall: Alice has y, g, p and claims to know x st. y = g x mod p. Alice proves to Bob that she knows
x without telling Bob x. Furthermore, leaking no information about x. The protocol is as follows (using
non-box notation):

Public knows {g, y, , p} where g Gq , y Gq and p is a safe prime.

Alice chooses a secret x Zq where x : y = g x mod p. She then chooses a Zq and b = g a
mod p and sends b to Bob.
Bob sets a challenge value and is denoted by c [0, 1] and then sends c to Alice

Alice sets d to a if c = 0 and sets d to a + x mod q if c = 1. Thus d would be a + cx mod q and

then sends d to Bob
?
Bob needs to verify this: g d = y c b which is g a+cx = g x g a = g a+cx .

What if Alice was malicious (A)?

e She would issue a proof" that she knows x even though she doesnt.
Fact: If and only if Alice can guess the challenge value correctly, she can cheat. The following is the
method that Malicious Alice would take:
Guesses that c0 = c
Arrange the following to hold: g d = y c b. She has to choose a b and a d st. this equation holds. We
can sort of ignore the y c value because its like a constant. Thus we look at g d = b. If she chooses
the value of b first, she cant find the value of d because of the DLP. Thus she must choose a d first
and then computes b.
0 0
She now has g d = y c b and re-arranging we get b = g d y c . Note that she does not know a due to
the DLP.

If Alice guesses c0 correctly she wins". Otherwise she loses".

15.2 3-move (Sigma) Protocol

Alice commits" to some data
Bob challenges Alice
Alice opens up some data in a way that is consistent with the commitment and the challenge

Challenge:
Must be unpredictable before Alice completes the first step above (the commit).
c {0, 1}. Note that c can be any integer. Note that Pr (Alice cheats) = 12 .

c {0, 1}t where Pr (Alice cheats) = 21t . On a side note, when you extend the challenge to t-bits,
it is no longer technically zero-knowledge (not going to be seen in the course).

43 of 59
15.3 Fiat-Shamir Heuristic Applied Cryptography

15.3 Fiat-Shamir Heuristic

It may seem unusual why Alice would try to prove such a statement above. In other words, its a way of
Alice proving that she knows the private key in a public key system. The only drawback to the Schnorr
protocol is that its interactive. Note that the Schnorr -protocol is interactive.
Let {{p, g, y}, {b, c, d}} be a transcript" of a run of Schnorr. This is unconvincing because no guarantee
that b was generated before c. Note that a fake transcript, given {{p, g, y}, {b, c, d}}, we have a chosen b
and d and then we set b = g d y c , is accepted. All of this boils down to the order of the chosen elements
{b, c, d}. The Fiat-Shamir Heuristic is a way of removing Bob and making it obvious that the b value came
before the c and d values.

Transcript should prove b is chosen before c

{{p, g, y}.{b, c = H(b), d}}
Add verification step where we check c = H(b).

Note:
b before c relies on pre-image resistance
c needs to be unpredictable. We need to assume the output of the hash is random (Random Oracle
Assumption).

c needs to be large st. faked hb, c, di values do not, by coincidence, have c = H(b).
You should actually do c = H(b, {p, g, y})
Thus the above removes Bob from the protocol and at the end we would output {{p, g, y}, {b, c, d}}. She
can give anyone this transcript and then everyone can verify it by the following:
?
1. g d = y c b
?
2. c = H(b)
?
3. In one step we can just do c = H(g d g c )

44 of 59
 Applied Cryptography

16 Digital Signatures
Alice has a public key, y, and a secret key x. Alice signs a message m as:

s = Sigx (m, r)

Note this has nothing to do with encryption and just integrity. Bob, or anyone, can verify hm, si. This
would be T rue/F alse = V erif yy (m, s).

16.1 Signature vs MAC

Sig convinces anyone
M AC convinces only the person you share the key with

16.2 Construction
There are two ways to do this:
1. Built from public key decryption

2. Built from ZKPs (Fiat-Shamir or non-interactive zero-knowledge)

16.2.1 Public Key Decryption

Suppose we have a public key encryption function c = Encpk (m) and m = Decsk (c). The signature
would be built as follows:
4
Signsk (m) = Decsk (m) = s
?
then send (m, s). To verify, we perform Encpk (s) = m. This method doesnt work with CPA-Secure
Encryption (e.g. ElGamal). Due to Enc being randomized, you wont necessarily get m back when you do
?
Encpk (s) = m. This also doesnt work with CCA-Secure because Decsk (m) should fail because it is hard
to construct a valid ciphertext. We will be revisiting this method when we get to RSA.

16.2.2 ZKPs
Shnoor alongside Fiat-Shamir proves that a transcript was generated by the person who knows x st. y = g x
mod p. We can let x be the sk and y be the pk.

16.3 Schnorr Signature

We have a transcript {{p, y, g}, {b, c = H(b, m), d}} where we do b first, c second, and d third. Given
that, then only the person who knows x can generate a valid d.

45 of 59
16.3 Schnorr Signature Applied Cryptography

16.3.1 Sign Function

s = {s1 , s2 , s3 } = Sigx (m, r) = {g r , H(g r ||m), r + H(g r ||m) x mod q}
= {b, c, b + cx} = {s1 , H(s1 ||m), r + s2 x}
? ?
We perform verification as follows V erif y(m, s, y) : g s3 = y s2 s1 and s2 = H(s1 ||m). Sig should
prevent forgeries and that is it infeasible to sign any message m without knowledge of the private key. We
? ?
would also have s1 y s2 = g s3 and thus by putting in s2 we have s1 y H(m||s1 ) = g s3 (drop s2 from the
signature).

16.3.2 Schnorr-Security
DLP (Schnorr-ZKP)
Pre-Image Resistance (Hash)

Random Oracle
Collision Resistance (Hash) (Find m0 st. H(s1 ||m0 ) = H(s1 ||m))

16.3.3 Schnorr Variants

We can have s3 = s2 x + r mod q where x is the secret key (hides). We have 1 equation and 2 unknowns
(x and r). We only know g r and g x and thus we cant solve for r and x because of the DLP. A famous
variant is s3 = r1 (s2 + s1 x) which is DSA (Digital Signature Algorithm). If were able to determine or
predict what r is, then it may be possible to solve for x (which is really bad). We address this problem
in one of the assignments and well be showing that we can actually extract the private key if the random
factor is used more than once.

46 of 59
 Applied Cryptography

17 Building CCA-Secure
Were going to look at CCA-Secure public key encryption. Recall ElGamal is CPA-Secure (reduction to DDH
assumption), but not CCA.

17.1 Naive Approach

1. Take CPA-Secure encryption and sign it, ie. ElGamal and Schnorr Signature:

hc1 , c2 , s1 , s2 , s3 i

This uses different keys for encryption and signatures

2. Cramer-Shoup: 4 elements and 1 key
3. Twin ElGamal: Very new and uses 2 elements: The public parameters are {p, q, g}, the secret key is
sk = {x, x2 } and the public key is pb = {y1 = g x mod p, y2 = g x2 mod p}. The Encryption is
Encpk (m, r) = hg r , SEnck (m, IV )i = {c1 , c2 } where the SEnck is something such as GCM or
any CCA-Secure mode of operation. From that encryption, we have k = H(g r , y1r , y2r ). To decrypt,
we have Decsk (c) = SDeck (c2 ) = m where k = H(c1 , cx1 1 , cx1 2 ) = H(g r , (g r )x1 , (g r )x2 ) =
H(g r , (g x1 )r , (g x2 )r ) = H(g r , y1r , y2r )

Recall Diffie-Hellman:
Key Exchange protocol
Passive adversary (eavesdrops, secure)
Active adversary (changes values, insecure due to MITMA)
Station-to-Station (STS): Diffie-Hellman with signed values.

17.2 STS
In this scenario, we have:
Public knowledge of {p, q, g}.
Alice has a [1, g], pkA , and yA = g a mod p. She sends to Bob yA .
Bob chooses b [1, q], pkB and then yB = g b mod p. Bob then sends to Alice yB , SEnck (SigskB (yB , yA )) =
cB . Bob also performs k = yAb
mod p = g ab .
Alice then does k = yB
a
mod p = g ab . Alice then sends back a confirmation by sending SEnck (SigskA (yA , yB )) =
cA .
Alice then performs SDeck (cB ) = Sig which she can verify with pkB and Bob can also perform
SDeck (cA ) = Sig which he can verify with pkA .
How does Alice and Bob learn each others public keys? Recall in Symmetric keys, we have (n2 ) keys
where n is the number of people. In Public key, we have O(n) keys. There is also a concept called
Certificates:

47 of 59
17.2 STS Applied Cryptography

Trusted third party: Certificate Authority (CA) (e.g. Carleton University).

m = Name Alice, SN=xxx, Public Key = pka "
Cert = SigcA (m)
Bob wants Alices public key. To do this, Bob sends a request and then Alice sends to Bob pkA , Cert.
Bob then does V erif y(pkA , Cert, pkCA ) where pka is the message, Cert is the signature, and
pkCA is the CAs public key. This will lead to a Centralized Public Key Infrastructure (PKI).

48 of 59
 Applied Cryptography

18 RSA Setting
We will work in mod N where N = pq where p, q are large safe primes.
Elements of Zn :
inverses; invertible iff. gcd(a, n) = 1 where a is an element (coprime to n)
Not invertible: p, 2p, 3p, . . . , (q 1)p, q, 2q, 3q, . . . , (p 1)q. Everything else is invertible: Zn
Elements of Zp :
All elements except 0 had inverses: Zp
Lets look at the differences of the order of an element:
Zn :
ord(a)|(p 1)(q 1) = ord(a)|2
p 2
q
p = 2
p + 1, q = 2
q+1
Therefore we have {1, 2, 4, p, q, pq, (p 1)(q 1)}
In general, ord(a) = (n)
Zp :
ord(a)|p 1 = ord(a)|2q which is {1, 2, q, p 1}
Recall that (n) is Eulers function which represents all the numbers coprime to n (and less than n). Note
that (p) = p 1 and (n) = (p 1)(q 1) where n = pq. This means that |Zn | = (p 1)(q 1).
Example 18.1. Find x given g and y:
y = xg mod n easy to find if y Zn
y = gx mod n easy to find if y Zn
y = gx mod n Discrete Log, still hard

y=x g
mod n Discrete Roots (trying to find x = g
y), hard, aka. RSA Problem

Example 18.2. Given n, find p and q: Factoring (hard for large n where |n| 2048, NIST of 2112 ) and p
and q are generally the same length (number of bits).

18.1 Textbook:" RSA Encryption

18.1.1 Key Generation
1. Pick two large safe primes p and q
2. Compute n = p q
3. Pick integer e (from Zn ), which is public, and relatively short e standardized by NIST
4. Compute d = e1 mod (n)
5. Public key: n, e, Private key: d, Secret but can be discarded: p, q

49 of 59
18.1 Textbook:" RSA Encryption Applied Cryptography

18.1.2 RSA Encryption

c = Encpk (m) = me mod n
Cannot find m from c, n because of discrete roots.

18.1.3 RSA Decryption

Decsk (c) = m = cd mod n = (me )d mod n = med = mod n = m
Cannot find d given e, n due to Factoring.

18.1.4 Properties
1. Not randomized, we encrypt the same message and get the same ciphertext. Not CPA-Secure (thus
not CCA-Secure)
2. Multiplicatively Homomorphic:

Enc(m1 ) Enc(m2 ) = Enc(m1 m2 ) = me1 me2 mod n = (m1 m2 )e mod n

Recall Signature methods:

1. ZKP that you know secret key bound to a message
2. Sign by decrypting: Doesnt work for ElGamal because of randomization and works with textbook"
RSA

18.1.5 RSA Signature

4
s = Signsk (m) = Decsk (m) = md mod n
Thus we output hm, si.
?
V erif ypk (m, s) : se mod n = m
= mde mod n
0
=m mod n
=m

Note that the RSA Signatures are also deterministic. It doesnt achieve the highest level of security (for
signatures):
?
Given m, s we have: m0 = m 2e and s0 = 2s. Thus (s0 )e = m0 which is (2s)e = 2e se = 2e mde = 2e m.
Example 18.3. Given valid Signature hm, si, compute forgery as m0 = m 2e mod n and s0 2s mod n.
?
V erif y(s0 , m0 ) = (s0 )e mod n = m0 mod n. We then have (2s)e mod n = m2e mod n and then
2e (md )e = m2e and thus 2e m = 2e m.
The above example shows that what we have is not strong enough. Thus, we need to do improvements.

50 of 59
18.2 Strengthening RSA Encryption/Signature Applied Cryptography

18.2 Strengthening RSA Encryption/Signature

Use padding scheme
Padding scheme is randomized
Padding scheme uses hash functions (assumed to be random oracle)
Enc(m||pad(r)): OAEP (Optimal Asymmetric Encryption Padding) and is CCA-Secure

Sig(m||pad(r)): PSS (Probabilistic Signature Scheme): as secure as Schnorr and DSA

Encryptions weve seen so far:

Textbook RSA : OTS
ElGamal : CPA
Twin ElGamal (Cramer-Shoup) : CCA

RSA-OAEP : CCA
Signatures weve seen so far:
Textbook RSA : Not Secure

RSA-PSS : Secure
DSA (DSS) : Secure
Schnorr : Secure
Key Establishment Protocols weve seen so far:

Diffie-Hellman (textbook) : Not Secure, MITM

DH with Signatures : Secure + Server-contributed randomness + Forward Secrecy (pkB gets compro-
mised. Can you compute old values of k? If no, forward secure)
Recall STS which is server authentication, where Bob sends pkB (signature key) to Alice.
Encryption-based (key transport) : Secure
Recall Key transports follows where Bob sends pkB to Alice and Alice creates a k where she sends
EncpkB (k) to Bob who then creates k 0 .

51 of 59
 Applied Cryptography

19 Fully Encrypted Protocol

Primitives used: Signature Scheme (RSA, DSA(DSS), Hash (MD5, SHA1, SHA256), Diffie-Hellman and Signature
(DSA, RSA), Public Key Encryption (RSA-OAEP), Encryption: RC4, AES-CBC, AES-GCM, MAC: HMAC (MD5,
SHA)
You want to connect to Google securely:

Get Googles public key = pkG : Both a signing and encryption key
k = KeyEstablishment(pkG ), where k is a shared secret key (master secret)
kEnc , kM AC = P RG(k)
EnckE (m||M ACkm ||pad)

52 of 59
 Applied Cryptography

20 HTTP Over SSL/TLS

For cryptography, we have SSL2.0, 3.0 and TLS 1.0, 1.1, 1.2 (IETF). Most browsers and some servers use TLS
1.2.

20.1 Sketch of TLS

1. Alice gets servers public key pkS (PKI CAs)
2. Alice and server do a key exchange, K = KeyExchange(pkS ) (DHE or RSA)
3. {kenc , kmac } = P RG(Ext(k)) (fixed function based on hashing)
4. c = Encke (m||M ACkm (m)||pad) (HMAC: hashed-based such as MD5, SHA1, SHA256) and the Enc
can be 3DES (CBC, GCM), AES or RC4

20.2 Cipher Suites

Specify which algorithms to use
Browser will support many
Server will have prioritize list of ciphersuites
Negotiate to use the highest priority suite from the servers list that client supports

20.3 Syntax
xxx _W IT H_ yyy
T LS_ |{z}
|{z}
Step 1 Step 4
xxx:
DHE_DSS (DSS=DSA
=Schnorr)
DHE_RSA(signature used in DH)
RSA: RSA Encryption
ECDHE
yyy:
AES256_CBC_SHA256 (AES could be 3DES, 256 could be 128, CBC could be GCM, and SHA256 could
also be MD5, SHA1, or SHA374)
RC4128_SHA256

20.4 Certificates
How do we know what the servers key is? Browsers come with a list of certificates" (known as Root
Certificates) for companies called certificate authorities" (CAs). CAs are trusted by the browser to correctly
bind public keys to domain names.

53 of 59
20.4 Certificates Applied Cryptography

20.4.1 Certificate Chain

CA Root (CAO): SigskCAO (CA0 , pkCA0 ) (self-signed cert) and the pkCA0 verifies the CAO in the next
step.
CA Intermediate (CA1): SigCAO (CA1, pkCA1 , CA : true) and then the pkCA1 verifies the server.com.
Server (S): SigCA1 (server.com, pks )

20.4.2 Misc. Things

1. Expiry

2. Revocation Info; link to a server and two protocols: CRL, OCSP.

Note that collision resistance matters since if we have two messages that hash to the same thing then the
signature will be the same for the two messages.

54 of 59
 Applied Cryptography

21 HTTPS Protocol
1. Handshake - establish keys
2. Change CipherSpec - check of handshake

3. Application Data Transfer

21.1 Handshake
Alice (user) sends ClientHello to the Server containing m1 = {TLS1.2, supported ciphersuites,
nonce} where TLS1.2 is the highest version client supports, the supported ciphersuites would be
something such as TLS_DHE_DDS_WITH_AES_128_CBC_SHA256, and the nonce is a random value
The Server replies with ServerHello to the User containing m2 = { TLS1.0, ciphersuite, nonce
} where TLS1.0 is the highest version in common with the client, the ciphersuite is the highest
prioritized ciphersuite, and the nonce.
The Server sends a Certificate Chain m3
The Server sends k = KeyExchange(P Kserver ) where it can be done using DHE with Signature
or RSA transport, called m4

Alice can then do {kE , km } which is done with P RN G(Ext(k)).

21.2 Change CipherSpec

Alice then sends m5 which is ChangeCipherSpec, which turns on encryption

Alice sends m6 which is ClientF inish.EnckE (H(m1 m5 ), M ACkm (H(m1 m5 ))), the encryp-
tion forces Server to decrypt which checks that kE is correct. The M AC is not generally negotiated
(all MACs are still secure) and MACs were not subjected to export laws
Server sends ChangeCipherSpec where the server checks the MAC

Server sends serverF inish : EnckE ("Finished", M ACkm ("Finished"))

Alice verifies the integrity of handshake
Alice confirms the correctness of kE and km

21.3 Application Data

The HTTP Data is turned into Records
Each Record has the following layout: Application Data, TLS1.0, Data, MAC(data), Pad. The Application
Data consists of the handshake, ChangeCipherSpec, and Alert. The TLS1.0 consists of the version and
Pad only applies to block cipher. Note that the Data, MAC(data), and PAD are all Encrypted.

55 of 59
21.4 Attacks Applied Cryptography

21.4 Attacks
21.4.1 Padding Oracle (Lucky 13)
Applies to CBC mode
Exploits the fact that, implemented, CBC mode is not CCA-Secure (even with a MAC)
Problem is with the padding: not inside the MAC
Lesson: better in general to Encrypt-Then-MAC (c = Enc(m||p)||M AC(E))

Adversary sees a Record (Client -> Server) We have a message m that is encrypted and e which
is also encrypted. e consists of m, M AC(m), P AD. e can look like a bunch of stuff with 7C, 03, 03, 03
where the length of the padding is repeated. Say we flip the last byte (flip a bit) in m. This means the last
part of e is flipped, the 03 part. When we decrypt m, the whole block will be ruined.
In TLS, decryption failures are due to bad padding and bad MACS could be distinguished (fixed).
Figure out the padding: Let us look at a new message where the last bit is x and we with y. If we
look at the encrypted message e where the last bit is w, we can see the following:
If y = 0, then its the same

If y = 1, then w = 00000010: Yields a padding error

If y = 2, then w = 00000001: Yields a MAC error
We know w y = 01 and thus w = y 01. Now we know that w = 3.
Using the padding, we can read the next bit: We use the fact that w 07 = 04 since w = 03 if
we look at some bit v in the message m, we see the following:
If v = 0, we produce a MAC error.

If v = 1, we produce another MAC error.

If v = 0x78, we get a padding error since v 7C = 04 and 7C = 04 78.

21.4.2 BEAST
Exploits the fact that CBC mode was not CPA-Secure (as implemented) but this was fixed in TLS1.1
and 1.2 using techniques.

Predictable IVs (IV for Recordi = Last block of Recordi1 )

Adversary sees a Record (Client -> Server) Let c1 = Enc(m1 IV ) and ci = Enc(mi ci1 ), i >
1. The message that is being transmitted consists of an HTTP header and a cookie (first block) and a
GET/PUT block as the last block. Well assume we know or we can choose some of the information in the
HTTP header.
1. Position your cookie st. only the first byte is in c1 . Let c1 be the first block that consists of the HTTP
and now we have the first byte of the cookie in c1 . c1 = Enc(HTTP Header || ?? IV0 )

56 of 59
21.5 HTTPS - Real World Concerns Applied Cryptography

2. I can get the client to encrypt any block I want

3. Ask it to encrypt HTTP Header stuff I know plus i where i = 0, . . . , F F .
4. I know the next IV 0 . Thus I can IV 0 with what I have above as the first block.
5. Inject this to be encrypted: m0 IV 0 IV0 (HTTP with the cookie byte).

6. Browser will do Enck (m0 IV 0 ) = Enck ( HTTP with the cookie byte IV0 ) = G

21.5 HTTPS - Real World Concerns

21.5.1 Issues in HTTPS
Assume the crypto works as promised
Any CA (about 600 organizers that can masquerade as Google.com) can issue a cert for any site. We
can assume the whole model is as strong as the weakest link and that some CAs are hacked.
Bad Validation Procedures - SSLcertificates@domain.com and SSLcertificates@hotmail.com: Imper-
sonations
Bad Parsing Errors - CA and Browser differences (e.g. bank.com evil.com where bank.com is the
Browser and evil.com is the CA)
Mistakes: They dont check basic constraints (e.g. changing CA:false, such as a company called
TURKTRUST)

One approach to addressing number of CAs is called pinning

21.5.2 Usability
Less than 40% looked at the security cues for HTTPS (lock, https://)
Ignore warnings?

1. Expired cert: 36% understood it and of them 62% ignored it

2. Unknown CA: 28% understood, 33% ignored
SSL-Stripping: drop Connector to HTTP
Browser Chrome (UI) Spoofing

22 Bitcoin
One bitcoin (BTC) is worth 135$ USD. A year ago it was worth 5USD.
Bitcoin is a digital currency: Not a digitalization of another currency. They are P2P currencies with
no centralized authority

Questions:

57 of 59
22.1 Security Applied Cryptography

Where does it come from?

Who gets it?
How fast?

22.1 Security
How do you ensure no counterfeiting?
How do you transfer money? The person who owns it should only be able to transfer it
The ultimate answer is Cryptography

Accounts have a public kye (for signing, eg. ECDSA) and is owned by a person who knows a secret key.

1. Alice sends Bob 1BTC

2. Alice has pka and it has 1BTC associated with it
3. Public log of every transaction
4. The log is maintained by P2P network

5. Not anonymous but it is pseudonymous (no one knows necessarily the link between pka and Alice
and same person can have as many keys as they want)

22.2 Transaction
From: pka
To: pkb
Amount: 1BTC
Signska (m)
The above is broadcast to the P2P network. For validation, you check Sigska is associated with the sender
and then the amount is available.
This a linked list of blocks which consist of a hash tree of transactions. Each block consists of { hash(trans),
hash(previous block), creator, and tweak/nonce }

58 of 59
end page