Visual RFC.
ALL RFCs / RFC 5869
Read the RFC ↗
RFC 5869 / HKDF KEY DERIVATION

Reproduce the official SHA-256 vector

05

A public test vector lets you check exact input roles, encoding, intermediate key and final output without using real secrets.

DIAGRAMRead RFC source: Appendix A.1 ↗
RFC 5869 · Appendix A.1EXAMPLE
3 / 3
Reproduce the official SHA-256 vectorPublic RFC5869 Appendix A1 test values are decoded as bytes, not ASCII hex. The displayed full PRK is 32 octets. The complete OKM is 42 octets, displayed in three hex rows of 16, 16 and ten octets. The underlying independent HMAC/vector regression verifies all bytes; these values must never be reused as production keys.Official SHA-256 test case 1Public test data only · not production keysOKM = HKDF-Expand(PRK, info, 42)expand and truncate3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865Full OKM: 42 octetsT(1) 32 bytes + T(2) first 10 bytesHexadecimal is representation; HMAC consumes the bytes
03
Compare all 42 output bytes.

Expand must reproduce the complete published OKM. Two blocks are computed, and the last is truncated to supply ten bytes.

Source for this drawing: RFC 5869 · Read RFC source: Appendix A.1 ↗

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 8446 TLS 1.3 RFC 4648 Base encodings

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

Terms in this drawing
Test vector
Published inputs and expected outputs for checking an implementation.
Hexadecimal
A representation where each pair of hexadecimal digits represents one byte.
Related RFCs and changes

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

KEY POINT

RFC 5869 Appendix A.1 chooses SHA-256, IKM as 22 repetitions of byte 0b, salt 000102030405060708090a0b0c, info f0f1f2f3f4f5f6f7f8f9 and L=42.

  • RFC 5869 Appendix A.1 chooses SHA-256, IKM as 22 repetitions of byte 0b, salt 000102030405060708090a0b0c, info f0f1f2f3f4f5f6f7f8f9 and L=42.
  • Extract yields PRK 077709362c2e32df0ddc3f0dc47bba63 90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets).
  • Expand yields OKM 3cb25f25faacd57a90434f64d0362f2a 2d2d0a90cf1a5a4c5db02d56ecc4c5bf 34007208d5b887185865 (42 octets).
  • These displayed values are hexadecimal representations of bytes; spaces between groups are for display, not additional bytes. Hash the decoded bytes; do not HMAC the printed hex characters.
DETAILS

All values are the RFC’s public test inputs/outputs. They are not example production keys to reuse. The appendix also includes SHA-1 vectors; showing this SHA-256 example is not a policy recommendation to deploy every historical algorithm. No key-generation or credential-entry feature is added to the site.

Read the RFC section ↗

All chapters in RFC 5869

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 ↗