# Help understanding NIST HMAC

The NIST (National institute of standards and technology) defines the HMAC standard as the following: $$\operatorname{MAC}(\text{text}) = \operatorname{HMAC}(K, \text{text}) = H((K_0 \oplus \text{opad} )|| H((K_0\oplus \text{ipad}) || \text{text}))$$ available in FIPS 198-1 (PDF).

I can see that the pre-shared key is XORed against internal padding and outer padding. I can also see that the results of which are not only hashed, but then concatenated together.

My question is how exactly is this used to ensure authentication/ integrity?

For example, If create a HMAC, how does my intended recipient use the HMAC sent with the message to ensure it is intact?

Also, given the inclusion of XORs, should I assume the inverse of these is calculated and somehow used in the process, as you can see I'm quite the novice, so some help would be very welcomed.

• Too late for an actual answer from me, but basically the recipient computes the HMAC over the received data himself again and checks if the received and the computed tags match up. – SEJPM Dec 5 '16 at 23:33
• I gathered that. But I rather wanted to know how, at a high level at any rate. Additionally I notice you edited my question, I'm grateful, as equally to your remark, it is late. All though, I copied the equation from the original source with regards to prettifying. – joemobaggins Dec 5 '16 at 23:36
• XOR is used here to flip about half the bits and create a large hamming distance between the keys. It is not used to make the operation reversible (that would not make sense in the first place, since the hash is not reversible). The construction is used to make it impossible that collisions in the hash result in loss of security and to make sure that length extension attacks are not possible. And yes, it is late here as well :) – Maarten Bodewes Dec 5 '16 at 23:59
• Hey thanks for the response. You're right, that was a stupid thought to have a reversible hash component of a hash. So, since the hash I assume is sent to the receiver, i.e. Bob. I assume they compute the same to check integrity. Is authentication confirmed by the receivers knowledge of the pre-shared key? Lastly, If we used AES with HMAC, would I need to compute this HMAC for every block of cipher text? Apologies for all the questions. – joemobaggins Dec 6 '16 at 0:25
• Yes, message authentication is confirmed because the MAC could only be calculated if the sender has the same key as the receiver. Beware of replay attacks and communication reversal attacks though. Yes, if you have a ciphertext you need to authenticate all of it, as well as the IV. But you're better off using authenticated encryption (GCM or EAX for instance). – Maarten Bodewes Dec 6 '16 at 0:42

XOR is used here to flip about half the bits and create a large Hamming distance between the two versions of the key. It is not used to make the operation reversible. Making the operation reversible would not make sense in the first place: the hash that is applied afterwards is a one-way function and therefore not reversible.

The HMAC construction is used to make it impossible that collisions in the hash result in loss of security and to make sure that length extension attacks are not possible.

Bonus answers for the questions in the comment:

Is authentication confirmed by the receivers knowledge of the pre-shared key?

Yes, message authentication is confirmed because the MAC can only be calculated if the sender has the same key as the receiver. Beware of replay attacks and communication reversal attacks though; these are not prevented by a MAC alone. In other words, you should uniquely be able to identify your messages and include that identification in the MAC for authentication.

If we used AES with HMAC, would I need to compute this HMAC for every block of cipher text?

Yes, if you have ciphertext you need to authenticate all of it as well as the IV/nonce. If you're not sure which parts of the ciphertext to authenticate then you're better off using authenticated encryption (GCM or EAX for instance).