I've read definitions of MAC and HMAC, but can't say I've completely grasped the differences.

  • What are principle differences?
  • When to use one and when the other?(Typical Use Cases)
  • 8
    $\begingroup$ HMAC is a MAC algorithm. The term MAC algorithm refers to any algorithm that authenticates a message. There are other MAC algorithms besides HMAC, such as VMAC. $\endgroup$ Commented Jun 16, 2012 at 13:45
  • 1
    $\begingroup$ @ChrisSmith - thks, I understand...so updating my question, what are typical use cases just of HMAC functions? $\endgroup$
    – Matteo
    Commented Jun 16, 2012 at 14:31
  • 3
    $\begingroup$ The same as any other MAC algorithm. HMAC just has the added advantage that it doesn't require a MAC IV. Its typical uses are the same as any other MAC algorithm, ensuring the authenticity and integrity of a transmitted message for example. $\endgroup$ Commented Jun 16, 2012 at 15:52

2 Answers 2


As Chris Smith notes in the comments, HMAC is a specific MAC algorithm (or, rather, a method for constructing a MAC algorithm out of a cryptographic hash function). Thus, HMAC can be used for any application that requires a MAC algorithm.

One possible reason for requiring HMAC specifically, as opposed to just a generic MAC algorithm, is that the HMAC construction actually provides (as long as the underlying hash function satisfies the appropriate assumptions) stronger security properties than what's required of a MAC. For example, nothing in the definition of a secure MAC algorithm (resistance to existential forgery under a chosen-plaintext attack) says that the MAC output can't reveal information about the plaintext to an attacker. If the plaintext is secret but the MAC is public, that would obviously be bad. HMAC, however, is guaranteed not to reveal any information about the plaintext as long as the underlying hash function is secure.

In particular, Bellare has shown that HMAC is a pseudo-random function (PRF) as long as the compression function of the underlying hash is also a PRF, and a "privacy-preserving MAC" (PP-MAC) as long as the compression function of the underlying hash is also a PP-MAC. Both of these are strictly stronger security properties than what's required of a plain MAC; in particular, being a PRF is a very strong security property — it essentially says that there's no practical way for an attacker to say anything about the output of the function based on the input, or vice versa, except for the obvious fact that the same input always yields the same output. There are many use cases for which a PRF will do whereas a plain MAC may not; HMAC, instantiated with a secure hash function, can be used for those.

Also, as Chris notes, some other MAC algorithms require a random IV to be secure; HMAC does not, so it can be used even in situations where deterministic output is required, or where messages must be kept as short as possible.

As for why you might not want to use HMAC, well, one reason is that it's not really optimized for speed. Dedicated MAC functions, particularly those based on universal hashing (the Carter–Wegman construction) like UMAC and VMAC, can be significantly faster. Also, MACs based on block ciphers (such as CMAC) can be very useful on limited platforms where an efficient block cipher primitive (like AES) is available but a secure hash function is not.


Something else that has not been mentioned before:

Remind the construction of a Merkle Damgard Hash with f the compression function (e.g. MD5, SHA1,2 -- thanks for pointing out my missconception @Ilmari Karonen):

enter image description here

In the following descriptions the function Hmd will be such a Hashfunktion constructed via MD. MAC(k,m) will be the function that protects the message for integrity by using Hmd in one way or another.


Bob is sending an integrity-protected message to Alice:

Bob ---- m, MAC(k,m) ----> Alice

Case 1: MAC(k,m) = HMD(k,m)

Mallory is woman-in-the-middle and catches m and MAC(k,m).

Now Mallory can extend m to m' = m || mean_extension and create MAC'(m') with MAC'(m') = f (MAC(k,m), mean_extention) where f is the compression function used for Merkle Damgard.

When Mallory forwards her generated message: (m', MAC'(m')) constructed as above, Alice has no possibility to determine the fraud. The MAC looks genuine to her, because it is.

So: f (MAC (k,m), mean_extention) == MAC (k, m || mean_extension) holds true, with the MAC being a simple Merkle Damgard Hashfunktion.

Case 2: MAC(k,m) = HMAC(k,m) = HMD(k || opad , HMD(k || ipad, m))

Now the structure of the MAC is not providing any possiblity to attack the bad construction of concatenating with the compression function.

This means: f (MAC (k,m), mean_extension) != MAC(k, m || mean_extension) contrary to Case 1, because MAC now is an HMAC constructed as above in the heading.

  • $\begingroup$ This reads more like an answer to this question to me. (Also, to correct your parenthetical remark, Merkle-Damgård hash functions are still widely used, the most notable example being the SHA-2 family still recommended by NIST alongside the newer SHA-3.) $\endgroup$ Commented Mar 13, 2018 at 23:19
  • $\begingroup$ You are completely correct, my brain tricked me. Thanks, I will edit this. $\endgroup$
    – Jan
    Commented Mar 14, 2018 at 11:55
  • $\begingroup$ Actually maybe the question here could also be a duplicate of that question of the one you linked to (or vice-versa). $\endgroup$
    – Jan
    Commented Mar 14, 2018 at 12:01
  • $\begingroup$ The other question only asks about the security of different ways of constructing a MAC based on a hash function. There are plenty of MACs that have nothing to do with hashes. For example, CBC-MAC / CMAC / PMAC are based on block ciphers, while UMAC / VMAC / Poly1305 and other Carter-Wegman style MACs use polynomial evaluation in a finite field. $\endgroup$ Commented Mar 14, 2018 at 12:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.