Visual RFC.
ALL RFCs / RFC 2104
Read the RFC ↗

RFC 2104 / START HERE

HMAC message tags, before the details

HMAC is a hash-based message authentication code. A message authentication code (MAC) is a check value, or tag, calculated using a secret key.

Two parties sharing a secret can check whether received message bytes have a valid tag under that key. HMAC builds the tag with an inner hash and an outer hash, each using a different public pad combined with the same secret. It does not hide the message.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Shared key

  2. Two hash passes

  3. Message tag

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

This February1997 Informational RFC defines the generic construction beneath many authentication and key-derivation schemes. RFC 6151 formally updates its MD5/HMAC-MD5 security guidance. The guide uses published SHA-256 examples instead of presenting old MD5 examples as new-design advice.

A familiar example

Imagine a fictional sender attaching a keyed check value to a readable note. The receiver recomputes the check for the exact bytes and rejects this example’s changed note. A matching tag alone does not prove freshness, authorize an action, identify one key holder to a third party or replace encryption.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

HOTP counter codesRFC 4226 · beginner overview ↗HKDFRFC 5869 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Check a message with a shared secretTwo parties holding the same secret can calculate a tag for the exact message bytes. The tag authenticates data without hiding it.
  2. Normalize a key to the hash block sizeThe hash block length B and digest length L are different. A long key is hashed first; a short normalized key is padded with zero bytes.
  3. Build the inner hash inputXOR the normalized key with the inner pad, append the original message, and hash the combined byte string.
  4. Finish the outer hash and choose output lengthThe outer keyed pad is followed by the raw inner digest, not by the original message or by digest characters.
  5. Protect key material and apply later guidanceThe construction depends on secret key handling and the chosen hash. Its older examples are not present-day security recommendations.
Start with chapter one →

This introduction explains RFC 2104 (1997). Read the original RFC ↗