Visual RFC.
ALL RFCs / RFC 6238
Read the RFC ↗
RFC 6238 / TIME-BASED ONE-TIME PASSWORDS

Compare the three permitted HMAC variants

04

RFC 6238 permits HMAC-SHA-256 and HMAC-SHA-512 in addition to the HOTP HMAC-SHA-1 building block. The hash and secret must match the setup used by both endpoints.

DIAGRAMRead RFC source: Appendix B ↗
RFC 6238 · Appendix BEXAMPLE
3 / 3
Compare the three permitted HMAC variantsThree separate local computations use the same time 59, counter1, eight-byte message and eight-digit width, but distinct correct published key fixtures. SHA-1 with20 bytes gives94287082; SHA-256 with32 bytes gives46119246; SHA-512 with64 bytes gives90693936. The repeating ASCII1234567890 sequence is cut to the indicated fixture length, as corrected by verified erratum 2866. Arrows represent local computation, not algorithm negotiation or transformations between hash modes.Three permitted HMAC choicesSame time 59 · T = 1 · eight digitsPublic ASCII fixture: 64 bytesRepeat 1234567890, cut to 64 charactersHMAC-SHA-512 then truncation90693936Verified erratum 2866: use the matching keyMAY choose SHA-256 or SHA-512
03
Use the 64-byte fixture with SHA-512.

With the same counter and width and this mode’s64-byte key, the official result is90693936.

Source for this drawing: RFC 6238 · Read RFC source: Appendix B ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 5869 HKDF RFC 4648 Base encodings

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Hash variant
Which permitted SHA-based HMAC function the setup uses.
Test vector
A published input and expected output for checking an implementation.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 instead of HMAC-SHA-1. These choices are not an on-the-wire negotiation defined by this RFC.

  • Implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 instead of HMAC-SHA-1. These choices are not an on-the-wire negotiation defined by this RFC.
  • At time 59, T0=0, X=30 and eight digits, Appendix B expects SHA-1:94287082, SHA-256:46119246, SHA-512:90693936.
  • Verified erratum 2866 corrects Appendix B: these test modes use different ASCII keys, of lengths20,32 and64 bytes respectively. Reusing the 20-byte fixture for all modes does not reproduce the table.
  • The 32-byte fixture is the repeating ASCII 1234567890 sequence cut after32 characters; the 64-byte fixture is the same repeating sequence cut after64. These are exact public fixtures, not a suggested key-generation method.
  • For interoperability, keys SHOULD have the length of the HMAC output (§5.1). Real keys SHOULD be randomly generated or derived using key-derivation algorithms; a different hash name alone does not protect a leaked key.
DETAILS

The drawings compare three local computations with counter 1; arrows show data flow, not a handshake between algorithms. Appendix A already uses the correct different key lengths. Verified erratum 4678 corrects JavaDoc, not the algorithm. Other merely reported errata are not adopted as requirements. The regression checks all 18 Appendix B values, including Unix time 20000000000.

Read the RFC section ↗

All chapters in RFC 6238

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗