Editing HMAC (section)

==Design principles==
The design of the HMAC specification was motivated by the existence of attacks on more trivial mechanisms for combining a key with a hash function. For example, one might assume the same security that HMAC provides could be achieved with MAC = '''H'''(''key'' ∥ ''message''). However, this method suffers from a serious flaw: with most hash functions, it is easy to append data to the message without knowing the key and obtain another valid MAC ("[[Length extension attack|length-extension attack]]"). The alternative, appending the key using MAC = '''H'''(''message'' ∥ ''key''), suffers from the problem that an attacker who can find a collision in the (unkeyed) hash function has a collision in the MAC (as two messages m1 and m2 yielding the same hash will provide the same start condition to the hash function before the appended key is hashed, hence the final hash will be the same). Using MAC = '''H'''(''key'' ∥ ''message'' ∥ ''key'') is better, but various security papers have suggested vulnerabilities with this approach, even when two different keys are used.<ref name=BCK96>{{Cite web|url=https://cseweb.ucsd.edu/~mihir/papers/kmd5.pdf |title=Keying Hash Functions for Message Authentication |pages=1–15 |first1=Mihir |last1=Bellare |author-link1=Mihir Bellare |first2=Ran |last2=Canetti |first3=Hugo |last3=Krawczyk |year=1996 |citeseerx=10.1.1.134.8430 }}</ref><ref>{{Cite journal|title=MDx-MAC and Building Fast MACs from Hash Functions |year=1995 |first1=Bart |last1=Preneel |author-link1=Bart Preneel |first2=Paul C. |last2=van Oorschot |author-link2=Paul van Oorschot |citeseerx=10.1.1.34.3855 }}</ref><ref>{{Cite journal|title=On the Security of Two MAC Algorithms |year=1995 |first1=Bart |last1=Preneel |author-link1=Bart Preneel |first2=Paul C. |last2=van Oorschot |author-link2=Paul van Oorschot |citeseerx=10.1.1.42.8908 }}</ref>

No known extension attacks have been found against the current HMAC specification which is defined as '''H'''(''key'' ∥ '''H'''(''key'' ∥ ''message'')) because the outer application of the hash function masks the intermediate result of the internal hash. The values of ''ipad'' and ''opad'' are not critical to the security of the algorithm, but were defined in such a way to have a large [[Hamming distance]] from each other and so the inner and outer keys will have fewer bits in common. The security reduction of HMAC does require them to be different in at least one bit.{{citation needed|date=June 2015}}

The [[Keccak]] hash function, that was selected by [[NIST]] as the [[SHA-3]] competition winner, doesn't need this nested approach and can be used to generate a MAC by simply prepending the key to the message, as it is not susceptible to length-extension attacks.<ref>{{cite web
| url=https://keccak.team/keccak_strengths.html
| title=Keccak Team – Design and security
| quote=Unlike SHA-1 and SHA-2, Keccak does not have the length-extension weakness, hence does not need the HMAC nested construction. Instead, MAC computation can be performed by simply prepending the message with the key.
| author=Keccak team
| access-date=31 October 2019}}
</ref>