Transparency Log

Once an entry is recorded in a transparency log, it can never be deleted, altered, or reordered. This property is enforced cryptographically rather than through policy. Each new entry is hashed and linked to the hash of the previous entry, forming a hash chain. Any attempt to modify a historical record would change its hash, breaking the chain and making the tampering immediately detectable by any auditor.

• Mechanism: Sequential cryptographic hashing (SHA-256)
• Guarantee: Non-repudiation of historical state
• Contrast: Unlike a traditional database, there is no administrative 'delete' function

A transparency log uses Merkle trees to enable efficient, compact proofs of inclusion. A Merkle tree hashes pairs of leaf entries together recursively until a single root hash is produced. To prove a specific entry exists in the log, a monitor only needs a logarithmic number of intermediate hashes (a Merkle audit path) rather than the entire log. This allows lightweight clients to verify inclusion without downloading terabytes of data.

• Inclusion Proof: Proves an entry is in the log
• Consistency Proof: Proves a newer tree extends an older one without mutation
• Efficiency: O(log n) proof size relative to log entries

The entire log is publicly accessible, allowing any third party to act as an auditor or monitor. Monitors continuously watch the log for two critical properties: that the log operator is not presenting a split view (a fork) to different observers, and that entries relevant to the monitor's domain (e.g., certificates for their domain) are logged correctly. This removes the need to trust the log operator; trust is derived from the mathematics of the log structure itself.

• Gossip Protocols: Monitors share their observed root hashes to detect forks
• Self-Auditing: Domain owners can verify their own certificates are publicly logged
• Trust Model: Trustless verification, not trusted third party

Each entry in a transparency log is accompanied by a Signed Certificate Timestamp (SCT) or equivalent cryptographic promise. This is a signature from the log operator confirming the entry was accepted at a specific point in time. The SCT serves as a receipt that can be presented to third parties (like browsers) as proof of logging. The timestamp is anchored to the log's chronological structure, providing a verifiable ordering of events.

• Format: A digital signature over the entry and its timestamp
• Function: Acts as a promise of future inclusion in the log
• Verification: Can be validated without querying the log directly

The primary defense against a malicious log operator presenting different views to different users is a gossip protocol. Monitors exchange their observed signed tree heads (the root hash of the Merkle tree) with each other. If any two monitors see different root hashes for the same tree size, a fork is detected. This makes it computationally infeasible for the log to serve inconsistent data without global detection, enforcing global consistency.

• Mechanism: Peer-to-peer exchange of signed tree heads
• Detection: Any inconsistency is immediately provable as cryptographic fraud
• Outcome: Enforces a single, global view of the log's state

A transparency log can be designed to reveal only the metadata necessary for verification, not the underlying sensitive data. Using Merkle trees, the log can commit to the hash of an entry without revealing the entry's contents. A subject can later prove inclusion of their data by revealing only the specific entry and its audit path, keeping all other entries in the log private. This supports privacy-preserving use cases like certificate transparency without exposing all issued certificates.

• Commitment: Hash of data is public; raw data is not
• Selective Reveal: Only the prover's own entry is disclosed during verification
• Application: Certificate Transparency, supply chain provenance

A process that cryptographically proves that a specific piece of data existed at a particular point in time, issued by a trusted third party or anchored to a distributed ledger. A transparency log inherently provides a verifiable ordering of events, functioning as a high-integrity timestamping service. By including a hash of a document in a log entry, a user can later prove the document existed before that entry was sequenced.