Transcript hash ($H(M_1\Vert \cdots \Vert M_n)$)

A transcript hash is a cryptographic hash function applied to the defined encoding of a cryptographic transcript. The included messages, ordering, boundaries and algorithm are part of its definition:In TLS1.3 the inputs include handshake type and length headers but exclude record-layer headers. A retry has an explicit synthetic-message substitution; ordinary payload concatenation is not that protocol's definition.^[ref]

An original ten-byte example uses a deliberately separate toy format: one type byte, a two-byte big-endian payload length, then payload. The first message is 01 00 02 48 69, carrying ASCII Hi; the second is 02 00 02 4f 4b, carrying OK. The SHA-256 digest of these ten bytes in that order is

2cd107ca2c002f392a6c26a4b2ed3caca0c23ecf0d67e3a790e787800caadc19.

Reversing the two encoded messages gives

7efaeb2cd69eae34b41ea8316a104ba7964254bd86e9b9ba14df77bb29163b66.

These are original computations, not TLS test vectors. Both message order and the encoded headers contribute to the input bytes.

Incremental hashing of a cryptographic transcript feeds those byte sequences into one continuing hash context and finalizes at the required point. It computes the same digest as hashing their full concatenation. Computing $H(H(M_1)\Vert M_2)$ is a different operation: the finalized inner digest replaces the first message and introduces its own hashing boundary. A running internal state is not interchangeable with a completed digest.

An unkeyed transcript hash alone does not authenticate who spoke. A digital signature or message authentication code binds it to the required authenticated context. Nor can a hash recover message boundaries omitted by an ambiguous encoder. TLS's Finished message illustrates the separate authentication step by applying HMAC to the specified transcript hash.^[ref]

Incremental hashing of a cryptographic transcript supplies successive encoded message bytes to one continuing cryptographic hash function state. Finalizing after the selected messages gives the same transcript hash as hashing their full concatenation in one call. TLS explicitly permits implementing the handshake computation using a running hash.^[ref]

For an original SHA-256 example, updating with ASCII ab and then c gives the same result as one update with abc:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.

A chunk boundary is an input-delivery detail. It does not insert a separator byte or end a message. A continuing implementation must preserve the processed bit count and any incomplete block as well as its chaining state; final padding encodes the complete input length. SHA-256's specification processes 512-bit blocks and pads the complete message before its final compression operations.^[ref]

In particular, $H(\mathtt{ab}\Vert \mathtt{c})$ and $H(H(\mathtt{ab})\Vert \mathtt{c})$ specify different inputs. The latter inserts a completed digest, with its already finalized hashing boundary, where the original bytes belonged. It is not an incremental implementation of the former.

The protocol must still define which bytes enter the state. TLS includes handshake headers in the transcript hash and specifies a special first-message substitution after a retry. A running hash implements that prescribed input, rather than defining the transcript by itself.^[ref] An unkeyed digest also supplies no sender authentication by itself; the protocol must bind it through its specified digital signature or message authentication code.