HMAC

HMAC⁡(K,m)=H⁡((K′⊕opad)∥H⁡((K′⊕ipad)∥m))K′={H⁡(K)if K is larger than block sizeKotherwise

where

K is the secret key.

⊕ denotes bitwise exclusive or (XOR).

blockSize) then key = hash(key) // Keys shorter than blockSize are padded to blockSize by padding with zeros on the right if (length(key) < blockSize) then return Pad(key, blockSize) // Pad key with zeros to make it blockSize bytes long return key

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"). 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.

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.

1. 1 2 3 Bellare, Mihir; Canetti, Ran; Krawczyk, Hugo (1996). "Keying Hash Functions for Message Authentication" (PDF). pp. 1–15.
2. 1 2 3 RFC 2104. Informational. Updated by "FIPS 180-2 with Change Notice 1" (PDF). csrc.nist.gov.
3. ↑ Preneel, Bart; van Oorschot, Paul C. (1995), On the Security of Two MAC Algorithms, CiteSeerX 10.1.1.42.8908{{citation}}: Cite uses deprecated parameter |citeseerx= (help)
4. ↑ H. Krawczyk; M. Bellare; R. Canetti (February 1997). HMAC: Keyed-Hashing for Message Authentication. IETF Network Working Group. doi:10.17487/RFC2104. Bellare, Mihir. "New Proofs for NMAC and HMAC: Security without Collision-Resistance" (PDF). Journal of Cryptology. Retrieved 15 December 2021. This paper proves that HMAC is a PRF under the sole assumption that the compression function is a PRF. This recovers a proof based guarantee since no known attacks compromise the pseudorandomness of the compression function, and it also helps explain the resistance-to-attack that HMAC has shown even when implemented with hash functions whose (weak) collision resistance is compromised.
5. 1 2 RFC 2104 and 1321.
6. ↑ "RFC 2104 Errata Held for Document Update · Erdem Memisyazici". www.rfc-editor.org. Retrieved 23 September 2016.
7. ↑ Eastlake, Donald; Hansen, Tony (May 2011). US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF). Internet Engineering Task Force. doi:10.17487/RFC6234. ISSN 2070-1721. RFC 3174