LESSON 27.3
Hash chains and tamper-evident logs
Chaining records by hash so history can't be quietly rewritten, Merkle-tree logs with inclusion and consistency proofs, certificate transparency, and where audit logs need these guarantees.
6 min read
Most logs can be edited by whoever runs the database. For audit trails, financial ledgers, software supply chains and certificates, that's not good enough: you want any change to history to be detectable, even by someone who doesn't trust the operator.
Hash chains
The simplest tamper-evident structure links each record to the one before it:
- Record n stores its data plus
prev = hash(record n-1). - Its own hash covers both, so it depends on all of history.
- Changing any old record changes its hash, breaking the link from the next record. Hiding that means rewriting every later record.
- Periodically anchor the latest hash somewhere the operator can't change: another organization, a public log, signed and timestamped receipts held by auditors.
The weakness of a plain chain is verification cost: proving that record 500 is in a chain of 10 million means checking the whole chain from that point on.
Merkle-tree logs
Building a Merkle tree over the log's entries keeps the tamper evidence and makes proofs short. The log's state is summarized by one root hash, signed by the log operator.
- Inclusion proof
- this entry is in the log with this root - checked by a client whose record was logged
- Consistency proof
- the newer tree contains the older one unchanged - checked by monitors
With both, a client can check a log it doesn't trust: its entry is there, and the operator hasn't rewritten history since the last root it saw.
Certificate transparency
The best-known deployment. Browsers require that TLS certificates appear in public certificate transparency logs, which are append-only Merkle logs. A certificate authority that issues a certificate for your domain, whether by mistake or under attack, can't hide it: monitors watch the logs and alert domain owners. Independent auditors fetch consistency proofs to ensure no log forks its history for different viewers.
The same design now protects software supply chains: Sigstore's Rekor logs signatures of build artifacts, so anyone can check a package was signed and logged.
When you need it
- Application logs for debugging
- no - ordinary storage
- Security audit trail for admin actions
- often - hash chain plus anchored head
- Ledger shared between organizations
- yes - signed roots and proofs
- Public trust (certificates, packages)
- yes - transparency logs with external monitors
Try it
Tamper-evident Audit Pipeline HLD
Design an audit trail whose history can't be quietly rewritten.