AUP - CS 335

Computer and Network Security

American University in Paris

Prof. Antonio Kung
Spring 2009

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 1
 AUP - CS 335

Chapter 11 – Message
Authentication and Hash
Functions

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 2
 AUP - CS 335
Message Authentication
• message authentication is concerned with:
– protecting the integrity of a message
– validating identity of originator
– non-repudiation of origin (dispute resolution)
• will consider the security requirements
• then three alternative functions used:
– message encryption
– message authentication code (MAC)
– hash function
 AUP - CS 335
Security Requirements
• disclosure
• traffic analysis
• masquerade
• content modification
• sequence modification
• timing modification
• source repudiation
• destination repudiation
 AUP - CS 335
Message Encryption
• message encryption by itself also provides a measure
of authentication
• if symmetric encryption is used then:
– receiver know sender must have created it
– since only sender and receiver know key used
– know content cannot have been altered
– if message has suitable structure, redundancy or a checksum
to detect any changes
 AUP - CS 335
Message Encryption with public key
• Case 1 : authentication only
– sender A signs message using its private-key
C= EKRA[M]
– Only A is able to create this message.
– Everyone is able to read it using A public key
M = EKUA[C]
– encryption provides no confidentiality since anyone potentially knows public-
key

• Case 2 : authentication + confidentiality

– sender A signs message using its private-key then encrypts with recipient B
public key
C=EKUB[EKRA[M] ]
– Only B is able to read it using its private key and A public key
M=EKUA[EKRB[C] ]
– We now have both confidentiality and authentication
 AUP - CS 335
Message Authentication Code (MAC)
• generated by an algorithm that creates a small fixed-
sized block
– depending on both message and some key
C(K,M)

– like encryption though need not be reversible

• Mechanism
– MAC is appended to message as a signature by sender A
– receiver B performs same computation on message and
checks it matches the MAC
– provides assurance that message is unaltered and comes
from sender A (assuming that only A and B share the key K)
 AUP - CS 335
Message Authentication Code
 AUP - CS 335
Message Authentication Codes
• as shown the MAC provides authentication
• if confidentiality is needed then
– Add encryption of M
• generally use separate keys for each Ka (authentication), Kc
(confidentiality)
• Two cases
– compute MAC before encryption
Y=EKc(C(Ka,M)+M)

– Compute MAC after encryption

Y= C(Ka,Ekc(M))+Ekc(M)
• is generally regarded as better done before
• why use a MAC?
– sometimes only authentication is needed
– sometimes need authentication to persist longer than the
encryption (eg. archival use)
• note that a MAC is not a digital signature
 AUP - CS 335
MAC Properties
• a MAC is a cryptographic checksum
MAC = CK(M)
– condenses a variable-length message M
– using a secret key K
– to a fixed-sized authenticator
• is a many-to-one function
– potentially many messages have same MAC
– but finding these needs to be very difficult
 AUP - CS 335
Requirements for MACs
• taking into account the types of attacks
• need the MAC to satisfy the following:
1. knowing a message and MAC, is infeasible to find
another message with same MAC
2. MACs should be uniformly distributed
3. MAC should depend equally on all bits of the
message
 AUP - CS 335
Using Symmetric Ciphers for MACs
• can use any block cipher chaining mode and
use final block as a MAC
• Data Authentication Algorithm (DAA) is a
widely used MAC based on DES-CBC
– using IV=0 and zero-pad of final block
– encrypt message using DES in CBC mode
– and send just the final block as the MAC
• or the leftmost M bits (16≤M≤64) of final block
• but final MAC is now too small for security
 AUP - CS 335
Data Authentication Algorithm
 AUP - CS 335
Hash Functions
• condenses arbitrary message to fixed size
• usually assume that the hash function is
public and not keyed
– cf. MAC which is keyed
• hash used to detect changes to message
• can be used in various ways with message
• most often to create a digital signature
 AUP - CS 335
Hash Functions & Digital Signatures
 AUP - CS 335
Hash Function Properties
• a Hash Function produces a fingerprint of
some file/message/data
h = H(M)
– condenses a variable-length message M
– to a fixed-sized fingerprint
• assumed to be public
 AUP - CS 335
Requirements for Hash Functions
• can be applied to any sized message M
• produces fixed-length output h
• is easy to compute h=H(M) for any message M
• given h is infeasible to find x s.t. H(x)=h
– one-way property
• given x is infeasible to find y s.t. H(y)=H(x)
– weak collision resistance
• is infeasible to find any x,y s.t. H(y)=H(x)
– strong collision resistance
 AUP - CS 335
Simple Hash Functions
• are several proposals for simple functions
• based on XOR of message blocks
• not secure since can manipulate any message and
either not change hash or change hash also
• need a stronger cryptographic function (next chapter)
 AUP - CS 335
General Structure of Secure Hash Code
• IV = Initial Value
• CV = Chaining Variable (h bits)
• Mi = ith input block (n bits)

M0 M1 Mi-1
f f f
IV= CV0 CV1 CVi-1 H = CVi

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 19
 AUP - CS 335
Block Ciphers as Hash Functions
• can use block ciphers as hash functions
– using H0=0 and zero-pad of final block
– compute: Hi = EMi [Hi-1]
– and use final block as the hash value
– similar to CBC but without keys
• resulting hash is too small (64-bit)
– both due to direct birthday attack
– and to “meet-in-the-middle” attack
• other variants also susceptible to attack
 AUP - CS 335
How Hash Codes are Attacked
• Birthday Attacks
• might think a (m=64) 64-bit hash is secure
• but by Birthday Paradox is not
– birthday attack works as follows:
• opponent generates 2m/2 variations of a valid message all with
essentially the same meaning
• opponent also generates 2m/2 variations of a desired fraudulent
message
• two sets of messages are compared to find pair with same hash
(probability > 0.5 by birthday paradox)
• have user sign the valid message, then substitute the forgery
which will have a valid signature
• conclusion is that need to use larger hash fields

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 21
 AUP - CS 335
Hash Functions & MAC Security
• like block ciphers have:
• brute-force attacks exploiting
m/
– strong collision resistance hash have cost 2 2

• have proposal for h/w MD5 cracker

• 128-bit hash looks vulnerable, 160-bits better
– MACs with known message-MAC pairs
• can either attack keyspace (cf key search) or MAC
• at least 128-bit MAC is needed for security
 AUP - CS 335
Hash Functions & MAC Security
• cryptanalytic attacks exploit structure
– like block ciphers want brute-force attacks to be the best
alternative
• have a number of analytic attacks on iterated hash
functions
– CVi = f[CVi-1, Mi]; H(M)=CVN
– typically focus on collisions in function f (a compression
function)
– like block ciphers is often composed of rounds
– attacks exploit properties of round functions

M0 M1 Mi-1
f f f
IV= CV0 CV1 CVi-1 CVi
 AUP - CS 335
Summary
• have considered:
– message authentication using message encryption
– MACs
– hash functions
– general approach & security
 AUP - CS 335

Chapter 12 – Hash Algorithms

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 25
 AUP - CS 335
MD5
• designed by Ronald Rivest (the R in RSA)
• latest in a series of MD2, MD4
• produces a 128-bit hash value
• until recently was the most widely used hash algorithm
– in recent times have both brute-force & cryptanalytic concerns
• specified as Internet standard RFC1321

• Should no longer be used

 AUP - CS 335
MD5 Overview
1. pad message so its length is 448 mod 512
2. append a 64-bit length value to message
3. initialise 4-word (128-bit) MD buffer (A,B,C,D)
4. process message in 16-word (512-bit) blocks (X[k]):
– using 4 rounds of 16 bit operations on message block &
buffer
– add output to buffer input to form new buffer value
5. output hash value is the final buffer value
 AUP - CS 335
MD5 Overview
 AUP - CS 335
MD5 Compression Function
• each round has 16 steps of the form:
– a = b+((a+g(b,c,d)+X[k]+T[i])<<<s)

• X[k] is the kth 32-bit word in the current message block.

• a,b,c,d : 4 words of the buffer, used in varying permutations
– note this updates 1 word only of the buffer
– after 16 steps each word is updated 4 times
• g(b,c,d) is a different nonlinear function in each round (F,G,H,I)
• T[i] ith entry in a matrix of constants T

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 29
 AUP - CS 335
MD5 Compression Function
 AUP - CS 335
Other Details
• In each round, we have 16 steps
– In step 1 : g(b,c,d) = (b AND c) OR (NOT b AND d)
– In step 2 : g(b,c,d) = (b AND d) OR (c AND NOT d)
– In step 3 : g(b,c,d) = b + c + d
– In step 4 : g(b,c,d) = c + (b OR NOT d)
• X[k] is the input from the message (16 elements of 32 bits = 512 bits)
• CVi (128 bits) is structured into 4 words A, B, C, D
• T[i] = integer part (232 abs(sin(i)). i is ranging from 1 to 64
 AUP - CS 335
Strength of MD5
• MD5 hash is dependent on all message bits
• Rivest claims security is good as can be
• known attacks are:
– Berson 92 attacked any 1 round using differential
cryptanalysis (but can’t extend)
– Boer & Bosselaers 93 found a pseudo collision
(again unable to extend)
– Dobbertin 96 created collisions on MD compression
function (but initial constants prevent exploit)
• conclusion is that MD5 is no longer usable
 AUP - CS 335
Secure Hash Algorithm (SHA-1)
• SHA was designed by NIST & NSA in 1993
– revised in 1995 as SHA-1
– US standard for use with DSA signature scheme
• standard is FIPS 180-1 1995, also Internet RFC3174
• nb. the algorithm is SHA, the standard is SHS

• produces 160-bit hash values

• now the generally preferred hash algorithm
• based on design of MD4 with key differences

• SHA-1 is also considered obsolete (2005)

 AUP - CS 335
SHA-1 vs MD5

A,B,C,D,E A,B,C,D,E A,B,C,D,E A,B,C,D,E

160 bits 160 bits 160 bits 160 bits

SHA-1 SHA-1 SHA-1 SHA-1

160 bits
digest

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 34
 AUP - CS 335
SHA Overview
1. pad message so its length is 448 mod 512
2. append a 64-bit length value to message
3. initialise 5-word (160-bit) buffer (A,B,C,D,E) to
(67452301,efcdab89,98badcfe,10325476,c3d2e1f0)
4. process message in 16-word (512-bit) chunks:
– expand 16 words (Yq) into 80 words (Wt) by mixing &
shifting
– use 4 rounds of 20 bit operations on message block &
buffer
– add output to input to form new buffer value
5. output hash value is the final buffer value
 AUP - CS 335
SHA-1 Compression Function
• each round has 20 steps which replaces the 5 buffer words thus:
(A,B,C,D,E) <-
(E+f(t,B,C,D)+(A<<5)+Wt+Kt),A,(B<<30),C,D)
• A, B, C, D, E refer to the 5 words of the buffer
• t is the step number
• f(t,B,C,D) is a nonlinear function for each round
• Wt is derived from the message block
• Kt is a constant value derived from square root calculation

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 36
 AUP - CS 335
SHA-1 Compression Function
 AUP - CS 335
Details
• In each round, we have 80 steps
– 0 to 19 : f(t,b,c,d) = (b and c) or (not b and d)
– 20 to 39 : f(t,b,c,d) = b + c + d
– 40 to 59 : f(t,b,c,d) = (b and d) or (b and d) or (c and d)
– 60 to 79 : f(t,b,c,d) = b + c + d
• Wt is a sequence of 80 words derived from Yq, the input
sequence of 16 words
– Wt = Yt from 0 to 15
– Wt=S1(Wi-16 xor Wi-14 xor Wi-8 xor Wi-3) when t >15
• CVi (160 bits) is structured into 4 words A, B, C, D, E
• Kt =
– 0 to 19 : integer part (230+square root (2))
– 20 to 39 : integer part (230+square root (3))
– 40 to 59 : integer part (230+square root (5))
– 60 to 79 : integer part (230+square root (10))
American University in Paris Spring 2009 Note that slides are from Larry Brown slide 38
 AUP - CS 335
SHA-1 versus MD5
• brute force attack is harder (160 vs 128 bits for MD5)
• vulnerable to known attacks
• a little slower than MD5 (80 vs 64 steps)
• both designed as simple and compact
• optimised for big endian CPU's (vs MD5 which is optimised for
little endian CPU’s)
 AUP - CS 335
Revised Secure Hash Standard
• NIST have issued a revision FIPS 180-2
• adds 3 additional hash algorithms
• SHA-256, SHA-384, SHA-512
• designed for compatibility with increased security provided by
the AES cipher
• structure & detail is similar to SHA-1
• hence analysis should be similar
 AUP - CS 335
Keyed Hash Functions as MACs
• have desire to create a MAC using a hash function rather than a block
cipher
– because hash functions are generally faster
– not limited by export controls unlike block ciphers
• hash includes a key along with the message
• original proposal:
– KeyedHash = Hash(Key|Message)
– some weaknesses were found with this
• eventually led to development of HMAC
 AUP - CS 335
HMAC
• specified as Internet standard RFC2104
• uses hash function on the message:
HMACK = Hash[(K+ XOR opad) ||
Hash[(K+ XOR ipad)||M)]]
• K+ : key padded out to size
• opad, ipad : padding constants
• overhead is just 3 more hash calculations
than the message needs alone
• any hash function can be used MD5, SHA-1,...
 AUP - CS 335
HMAC Overview
 AUP - CS 335
HMAC Security
• know that the security of HMAC relates to that of the underlying
hash algorithm
• attacking HMAC requires either:
– brute force attack on key used
– birthday attack (but since keyed would need to observe a very large
number of messages)
• choose hash function used based on speed versus security
constraints
 AUP - CS 335
Summary
• have considered:
– some current hash algorithms: MD5, SHA-1
– HMAC authentication using hash function

• SHA-256, SHA-368, SHA-512 should now be used

 AUP - CS 335
Recap on Authentication
• message authentication using message encryption
– Message = Ek(M)
– Receiver assumes that sender is the only person knowing the key
– Sender needs to encrypt the whole message, The receiver has to decrypt it
– Receiver has to trust the sender
• MACs
– Message = M || Ck(M)
– Receiver also assumes that sender is the only person knowing the key
– There is no decryption. Receiver recalculates Ck(M)
– Sender needs to code the whole message, The receiver has to recalculate the code (since M is visible)
– Receiver has to trust the sender
• hash functions
– Message = M || H(M)
– There is no key
– Subject to birthday attack
• Digital signature
– Message = M || Ek(H(M))
– The hash value is encrypted (e.g. Using a private key)
– The receiver knows the sender public key and can verify
– Receiver has to trust the sender
 AUP - CS 335

Chapter 13 –Digital Signatures &

Authentication Protocols

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 47
 AUP - CS 335
Digital Signatures
• have looked at message authentication
– but does not address issues of lack of trust
• digital signatures provide the ability to:
– verify author, date & time of signature
– authenticate message contents
– be verified by third parties to resolve disputes
• hence include authentication function with additional
capabilities
 AUP - CS 335
Digital Signature Properties
• must depend on the message signed
• must use information unique to sender
– to prevent both forgery and denial
• must be relatively easy to produce
• must be relatively easy to recognize & verify
• be computationally infeasible to forge
– with new message for existing digital signature
– with fraudulent digital signature for given message
• be practical save digital signature in storage
 AUP - CS 335
Direct Digital Signatures
• involve only sender & receiver
• assumed receiver has sender’s public-key
• digital signature made by sender signing entire message or
hash with private-key
• can encrypt using receivers public-key
• important that sign first then encrypt message & signature
• security depends on sender’s private-key
 AUP - CS 335
Arbitrated Digital Signatures
• involves use of arbiter A
– validates any signed message
– then dated and sent to recipient
• requires suitable level of trust in arbiter
• can be implemented with either symmetric or assymetric
algorithms
• arbiter may or may not see message
 AUP - CS 335
Arbitrated Digital Signature Techniques
• X sends a digitally signed message to Y using A as an Arbiter
• Case 1 :
– Symmetric Encryption
– A sees message
– T is a timestamp
• Protection against replay attacks
– IDx identifies X
X → A: M || S where S = EKXA [IDx || H(M)]
A → Y: EKAY[IDX || M || S || T]

• Case 1 : Y cannot directly check signature

 AUP - CS 335
Arbitrated Digital Signature Techniques
• X sends a digitally signed message to Y using A as an Arbiter
• Case 2
– Use symmetric encryption
– Plus : A does not see message content
X → A: IDX || EKXY [M] || S
where S = EKXA [IDx || H(EKXY [M])]
A → Y: EKAY[IDX || EKXY [M] || S || T]

• Case 2 : Y cannot directly check signature

 AUP - CS 335
Arbitrated Digital Signature Techniques
• X sends a digitally signed message to Y using A as an Arbiter
• Case 3
– Public Key Encryption : A does not see message
X → A: IDX || EKRX [IDX || C] where C = EKUY [EKRX[M]]
A → Y: EKRA[IDX || C || T]

• Case 3 : Y can directly decode C

 AUP - CS 335
Authentication Protocols
• used to convince parties of each others identity and to
exchange session keys
• may be one-way or mutual
• key issues are
– confidentiality – to protect session keys
– timeliness – to prevent replay attacks
 AUP - CS 335
Replay Attacks
• where a valid signed message is copied and later
resent
– simple replay
– repetition that can be logged
– repetition that cannot be detected
– backward replay without modification
• countermeasures include
– use of sequence numbers (generally impractical)
– timestamps (needs synchronized clocks)
– challenge/response (using unique nonce)
 AUP - CS 335
Using Symmetric Encryption
• as discussed previously can use a two-level hierarchy of keys
• usually with a trusted Key Distribution Center (KDC)
– each party shares own master key with KDC
– KDC generates session keys used for connections between parties
– master keys used to distribute these to them
 AUP - CS 335
Needham-Schroeder Protocol
• original third-party key distribution protocol
• for session between A B mediated by KDC
• protocol overview is:
1. A → KDC: IDA || IDB || N1
2. KDC → A: EKa[Ks || IDB || N1 || EKb[Ks || IDA] ]
3. A → B: EKb[Ks || IDA]
4. B → A: EKs[N2]
5. A → B: EKs[f(N2)]
 AUP - CS 335
Needham-Schroeder Protocol

American University in Paris Spring 2009 Note that slides are from Larry Brown slide 59
 AUP - CS 335
Needham-Schroeder Protocol
• used to securely distribute a new session key for
communications between A & B
• but is vulnerable to a replay attack if an old session key has
been compromised
– then message 3 can be resent convincing B that is communicating
with A
• modifications to address this require:
– timestamps (Denning 81)
– using an extra nonce (Neuman 93)
 AUP - CS 335
Using Public-Key Encryption
• have a range of approaches based on the use of public-key
encryption
• need to ensure have correct public keys for other parties
• using a central Authentication Server (AS)
• various protocols exist using timestamps or nonces
 AUP - CS 335
Denning AS Protocol
• Denning 81 presented the following:
1. A→AS: IDA || IDB

2. AS→A: InfoA || InfoB

where InfoA = EKRas[IDA || Kua || T]
where InfoB = EKRas[IDB || Kub || T]

3. A→B: InfoA || InfoB || EKUb[EKRa[Ks || T] ]

• note session key is chosen by A, hence AS need not be
trusted to protect it
• timestamps prevent replay but require synchronized clocks
 AUP - CS 335
One-Way Authentication
• required when sender & receiver are not in communications
at same time (eg. email)
• have header in clear so can be delivered by email system
• may want contents of body protected & sender authenticated
 AUP - CS 335
Using Symmetric Encryption
• can refine use of KDC but can’t have final exchange of
nonces, vis:
1. A→KDC: IDA || IDB || N1
2. KDC→A: EKa[Ks || IDB || N1 || EKb[Ks || IDA] ]
3. A→B: EKb[Ks || IDA] || EKs[M]
• does not protect against replays
– could rely on timestamp in message, though email delays make this
problematic
 AUP - CS 335
Public-Key Approaches

• have seen some public-key approaches

• if confidentiality is major concern, can use:
A→B: EKUb[Ks] || EKs[M]
– has encrypted session key, encrypted message
• if authentication needed use a digital signature with a digital certificate:
A→B: M || S || C
where S = EKRa[H(M)]
where C = EKRas[T || IDA || KUa]
– with message, signature, certificate
– when B receives message
• He gets the certificate C provided by AS proving that A is owning KUa
• He gets the signature S provided by A proving that M has not be changed
• He gets M
 AUP - CS 335
Digital Signature Standard (DSS)
• US Govt approved signature scheme FIPS 186
• uses the SHA hash algorithm
• designed by NIST & NSA in early 90's
• DSS is the standard, DSA is the algorithm
• a variant on ElGamal and Schnorr schemes
• creates a 320 bit signature, but with 512-1024 bit security
• security depends on difficulty of computing discrete
logarithms
 AUP - CS 335
DSA Key Generation
• have shared global public key values (p,q,g):
– a large prime p of the order of 2L
• where L= 512 to 1024 bits and is a multiple of 64
– choose q, a 160 bit prime factor of p-1
– choose g = h(p-1)/q
• where h<p-1, h(p-1)/q mod p > 1
• users choose private & compute public key:
– Choose user private key x : x<q
– Compute user public key y : y = gx mod p
 AUP - CS 335
DSA Signature Creation
• to sign a message M the sender:
– generates a random signature key k, k<q
– nb. k must be random, be destroyed after use, and never be reused

• then computes signature pair:

r = (gk mod p) mod q
s = k-1(SHA(M) + xr) mod q
• sends signature (r,s) with message M
 AUP - CS 335
DSA Signature Verification
• having received M & signature (r,s)
• to verify a signature, recipient computes:
w = s-1 mod q
u1 = (SHA(M) w) mod q
u2 = (r.w) mod q
v = (gu1.yu2 mod p) mod q
• if v = r then signature is verified
• see book web site for details of proof why
 AUP - CS 335
Summary
• have considered:
– digital signatures
– authentication protocols (mutual & one-way)
– digital signature standard