Finish the outer hash and choose output length
04The outer keyed pad is followed by the raw inner digest, not by the original message or by digest characters.
The first two rows of byte cells are kept. The remaining16 bytes are discarded for this chosen shortened output; a preview ellipsis is not used as the actual tag.
Source for this drawing: RFC 2104 · Read RFC section 2 ↗
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.
Finish both hash passes before keeping the leftmost bits of the final tag.
- The outer pad opad is5c repeated B times. Use the same normalized K0 as in the inner pass. For this public example, K0 XOR opad is57 repeated 20 times followed by5c repeated 44 times. This is a different prefix from the inner keyed pad (§2 steps5–7).
- Append the32raw inner-digest bytes to the 64-byte outer keyed pad, producing96 input bytes for SHA-256. The original eight-byte message is not appended here, nor is the 64-character hex representation of the inner digest. Hash this96-byte sequence to obtain the full 32-byte tag.
- The complete main-example tag matches RFC 4231 §4.2. Both passes use the ordinary hash function. RFC 2104’s full construction is H((K0 XOR opad) || H((K0 XOR ipad) || message)); || means byte concatenation, not a comma byte in the message.
- An application can choose a truncated output consisting of the t LEFTMOST bits after the full HMAC computation. RFC 2104 §5 recommends t at least half the hash-output length and at least80 bits. For our256-bit hash, that recommendation means at least128 bits. It is a recommendation, not a new blanket MUST or a complete current protocol policy.
- The final state illustrates a chosen128-bit prefix of the main example: the first16of32 bytes, b0344c61d8db38535ca8afceaf0bf12b. This is separate from RFC 4231 §4.6’s published truncated Test Case5, which the regression also checks. Truncating the inner digest first, retaining the rightmost bytes, or confusing bits and bytes produces a different construction. If t is unspecified, RFC 2104 assumes the full output (§5).
Selected construction rules and public test data; not a cryptographic library, key exchange, authentication protocol or deployment certification.
Read the RFC section ↗