Lecture 5

Looking back…
• Proof that the pseudo-OTP is secure…
• …with some caveats
– Assumes G is a pseudorandom generator
– Security is relative to our definition

• The only ways the scheme can be broken are:

– If a weakness is found in G
– If the definition isn’t sufficiently strong…
 Recall…
• Perfect secrecy has two limitations/drawbacks
– Key as long as the message
– Key can only be used once

• We have seen how to circumvent the first

• Does the pseudo-OTP have the second
limitation?

• How can we circumvent the second?

 But first…
• Develop an appropriate security definition

• Recall that security definitions have two parts

– Security goal
– Threat model

• We will keep the security goal the same, but

strengthen the threat model
 Single-message secrecy

c
k k

m
c ¬ Enck(m)
 Multiple-message secrecy

c1, …, ct
k k

m1, …, mt
c1 ¬ Enck(m1)
…
ct ¬ Enck(mt)
 A formal definition
• Fix P, A
• Define a randomized exp’t PrivKmultA,P(n):
1. A(1n) outputs two vectors (m0,1, …, m0,t) and
(m1,1, …, m1,t)
• Require that |m0,i| = |m1,i| for all i
2. k ¬ Gen(1n), b ¬ {0,1}, for all i: ci ¬ Enck(mb,i)
3. b’ ¬ A(c1, …, ct); A succeeds if b = b’, and
experiment evaluates to 1 in this case
 A formal definition
• P is multiple-message indistinguishable if for
all PPT attackers A, there is a negligible
function e such that

Pr[PrivKmultA,P(n) = 1] ≤ ½ + e(n)

• Question: Is pseudo-OTP multiple-message

indistinguishable?
 Multiple-message secrecy
• No encryption scheme is multiple-message
indistinguishable!
– Proof?

• What assumption did we make?

• No deterministic (and stateless) encryption

scheme is multiple-message indistinguishable
– Need to consider randomized schemes!
 Randomized encryption
• The issue is not an artefact of our definition
– It really is a problem if an attacker can tell when
the same message is encrypted twice
 Multiple-message secrecy
• We are not going to work with multiple-
message indistinguishability

• Instead, define something stronger: security

against chosen-plaintext attacks (CPA-security)
– Nowadays, this is the minimal notion of security
an encryption scheme should satisfy
 CPA-security

c 21
k k

m
cc12 ¬ Enck(m
(m)12) m21
 Is the threat model too strong?
• In practice, there are many ways an attacker
can influence what gets encrypted
– Not clear how best to model this
– Chosen-plaintext attacks encompass any such
influence

• In some cases an attacker may have complete

control over what gets encrypted
 “Midway”

AFWill
is out
attack
of water…
AF …

Help! Fresh water needed

Midway Island

For more details, see: http://www.navy.mil/midway/how.html

 CPA-security
• Fix P, A
• Define a randomized exp’t PrivKCPAA,P(n):
1. k ¬ Gen(1n)
2. A(1n) interacts with an encryption oracle Enck(·),
and then outputs m0, m1 of the same length
3. b ¬ {0,1}, c ¬ Enck(mb), give c to A
4. A can continue to interact with Enck(·)
5. A outputs b’; A succeeds if b = b’, and
experiment evaluates to 1 in this case
 CPA-security
• P is secure against chosen-plaintext attacks
(CPA-secure) if for all PPT attackers A, there is
a negligible function e such that

Pr[PrivKCPAA,P(n) = 1] ≤ ½ + e(n)
 Relation with previous def’n?
• CPA-security is stronger than multiple-
message indistingiushability

• I.e., if P is CPA-secure then it is also multiple-

message indistinguishable
– Corollary: no deterministic encryption scheme can
be CPA-secure
Pseudorandom functions
 Random function
• When we talk about a random function f, we
mean
1. Choosing f uniformly (and then fixing it)
2. Interacting with f

• In particular, once we choose f there is no

more randomness involved
– I.e., if we query f on the same input twice, we get
the same result
 Choosing a uniform function
• Funcn = all functions mapping {0,1}n to {0,1}n

• How big is Funcn ?

– Can represent 000
a function
010
in Func n using n · 2 n bits

Þ|Funcn| = 2n·2n001 100

010 100
011 111
# of entries: 23 = 8
100 001
101 010
110 010
111 000
 Choosing a uniform function
• Choose uniform f Î Funcn

• Equivalent: for each x Î {0,1}n, choose f(x)

uniformly and independently in {0,1}n
– I.e., fill up the function table with uniform values
– Can also view this as being done “on-the-fly,” as
values are needed
 Pseudorandom functions
• Informally, a pseudorandom function “looks
like” a random (i.e., uniform) function
 Pseudorandom functions
• Informally, a pseudorandom function “looks
like” a random function

• As in our discussion of PRGs, it does not make

sense to talk about any fixed function being
pseudorandom
– We look instead at functions chosen according to
some distribution
– In particular, we look at keyed functions
 Keyed functions
• Let F: {0,1}* x {0,1}* ® {0,1}* be an efficient,
deterministic algorithm
– Define Fk(x) = F(k, x)
– The first input is called the key

• Assume F is length preserving: F(k, x) only defined

if |k|=|x|, in which case |F(k, x)| = |k| = |x|

• Choosing a uniform k Î {0,1}n is equivalent to

choosing the function Fk : {0,1}n ® {0,1}n
– The algorithm F defines a distribution over functions
in Funcn!
 Note
• The number of functions in Funcn is 2n·2n
• {Fk}kÎ{0,1}n is a subset of Funcn
– The number of functions in {Fk}kÎ{0,1}n is at most 2n
– This is only a tiny fraction of Funcn!
 Pseudorandom functions (PRFs)
• F is a pseudorandom function if Fk, for uniform
key k Î {0,1}n, is indistinguishable from a
uniform function f Î Funcn

• Formally, for all poly-time distinguishers D:

| Prk¬{0,1}n[DFk(·) = 1] - Prf¬Funcn[Df(·) = 1] | ≤ ε(n)
 x1
f Î Funcn chosen f(x1)
f

…
uniformly at random
xt
World 0 f(xt) ??

World 1 x1 (poly-time)
Fk(x1)
k Î {0,1}n chosen Fk

…
uniformly at random xt
Fk(xt)
 Examples (insecure)
• F(k, x) = 0n
• F(k, x) = k
• F(k, x) = k Å x
 Pseudorandom permutations (PRPs)
• Let f Î Funcn
• f is a permutation if it is a bijection
– This means that the inverse f-1 exists
• Let Permn Ì Funcn be the set of permutations
• What is |Permn|?
 Pseudorandom permutations
• Let F be a length-preserving, keyed function
• F is a keyed permutation if
– Fk is a permutation for every k
– Fk-1, the inverse of Fk, is efficiently computable

• F is a (strong) pseudorandom permutation if Fk ,

for uniform key k Î {0,1}n, is indistinguishable
from a uniform permutation f Î Permn
– Even if attacker can query both forward and inverse
directions
 Note
• For large enough n, a random permutation is
indistinguishable from a random function

• So in practice, PRPs are also good PRFs

 Block ciphers
• Block ciphers are practical constructions of
pseudorandom permutations

• No asymptotics: F: {0,1}n x {0,1}m ® {0,1}m for

fixed n, m
– n = “key length”
– m = “block length”

• Hard to distinguish Fk from uniform f Î Permm

even for attackers running in time »2n
 AES
• Advanced encryption standard (AES)
– Key length = 128, 192, or 256 bits
– Block length = 128 bits

• Available in standard crypto libraries

• No real reason to use anything else
 CPA-security
• Fix P, A
• Define a randomized exp’t PrivKCPAA,P(n):
1. k ¬ Gen(1n)
2. A(1n) interacts with an encryption oracle Enck(·),
and then outputs m0, m1 of the same length
3. b ¬ {0,1}, c ¬ Enck(mb), give c to A
4. A can continue to interact with Enck(·)
5. A outputs b’; A succeeds if b = b’, and
experiment evaluates to 1 in this case
 CPA-security
• P is secure against chosen-plaintext attacks
(CPA-secure) if for all PPT attackers A, there is
a negligible function e such that

Pr[PrivKCPAA,P(n) = 1] ≤ ½ + e(n)
 CPA-secure encryption
• Recall the EAV-secure scheme based on a
pseudorandom generator
– Core idea: use a pseudorandom pad in place of a
random pad

• What if the sender could generate a fresh,

pseudorandom pad every time they encrypt?
– While still giving the receiver the ability to decrypt
 CPA-secure encryption
• Let F be a length-preserving, keyed function

• Gen(1n): choose a uniform key k Î {0, 1}n

• Enck(m), where|m| = |k| = n:
– Choose uniform r Î {0, 1}n (nonce/initialization
vector)
– Output ciphertext < r, Fk(r) Å m >
• Deck(c1, c2): output c2 Å Fk(c1)

• Correctness is immediate
 r

key F pseudorandom

ciphertext
message
 Security?
• Theorem: if F is a pseudorandom function,
then this scheme is CPA-secure
 Security?
• Theorem: if F is a pseudorandom function,
then this scheme is CPA-secure

• Proof by reduction…
 Proof of security (high level)
• Replace Fk with a random function f
• Whenever f is evaluated on a new input, the
result is uniform and independent of
everything else
• Bound the adversary’s success probability
assuming f is never evaluated on the same
input twice
• Argue that f is never evaluated on the same
input except with negligible probability
 m0, m1

b ← {0,1}
r* ← {0,1}n
r* , Fk(r*) Å m
 Analysis
• Since F is a pseudorandom function, we can
replace Fk with a truly random function f
 Analysis
• What is the success probability of A when the
experiment uses a random function f?
• There are two sub-cases
– r* was used for answering some encryption-oracle
query (call this event Repeat)
– r* was not used for any encryption-oracle query
• Let q(n) be a bound on the number of
encryption queries made by A
 Analysis
• Pr[success] ≤ Pr[success|¬Repeat] + Pr[Repeat]
• Pr[Repeat] ≤ q(n)/2n
– Why?
• Pr[ success | ¬Repeat] = ½
– Analogous to the one-time pad in this case, since
f(r*) is uniform and independent of everything else

• Pr[A succeeds] ≤ ½ + q(n)/2n

• I.e., the scheme is secure!
 Real-world security?
• The security bound we proved is tight

• What happens if a nonce r is ever reused?

• What happens to the bound if the nonce is

chosen non-uniformly?
 Attacks?
• If r repeats, security fails
– Exactly analogous to multiple encryptions using
the (pseudo)one-time pad scheme
• When r is a uniform, n-bit string, the
probability of a repeat is negligible
• If r is too short, or is chosen from another
distribution, repeats may happen!
– May make scheme insecure
 Breaking encryption schemes
• Let F be a block cipher
• Two general CPA-attacks on a scheme
– F not used correctly
• (Function of) plaintext directly leaked in ciphertext
E.g., < m, Fk(m) >
• F not used with a random, unknown key
E.g., Enck(m) = < r, Fr(m) >
– Cause F to be evaluated on the same input twice
• E.g., Enck(m1, m2) = < r, Fk(r) Å m1, Fk(m1) Å m2 >
• Any deterministic scheme
 CPA-secure encryption
• We have shown a CPA-secure encryption
scheme based on any block cipher/PRF
– Enck(m) = <r, Fk(r) Å m>

• Drawbacks?
– Only defined for encryption of n-bit messages
– A 1-block plaintext results in a 2-block ciphertext
 Encrypting long messages?
• Recall that CPA-security Þ security for the
encryption of multiple messages

• So, can encrypt the message m1, …, mt as

Enck(m1), Enck(m2), …, Enck(mt)
– This is also CPA-secure!
 Drawback
• The ciphertext in that case is twice the length
of the plaintext
– I.e., ciphertext expansion by a factor of two

• Can we do better?

• Modes of operation
– Stream-cipher modes of operation
– Block-cipher modes of operation
Stream ciphers
 Stream ciphers
• As we defined them, PRGs are limited
– They have fixed-length output
– They produce output in “one shot”

• In practice, stream ciphers are used

– Can be viewed as producing an “infinite” stream
of pseudorandom bits, on demand
– More flexible, more efficient
 Stream ciphers
• Pair of efficient, deterministic algorithms
(Init, Next)
– Init takes a seed s (and optional IV), and outputs
initial state st
– Next takes the current state st and outputs a
bit y along with updated state st’
• (In practice, y would be a block rather than a bit)
 Stream ciphers
• Can use (Init, Next) to generate any desired
number of output bits from an initial seed/IV

s IV

Init

st0 Next st1 Next st2

y1 y2
 Stream ciphers
• A stream cipher is secure if the output stream
(from a uniform seed) is pseudorandom
– I.e., regardless of how long the output stream is
(as long as it is polynomial)

• Easy to construct from a block cipher

 Modes of operation
• Stream-cipher modes of operation
– Synchronized
– Unsynchronized
 Synchronized mode
• Sender and receiver maintain state (i.e., they
are stateful), and must be synchronized

• Makes sense in the context of a limited-time

communication session where both parties are
online and messages are received in order,
without being dropped
 Synchronized mode
s s

Init Init

st0 m1 st0
y1 c1 y1
Next Å Å Next
m1
st1 m2 st1
y2 c2 y2
Next Å Å Next
m2
st2 st2
 Synchronized mode
• Advantages
– Stream cipher does not need to support an IV
– No ciphertext expansion

• Disadvantages
– Stateful
– Assumes messages arrive in order; never dropped
 Unsynchronized mode
• Choose random IV to encrypt next message

• Similar to the first CPA-secure scheme we saw

– But “natively” handles arbitrary-length messages
with better ciphertext expansion
 Unsynchronized mode

s IV IV IV s

Init Init

st0 m1, m2, … st0

y 1 , y2 , … c1, c2, … y 1 , y2 , …
Next Å Å Next
m1, m2, …
Block-cipher modes
of operation
 ECB mode
• Enck(m1, …, mt) = Fk(m1), …, Fk(mt)

• Deterministic
– Not CPA-secure!

• Can tell from the ciphertext whether mi = mj

– Not even EAV-secure!
Not just a theoretical problem!

original encrypted using ECB mode

(Taken from http://en.wikipedia.org and derived from images created by

Larry Ewing ([email protected]) using The GIMP.)
 CTR mode
• Enck(m1, …, mt) // note: t is arbitrary
– Choose ctr ¬ {0,1}3n/4, set c0 = ctr
– For i=1 to t:
• ci = mi Å Fk(ctr | i)
– Output c0, c1, …, ct

• Decryption?
– Note that F need not be invertible

• Ciphertext expansion is <1 block

 CTR mode

ctr ctr|1 ctr|2 ctr|t

Fk Fk … Fk

m1 Å m2 Å mt Å

c0 c1 c2 ct
 CTR mode
• Theorem: If F is a pseudorandom function,
then CTR mode is CPA-secure

• Proof sketch:
The sequence Fk(ctr | 1), …, Fk(ctr | t) used for
the challenge ciphertext is pseudorandom
– Moreover, it is independent of every other such
sequence unless ctr | j = ctri’ | j’ for some i’, j’
• Just need to bound the probability of that event
 CBC mode
• Enck(m1, …, mt) // note: t is arbitrary
– Choose random c0 ¬ {0,1}n (also called the IV)
– For i=1 to t:
• ci = Fk(mi Å ci-1)
– Output c0, c1, …, ct

• Decryption?
– Requires F to be invertible, i.e., a permutation

• Ciphertext expansion is just 1 block

 CBC-mode encryption
m1 m2 mt
IV Å Å Å

Fk Fk … Fk

c0 c1 c2 ct

70
 CBC mode
• Theorem: If F is a pseudorandom
permutation, then CBC mode is CPA-secure

• Proof is more complicated than for CTR mode