---
title: "Glossary: Tamper-evident"
canonical_url: "https://tokenobserve.com/glossary/tamper-evident"
published: 2026-09-02
last_updated: 2026-10-21
---

# Glossary: Tamper-evident

Tamper-evident describes a record whose alteration can be detected afterwards by whoever checks it. Tamper-proof would describe a record that cannot be altered at all — a property no scheme delivers over storage the alterer administers — so a claim of tamper-evidence means something only when it names the attacker it holds against and the check that would reveal the change.

## Also called

- tamper evident
- tamper-proof
- tamperproof
- tamper-resistant

## In practice

The two words differ in who acts and when. Prevention stops the change; evidence catches it afterwards, and only if somebody looks, and only if they have something to look against. Almost nothing in software is tamper-proof, because the storage is administered by somebody, and that somebody can write to it. A vendor using the word about a database their own product also writes to has either not thought about it or is hoping you will not. The useful form of the claim is conditional and specific: this alteration, by this actor, would be detected by this check.

For a plain hash chain the conditional is exact. It detects every alteration that does not also recompute every downstream digest. That covers a great deal of what happens to a database — accidental corruption, a restore that lost its tail, a migration that rewrote a column, an injection that reaches one row, an operator who edits the row they care about and does not know the rows are linked. It does not cover the party who can write every row, and that party is in the threat model by definition whenever the reason for the log is to hold administrators to account. This is why a verification result that reports only valid is under-informative: on an unkeyed chain, valid means nothing was altered without recomputing, which is a materially weaker statement than nothing was altered, and the result should say which of the two it is entitled to.

Each further mechanism moves the target somewhere specific rather than removing it. Keying the digests, so that entries are authenticated under a key held outside the store, moves it from whoever can write the database to whoever holds the key, and holds only if the key comes from a secret manager the database administrator cannot read. Sealing the head with a keyed checkpoint extends that backwards over history written before the key existed, at the level of the head rather than the individual row. Signing a statement of the head and publishing it off the box moves it again, to whoever holds the signing key and can also reach every copy you took. Write-once storage or object lock is a real complementary control at the infrastructure layer, and it proves nothing cryptographically and cannot be checked offline. None of these steps reaches tamper-proof, and they are best presented as a ladder with the residual named at each rung.

Three things stay invisible to any in-store scheme, and they are the ones to plan around. Truncation where nothing is written afterwards leaves every surviving link intact. An attacker willing to edit the sequence counter as well can hide a deletion that would otherwise leave a hole. And host compromise — reading the key out of the process environment or the key store — signs or authenticates anything the attacker likes. The first two are answered outside the store, by a head sequence and digest recorded elsewhere before the event, or by an off-box signed anchor. The third is not answered at all, and should be stated as out of scope rather than argued away.

The word also fails people through tooling. A missing key and an altered entry produce the same bytes: the digests do not match. One of those is a configuration mistake an operator made five minutes ago; the other is an accusation of tampering. A verification result that reports the second when the first is the likelier explanation makes the product accuse its own operators of the exact act it exists to detect, over a dropped environment variable. So where a failure occurs at or after a sequence that a keyed checkpoint seals, and this process holds no key, the result should say the key is suspected missing and label that a diagnosis rather than proof.

## Example: The test that belongs beside the claim

Take a working install, alter one audit entry’s detail field, then walk forward re-hashing every subsequent entry with the same algorithm the writer used. On an unkeyed chain, verification reports valid. That is the boundary of the claim, so write it down as a test: the forgery passes on a default install and fails once an audit key is configured. Two things follow. The limit becomes a tested fact rather than a caveat in prose, so it cannot drift as the code changes. And the sales claim and the engineering claim are forced to be the same sentence, which is the only reliable way of keeping the word tamper-proof out of the room.

## Routinely confused with

Tamper-proof: Tamper-proof asserts that alteration is impossible. Tamper-evident asserts that alteration is detectable by a stated check, against a stated attacker. The first is essentially never true of a record held on storage somebody administers; the second is achievable and is what hash chaining, keyed digests and signed anchors deliver in increasing measure.

Tamper-resistant: Resistance raises the cost of making the change — write-once media, object lock, a hardware security module — and makes no promise that a change you did manage would be visible afterwards. Evidence and resistance are worth having together, and neither substitutes for the other: resistance without evidence gives you no verdict, evidence without resistance gives you no delay.

Immutable: Immutability, in most product copy, means the storage layer is configured not to accept updates or deletes. That configuration is held by the party the log exists to constrain, so it is a property of the deployment rather than of the records. Chained records stay checkable after the configuration has been changed and changed back.

Non-repudiation: Non-repudiation means an actor cannot credibly deny having done something, which requires a signature under a key only that actor holds. A tamper-evident log gives you integrity of the record and attribution to whatever identity the system authenticated, but not a cryptographic answer to a person who says the log is lying about them.