= Cryptographic transcript
A \b[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.<The Transport Layer Security Protocol Version 1.3 (RFC 8446)>[§4.4.1, transcript hash and HelloRetryRequest exception; §4.4.4, Finished authentication]{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.
Back to article page
