CMSC 414
Computer and Network Security
Lecture 4
Jonathan Katz
Review
 If we want perfect secrecy, we face several
inherent limitations
– Key as long as the message
– Key used only once
– Not secure against chosen-plaintext attacks
 Computational secrecy offers the potential to
circumvent these limitations
 E.g., the pseudo-one-time pad
– Which drawbacks does this address?
Attack taxonomy
 So far, we have been considering only passive
eavesdropping of a single ciphertext
– aka, ciphertext-only attack
 In practice, stronger attacks need to be considered
– Known-plaintext attacks
– Chosen-plaintext attacks
• Implies security for multiple messages encrypted using the
same key
– Chosen-ciphertext attacks (by default, encompasses
chosen-plaintext attacks)
Definitions?
c = Enck(m)
k
k
In all cases, a bounded adversary should be unable
c’ better than ½)
to determine (with probability much
whether ma or mb was encrypted
Chosen-ciphertext
Chosen-plaintext
attack
attack
Ciphertext-only attack
I know the message m
is either ma or mb,
but which one?
Chosen-plaintext security
 Is the definition too strong?
c
Voters
Chosen-plaintext security
 Is security against chosen-plaintext attacks even
possible??
 Deterministic encryption schemes cannot be
secure against chosen-plaintext attacks
– Nor can they be secure for encrypting multiple
messages
 To be secure against chosen-plaintext attack,
encryption must be randomized
 Moral: always use randomized encryption!
Minimum requirements
 The minimum level of security nowadays is
security against chosen-plaintext attacks
 But security against chosen-ciphertext attacks (or
even stronger) is often necessary for certain
applications
– Make sure you are aware of this when deploying
encryption!
 We will revisit this issue after discussing message
authentication
Block ciphers
 Keyed, invertible permutation F
 Large key space, large block size
 Indistinguishable from a random permutation
 A block cipher is not an encryption scheme
– A block cipher can be used to build an encryption
scheme (and other things as well)
 Example – the “trivial” encryption scheme:
– C = FK(m)
– This is not randomized…
Data Encryption Standard (DES)
 Developed in 1970s by IBM / NSA / NBS
– Non-public design process
 56-bit key, 64-bit input/output
– A 64-bit key is derived from 56 random bits
– One bit in each octet is a parity-check bit
 The short key length is a major concern…
 The short block length is also a concern
Concerns about DES
 Short key length
– DES “cracker”, built for $250K, can break DES in days
– Computation can be distributed to make it faster
– Does not mean “DES is insecure”; depends on desired
security
 Short block length
– Repeated blocks happen “too frequently”
 Some (theoretical) attacks have been found
– Claimed known to DES designers 15 years before
public discovery!
 Non-public design process
3DES/triple-DES
 Expands the key length
 Now, key K = (K1, K2); |K| = 112
– Still has the short block length
 The “new” block cipher is just:
– EK1,K2(m) = DESK1(DES-1K2(DESK1(m)))
 This is a permutation, and invertible
 Fairly slow…but widely used in practice
AES
 Public contest sponsored by NIST in ’97
–
–
–
–
15 candidates submitted
Narrowed to 5 finalists in ’99
Winner selected in 2000
Entire contest open; intense cryptanalytic effort
 Rijndael selected as the AES
– Supports variety of block/key sizes, but defaults to 128-bit key
length and 128-bit block length
– 2128 is a huge number
• Number of seconds since big bang (estimate): ~258
• Number of nanoseconds since big bang: ~290
 Both efficiency and security taken into account
– The “most secure” finalist was not the one chosen
Other block ciphers?
 No compelling reason to use anything but AES
– Unless (possibly) you have very severe performance
requirements, or are paranoid about security
– Even then, think twice
 Same goes for stream ciphers (which are
essentially PRNGs)
Modes of encryption
 Used for encrypting a long message m1, …, mn
 ECB
– Ci = FK(mi); the ciphertext is (C1, …, Cn)
 CBC
– IV; Ci = FK(mi  Ci-1); the ciphertext is (IV, C1, …, Cn)
 OFB (stream cipher mode)
– IV; zi = FK(zi-1); Ci = zi  mi; the ciphertext is (IV, C1, …, Cn)
 CTR (stream cipher mode)
– IV; zi = FK(IV+i); Ci = zi  mi; the ciphertext is (IV, C1, .., Cn)
 Others…
Security?
 ECB should not be used
– Why?
The effect of ECB mode
original
encrypted using ECB mode
*Images
from Wikipedia
Security
 CBC, OFB, and CTR modes are secure against
chosen-plaintext attacks
 CBC, OFB, and CTR modes are not secure against
chosen-ciphertext attacks
*Images
from Wikipedia
Message integrity
Message integrity
m
m’
Encryption does not provide integrity
 “Since encryption garbles the message, decryption
of a ciphertext generated by an adversary must be
unpredictable”
– WRONG
 E.g., one-time pad, CBC-/CTR-mode encryption
 Why is this a concern?
– Almost always, integrity is needed in addition to
secrecy
– Lack of integrity can lead to lack of secrecy
 Use message authentication codes (MACs)
Message authentication code (MAC)
 In the private-key setting, the tool for achieving
message integrity is a MAC
 Functionality:
– MACK(m) = t (we call t the “tag”)
– VrfyK(m, t) = 0/1 (“1” = “accept” / ”0”=“reject”)
– Correctness…
MAC usage
Bob
Alice
m, t
k
t = Mack(m)
k
Vrfyk(m’,t’) ??
•Shared key k
•Sender computes a tag t on the message m
using k
•Receiver verifies the message/tag pair using k
MAC usage
Bob
K
Defining security
 Attack model:
– A random key k is chosen
– Attacker is allowed to obtain t1 = MACk(m1), …, tn =
MACk(mn) for any messages m1, …, mn of its choice
 “Break” of security
Attacker “breaks” the scheme if it outputs a forgery; i.e.,
(m, t) with:
• m ≠ mi for all i
• VrfyK(m, t) = 1
Defining security
 A MAC is secure if for all attackers running for
some time T (e.g., T=100 years), the probability
that the attacker “breaks” the scheme is at most 
(e.g.,  = 2-80)
– The key length lower-bounds  as always
– The tag length also lower-bounds 
 Is the definition too strong?
– When would an attacker be able to obtain tags on any
messages of its choice?!
– Why do we count it as a break if the adversary outputs
a forgery on a meaningless message?!
Replay attacks
 A MAC inherently cannot prevent replay attacks
 Replay attacks must be prevented at a higher level
of the protocol!
– (Note that whether a replay is ok is applicationdependent.)
 Replay attacks can be prevented using nonces,
timestamps, etc.
A MAC for short messages
 Let F be a block cipher with n-bit output
 To authenticate m using key k, compute
t = Fk(m)
 Vrfyk(m, t): output 1 iff t = Fk(m)
 Why is this secure?
(Informal) sketch of security
 Replace Fk with a random permutation f
– Can do this since F is a block cipher
 Seeing f(m1), …, f(mt) does not help (much) to
predict f(m) for any m{m1,…,mt}
– If adversary outputs (m, t), the probability that t is
correct is roughly 2-n
– For n large enough, the probability of forgery is small