Talk:HMAC
From Wikipedia, the free encyclopedia
 |
On November 15, 2007, HMAC was linked from Wired News, a high-traffic website. All prior and subsequent edits to the article are noted in its revision history. |
|---|
 |
This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks. |
|
It is intended that this article be included in WikiReader Cryptography, a WikiReader on the topic of cryptography. Help and comments for improving this article would be especially welcome. A tool for coordinating the editing and review of these articles is the daily article box. |
 To-do list for HMAC: |
edit · history · watch · refresh |
|---|---|
|
|
Contents |
[edit] 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)
[edit] 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)
-
[edit] 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.
[edit] 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!
