Talk:HMAC

message: "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)
replies: text: what is the correct key 120.28.219.213 (talk) 15:19, 12 June 2023 (UTC)

text: 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)
thread_title:  timing attacks ?! 

message: 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)
replies: text: 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)
thread_title:  added example usage for non-mathletes. 

message: 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)
thread_title:  Blocksize on pseudo code 

message: 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)
replies: text: 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)
thread_title:  Bug in pseudo code?? 

message: 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)
replies: text: Read the references in the article.  Knowing F(k||v) means you can compute F(k||v||u||...) trivially.  Nesting prevents this  (page 16, at the bottom).  mdf 13:44, 16 May 2006 (UTC)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Advantages over a pure hash 

message: 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)
thread_title:  Typical usage?! 

message: 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)
replies: text:  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)
replies: text:  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)
thread_title:  Padding 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Block Size 

message: 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)
thread_title:  Illustration 

message: 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)
replies: text: 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)
thread_title:  Problems displaying Unicode characters 

message: 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)
thread_title:  order of XOR in pseudo code 

message: 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)
replies: text: Nope, 'everything explained' looks like a wikipedia clone to me. 81.62.78.223 (talk) 08:20, 7 November 2011 (UTC)
thread_title:  Copy 

message: 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)
thread_title:  Image 

message: 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)
thread_title:  ipad and opad not important? 

message: 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)
thread_title:  "Hashed" redirect 

message: 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)
thread_title:  Replace Image 

message: Hello fellow Wikipedians,
I have just added archive links to  on Hash-based message authentication code. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive https://web.archive.org/20100604234324/http://citeseerx.ist.psu.edu:80/viewdoc/summary?doi=10.1.1.34.3855 to http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.3855
*Added archive https://web.archive.org/20090223134840/http://citeseerx.ist.psu.edu:80/viewdoc/summary?doi=10.1.1.42.8908 to http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.8908
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers. —cyberbot IITalk to my owner:Online 00:30, 16 October 2015 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: 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)
thread_title:  Pseudo code does not match functionality of definition 

message: 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)
replies: text: 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)
thread_title:  Please add check algorithm for clients receiving the message and HMAC 

message: 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)
thread_title:  Sha-1 is mentioned a lot, is it safe? 

message: 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)
replies: text: . 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)
replies: text: 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  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)
replies: text:  There actually was a C implementation. I've just added it back. cherkash (talk) 00:03, 18 December 2018 (UTC)
replies: text:  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)

text:  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)

text:  How about an Implementations section like some others have, then they can be refs? Widefox; talk 15:50, 15 December 2018 (UTC)
replies: text: 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)
thread_title:  External links 

message: Kitar la aplicasion 2806:103E:23:5AC0:E027:CF36:D618:4286 (talk) 06:45, 29 January 2023 (UTC)
replies: text: @ 177.239.39.199 (talk) 08:07, 26 April 2023 (UTC)
thread_title:  Kitar aplicasion 

message: 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)
replies: text: No, 512 bits is the correct block size for SHA-256. Yawkat (talk) 19:35, 28 March 2023 (UTC)
thread_title:  Possible Typo 

message: 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)
replies: text: Thanks. Countercheck (talk) 18:49, 5 December 2023 (UTC)
replies: text: Hlow 143.44.164.13 (talk) 00:17, 17 December 2023 (UTC)
thread_title:  Quantum computing risks