Appears in RSA Laboratories’ CryptoBytes, Vol. 2, No. 1, Spring 1996.

Message Authentication using Hash Functions— The

Mihir Bellare∗ Ran Canetti† Hugo Krawczyk‡

There has recently been a lot of interest in the the most popular is the CBC MAC. (Its security is
subject of authenticating information using cryp- analyzed in [4, 12]). More recently, however, people
tographic hash functions like MD5 and SHA, par- have suggested that MACs might be constructed
ticularly for Internet security protocols. We report from cryptographic hash functions like MD5 and
on our HMAC construction [1] which seems to be SHA. There are several good reasons to attempt
gaining acceptance as a solution. this: In software these hash functions are signifi-
cantly faster than DES; library code is widely and
Introduction freely available; and there are no export restrictions
on hash functions.
Two parties communicating across an insecure
channel need a method by which any attempt to Thus people seem agreed that hash function based
modify the information sent by one to the other, or constructions of MACs are worth having. The more
fake its origin, is detected. Most commonly such difficult question is how best to do it. Hash func-
a mechanism is based on a shared key between tions were not originally designed for message au-
the parties, and in this setting is usually called a thentication. (One of many difficulties is that they
MAC, or Message Authentication Code. (Other are not even keyed primitives, i.e., do not accommo-
terms include Integrity Check Value or Crypto- date naturally the notion of a secret key). Several
graphic Checksum). The sender appends to the constructions were proposed prior to HMAC, but
data D an authentication tag computed as a func- they lacked a convincing security analysis.
tion of the data and the shared key. At reception, The HMAC construction is intended to fill this gap.
the receiver recomputes the authentication tag on It has a performance which is essentially that of the
the received message using the shared key, and ac- underlying hash function. It uses the hash func-
cepts the data as valid only if this value matches tion in a black box way so that it can be imple-
the tag attached to the received message. mented with available code, and also replacement
The most common approach is to construct MACs of the hash function is easy should need of such a
from block ciphers like DES. Of such constructions replacement arise due to security or performance
reasons. Its main advantage, however, is that it can
∗Department of Computer Science & Engineering, Mail be proven secure provided the underlying hash func-
Code 0114, University of California at San Diego, 9500 tion has some reasonable cryptographic strengths.
Gilman Drive, La Jolla, CA 92093. Email: [email protected].
edu. http://www-cse.ucsd.edu/users/mihir.
The security features can be summarized like this: if
† Laboratory for Computer Science, 545 Technology HMAC fails to be a secure MAC, it means there are
Square, Cambridge, MA 02139. Email: canetti@theory. sufficient weaknesses in the underlying hash func-
lcs.mit.edu. Supported by a post-doctoral grant from the tion that it needs to be dropped not only from this
Rothschild Foundation.
‡IBM T.J. Watson Research Center, PO Box 704, York- particular usage but also from a wide range of other
town Heights, New York 10598. Email: [email protected]. popular usages to which it is now subject.
com.

1
Several articles in the literature survey existing con- byte string resulting from step (5)
structions, their properties, and some of their weak- (7) Apply H to the stream generated in step (6)
nesses, so we will not try to do this again here. In and output the result
particular the reader is referred to Tsudik [17], who
provides one of the earliest works on the subject; The recommended length of the key is at least l bits.
Kaliski and Robshaw who, in the first CryptoBytes A longer key does not add significantly to the secu-
[8], compare various possible constructions; updates rity of the function, although it may be advisable if
appearing in succeeding issues of CryptoBytes; and the randomness of the key is considered weak.
Preneel and van Oorschot [12, 13], who present a de- HMAC optionally allows truncation of the final out-
tailed description of the effect of birthday attacks on put say to 80 bits.
“iterated constructions” and also a new construc-
tion called MDx-MAC. As a result we get a simple and efficient construc-
tion. The overall cost for authenticating a stream
We now move on to discuss the HMAC construc- Text is close to that of hashing that stream, espe-
tion, status, and rationale. For a complete descrip- cially as Text gets large. Furthermore, the hashing
tion, implementation guidelines, and detailed anal- of the padded keys can be precomputed for even
ysis we refer the reader to [1, 9]. improved efficiency.
Note HMAC uses the hash function H as a black
HMAC
box. No modifications to the code for H are re-
Let H be the hash function. For simplicity of de- quired to implement HMAC. This makes it easy
scription we may assume H to be MD5 or SHA-1; to use library code for H, and also makes it easy
however the construction and analysis can be ap- to replace a particular hash function, such as MD5,
plied to other functions as well (see below). H with another, such as SHA, should the need to do
takes inputs of any length and produces l-bit out- this arise.
put (l = 128 for MD5 and l = 160 for SHA-1). Let
HMAC was recently chosen as the mandatory-to-
Text denote the data to which the MAC function is
implement authentication transform for the Inter-
to be applied and let K be the message authentica-
net security protocols being designed by the IPSEC
tion secret key shared by the two parties. (It should
working group of the IETF (it replaces as a manda-
not be larger than 64 bytes, the size of a hashing
tory transform the one described in [10]). For this
block, and, if shorter, zeros are appended to bring
purpose HMAC is described in the Internet Draft
its length to exactly 64 bytes.) We further define
[9], and in an upcoming RFC. Other Internet pro-
two fixed and different 64 byte strings ipad and opad
tocols are adopting HMAC as well (e.g., s-http [14],
as follows (the “i” and “o” are mnemonics for inner
SSL [7]).
and outer):
ipad = the byte 0x36 repeated 64 times The rationale
opad = the byte 0x5C repeated 64 times. We now briefly explain some of the rationale used
The function HMAC takes the key K and Text, and in [1] to justify the HMAC construction.
produces HMACK (Text) = As we indicated above, hash functions were not orig-
H(K ⊕ opad, H(K ⊕ ipad, Text)) . inally designed to be used for message authentica-
tion. In particular they are not keyed primitives,
Namely, and it is not clear how best to “key” them. Thus,
one ought to be quite careful in using hash functions
(1) Append zeros to the end of K to create a 64 to build MACs.
byte string
(2) XOR (bitwise exclusive-OR) the 64 byte string The standard approach to security evaluation is to
computed in step (1) with ipad look for attacks on a candidate MAC construction.
When practical attacks can be found, their effect
(3) Append the data stream Text to the 64 byte is certainly conclusive: the construction must be
string resulting from step (2) dropped. The difficulty is when attacks are not yet
(4) Apply H to the stream generated in step (3) found. Should one adopt the construction? Not
(5) XOR (bitwise exclusive-OR) the 64 byte string clear, because attacks might be found in the future.
computed in step (1) with opad The maxim that guided the HMAC construction
(6) Append the H result from step (4) to the 64 was that an absence of attacks today does not im-

2
ply security for the future. A better way must be and the output of H on text x is computed by break-
found to justify the security of a construction before ing x into 512 bit blocks and hashing in stages using
adopting it. f , in a simple way that the reader can find described
in many places, e.g. [8].)
You can’t make good wine from bad grapes: if no
strengths are assumed of the hash function, we can’t Roughly what [1] say is that an attacker who can
hope to justify any construction based on it. Ac- forge the HMAC function can, with the same effort
cordingly it is appropriate to make some assump- (time and collected information), break the under-
tions on the strength of the hash function. lying hash function in one of the following ways:
A well justified MAC construction, in our view, is (1) The attacker finds collisions in the hash func-
one under which the security of the MAC can be re- tion even when the IV is random and secret,
lated as closely as possible to the (assumed) security or
properties of the underlying hash function.
(2) The attacker is able to compute an output of
The assumptions on the security of the hash func- the compression function even with an IV that
tion should not be too strong, since after all not is random, secret and unknown to the attacker.
enough confidence has been gathered in current can- (That is, the attacker is successful in forging
didates (like MD5 or SHA). In fact, the weaker the with respect to the application of the compres-
assumed security properties of the hash function, sion function secretly keyed and viewed as a
the stronger the resultant MAC construction is. MAC on fixed length messages.)
We make assumptions that reflect the more stan- The feasibility of any of these attacks would contra-
dard existing usages of the hash function. The prop- dict some of our basic assumptions about the cryp-
erties we require are mainly collision-freeness and tographic strength of these hash functions. Suc-
some limited “unpredictability.” What is shown is cess in the first of the above attacks means success
that if the hash function function has these prop- in finding collisions, the prevention of which is the
erties the MAC is secure; the only way the MAC main design goal of cryptographic hash functions,
could fail is if the hash function fails. and thus can be assumed hard to do. But in fact,
In fact the assumptions we make are in many ways even more is true: success in the first attack above is
weaker than standard ones. In particular we require even harder than finding collisions in the hash func-
only a weak form of collision-resistance. Thus it is tion, because collisions when the IV is secret (as is
possible that H is broken as a hash function (for the case here) is far more difficult than finding col-
example collisions are found) and yet HMAC based lisions in the plain (fixed IV) hash function. This
on H survives. is because the former requires interaction with the
legitimate user of the function (in order to generate
pairs of input/outputs from the function), and disal-
A closer look lows the parallelism of traditional birthday attacks.
Security of the MAC means security against forgery. Thus, even if the hash function is not collision-free
The MAC is considered broken if an attacker, not in the traditional sense, our schemes could be se-
having the key K, can find some text Text together cure.
with its correct MAC value HMACK (Text). The at- Some “randomness” of hash functions is assumed
tacker is assumed able to gather some number of ex- in their usage for key generation and as pseudo-
ample pair of texts and their valid MACs by observ- random generators. (For example the designers of
ing the traffic between the sender and the receiver. SHA suggested that SHA be used for this purpose
Indeed the adversary is even allowed a chosen mes- [6].) Randomness of the function is also used as
sage attack under which she can influence the choice a design methodology towards achieving collision-
of messages for which the sender computes MACs. resistance. The success of the second attack above
Following [4, 3] we quantify security in terms of the would imply that these randomness properties of
probability of successful forgery under such attacks. the hash functions are very poor.
The analysis of [1] applies to hash functions of the The analyses in [1] used to establish the above are
iterated type, a class that includes MD5 and SHA, exact (no asymptotics involved), consider generic
and consists of hash functions built by iterating ap- rather than particular attacks, and establish a tight
plications of a compression function f according to relationship between the securities.
the procedure of Merkle [11] and Damgård [5]. (In
this construction a l-bit initial variable IV is fixed,

3
Resistance to known attacks Lecture Notes in Computer Science Vol. 839,
Y. Desmedt ed., Springer-Verlag, 1994.
As shown in [12, 2], birthday attacks, that are
the basis to finding collisions in cryptographic hash [5] I. Damgård. A design principle for hash func-
functions, can be applied to attack also keyed MAC tions. Advances in Cryptology – Crypto 89
schemes based on iterated functions (including also Proceedings, Lecture Notes in Computer Sci-
CBC-MAC, and other schemes). These attacks ap- ence Vol. 435, G. Brassard ed., Springer-
ply to most (or all) of the proposed hash-based Verlag, 1989.
constructions of MACs. In particular, they con-
stitute the best known forgery attacks against the [6] National Institute for Standards and
HMAC construction. Consideration of these at- Technology. Digital Signature Standard
tacks is important since they strongly improve on (DSS). Federal Register, Vol. 56, No. 169, Au-
naive exhaustive search attacks. However, their gust, 1991
practical relevance against these functions is negli-
gible given the typical hash lengths like 128 or 160. [7] A.O. Freier, P. Karlton, and P.
Indeed, these attacks require the collection of the C. Kocher. The SSL Protocol – Version 3.0.
MAC value (for a given key) on about 2l/2 mes- Internet draft draft-freier-ssl-version3-01.txt,
sages (where l is the length of the hash output). For March 1996.
values of l ≥ 128 the attack becomes totally infea-
[8] B. Kaliski and M. Robshaw. Message Au-
sible. In contrast to the birthday attack on key-less
thentication with MD5. RSA Labs’ Crypto-
hash functions, the new attacks require interaction
Bytes, Vol. 1 No. 1, Spring 1995.
with the key owner to produce the MAC values on
a huge number of messages, and then allow for no [9] H. Krawczyk, M. Bellare and R. Can-
parallelization. For example, when using MD5 such etti. HMAC-MD5: Keyed-MD5 for Message
an attack would require the authentication of 264 Authentication. Internet draft draft-ietf-ipsec-
blocks (or 273 bits) of data using the same key. On hmac-md5-txt.00, March 1996.
a 1 Gbit/sec communication link, one would need
250,000 years to process all the data required by [10] P. Metzger and W. Simpson. IP Authen-
such an attack. This is in sharp contrast to birth- tication using Keyed MD5”, IETF Network
day attacks on key-less hash functions which allow Working Group, RFC 1828, August 1995.
for far more efficient and close-to-realistic attacks
[18]. [11] R. Merkle. One way hash functions and
DES. Advances in Cryptology – Crypto 89
References Proceedings, Lecture Notes in Computer Sci-
ence Vol. 435, G. Brassard ed., Springer-
[1] M. Bellare, R. Canetti and H. Kraw- Verlag, 1989. (Based on unpublished paper
czyk. Keying hash functions for message from 1979 and his Ph. D thesis, Stanford,
authentication. Advances in Cryptology – 1979).
Crypto 96 Proceedings, Lecture Notes in Com-
puter Science Vol. ??, N. Koblitz ed., Springer- [12] B. Preneel and P. van Oorschot. MD-x
Verlag, 1996. MAC and building fast MACs from hash func-
[2] M. Bellare, R. Canetti and H. Kraw- tions. Advances in Cryptology – Crypto 95
czyk. Pseudorandom functions revisited: The Proceedings, Lecture Notes in Computer Sci-
cascade construction. Manuscript, April 1996. ence Vol. 963, D. Coppersmith ed., Springer-
Verlag, 1995.
[3] M. Bellare, R. Guérin and P. Rogaway.
XOR MACs: New methods for message au- [13] B. Preneel and P. van Oorschot. On
thentication using finite pseudorandom func- the security of two MAC algorithms. Advances
tions. Advances in Cryptology – Crypto 95 in Cryptology – Eurocrypt 96 Proceedings,
Proceedings, Lecture Notes in Computer Sci- Lecture Notes in Computer Science Vol. ??,
ence Vol. 963, D. Coppersmith ed., Springer- U. Maurer ed., Springer-Verlag, 1996.
Verlag, 1995.
[14] E. Rescorla and A. Schiffman. The
[4] M. Bellare, J. Kilian and P. Rogaway. Secure HyperText Transfer Protocol. Inter-
The security of cipher block chaining. Ad- net draft draft-ietf-wts-shttp-01.txt, Febru-
vances in Cryptology – Crypto 94 Proceedings, ary 1996.

4
[15] R. Rivest. The MD5 message-digest al-
gorithm. IETF Network Working Group,
RFC 1321, April 1992.
[16] FIPS 180-1. Secure Hash Standard. Fed-
eral Information Processing Standard (FIPS),
Publication 180-1, National Institute of Stan-
dards and Technology, US Department of
Commerce, Washington D.C., April 1995.
[17] G. Tsudik. Message authentication with one-
way hash functions. Proceedings of Info-
com 92.
[18] P. van Oorschot and M. Wiener. Par-
allel Collision Search with Applications to
Hash Functions and Discrete Logarithms. Pro-
ceedings of the 2nd ACM Conf. Computer
and Communications Security, Fairfax, VA,
November 1994.