Tamper-evident vs. tamper-proof: what actually protects a writing record

Why one syllable matters

If you are relying on a record to prove you wrote something — a version history, a process log, a provenance record — the single most important question about that record is: could someone have changed it after the fact without anyone being able to tell?

Vendors answer this question with two words that sound interchangeable and are not. Tamper-proof means the record cannot be altered. Tamper-evident means the record can be altered, but any alteration leaves a mark that a checker will catch. The first is a claim about prevention; the second is a claim about detection.

Here is the uncomfortable truth that makes the distinction matter: tamper-proof digital records do not exist. Every digital record is bytes on a disk somewhere, and whoever controls that disk can change the bytes. A database administrator can run an UPDATE. A laptop owner can hex-edit a file. A cloud provider can — in principle — rewrite anything it stores. "Tamper-proof" is a marketing word, not an engineering property, and a vendor who uses it unironically is telling you something about how carefully they speak.

Tamper-evidence, by contrast, is a real, achievable, verifiable engineering property — and for a writing record, it turns out to be exactly enough.

The idea is older than computers

The physical world settled this question long ago. An evidence bag is not a safe: anyone with scissors can open it. What it has is a seal that cannot be reclosed — opening it is easy, but opening it undetectably is the hard part. A numbered seal on a shipping container works the same way: it does not stop a thief, it guarantees the recipient will know a thief was there. Pharmacy packaging, election ballot boxes, notary embossing — none of these prevent tampering. All of them make tampering visible.

The insight behind all of them: when you cannot make something impossible to alter, make it impossible to alter quietly. Shift the defense from prevention to detection, and then make detection cheap and reliable.

Digital tamper-evidence is the same move, executed with mathematics instead of foil and glue.

Hash chains, in plain language

The mathematical tool is a hash function: a one-way algorithm that takes any input — a sentence, a document, a gigabyte — and produces a short, fixed fingerprint. Three properties make it useful:

1. The same input always gives the same fingerprint.
2. Any change to the input — one character, one space — gives a completely different fingerprint. Not slightly different: unrecognizably different.
3. You cannot work backward from a fingerprint to an input, and you cannot realistically craft a second input that produces the same fingerprint.

Now suppose you keep a log of a writing session as a list of entries: "9:02 — typed 140 characters," "9:14 — pasted 60 characters," and so on. To make this log tamper-evident, each new entry includes one extra ingredient: the fingerprint of the entry before it. Entry 2 contains the hash of entry 1. Entry 3 contains the hash of entry 2 — which itself depends on the hash of entry 1. Every entry is welded to its entire past.

Watch what this does to a would-be editor. Say someone wants to quietly change entry 2 — turn that paste into typing. The moment they touch entry 2, its fingerprint changes. Entry 3 recorded the old fingerprint, so entry 3 no longer matches — the chain is visibly broken at that link. To hide the edit, they must rewrite entry 3's stored hash, which changes entry 3's own fingerprint, which breaks entry 4, and so on through every subsequent entry to the end of the chain. One quiet edit becomes a full rewrite of everything after it. That is the seal on the evidence bag: altering the record is easy; altering it without leaving a trace is not.

Checking the chain is mechanical: recompute each fingerprint, compare it against what the next entry recorded, and flag any mismatch. No judgment calls, no statistical model, no confidence score — a link either matches or it doesn't. This is why tamper-evidence, unlike AI detection, produces answers a committee can actually act on.

The catch: a chain only protects its own past

Here is where most "tamper-evident" claims quietly fall apart, and where you should press hardest.

A hash chain guarantees that nobody altered the middle of a record without breaking it. It does not, by itself, stop someone from throwing the whole chain away and manufacturing a new one from scratch. If I control the software that writes the log, I can delete the honest log and generate a fresh, perfectly self-consistent chain that tells whatever story I like. Every link will check out — because I forged all of them together.

This is not hypothetical. Google Docs version history is often treated as a process record, but it was never designed as a sealed one — and there are public tools, like the DocuSim revision-history simulator on GitHub, that replay arbitrary text into a document so the revision trail shows gradual, human-looking progress that never happened. The trail looks like evidence. Nothing in it is sealed against its own author. (We cover what version history is still good for — which is a lot — in a dedicated article.)

So real tamper-evidence needs a second ingredient: the chain's endpoint has to be anchored somewhere the author doesn't control. The standard moves:

• Cryptographic signing. The record (or its final fingerprint) is signed with a key the writer does not hold — a server's key, an institution's key, a timestamping authority's. Regenerating the chain is now useless, because the forger cannot re-produce the signature. This is the approach the C2PA standard — backed by camera makers, software vendors, and news organizations — takes for photos and media: a signed manifest that travels with the file, checkable by anyone.
• Timely escrow. Fingerprints are shipped to an independent service while the writing happens, not after. A forger working backward from a finished essay cannot retroactively plant fingerprints in last week's escrow.
• Third-party verification. Anyone — not just the vendor — can run the check. A record that only its maker can validate merely relocates the trust problem.

A useful way to hold all this: the chain makes the record tamper-evident against everyone else; the anchor makes it tamper-evident against the person who made it. A writing record needs both, because the person with the strongest motive to edit a writing record is sometimes its author — and a record that can't rule that out is worth little to the honest writer trying to distinguish herself from a dishonest one.

Scoring the records students actually have

Put the common forms of writing evidence against both requirements:

Record	Chained?	Anchored outside the author's control?	Honest verdict
Screenshots of drafts	No	No	Trivially editable; weak on its own
Word/Docs file with tracked changes	No	No	Lives in an editable file the author holds
Google Docs version history	Google holds it, so casual editing is out	Not sealed or signed; replayable with public simulators	Useful corroboration, not tamper-evident proof
Email-to-self of drafts	No	Timestamps held by mail servers	Crude but real anchoring; coarse
Sealed provenance record	Yes — hash-chained during writing	Yes — signed and independently checkable	The only entry built for the job

The pattern in the table is the point of this article: most of what people instinctively collect as proof is history, not evidence — a story about the past stored in a form the storyteller can revise. The difference between the two is precisely tamper-evidence. (How to combine these layers when an accusation has already landed is covered in how to prove you didn't use AI.)

Four questions that expose a fake "tamper-proof" claim

Whether you are a student choosing a tool, an instructor evaluating evidence, or an administrator reading a vendor deck, these four questions sort real tamper-evidence from theater:

1. "Tamper-proof, or tamper-evident?" If the answer is "tamper-proof," ask how, and watch the answer collapse into either tamper-evidence or hand-waving. Precision here predicts precision everywhere else.
2. "What happens if someone edits the record?" The right answer names a mechanism: a broken hash link, a failed signature. "They can't" is not a mechanism.
3. "Can the record's author regenerate it from scratch?" If yes, it is a diary, not a seal. Ask what anchors the record outside the author's reach, and when that anchoring happens — during writing, or after.
4. "Who can run the verification?" "Our support team can confirm it" means you are trusting the vendor, which was the problem you were trying to solve. The honest answer is: anyone, with public tooling.

The bottom line

"Tamper-proof" is a promise nobody can keep; distrust records sold under that word. "Tamper-evident" is a promise mathematics can keep — a hash chain welds a record to its own history so edits break visibly, and an external anchor (signatures, escrow, independent verification) stops the record's author from simply starting over. A record with both properties doesn't ask anyone to trust the writer, the institution, or the vendor: it hands every party the same mechanical check and lets the check do the talking.

That is the standard a writing provenance record is built to meet — and the standard any evidence of authorship should be measured against, because an accusation is exactly the moment when "trust me, I didn't edit it" stops working.

If you already have a file and want the practical version — what a pass means, what a fail means, and which checker to open — read what checking a seal actually shows.