Read the binary coding header
02The encrypted body begins with a binary prefix: salt, record size, key-identifier length and key identifier. This prefix is inside the body, not an HTTP header field. An octet is an eight-bit byte.
For this 73-octet published body, the 23-octet header is followed by record 0 at offsets 23–47 and record 1 at 48–72. Header bytes do not count toward rs. Byte offsets are zero-based.
Source for this drawing: RFC 8188 · Read RFC section 2.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.
salt occupies 16 octets. rs is an unsigned 32-bit record size in network byte order; values below 18 are invalid.
- salt occupies 16 octets. rs is an unsigned 32-bit record size in network byte order; values below 18 are invalid.
- idlen occupies one octet and gives the following keyid length. keyid SHOULD be UTF-8, especially for textual display; it identifies keying material rather than carrying the secret key.
- The published two-record example has keyid a1, a 23-octet prefix and two 25-octet records. The final record may be shorter than rs.
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 ↗