I was reading HMAC on wikipedia and I was confused about a few points.

  1. Where do I use HMAC?
  2. Why is the key part of the hash?
  3. Even if someone successfully used a "length-extension attack", how would that be useful to the attacker?
  • 4
    If anyone is curious what i wanted to know was hmac is a way to sign data using a symmetrical key. "Its more complex then hashing the message and key together which is not secure" is a bonus.
    – user5575
    Commented Sep 18, 2012 at 19:09
  • 2
    A friend of mine runs one of the largest "crypto currency" exchanges in the world. His API requires HMAC signing of all api calls with the users Private api key( it would be the "secret" you refer to in your question), which includes the public key in the hash. This is the basic use case, as an additional layer of security for API calls. In the cryptocurrency world, his is the only platform yet to be hacked, despite millions of attempts. HMAC is useful, just make sure you know how to use it. i thought i did, but didn't and paid the price in the form of a devastating API hack.
    – r3wt
    Commented Sep 27, 2014 at 2:21
  • use this one to debug 8gwifi.org/hmacgen.jsp
    – anish
    Commented Dec 11, 2017 at 6:35

5 Answers 5


A message authentication code (MAC) is produced from a message and a secret key by a MAC algorithm. An important property of a MAC is that it is impossible¹ to produce the MAC of a message and a secret key without knowing the secret key. A MAC of the same message produced by a different key looks unrelated. Even knowing the MAC of other messages does not help in computing the MAC of a new message.

An HMAC is a MAC which is based on a hash function. The basic idea is to concatenate the key and the message, and hash them together. Since it is impossible, given a cryptographic hash, to find out what it is the hash of, knowing the hash (or even a collection of such hashes) does not make it possible to find the key. The basic idea doesn't quite work out, in part because of length extension attacks, so the actual HMAC construction is a little more complicated. For more information, browse the hmac tag on Cryptography Stack Exchange, especially Why is H(k||x) not a secure MAC construction?, Is H(k||length||x) a secure MAC construction? and HMAC vs MAC functions. There are other ways to define a MAC, for example MAC algorithms based on block ciphers such as CMAC.

A MAC authenticates a message. If Alice sees a message and a MAC and knows the associated secret key, she can verify that the MAC was produced by a principal that knows the key by doing the MAC computation herself. Therefore, if a message comes with a correct MAC attached, it means this message was seen by a holder of the secret key at some point. A MAC is a signature based on a secret key, providing similar assurances to a signature scheme based on public-key cryptography such as RSA-based schemes where the signature must have been produced by a principal in possession of the private key.

For example, suppose Alice keeps her secret key to herself and only ever uses it to compute MACs of messages that she stores on a cloud server or other unreliable storage media. If she later reads back a message and sees a correct MAC attached to it, she knows that this is one of the messages that she stored in the past.

An HMAC by itself does not provide message integrity. It can be one of the components in a protocol that provides integrity. For example, suppose that Alice stores successive versions of multiple files on an unreliable media, together with their MACs. (Again we assume that only Alice knows the secret key.) If she reads back a file with a correct MAC, she knows that what she read back is some previous version of some file she stored. An attacker in control of the storage media could still return older versions of the file, or a different file. One possible way to provide storage integrity in this scenario would be to include the file name and a version number as part of the data whose MAC is computed; Alice would need to remember the latest version number of each file so as to verify that she is not given stale data. Another way to ensure integrity would be for Alice to remember the MAC of each file (but then a hash would do just as well in this particular scenario).

¹ “Impossible” as in requiring far more computing power than realistically possible.

  • 12
    i find this a bit unclear and lengthy, though i definitely learned a bit
    – neaumusic
    Commented Oct 23, 2015 at 20:52
  • Can the hmac code be shared? It seems confusing to me - It is a hash but can't be shared.
    – R11G
    Commented May 3, 2019 at 20:47
  • @R11G I don't understand your question. Do note that “it is a hash” is not a useful way to understand HMAC. HMAC is a MAC. The fact that it's based on a hash is an implementation detail. There are other MAC algorithms that have the same security properties but don't use a hash internally, for example CMAC. Commented May 3, 2019 at 21:03
  • @Gilles Sorry. I meant if I log HMAC in my service logs - is it a potential security flaw?
    – R11G
    Commented May 3, 2019 at 22:26
  • @R11G That depends what it's the HMAC of and what security guarantee you're aiming for. You can't go back from the HMAC to the input without the key. Even with the key, you can only go back by guessing the input and checking it. However, if you see the same HMAC twice, you know it has to be the same input with the same key. Commented May 4, 2019 at 22:08

HMAC is a computed "signature" often sent along with some data. The HMAC is used to verify (authenticate) that the data has not been altered or replaced. Here is a metaphor:

You are going to mail a package to Sarah which contains a photograph. You expect her to open the package and view the photograph. At some point in the near future you expect her to send you back the package with that photograph in it. It's vital that she put the same photograph back in the package. You need to be absolutely sure she doesn't send you back an altered photograph even a little bit, or replace it with a different one. You've got hundreds of these packages going out daily with different photos; you'd never remember the photo in such detail that you could tell if she changed a small bit of it (like if she airbrushed a small zit off her face).

Here's what you can do: Before you send her the package, place another copy of the photograph inside a small locked box. Keep the key. Place the small locked box inside the package along with the original photograph you are mailing her. Assume she knows she is not to remove the locked box from the package. When you receive the package back from her, open it, place the photo on the table. Open the locked box, remove the copy, compare the two. If they are the same, then she has not altered the photograph (it is "authentic"). If the locked box is not in the package or your key will not open it, then assume she has done something nefarious and throw the whole package in the trash. The beauty here is that you don't need to "remember" anything about what you originally sent her; everything you need to ensure legitimacy of the photo comes back inside the package.

In the example above, the small locked box represents an HMAC. Your key is the HMAC's key. The photograph is the data you are applying the HMAC to.

The above is a round trip metaphor where only you have a key. In a different situation, let's say you often send packages to Tommy. You're worried that the nosey mail carriers might be opening your packages and replacing the photographs or changing them. You do the same thing with the locked box, except in this case, you let Tommy have a copy of the key, so that when he receives a package, he can open the locked box included and compare the photos himself. If upon receipt he finds the photos differ, his key doesn't open the box, or the box missing, he knows something is fishy.

The above metaphors describe why HMACs are needed but not so much how they work. Let's change the metaphor again to get closer to how they work:

Let's keep the mental imagery of the package with the photograph: you want to mail it, then receive it back again like before, ensuring the photo was not altered or replaced by the receiver, or during the round trip.

Before you close the package and mail it, you make a copy of the photograph. No locked box this time, instead you brush over the copy with a concoction of liquid chemicals. Only you know the recipe (key) for this mixture, and anytime you brush over a copy, you use the exact same brush strokes. The mixture will swirl and blur the copy of the photograph into something resembling modern art; let's call it an HMAC. You're not exactly sure what it will look like after it dries, but you know that if you brush any two identical photos with the same recipe and the same brush strokes, the resulting HMACs will look the same. So you place the dried HMAC into the package along with the original photograph and send it off to Sarah.

When you get the package back from Sarah, it contains what you hope is the un-altered original photograph along with what you expect is the HMAC you created and included with it. Take the photograph out of the package, copy it, and create another HMAC with that copy (apply your mixture/brush strokes). Compare the HMAC you just created with the HMAC that came back in the package. If they are identical, then you can be sure Sarah and the mail carriers did not alter the photograph.

If Sarah had altered the photo, then the HMACs will not be identical. If Sarah had altered the HMAC, then the HMACs will not be identical. If Sarah had altered the photo, and tried to create a new HMAC, then the HMACs will not be identical (she doesn't know your recipe).

Thus you know if the photo (data) is authentic or not, which is exactly what HMACs are used for.

  • 4
    Thank you. I found your "swirled painting" explanation really helpful. Commented Jun 14, 2019 at 20:05
  • 2
    (Yes, I know I'm 5 years late.) Problem appears when Sarah has multiple photographs from you. She could send you back the wrong one, and since the "key" is common, you'd quite happily accept it. Additional checks might be required, or this risk accepted. Gilles above describes this problem.
    – domen
    Commented Jul 25, 2019 at 9:21

The short answer is "HMAC provides digital signatures using symmetric keys instead of PKI". Essentially, if you don't want to deal with complexities of public/private keys, root of trust and certificate chains, you can still have reliable digital signature with HMAC. HMAC relies on symmetric key cryptography and pre-shared secrets instead of private/public pairs. The downside is the same as with symmetric key cryptography in general - you now need to worry about distribution and protection of your secret keys.

  • 7
    Thanks, I was trying to understand what scenarios you would use an HMAC rather than a public-key digital signature scheme, this seems to be a great example of why - you don't need a PKI Commented Sep 11, 2015 at 14:52
  • 5
    Important differentiation between symmetric and asymmetric keys
    – Cuga
    Commented Oct 17, 2016 at 19:10
  • 1
    You mean that HMAC doesn't needs a PKI?
    – PRVS
    Commented Feb 22, 2017 at 15:14
  • 2
    @PRVS Yes that is exactly right, HMAC does not require PKI.
    – dtoubelis
    Commented Feb 22, 2017 at 15:50

1 . You use HMAC whenever you want integrity of the data maintained (and authenticity)

2 . The key is part of the HMAC. Since it is a shared secret known between 2 parties only and only they can create the HMAC and no one else. (Ensures authenticity)

3 . Length extension attacks are not possible on HMAC. MACs on the other hand simply appends key to the message, which is susceptible to it. HMAC was introduced to overcome this attack on MACs.

  • 4
    +1 as I was confused why just concatinate the message and the key, and what difference a key has over just concatenating it. Although I'm still confused.
    – doc_id
    Commented Jan 26, 2014 at 10:28
  • HMACS are used when you need to check two "integrity" and "authenticity". For eg: consider a scenario where you are sent a piece of data along with its hash -- you can verify the integrity of the message by recomputing the hash of the message and comparing it with the hash that you received. However, you don't know for sure if the message and the hash was sent by someone you knew/trusted. If you had resorted to using HMACS, you could recompute the HMAC using a secret key that only you and a trusted party know, and compare it with the HMAC you just received -- in effect, serving the purpose of "authenticity".

  • Like I mentioned earlier, the secrecy of the key ensures that the HMAC was computed by a trusted party.

  • HMACS are not keyed hashes. Length extension attacks are possible when you used keyed hashes, not HMACS. For further reading you might want to check out this.


Answer edited to answer comment below :- "I still don't understand why the key is in the message? Do I not know the public key of the party? If I know the public key then why is the key in the message rather me using the already known key? If I don't know the key then why would i trust that party?"

  • The key is not "in" the message. The key is used in generating the HMAC from a message. The key used for generating HMACS is not anyones "public key". Its more like a shared secret between two parties. You could check out the REST API authentication method for AWS stuff to better understand how HMACS are used for URL-signing.

You must log in to answer this question.