CMSC 414
Computer and Network Security
Lecture 5
Jonathan Katz
Administrative announcements
 Midterm I
– March 6
 GRACE accounts set up
– Need to have a glue account
– HW submission done using GRACE submit script
 Finding a partner
– Email TA with “partner-414” in subject line
Message integrity
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?
– Lack of integrity can lead to lack of secrecy
– Almost always, integrity is needed in addition to
secrecy
Message authentication codes
(MACs)
 In the private-key setting, the correct tool for
achieving message integrity is a MAC
 Functionality:
– MACK(m) = t (“tag”)
– VrfyK(m, t) = 0/1 (“1” = “accept” / ”0”=“reject”)
– Correctness…
 Security?
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)
– Note that length of the tag 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
– These must be prevented at a higher level of the
protocol! (Note that whether a replay is ok is
application-dependent.)
– Can be prevented using nonces, timestamps, etc.
Hash functions
 A (cryptographic) hash function H maps arbitrary length
inputs to a fixed-length output
 Main goal is collision resistance:
– Hard to find distinct x, x’ such that H(x) = H(x’)
– Birthday attacks show that output length of H is critical
 Other goals
– Second pre-image resistance: given x, hard to find x’ ≠ x with
H(x) = H(x’)
• Weaker than collision resistance
– “Random-looking output”: I.e., “acts like a random oracle”
• Controversial
Hash functions in practice
 MD5
– 128-bit output
– No longer collision resistant (as of 2004)
• Still second pre-image resistant (for now…)
– Still widely deployed…
 SHA-1
– 160-bit output
– No collisions known (yet), but theoretical attacks exist
 SHA-2
– 256-/512-bit outputs
 Competition to design new hash standard has just begun…
Hash-and-MAC
 Say we have a secure MAC for “short” messages
– How to extend it for longer messages?
 Hash and MAC
– Hash message to short “digest”
– MAC the digest
 Not used in practice for MACs
K
– But used extensively for signatures (see later)
– Similar
practical MAC constructions
M ideas used inH(M)
t
H
MAC
MACs in practice
 CBC-MAC
– Can be constructed from any block cipher
– Directly handles long messages (without hashing)
– “Standard” variant is insecure if used on messages of
different lengths
• Known fixes for variable-length messages – make sure to use!
 HMAC
– Constructed from a hash function
– Directly handles long messages (hashing done as part
of construction)
Encryption + integrity
 In most settings, confidentiality and integrity are
both needed
– How to obtain both?
 Three “natural” possibilities:
– Encrypt-and-authenticate
– Authenticate-then-encrypt
– Encrypt-then-authenticate
 Only the latter is problem-free…
 Can also use dedicated mode of encryption
Toward public-key crypto…
Sharing keys?
 Secure sharing of a key is necessary for private-
key crypto
– How do parties share a key in the first place?
 One possibility is a secure physical channel
– E.g., in-person meeting
– Dedicated (un-tappable) phone line
– USB stick via courier service
 Another possibility: key exchange protocols
– Parties can agree on a key over a public channel
– This is amazing! (And marked a revolution in crypto…)
Diffie-Hellman key exchange
 Modular arithmetic, ZN, ZN*
 Diffie-Hellman protocol
 Security?
– Secure against passive eavesdropping only
 We will cover stronger notions of security for key
exchange in much more detail later in the semester
The Diffie-Hellman protocol
prime p, element g  Zp*
hA = gx mod p
hB = gy mod p
KAB = (hB)x
KBA = (hA)y
Security?
 Consider security against a passive eavesdropper
 Under the computational Diffie-Hellman (CDH)
assumption, hard for an eavesdropper to compute
KAB = KBA
– Not enough for security!
– Can hash the key before using
 Under the decisional Diffie-Hellman (DDH)
assumption, the key KAB looks random to an
eavesdropper
Technical notes
 p and g must be chosen so that the CDH/DDH
assumptions hold
– Need to be chosen with care
– Details in CMSC456
 Can also use other groups
– Elliptic curves are also popular
 Modular exponentiation can be done quickly (in
particular, in polynomial time)
– But the naïve algorithm does not work!
Security against active attacks?
 The basic Diffie-Hellman protocol we have shown
is not secure against a ‘man-in-the-middle’ attack
 In fact, impossible to achieve security against such
an attacker unless some information is shared in
advance
– E.g., private-key setting
– Or public-key setting (next)