Chain expansion blocks with a byte counter
03Expand repeatedly applies HMAC with the same PRK key, the previous block, the context info and a one-octet counter.
The third HMAC message uses T(2), info and byte 03. The output stream begins T(1) | T(2) | T(3); length selection is a separate final operation.
Source for this drawing: RFC 5869 · Read RFC section 2.3 ↗
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
- T(i)
- The ith HashLen-octet expansion block.
- Concatenation
- Joining byte strings in order.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
T(0) is the empty string. T(1) = HMAC-Hash(PRK, info | 0x01); the omitted T(0) contributes zero bytes.
- T(0) is the empty string. T(1) = HMAC-Hash(PRK, info | 0x01); the omitted T(0) contributes zero bytes.
- T(2) = HMAC-Hash(PRK, T(1) | info | 0x02). Further blocks use the immediately previous block, the same info and the next counter octet.
- The vertical bar denotes byte concatenation, not an OR operation. The counter is one binary octet, not a decimal string, ASCII digit or four-byte integer.
- N = ceil(L / HashLen) blocks are concatenated; take the first L octets. The output limit 255 × HashLen prevents wrapping the one-octet counter past 0xff.
This schematic SHA-256 example requests L=82 octets, so N=3. Every block is 32 octets and every HMAC call is keyed with the same PRK. info can be empty. Reported editorial erratum 5161 remains unverified; no counter wrap or modulo-extension algorithm is adopted. The published equations and 255-block bound already determine the counters used here.
Read the RFC section ↗