Protect key material and apply later guidance
05The construction depends on secret key handling and the chosen hash. Its older examples are not present-day security recommendations.
The repeated bytes produce a valid MAC again. Only a separately labeled illustrative application freshness check stops the replay; HMAC itself has supplied no replay rule.
Source for this drawing: RFC 2104 · Read RFC section 6 ↗
New to this? Start hereA quick picture + helpful background
A seal answers a specific question.
A certificate or signature supports particular checks about a key or message. It does not automatically prove that every claim or sender is trustworthy.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
RFC 6151 updates MD5/HMAC-MD5 security considerations: new protocol designs should not include HMAC-MD5; HMAC-SHA256 is a listed alternative. This is not a blanket claim that all existing HMAC-MD5 uses are broken.
Read the updated RFC section ↗A MAC result alone does not establish freshness, confidentiality or a complete protocol.
- RFC 2104 §3 recommends a key at least L bytes long, discourages shorter keys and calls for random or cryptographically strong pseudorandom key generation and periodic refresh. It specifies no universal refresh interval. Secure key exchange and secrecy protection remain essential (§6). Published example keys are public test data, not deployment keys.
- An implementation can precompute intermediate compression states after the B-byte inner and outer keyed pads. These are states before final hash padding, not ordinary finalized hashes of the pad alone. Stored intermediate values need the same protection as secret keys; this optimization is optional and does not change interoperability (§4). The illustration treats states as opaque and does not implement this optimization.
- RFC 6151 formally updates RFC 2104’s security considerations. Its §§2,2.3 say new protocol designs should not include HMAC-MD5 and identify HMAC-SHA256 as an alternative. That update distinguishes MD5 collisions from HMAC forgery and does not say every existing HMAC-MD5 use is immediately broken. The blocked design path illustrates that stated guidance, not a failure of the MD5 computation.
- RFC 2104 does not introduce RFC 2119 keyword definitions; its recommendations are paraphrased at their stated strength. Do not manufacture uppercase MUST/SHOULD/MAY requirements for key length, refresh frequency or truncation. The original 1997 attack estimates and MD5/SHA-1 discussion are historical, not a current security certification (§§1,3,5–6; update RFC 6151).
- A repeated exact message and tag still pass the same MAC comparison if the key and parameters are unchanged. An illustrative freshness gate may then reject the repeated operation, but such a gate is supplied by a surrounding protocol, not by RFC 2104. No nonce/timestamp/replay format, authorization rule, password storage, secure key exchange or account system is implemented here.
Selected construction rules and public test data; not a cryptographic library, key exchange, authentication protocol or deployment certification.
Read the RFC section ↗