An iterative hash function breaks up a message into blocks of a fixed size and iterates over them with a compression function. For example, MD5 and SHA-1 operate on 512-bit blocks. The size of the output of HMAC is the same as that of the underlying hash function (128 or 160 bits in the case of MD5 or SHA-1, respectively), although it can be truncated if desired. Truncating the hash image reduces the security of the MAC which is upper bound by the birthday attack.
The construction and analysis of HMACs was first published in 1996 by Mihir Bellare, Ran Canetti, and Hugo Krawczyk, who also wrote RFC 2104. FIPS PUB 198 generalizes and standardizes the use of HMACs. HMAC-SHA-1 and HMAC-MD5 are used within the IPsec and TLS protocols.
where h is a cryptographic hash function, K is a secret key padded to the right with extra zeros to the block size of the hash function, m is the message to be authenticated, || denotes concatenation, denotes exclusive or (XOR), and the outer padding opad = 0x5c5c5c...5c5c and inner padding ipad = 0x363636...3636 are two one-block–long hexadecimal constants.
function hmac (key, message)
opad = [0x5c * blocksize] // Where blocksize is that of the underlying hash function
ipad = [0x36 * blocksize]
if (length(key) > blocksize) then
key = hash(key) // keys longer than blocksize are shortened
for i from 0 to length(key) - 1 step 1
ipad[i] = ipad[i] XOR key[i]
opad[i] = opad[i] XOR key[i]
return hash(opad || hash(ipad || message)) // Where || is concatenation
The design of the HMAC specification was motivated by the existence of attacks on more trivial mechanisms for combining a key with a hash function. For example, one might assume the same security that HMAC provides could be achieved with MAC = H(key || message). However this method suffers from a serious flaw, depending on the hash functions implementation, one could add data to the message without knowing the key and obtain a valid MAC. To fix this, one might consider inputting the message length at the beginning, however this too has been found to have weaknesses. Using MAC = H(key || message || key) is better, however various security papers have suggested vulnerabilities with this approach, even when two different keys are used. No known extensions attacks have been found against the current HMAC specification which is defined as H(key1 || H(key2 || message)) because the outer application of the hash function masks the intermediate result of the internal hash. The ipad and opad were defined in such a way to have a large hamming distance from each other and so the inner and outer keys will have fewer bits in common.
In the recently (2006) published paper "On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1", by Jongsung Kim, Alex Biryukov, Bart Preneel, Seokhie Hong, claim to have devised: "two new distinguishers of the structure of HMAC, called differential and rectangle distinguishers, and use them to discuss the security of HMAC based on HAVAL, MD4, MD5, SHA-0 and SHA-1. We show how to distinguish HMAC with reduced or full versions of these cryptographic hash functions from a random function or from HMAC with a random function. We also show how to use our differential distinguisher to devise a forgery attack on HMAC. Our distinguishing and forgery attacks can also be mounted on NMAC based on HAVAL, MD4, MD5, SHA-0 and SHA-1. Furthermore, we show that our differential and rectangle distinguishers can lead to second-preimage attacks on HMAC and NMAC.". They go on to claim: "With these distinguishing and forgery attacks we have shown that HMAC with the full versions of 3-pass HAVAL and SHA-0 can be distinguished from HMAC with a random function, and HMAC with the full version of MD4 can be forged. These distinguishing and forgery attacks have also been applied to HMAC based on reduced versions of MD5 and SHA-1. All these attacks do not contradict the security proof of HMAC, but they improve our understanding of the security of HMAC based on existing cryptographic hash functions."