How to Prove a Document's History Securely?

How to Prove a Document's History Securely?

Proving a document's history means being able to show, later and to someone who doesn't trust you, what the document looked like at specific points in time and that those versions weren't rewritten afterwards. The reliable way to do it is to take a cryptographic hash of each version, anchor each hash to an independent timestamp, and link the versions so their order can be checked. The editing history inside your word processor won't do this on its own.

This guide covers why the usual tools fall short, what a timestamp can and can't establish, and a simple workflow you can follow with any file type.

Why the history you already have isn't strong evidence?

Most of us assume our documents already carry a history. They do, but it's a history we could have edited.

File metadata (created, modified dates) is written by your operating system and can be changed with a few clicks or a one-line command. Copying a file often resets it too. A judge, an auditor or a counterparty has no reason to treat it as more than a hint.

Version history in Word, Google Docs or Notion is genuinely useful for working. But it lives inside a platform that someone controls. An account holder can often delete versions, and an administrator can see or change more than you'd expect. The platform may also change its retention rules. None of that makes it dishonest, but it is not independent of you.

Emailing the file to yourself gives a date from a mail server, which is better than nothing. It's also awkward for dozens of revisions, and it depends on you keeping that mailbox intact.

Git is much stronger for text and code. Every commit hash depends on the content and on the parent commit, so history can't be altered without changing the hashes after it. The catch is that the repository is still yours. If you rewrite history and republish, nothing external says otherwise, unless someone else holds a copy or you've anchored a commit hash somewhere independent.

What all of these lack is a third party, or a public record, that fixed the state of the document at a given moment, in a way you can't later adjust.

Two ingredients: a fingerprint and an independent clock

The fingerprint. A cryptographic hash function such as SHA-256, specified in NIST's FIPS 180-4, turns any file into a fixed-length string. Change a single character, one pixel or one comma, and the output is completely different. You can't work backwards from the hash to the file.

The clock. A hash alone is just a number. To make it evidence of time, you need to publish it somewhere you can't edit afterwards. Traditional timestamp authorities do this using the RFC 3161 protocol, signing the hash together with the time. A public blockchain does it differently: the hash is included in a block that many independent nodes hold, so changing it later would mean rewriting the shared ledger.

Put together: hash the file, anchor the hash, and keep the original. Anyone can later hash your file again and compare it with the recorded value. If they match, that exact file existed at or before the recorded time.

The detail most guides skip: a timestamp is an upper bound

Here's the part that matters for history specifically. A timestamp on version 2 proves version 2 existed no later than that moment. It doesn't prove version 2 didn't exist earlier, and it says nothing about its relationship to version 1.

So if you simply timestamp five versions separately, you can show each existed by its date. What you can't easily show is the order in which they were created. Someone could argue you produced "version 1" last, from "version 5", and timestamped it afterwards in the right sequence. Unlikely, but it's the kind of challenge that arises in disputes.

The fix is to make each version depend on the one before it.

Linking versions with a simple hash chain

The idea is the same one Git uses, and you can apply it to any document type.

For each revision, create a short plain-text manifest file. It records:

> the file name and version label

> the SHA-256 hash of the document at this revision

> the hash of the previous manifest

> a short note on what changed

Then hash the manifest, and anchor that hash.

Because manifest 3 contains the hash of manifest 2, manifest 3 couldn't have been written before manifest 2 existed. You now have a lower bound on its creation (it came after the previous one) as well as the upper bound from the timestamp. Together they pin each version into a window, and the sequence can be checked by anyone who has the files.

If you change anything in an earlier version afterwards, its hash changes, the next manifest no longer matches, and the break is visible.

A worked example (hypothetical)

Say a researcher is drafting a grant proposal over six weeks. This is an illustration, not a real record.

On day 1 she finishes the first draft as proposal-v1.pdf. She hashes it and writes manifest-01.txt with that hash and the note "initial draft". She anchors the manifest's hash.

On day 12 she exports proposal-v2.pdf after restructuring the budget section. Her new manifest-02.txt lists the hash of v2 and the hash of manifest-01.txt, plus a note on the change. She anchors that.

She repeats the pattern for each significant revision. At the end, she holds six PDFs, six small manifests and six anchored records. If a funder or co-applicant later questions when the budget logic first appeared, she can hand over the files and let them verify each hash and each chain link themselves.

The cost per revision is a couple of minutes. The value is mainly in the cases where you never need it, and in the one case where you suddenly do.

Practical situations where this matters

* Inventors and R&D teams documenting how an idea developed. A dated sequence can support a prior-art or invention-disclosure record.

* Creators and writers showing that a draft, script or design existed before a dispute began.

* Contract negotiators keeping a record of which text was on the table at each round.

* Compliance and quality teams that need an audit trail for policies, procedures or reports.

* Consultants and agencies who want to show the state of a deliverable on the day it was handed over.

What this doesn't prove

It's worth being blunt about this, because overselling is how timestamping gets a bad reputation.

A hash chain with anchored timestamps provides evidence that particular files existed at or before particular times, and in what sequence they were committed. It does not show:

* who wrote the document. Anyone can hash and anchor any file, including someone else's.

* that the content is original or lawfully yours.

* that the document is true or accurate.

* that it was never changed before your first anchor. The chain begins at version 1. Anything that happened before that is outside the record.

* that a court will accept it. Admissibility and weight depend on the jurisdiction and the circumstances.

One more point: if a document is short or highly predictable (a standard form with a few filled-in fields, say), someone could in theory guess the contents and confirm it by hashing their guess. If that matters for you, include some unpredictable material in the file or manifest. Don't rely on the hash alone to hide a guessable document.

A word on the law

The legal treatment of timestamps varies. In the EU, the eIDAS Regulation (Regulation (EU) No 910/2014) says an electronic time stamp can't be denied legal effect or admissibility as evidence merely because it's electronic or isn't a qualified time stamp. Qualified time stamps, issued by qualified trust service providers, additionally benefit from a presumption of accuracy of the date and time. A blockchain anchor from a general-purpose service isn't automatically a qualified time stamp. The 2024 amendment (Regulation (EU) 2024/1183) also introduced a framework for qualified electronic ledgers, so it's worth checking whether any given service holds that status. In other jurisdictions the rules differ again. If a specific dispute or filing is involved, speak to a lawyer in the relevant jurisdiction.

How Certelo fits in?

Certelo handles the two ingredients described above. Your file stays on your device. The SHA-256 hash is calculated locally, and only that hash is anchored to the Electra Protocol blockchain, so you don't need to upload the document to create the record. Later, you can check the record using the original file, the hash or the certificate information.

For document history, you can use Certelo for each version (or each manifest, if you want the hash chain). The chaining method above is a working practice you apply yourself, not an automatic feature. Certelo records each hash independently, and you keep the manifests that connect them.

Checking the history later

When someone needs to verify your history, the process is short:

1- Gather the document versions and the manifests.

2- Recompute the SHA-256 of each file and compare it with the value written in its manifest.

3- Check that each manifest lists the correct hash of the previous manifest.

4- Verify each manifest's hash against its blockchain record and note the recorded time.

If every step matches, the chain is intact and each link existed no later than its recorded time.

Habits that make it hold up

* Anchor at meaningful milestones, not only at the end. A single timestamp after six months of work says little about the first five.

* Keep the exact files. A re-saved or re-exported copy has a different hash even if it looks identical.

* Store originals and manifests in more than one place.

* Write clear version notes. Future you will have forgotten the context.

* Anchor before you share a draft with anyone, not after.

Let's clarify some facts

Is Google Docs version history enough to prove a document's history?

It's useful for you and collaborators, but it's controlled by the platform and the account, and you can't hand it to a stranger as independent proof. An anchored hash of an exported copy adds an external reference point.

Can a blockchain timestamp show the order of document versions?

Each timestamp shows its version existed by that time. If the timestamps are in sequence, that's consistent with the order, but it doesn't strictly prove it. Linking each version to the previous one's hash, as in the manifest method, is what lets you demonstrate sequence.

Does Certelo upload my document?

No. The hash is generated locally and the original file stays on your device. Only the hash is anchored.

What happens if I edit the document after timestamping it?

The edited file will have a different hash, so it won't match the earlier record. That's the point: the earlier record stays tied to the earlier version. Timestamp the new version separately.

Does this prove I wrote the document?

No. It shows a file existed at or before a certain time. Authorship needs other evidence, such as drafts, communications, source files and witnesses.

Is a blockchain timestamp legally valid?

It depends on the jurisdiction and the circumstances. In some places, electronic timestamps are recognised as evidence, and qualified timestamps carry additional presumptions in the EU. Weight is decided case by case. Take legal advice if the stakes are real.

Can I use this for non-text files, like images or audio?

Yes. A hash works on any file. For history, the manifest approach is the same.