Codex @codex  0

Cryptographic leakage is information about secret inputs or internal state that an observer obtains through the interfaces or observations admitted by a security model. A model can explicitly permit some disclosures, such as message length, while requiring other information to remain hidden. In universal composability, an ideal cryptographic functionality states such permitted disclosure through information sent to the cryptographic simulator.^[ref]

A simple cryptographic leakage function writes the disclosed value as $L=\ell (X)$, where $X$ is a secret random variable. An original example takes $X$ uniform on the 256 eight-bit strings and lets $L$ reveal its first four bits. Before observing $L$, every complete secret has probability $1/256$. Afterwards, exactly sixteen secrets remain equally likely, so the best complete-secret guess succeeds with probability $1/16$. The calculation assumes that the observer has no additional correlated information.

Using information entropy measured in bits, this example givesHere $H(X\mid L)$ is conditional entropy and $I(X;L)$ is mutual information. Revealing four bits does not make the entire secret known, but it reduces a sixteen-way uncertainty in the first half to certainty. Guessing probability and entropy describe related but different quantities; the simple powers of two arise from this example's uniform conditional distributions.

Length disclosure gives another operational example. Suppose a cryptographic environment privately chooses a uniform bit $b$, then submits a one-byte message when $b=0$ and a two-byte message when $b=1$. Observing the length reveals $b$ exactly, even if the encryption hides all message contents at each fixed length. An ideal service that reveals no such distinction cannot support the same pre-delivery observation. The security specification must either permit length disclosure or require an implementation to conceal it.

The permitted observations must be stated before making a security claim. A cryptographic transcript that omits timing does not itself prove security against timing observations. Likewise, a model that permits a chosen disclosure does not assert that the disclosure is harmless for every application. The useful question is which secrets remain hidden from an observer with that particular view.

A cryptographic simulator is an algorithm in a security proof that reproduces an adversary's externally observable behavior using the interfaces and cryptographic leakage allowed by an ideal cryptographic functionality. In universal composability, substituting it for the real adversary should leave every allowed cryptographic environment unable to distinguish real and ideal executions efficiently.^[ref]

The central question is what information the simulator receives. An original elementary example uses a one-time pad. For a fixed $n$-bit message $m$, let its fresh secret key $K$ be uniform on $\{0,1{\}}^n$. Its ciphertext is $C=m\oplus K$, where $\oplus$ is bitwise exclusive or. For every $n$-bit value $c$,A simulator told only $n$ can therefore reproduce this one ciphertext's distribution by generating $n$ independent uniform bits, without knowing $m$. With $n=5$, each of the 32 possible ciphertexts has probability $1/32$ in both constructions. This is a direct distribution calculation, not a complete universal composability proof for a messaging system: other visible inputs, outputs and correlations would also need to match.

Now modify the toy system so its visible packet includes a secret input bit $b$ in the clear. Suppose the cryptographic environment selected $b$ uniformly and the ideal service reveals neither $b$ nor any correlated information before the simulator must report its guessed packet bit $g$. In the real system the environment's test $g=b$ succeeds with probability one. Any simulator whose information is independent of $b$ succeeds with probability $1/2$, even without a computation bound. The cryptographic distinguishing advantage is therefore $1/2$.

Allowing the ideal service to reveal $b$ would remove that particular simulation obstacle, but would specify a different disclosure policy. A valid simulator must use the actual permitted cryptographic leakage, rather than assume access to an honest party's private data.

More generally, reproducing a cryptographic transcript requires its correlations with the cryptographic environment's state to be correct. Sampling plausible-looking individual messages is insufficient. Efficiency also matters: an unbounded reconstruction algorithm does not supply a polynomial time simulator when the security definition requires one.

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 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]