 Ideal cryptographic functionality

An ideal cryptographic functionality is an executable specification of a desired cryptographic service, represented as a trusted computation. Its interfaces specify inputs, outputs, state, permitted cryptographic leakage and permitted adversarial influence. In universal composability, honest-party forwarding interfaces connect it to the cryptographic environment, while the cryptographic simulator uses its adversarial interface.^[ref]

An ideal service is a way to state the security goal; it does not assert that the deployed system contains a physically trusted central machine. A cryptographic protocol realizes the service only if the relevant real/ideal comparison is proved.

For a concrete original specification, consider a single-message channel between two fixed, honest parties, with no party corruption in this toy model. Its state begins empty. On the designated sender's submission of $(\mathrm{sid},m)$, it stores the message under the session label $\mathrm{sid}$ and marks it pending. It reveals the session label, sender, recipient and byte length $|m|$ to the adversarial interface, but not $m$. A later delivery instruction naming that pending session makes it output the stored $m$ to the designated recipient and mark the session delivered. Further delivery instructions for that session have no effect; a second submission for the same session is rejected.

This state machine gives both message authentication and message confidentiality specific meanings. The adversarial interface has no instruction for replacing the stored message or impersonating the designated sender. It can delay delivery indefinitely. Thus the toy specification permits length disclosure and denial of delivery, while excluding content disclosure through that interface, message replacement and repeated delivery. These are separate choices, rather than consequences of the word “secure”. The primary tutorial similarly distinguishes authenticated communication, delayed delivery, corruption and message-hiding guarantees.^[ref]

For an example execution, the sender submits ASCII bytes 41 42 43 under a fresh session label. Before delivery, the simulator learns length three and the endpoints. On the first delivery instruction the recipient receives those three stored bytes. A second delivery instruction produces no new recipient output. If no delivery instruction arrives, the message remains pending. An observed recipient output 41 42 44 would violate this toy specification, regardless of whether it had the correct length.

Stating these transitions makes a proof obligation testable: an implementation must match the specified service's observable behavior against every allowed cryptographic environment. Changing the permitted cryptographic leakage, delivery rule or corruption behavior changes the service being implemented.