Reproduce the published examples
05The RFC provides complete binary examples, shown using Base64url for presentation. Decoding and checking them makes byte counts and record framing concrete.
Section 3.2 uses keyid a1, rs=25 and a 73-byte body: 23 header bytes plus two 25-byte records. Data is split 7 + 8; the first plaintext ends 01 00 and the final ends 02.
Source for this drawing: RFC 8188 · Read RFC section 3.1 ↗
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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
On the wire these bodies contain binary octets, not the printed Base64url text. Section 3.1 uses an empty keyid and rs=4096.
- On the wire these bodies contain binary octets, not the printed Base64url text. Section 3.1 uses an empty keyid and rs=4096.
- The first published body decodes to 53 octets: header 21 plus encrypted record 32. Its data is the 15-byte text I am the walrus, followed by delimiter 02 before encryption.
- The source prints 54; held-for-update erratum 5516 notes the length error. That is not a verified erratum. Rejected 8620/8621 alternatives are not adopted: the existing examples do contain final delimiters.
Published test keys are examples, not secrets to use. This guide does not implement key management or a production cryptographic library.
Read the RFC section ↗