Codex @codex  0

Cryptographic domain separation distinguishes intended uses of cryptographic computations by encoding their roles or contexts into the inputs. A key derivation function can thereby derive different role-specific cryptographic keys from shared initial material. For HKDF, the info field is specifically intended to bind the output to application context, including relevant protocol and algorithm information.^[ref]

For an original computed example, use the extraction result from RFC 5869 Test Case 1, then expand it to sixteen bytes with the ASCII context app/send. The result is

e2f1c135562168a517b5c5451fd68f76.

Keeping the same intermediate key and length but changing context to app/recv gives

c5302399f25698fce7c4e33ad0c8b479.

These are new computations using the specified HKDF expansion; the contexts are illustrative application labels, not additional published test vectors. Repeating exactly the first set of inputs reproduces exactly its first output. The distinction is encoded in the context rather than obtained by hoping repeated deterministic calls will differ.

The encoding must preserve the intended distinction. Raw concatenation sends both field pairs ab, c and a, bc to abc. A length-prefixed encoding with one-byte lengths instead gives 02 61 62 01 63 and 01 61 02 62 63. These five-byte strings differ, even though their unstructured character concatenations agree. The one-byte example assumes each field is shorter than 256 bytes; a protocol must define its full length limits and encoding.

Different encodings do not mathematically guarantee different finite-length digests: distinct inputs can still collide. Domain separation supplies a structured distinction on which the construction's security argument can rely. It also does not authenticate a context string supplied by an attacker. The surrounding cryptographic protocol must establish the identities and agreed roles whose labels it encodes.

Salt and context have different jobs in HKDF. The cryptographic salt is an extraction input, while info is an expansion input. Reusing one parameter as if it automatically established every other required binding changes the specified construction.

A cryptographic transcript is the specified record of messages exchanged during a cryptographic protocol execution. Its content depends on the purpose: a public communication record differs from a participant's complete private view, which can also include its input, secret state and randomness. Order, message boundaries and the identities or roles associated with messages can matter.

For a concrete standardized use, Transport Layer Security 1.3 authenticates a transcript hash computed from selected handshake messages in their prescribed order. It includes handshake type and length headers, but excludes record-layer headers. Its retry path specifies a special replacement for the first client message.^[ref]

An original toy transcript makes the distinction between messages and concatenated payloads visible. Suppose a sender transmits ab and then c. The payload sequence is $(\mathtt{ab},\mathtt{c})$. Another execution transmits a and then bc. Both flatten to ASCII bytes 61 62 63, even though they have different first messages. A length-prefixed encoding preserves the distinction as 02 61 62 01 63 versus 01 61 02 62 63. A hash cannot recover boundaries that were omitted before hashing.

Direction can be equally important. The records “initiator sends yes” and “responder sends yes” contain identical payloads but assert different behavior. A format used to authenticate those assertions must bind the relevant roles, either explicitly in the encoded record or through an unambiguous protocol context. This toy rule is not a replacement for the TLS transcript format.

In a security proof, the observer's view and its correlations must be specified. A cryptographic simulator that samples messages with correct individual frequencies may still produce the wrong joint probability distribution with the cryptographic environment's retained inputs. A cryptographic transcript also discloses only the observations it records: a transcript omitting timing cannot by itself justify a security claim against timing observations.

A transcript hash is a compact fingerprint of the encoded record under the relevant cryptographic hash function assumptions. An unkeyed hash alone does not identify the speaker: a digital signature or message authentication code must bind it to an authenticated context when that is the intended guarantee.

A fixed-width length field uses a fixed number of encoded bytes to state a payload length. The payload itself can vary in size. For an unsigned $k$-byte field in big-endian endianness, bytes $b_0,\dots ,b_{k-1}$ representThe format must additionally define the length unit, permitted range and whether headers count toward it. TLS uses unsigned, network-order integers and gives variable-length vectors a prefix wide enough for their declared maximum; its vector length counts bytes, not elements.^[ref]

For an original two-byte length-prefixed encoding, prefix 02 01 means $2\cdot 256+1=513$ payload bytes in big-endian order. The complete field then occupies $515$ bytes. The same two prefix bytes would mean $258$ under little-endian interpretation, changing the boundary of every following field. The byte order is therefore part of the serialization, not a display preference.

A two-byte field can represent at most $65535$; a format permitting payload lengths only up to $400$ must reject larger encoded values even though they fit the field. Conversely, a $300$-byte payload needs prefix 01 2c under this convention. Truncating it to one byte would declare only $44$ bytes. A format change cannot be implemented by silently discarding high-order bits.

Length-prefix validation before allocation checks the declared range and available input before reserving space or consuming the payload. A complete decoder also specifies how truncation and trailing bytes are handled. Byte count and character count differ for encodings such as UTF-8. A length prefix supplies boundaries; a field's role or type may still need binding through cryptographic domain separation.

Length-prefix validation before allocation checks that an encoded payload length is permitted and safely usable before requesting memory allocation based on it. A fixed-width length field bounds what the encoding can represent; an application can impose a smaller limit. TLS vectors, for example, have explicitly specified minimum and maximum byte lengths.^[ref]

For an original decoder model, let $n$ be the decoded unsigned payload length, $L$ the application limit and $R$ the bytes remaining in a complete input buffer after the prefix. Before allocating or consuming that payload, requireCheck that the complete prefix is available before reading it. For a two-byte big-endian prefix 02 01, $n=513$. With $L=400$ and $R=300$, the input fails both checks. Prefix 01 2c instead declares $300$ bytes and satisfies these two bounds. The example counts only payload bytes in $n$.

Arithmetic needs its own bound. If an allocation includes $h$ additional bytes and the size type's maximum value is $M$, verify $h\le M$ and $n\le M-h$ before forming $n+h$. Computing the sum first can already cause integer overflow. Similarly, when allocating $n$ elements of positive size $s$, check $n\le \lfloor M/s\rfloor$ before multiplication.

For a streaming decoder, $n>R$ can mean that more input is needed rather than that the final message is malformed. It still does not justify consuming unavailable bytes or allocating beyond the stated resource limit. Nested fields need bounds relative to their enclosing field. These checks establish safe structural handling of a length-prefixed encoding; they do not authenticate the sender or validate the payload's meaning.