Summary

  • RFC 2104 wrapped an existing iterative hash in two keyed passes, using fixed inner and outer pads, so implementations could reuse fast hash code without modifying its compression function.
  • The document made the hash replaceable and the output optionally truncatable, but required protocols to specify the algorithm, key handling and tag length that gave a value meaning.
  • A matching HMAC is evidence about exact bytes under a shared key and a named algorithm. It does not by itself prove a unique sender, authorization, freshness, canonicalization, confidentiality, delivery or correct deployment.

In 1997, the important engineering object was not a new block cipher or a new wire packet. It was a wrapper. Cryptographic hash functions were already fast, portable and widely implemented. Protocols wanted keyed integrity, but the apparently simple act of putting a secret before or after a message had awkward security properties. RFC 2104 turned prior cryptographic analysis into a small common construction that software could reuse.

That modest interface became HMAC. Its historical strength was also its evidentiary limit: it answered a precise question about a key, an algorithm and a byte string. Everything a system might wish to infer after that answer remained somebody else’s responsibility.

The two pads created separation without replacing the hash

RFC 2104 denotes the hash function by H, its input-block size by B and its output length by L. A key longer than B is first hashed; a shorter key is padded with zeroes to B bytes. Two fixed B-byte strings then separate the two passes: ipad repeats byte 0x36, while opad repeats 0x5c.

The construction is H((K xor opad) || H((K xor ipad) || text)). The inner pass combines one key-derived block with the message. The outer pass combines a different key-derived block with the inner digest. Existing hash code can execute both passes unchanged. The document’s goals were explicit: retain available implementations and their performance, keep key handling simple, support analysis, and make the underlying hash easy to replace.

This was an unusually thin common layer. It did not prescribe what a message meant, how it was serialized, who was allowed to send it or what a receiver should do. It prescribed how both sides would compute the same authentication value once those adjacent choices had already been made.

Reuse included an operational secret

RFC 2104 noted that implementations could precompute the hash states reached after processing the inner and outer key blocks. For short messages, avoiding those two repeated compression steps could matter. The optimization was local and did not change interoperability.

But the cached states inherited the key’s sensitivity. The RFC says they must be protected like secret keys. That sentence prevents a common category error: a derived performance artifact is not harmless simply because it is not the original key file. A deployment that protects K but exposes reusable keyed states has preserved the formula and lost its security boundary.

Keys themselves were also outside the formula’s automatic protection. RFC 2104 called for random or cryptographically pseudorandom selection, secrecy and periodic refresh. It identified correct implementation and secure key exchange as essential ingredients. The nested construction could standardize a computation; it could not manufacture entropy, custody or rotation.

A tag has meaning only with its context

HMAC applications may truncate the result to the leftmost t bits. RFC 2104 supplied contemporary guidance, while leaving the application to choose t. That choice affects the work needed to guess a valid tag and belongs to the protocol definition. A 96-bit tag and a full-length tag can both be HMAC outputs, yet they are not interchangeable evidence.

The same applies to the hash algorithm, the key identity and the exact bytes. A verifier needs all four: algorithm, key, message representation and tag rule. “HMAC verified” without them is an incomplete receipt.

Exact bytes deserve emphasis. HMAC does not know whether two JSON objects, header sets or Unicode strings express the same idea. If a sender authenticates one serialization and a receiver reconstructs another, the tags differ. If both sides consistently authenticate an unintended representation, the tags match while the semantic mistake survives. Canonicalization is an adjacent protocol, not a property supplied by the MAC.

Test vectors made the interface executable

Seven months later, RFC 2202 published HMAC-MD5 and HMAC-SHA-1 test cases for conformance. Known keys and messages leading to known outputs gave implementers a shared checkpoint. That is how a textual construction became executable common practice: independent code could demonstrate agreement at the byte boundary.

The receipt remained bounded. Passing test vectors says those cases produced the expected values. It does not prove that every input length works, that comparison is side-channel resistant, that production selects the right key, that replay state exists, or that an authenticated request is authorized. Interoperability evidence is valuable precisely when it is not inflated into a proof of the surrounding system.

Replaceability was designed in, migration was not automatic

RFC 2104 named MD5 and SHA-1 as contemporary examples but made H generic. Its authors anticipated that faster or safer hashes would be required. Later history validated the interface. RFC 4868 defined HMAC with SHA-256, SHA-384 and SHA-512 for IPsec. RFC 6151 updated the MD5 assessment and advised new protocol designs not to use HMAC-MD5.

That does not mean algorithm agility happened by itself. Identifiers, negotiations, implementations, policy, test coverage and key lifecycles still had to move. HMAC reduced the amount of conceptual machinery that needed replacement; it did not remove the organizational work of replacing it.

NIST’s later FIPS 198-1 illustrates the construction’s institutional reach. The persistence of the interface should not be confused with permanence of every instantiation. A stable composition can outlive the hash choices that first made it familiar.

The matching tag was one receipt in a longer decision

With a shared symmetric key, every legitimate key holder can generate a matching tag. The tag therefore does not uniquely name a person, process or host among those holders. It is not a digital signature and does not supply non-repudiation.

Nor is a valid old tag made fresh by being valid. Replay resistance requires a nonce, counter, timestamp window or other state, plus rules for resets and duplicates. Authorization requires a mapping from an authenticated context to a permitted action. Confidentiality requires encryption. Delivery and committed business effect require downstream receipts. Correctness requires review, tests and secure operation beyond the known-answer cases.

The durable legacy of RFC 2104 is not that one hexadecimal value settled all those questions. It is that the Internet received a narrow, reusable component whose boundary could be stated clearly. Two hash passes made a dependable MAC interface. Trust still had to be assembled around it.

Sources