HMAC and dynamic truncation
02HMAC is a keyed message authentication code: it mixes the shared secret K with the eight-byte counter T. Dynamic truncation then selects four digest bytes and clears one bit to make a nonnegative 31-bit integer.
Mask the high bit of the first selected byte. c1 becomes41; 0x41397eea equals1094287082 in decimal.
Source for this drawing: RFC 6238 · Read RFC source: Appendix A ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
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
- HMAC
- A keyed computation with the secret as key and counter bytes as message.
- Dynamic truncation
- Choosing a four-byte slice using an offset derived from the digest itself.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The algorithm MUST use HOTP as its building block. The SHA-1 example uses the low four bits of the final digest byte as a zero-based offset; the selected four-byte value has its highest bit cleared.
- The algorithm MUST use HOTP as its building block. The SHA-1 example uses the low four bits of the final digest byte as a zero-based offset; the selected four-byte value has its highest bit cleared.
- For the public test secret ASCII 12345678901234567890 and T=1, the complete HMAC-SHA-1 digest is 75a48a19d4cbe100644e8ac1397eea747a2d33ab.
- The final byte is ab; ab AND 0f is 0b, decimal 11. Starting at byte 11 selects c1 39 7e ea. Byte offsets begin at zero.
- Clear the top bit: c1 AND 7f = 41. The resulting big-endian value 0x41397eea is 1094287082. This is still an intermediate integer, not yet the displayed OTP.
- The counter is the HMAC message; the secret is the HMAC key. Neither an unkeyed hash of time nor reversing key and message produces the specified construction.
RFC 6238 §1.2 invokes HOTP; RFC 4226 §§5.2–5.3 define its truncation. RFC 6238 Appendix A applies the same low-final-nibble offset rule to the permitted SHA-256 and SHA-512 variants. All shown keys are published test fixtures, unsafe for real accounts.
Read the RFC section ↗