Talk:HMAC

timing attacks ?!

"At least theoretically a timing attack could be performed to find out a HMAC digit by digit.[9]" There are no such things as timing attacks on HMAC by itself: it might leak the key size but nothing more if the underlying hash function is not vulnerable to timing attacks. The reference probably refers to a timing attack made on the memcmp used to compare the stored mac with the evaluated mac. That would allow the attacker to forge a valid, stored, HMAC digit by digit. See http://beta.ivc.no/wiki/index.php/Xbox_360_Timing_Attack — Preceding unsigned comment added by 93.50.106.102 (talk) 23:00, 17 July 2012 (UTC)

added example usage for non-mathletes.

I added some text for readers that just want to know how to implement an HMAC without necessarilly understanding the math behind it. I plan to add some example C or python code that displays how a message would be verified.

I don't think we'd gain anything from programming language code, to be honest. There isn't a great deal of maths to understand for HMAC. It's just a short sequence of concatenations, XORs and hash function calls, and is readily comprehensible from the definition given in the article. I think it would be redundant to write it again out in C or Python. Compare, say, SHA-1 or MD5, which are complex algorithms which benefit from a pseudo-code treatment. — Matt Crypto 09:31, 5 November 2005 (UTC)

Bug in pseudo code??

Existing Pseudo code

   if (length(key) > blocksize) then
       key = hash(key) // keys longer than blocksize are shortened
   else if (length(key) < blocksize) then
       key = key ∥ zeroes(blocksize - length(key)) // keys shorter than blocksize are zero-padded
   end if

At the end of this if statement key is hashed first branch is taken and not hashed otherwise. Looking at algorithm I suggest the following:

   if (length(key) > blocksize) then
       key = left(key,blocksize) // keys longer than blocksize are shortened
   else if (length(key) < blocksize) then
       key = key ∥ zeroes(blocksize - length(key)) // keys shorter than blocksize are zero-padded
   end if

Tony Wallace (tony@tony.gen.nz) —Preceding unsigned comment added by 131.203.134.23 (talk) 22:36, 19 April 2010 (UTC)

Your suggestion is irrelevant. What matters is the standard that defines HMAC. This standard was accurately described before you changed it. Hence, I'm reverting your proposal. 83.78.173.160 (talk) 23:51, 20 April 2010 (UTC)

Advantages over a pure hash

Can someone please explain why using HMAC(hashfunc, k, v) is better than using doing hashfunc(k||v)? It seems like this is a key question. (If you do answer this, I'd appreciate it if you leave a note on my talk page.) AaronSw 15:32, 13 April 2006 (UTC)

Read the references in the article. Knowing F(k||v) means you can compute F(k||v||u||...) trivially. Nesting prevents this [1] (page 16, at the bottom). mdf 13:44, 16 May 2006 (UTC)

Except that all hash algorithms used with HMAC in practice already defeat this attack by including the original message length in the hashing process (ie. you can't construct H(k||v||u) from H(k||v); you must already know k and v). Was this added just to support theoretical hash functions that don't have this property? The other question that arises is: why are the two keys (k1, k2) derived by XORing the key k with those magic numbers (0x36 and 0x5c)? Are the two keys required to be different (why?) and is there a motivation for using XOR (other than that it's fast) or would some random operation like k1 = k, k2 = (k + 1) mod 2^|k| work just as well? If you feel qualified to answer these questions, please add them to the article (instead of only replying here). Thanks in advance! 130.89.167.52 21:17, 16 February 2007 (UTC)

AIUI, because the message length and padding are known to the attacker, you can "back up" those hash functions to the previous (before finalize) state in order to do the concatenation attack. 121a0012 21:43, 27 February 2007 (UTC)

The length being included doesn't help, because an attacker can include the length code in the extension data (u = original_length_code || new_data), which limits the choices for the extension data somewhat, but not enough to make attacks impractical at all. 2001:470:D08D:0:0:0:0:1 (talk) 20:23, 6 July 2013 (UTC)

Typical usage?!

A pizza restaurant that suffers from attackers that place bogus orders is a typical usage of HMAC? Why won't anyone mention SMTP for God's sake? — 212.76.37.162 11:57, 18 March 2006 (UTC)

Right...I'm sure this would be a great business model, for the 0.01% of customers who could be bothered to do such nonsense - as opposed to just calling. — 24.8.120.181 18:41, 21 May 2006 (UTC)

Maybe the example was not explained properly. If you translate it to a normal use case scenario, the customer would be forced to provide a password along with the order on pizza company's webpage, and a applet on the browser would computer the hmac based on the password as the key, before passing it to the server.

Padding

In the described pseudocode implementation of a HMAC, the padding of the key, if it is shorter than the blocksize of the message input of the specific hashfunction, is missing! How do you want to operate a XOR function if you don't have the same amount of bits on each sides? --> If key's size is less than 512 bit long(after ipad) the fingerprint / hash of the key couldn't be the the initial key for the hashfunction (each 512 bit blocksize) of the message appended to the key!

The pseudocode is fine. It alters ipad and opad, which have been set up to have the right length, by XORing the bytes of the key into the beginning of ipad and opad, leaving the final bytes (if any) unchanged at their original values. Remember that XORing with zero doesn't do a thing. Hanche (talk) 08:22, 2 January 2009 (UTC)

Illustration

The illustration is really bad, I think. Utterly confusing. First, it appears to show HMAC(k,m) to be the two inputs rather than the output. Second, it shows the hash function h with two inputs and two outputs, with one of the two outputs feeding back into one of the inputs. You have to read the text to realize that the vertical direction is one application of h and the horizontal direction another. The two applications of h should have been drawn as separate boxes for clarity. Hanche (talk) 08:28, 2 January 2009 (UTC)

Security Section

This section is very poorly written. No mention of an NMAC is given. This seems to be a summary of one paper on the security analysis of HMACs, this requires cleanup.--Chrismiceli (talk) 06:37, 20 July 2009 (UTC)

I have taken the liberty of performing the cleanup myself. Please comment if desired. --Chrismiceli (talk) 05:02, 21 July 2009 (UTC)

There is the problem? If the hash is secure, it is impossible to find too different arguments with the same hash. That means, it is impossible to find to different messages or keys with the same HMAC. If the hash ist a one way function the HMAC is a one way function of message and key. It means HMAC is secure, if the hash is secure. --95.222.228.77 (talk) 21:37, 28 July 2010 (UTC)

No. The requirements for a secure hash function and a secure HMAC are different. A secure hash function must be collision resistant. For the HMAC to be secure it is according to the paper by Bellare sufficient if the underlying hash function is a "privacy preserving pseudorandom function". As far as I know neither security requirement implies the other one. In particular, Bellare's paper points out that collision resistant is not a necessary requirement for a secure HMAC and he does not use collision resistance in his security reductions. It is also not a problem if two HMACs ever are the same. Otherwise it would not be possible to truncate HMACs. 85.1.138.140 (talk) 07:27, 29 July 2010 (UTC)

If the hash function is collision resistent, the securty is free of doubt. It should be possible to truncate the HMAC to 128 bits or 16 bytes, since it is only required, that for given key and message no second key or message can be found with the same HMAC. Even if the key is known, a second message never can be found by brute force testing a large number of messages with a 128 bit HMAC. --95.222.228.77 (talk) 18:08, 30 July 2010 (UTC)

No. This is wrong. The security requirement is that an attacker can neither find the key nor find the correct HMAC for a new message. This requirement does not follow from collision resistance. Because MACs are an important application of hash functions, the SHA-3 submission are also examined for their resistance against so called "key recovery attacks" besides resistance against collision attacks. 83.78.82.132 (talk) 19:34, 30 July 2010 (UTC)

In principle you are right, the hash function should not only be collision resistent, but also one way, meaning that there is no way to find the key from the HMAC (besides brute force). In practise collision resistent hash functions are allways believed to be one way. If it is impossible to find the key from the whole HMAC and message that is certainly true, if the HMAC is truncated. If the hash is not collision resistent it might be possible to calculate the HMAC for some special messages. That is probably not possible if the HMAC is truncated. —Preceding unsigned comment added by 95.222.228.77 (talk) 10:38, 2 August 2010 (UTC)

I'm sorry, but most of that is wrong.

• $h$ collision resistant and one-way $\nRightarrow$ HMAC instantiated with $h$ is a secure MAC: Assume $h':\{0,1\}^{*}\rightarrow \{0,1\}^{n}$ is a random oracle. Let $h:\{0,1\}^{\geq n}\rightarrow \{0,1\}^{2n},h(m)=h(m_{1}\cdot m_{2})=m_{1}\cdot h'(m_{2})\$ where $m=\ m_{1}\cdot m_{2}\$ and $\ |m_{1}|=n$ i.e. $m$ is split into the first block and the rest of the input. The first two blocks are copied to the output in clear, the rest is hashed securely. $h$ is certainly collision resistant, but HMAC instantiated with $h$ outputs the key in the clear. Also note that $h$ is one way for inputs $m$ with $|m|\geq 2n$. Oh and you can also truncate the HMAC and it will still be insecure.
• $h$ not collision resistant $\nRightarrow$ HMAC instantiated with $h$ is is insecure: For example MD5 is still acceptable for use with HMAC. As a more formal counterexample consider $h\left(m\right)=h\left(m_{1}\cdot m_{2}\right)={\begin{cases}0^{n}&\;m_{1}=0^{\frac {n}{2}}\\h'\left(m\right)&\;{\text{otherwise}}\end{cases}}$

The property you really need is pseudo randomness of $h$, i.e. you cannot distinguish the output of $r:m\mapsto h(k||m)$ from a completely random function without the key $k$. --Eta Aquariids (talk) 06:19, 9 August 2012 (UTC)

One possiblity would be to choose randomly 80 of the 160 bits from SHA-1 HMAC. I guess this is very secure. --95.222.228.77 (talk) 10:48, 2 August 2010 (UTC)

MACs have to be deterministic to be of any use. Choosing the bits at random kind of defeats it's purpose. Also, as SHA1 tries to be a pseudorandom function itself, any 80 bits are as good as any other, as long as there is no serious attack on SHA1 found. --Eta Aquariids (talk) 11:42, 8 August 2012 (UTC)

Problems displaying Unicode characters

Let me show you what your italicized unicode characters look like on my computer:
In Firefox
In IE
--66.168.1.178 (talk) 18:56, 2 December 2009 (UTC)

What this person is complaining about appears to be the characters ∥ (U+2225 PARALLEL TO) and ⊕ (U+2295 CIRCLED PLUS) used in the article (though not in italics). They show up fine in firefox, but become boxes in IE. (Oddly, in the fonts his and my firefox are using, U+2225 shows up as two slanted parallel lines, hence the “italics” misunderstanding, I think. In the Unicode code charts, the lines are vertical.) Maybe one should use standard mathematical formating instead? (I lightly edited the anonymous user's entry, improving the headline for clarity.) Hanche (talk) 00:06, 3 December 2009 (UTC)

order of XOR in pseudo code

The definition and the pseudo code don't use the same order in the XOR operation.

In the definition: HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m))

In the pseudo code:

o_key_pad = [0x5c * blocksize] ⊕ key
i_key_pad = [0x36 * blocksize] ⊕ key

My guess is that the latter is wrong and should be instead:

o_key_pad = key ⊕ [0x5c * blocksize]
i_key_pad = key ⊕ [0x36 * blocksize]

The order is irrelevant since XOR is commutative. But possibly, it might be worth changing the order for notational concistency. Hanche (talk) 19:37, 30 September 2010 (UTC)

Copy

The Intro seems entirely copied from this source: http://everything.explained.at/HMAC/ — Preceding unsigned comment added by 118.208.214.179 (talk) 21:51, 6 November 2011 (UTC)

Nope, 'everything explained' looks like a wikipedia clone to me. 81.62.78.223 (talk) 08:20, 7 November 2011 (UTC)

Can any one provide full Psuedocode for HMAC? 119.154.6.10 (talk) 12:45, 25 April 2012 (UTC)

Image

The file associated with the article (File:Shahmac.jpg) uses "N byte" where it should use "N bits". JPGoldberg (talk) 15:06, 8 June 2012 (UTC)

ipad and opad not important?

In the article, it says "The values of ipad and opad are not critical to the security of the algorithm". Is it safe to leave them out entirely? What is the significance of ensuring the inner and outer keys have few bits in common? Fresheneesz (talk) 18:38, 8 August 2012 (UTC)

The underlying idea of the HMAC security reduction requires the use of two different inner and outer keys. This is replaced with $k\oplus OPAD$ and $k\oplus IPAD$ with the argument that the first iteration of $h$ ($h$ is assumed to hash the data iteratively in a Merkle–Damgård construction) will act as a pseudo random function and generate two - for practical purposes independent - keys. This works as long as the two inputs to the first iteration of the hash function are different and that will be the case as long as IPAD and OPAD differ in at least one bit. Thus, although it is probably still secure to leave them out entirely, it is a bad idea as you have no formal argument why it is still secure. --Eta Aquariids (talk) 06:40, 9 August 2012 (UTC)

"Hashed" redirect

Are there any objections to the creation of a redirect from Hashed message authentication code to this article? I believe it is a "sufficiently confusable" title since, for example, RFC 4635 expands the abbreviation that way. SoledadKabocha (talk) 00:50, 26 September 2012 (UTC)

Replace Image

Someone registered may replace the image by this reworked png-version done by me. http://www.imgbox.de/users/public/images/ZIehXcr0yA.png — Preceding unsigned comment added by 193.175.119.11 (talk) 10:59, 11 January 2013 (UTC)