Talk:HMAC

Cryptography: Computer science High‑importance

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
High	This article has been rated as High-importance on the importance scale.
	This article is supported by WikiProject Computer science (assessed as High-importance).

On November 15, 2007, HMAC was linked from Wired News, a high-traffic website. (Traffic)

All prior and subsequent edits to the article are noted in its revision history.

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)[reply]

I have removed mention of the timing attack. as it was unsourced with respected to HMACs. If someone can find a good source for it then it can be put back in 103.38.149.55 (talk) 09:58, 3 April 2017 (UTC)[reply]

i agree with the removal, but for a different reason: it is about "short circuit" comparison, which does not belong to this topic, because it is a more general concept. Krisztián Pintér (talk) 11:55, 3 April 2017 (UTC)[reply]

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)[reply]

Just passing by: the python example really ain't that easy to read, nor is it close to the pseudo-code sample: it uses a smart hack with translation tables to avoid XOR operations, which are quite expensive in Python. --Mistouille (talk) 08:49, 22 July 2013 (UTC)[reply]

Blocksize on pseudo code

blockSize: Integer   the block size of the underlying hash function (e.g. 32 bytes for SHA-256)

On SHA-256, the output size is 32 bytes, however the input block size is 64 bytes. In this example, using SHA-256, shouldn't block size be set to 64 instead ? — Preceding unsigned comment added by 164.40.221.237 (talk) 13:39, 12 November 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

This is the problem with pseudocode... it's fine or not fine depending on how your pseudo xor is defined. If it's defined as padding the short operand with zeros to the length of the long one, then you get a valid HMAC. If it's defined as truncating the long operand to the length of the short one, you get something else. These are 2 reasonable interpretations; there may be more. (In fact, I think "xor on different length strings throws an exception" would be reasonable too.) The pseudocode and the Definition section both require the reader will guess the correct interpretation. 67.162.91.170 (talk) 19:11, 11 February 2017 (UTC)[reply]

the pseudocode never xors different length data. the only case it could happen if the hash produced more bits than the blocksize. but using such a hash would not make much sense, considering that it is there to shorten the long key. if either the original or the hashed key is shorter than the blocksize, 0's are appended. Krisztián Pintér (talk) 19:22, 11 February 2017 (UTC)[reply]

Block Size

The pseudocode could use some help as to the clarity of L from RFC2104, being the output length of the Hash function used. While the code is written correctly it does kind of gloss over the fact that if length(key) > blocksize happens, length(key) < block size can and will also happen after key = hash(key) when using MD5; because B=64 and L=16.199.34.4.20 (talk) 00:46, 2 June 2016 (UTC)[reply]

it is in the definition of K' in the previous section. i don't think there should be more explanation in the pseudocode section. explanations belong to the definition section. Krisztián Pintér (talk) 08:07, 2 June 2016 (UTC)[reply]

I was also confused by the definition of K'. But I could not think of a succinct enough way to state the definition. Cowlicks (talk) 21:34, 9 December 2016 (UTC)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

I've just removed a comment by 192.153.142.154 from the bottom of the intro section that read: [Great introduction of HMAC, largely plagiarized from "CCNA Security," Cisco Press (Michael Watkins & Kevin Wallace, 2008) pages 470-471]. I haven't got a copy of that book, but if the comment's right the intro needs to be changed to avoid copyright infringement. If it qualifies under fair use, the book needs to be in the references. Wocky (talk) 10:22, 16 May 2015 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Hash-based message authentication code. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 00:30, 16 October 2015 (UTC)[reply]

Pseudo code does not match functionality of definition

In the definition section, the following three elements are concatenated:

K' ⊕ opad
H( K' ⊕ ipad )
message

However in the pseudocode the following two elements are concatenated:

K' ⊕ opad
H( K' ⊕ ipad , message )

Is the problem in the Documentation or in the Pseudocode?

Dotancohen (talk) 16:26, 5 November 2016 (UTC)[reply]

i think you lost track of parens. the definition is not what you describe here, and is identical to the pseudocode.Krisztián Pintér (talk) 23:52, 5 November 2016 (UTC)[reply]

Please add check algorithm for clients receiving the message and HMAC

I understand that clients will have the public key associated to the private key used for signing prior to receiving the message and HMAC. The validation must then check that the HMAC match some sort of operation using the message and the public key as input.

What's the exact algorithm?  — Preceding unsigned comment added by 13.94.145.70 (talk) 08:31, 17 August 2017 (UTC)[reply]

don't confuse hash based signatures with hash based MACs. this is not a public key algorithm, there is no public key here. the private key is shared by the two parties. Krisztián Pintér (talk) 09:25, 17 August 2017 (UTC)[reply]

Sha-1 is mentioned a lot, is it safe?

I'm no security expert, but I remember the shappening and was under the impression that sha-1 is no longer strong enough for Internet encryption. If this is the case, shouldn't this article use ex. sha-256 in its examples and references? — Preceding unsigned comment added by Finnjohnsen (talk • contribs) 09:24, 15 February 2018 (UTC)[reply]

External links

User:Cherkash I trimmed the clearly excessive buildup of implementations in multiple languages EXT links per WP:EXT WP:ELNO. A couple of reference ones like Python and Java are useful, but bitbucket.org for Picolisp obviously isn't, in keeping with other articles and WP:CODE, where advised to use LiteratePrograms or Rosetta Code if needed to cover lots of implementations. Widefox; talk 11:29, 14 December 2018 (UTC)[reply]

Widefox. My concern is that this choice of which languages to leave and which to remove, is fairly arbitrary, and while it's probably dictated by your personal preferences, others' preferences may be quite different – so if you insist on trimming the list down (not sure why, but ok), I would suggest to retain more languages. cherkash (talk) 12:10, 14 December 2018 (UTC)[reply]

Ultimately any finite list will be arbitrary which also applies to 100, 10, or 1 items yes. But, instead of guessing about other editor's motivations, I suggest you check what languages are used for teaching, or other metrics such as TIOBE index [2] 1. Java 2. C 3. Python. There was no C link. Those two EXT links also are from reference implementations, rather than pastbin / bitbucket, so I hope you agree it's both considered in language and quality of source, and in keeping with other articles - random example Quicksort which has no (zero) code links in the EXT. Keep up the good work, regards Widefox; talk 12:21, 14 December 2018 (UTC)[reply]

Widefox: There actually was a C implementation. I've just added it back. cherkash (talk) 00:03, 18 December 2018 (UTC)[reply]

OK, I'm corrected. It's entirely possible I'd just thought C less educational and not remembered that. (Python replacing Java in graduate teaching is what I actually considered rather than TIOBE, and covered both). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto/hmac.c may be an alternative at half the code (caveat: kernel C). Not sure if you've noticed that the Java link is misleading - it's not to the implementation? Widefox; talk 01:48, 18 December 2018 (UTC)[reply]

Yes, my edit summary was just a couple of implementations. I was surprised that Rosetta Code didn't have code, no idea how much code is in Wikibooks per WP:CODE but https://en.wikibooks.org/wiki/Cryptography/Hashes doesn't. (the Python link like the Java isn't to the implementation, but to using the builtin, but I think it does link through to the implementation.) Widefox; talk 01:59, 18 December 2018 (UTC)[reply]

Cherkash How about an Implementations section like some others have, then they can be refs? Widefox; talk 15:50, 15 December 2018 (UTC)[reply]

I don't mind. Feel free to implement it that way if it makes sense to you. cherkash (talk) 00:03, 18 December 2018 (UTC)[reply]

Possible Typo

Possible typo in the section that says "For example, SHA-256 operates on 512-bit blocks. The size of the output of HMAC is the same as that of the underlying hash function (e.g., 256 and 512 bits in the case of SHA-256 and SHA3-512, respectively), although it can be truncated if desired." I think SHA-256 operates on 256-bit blocks, not 512, as the paragraph itself later implies. Metacosm (talk) 10:41, 21 March 2023 (UTC)[reply]

No, 512 bits is the correct block size for SHA-256. Yawkat (talk) 19:35, 28 March 2023 (UTC)[reply]

Quantum computing risks

A discussion as to the safety of HMAC encrypted data relative to future quantum computer attacks is needed.

HMAC security reduces to the security of the underlying hash function. If that hash function is vulnerable to quantum computer attacks, HMAC may be too. However most hash functions used in practice (such as the SHA family) are not particularly vulnerable. Yawkat (talk) 11:13, 7 September 2023 (UTC)[reply]