Transparency Log

A transparency log is structured as a Merkle Tree, where each new entry is cryptographically hashed and linked to all previous entries. Once data is recorded, it cannot be altered or deleted without detection. Any attempt to modify a historical record would invalidate the root hash, immediately signaling tampering to auditors. This property ensures that the log provides a tamper-evident historical record, making it impossible for a compromised Certificate Authority to silently issue a rogue certificate without leaving permanent forensic evidence.

Transparency logs generate compact Merkle audit proofs that mathematically verify a specific entry exists within the log without requiring the entire log to be downloaded. A client can present a small set of intermediate hashes that, when combined with the entry, recompute the trusted Signed Tree Head (STH). This enables lightweight clients and browsers to efficiently verify that a certificate or software artifact was publicly logged, preventing split-view attacks where a malicious server shows different log contents to different observers.

To prevent a log server from presenting divergent views to different monitors, transparency logs rely on gossip protocols for STH exchange. Independent auditors and monitors continuously share the latest Signed Tree Heads they have observed. If a log operator attempts an equivocation attack—presenting one STH to a victim and a different STH to the public—the conflicting STHs are detected and exposed. This peer-to-peer consistency mechanism ensures all observers eventually converge on a single, canonical log state.

Transparency logs are designed for continuous public scrutiny. Dedicated monitors watch the log in real-time for certificates or artifacts that match specific domain names or organizational identities. Any unexpected issuance triggers immediate alerts. This shifts the security model from reactive revocation checking—such as OCSP and CRLs—to proactive detection. The log itself becomes a permanent, publicly accessible audit trail that any party can independently verify without trusting the log operator.

The Signed Tree Head is the root of trust for a transparency log. It contains:

• The root hash of the Merkle Tree at a specific point in time
• The tree size (total number of entries)
• A timestamp
• A digital signature from the log operator

Clients and auditors cache trusted STHs and use them to verify inclusion proofs. The signature ensures non-repudiation—the log operator cannot later deny having issued a specific STH that committed to a particular tree state.

A Signed Certificate Timestamp (SCT) is a promise from the log to include a certificate within a bounded time period, known as the Maximum Merge Delay (MMD). The SCT is cryptographically signed by the log and embedded directly into the certificate or delivered during the TLS handshake. Browsers require valid SCTs to trust a certificate, ensuring that even if a CA is compromised, the fraudulent certificate must be publicly logged—exposing the breach to domain owners who monitor the log.

The core data structure powering the cryptographic integrity of a transparency log. A Merkle tree is a tree where every leaf node is labelled with the cryptographic hash of a data block, and every non-leaf node is labelled with the hash of its child nodes. This structure enables efficient and secure verification of the contents of large data sets.

• Efficiency: Allows inclusion proofs (proving a record exists) without downloading the entire log.
• Consistency: Enables consistency proofs (proving a later log version is an extension of an earlier one).

An application of the transparency log model to the software supply chain. Binary transparency requires that all released software binaries are logged to a public, append-only ledger. This allows users to verify that a downloaded binary is the exact same one that was publicly logged and that it hasn't been tampered with by a compromised build server.

• Goal: Mitigate supply chain attacks.
• Verification: Users check the log for a cryptographic inclusion proof before execution.

A method for publicly auditing the binding between a user account and a public cryptographic key. It uses a transparency log to create a public, auditable record of all key changes. This allows messaging applications to detect man-in-the-middle attacks where an attacker surreptitiously adds a malicious key to a user's account.

• Use Case: End-to-end encrypted messaging.
• Detection: Users or automated monitors can verify that their view of a contact's keys is consistent with the public log.

A peer-to-peer communication mechanism often used to distribute and verify transparency log states. In a gossip protocol, nodes periodically exchange information about the log state they have seen. This ensures that even if a log server attempts to show a split-view (different data to different users), the inconsistency will be rapidly detected and propagated through the network.

• Function: Ensures eventual consistency and censorship resistance.
• Application: Used by Certificate Transparency monitors to cross-reference log states.