Can You Prove a File Was Never Changed? - blog

Understanding File Integrity, Version History, Digital Signatures, and Trusted Timestamps

In a world where contracts, financial records, business agreements, and confidential documents are increasingly created, shared, and stored digitally, one important question remains:

How can you prove that a file has not been changed since it was originally created or signed?

Imagine that your company signs a digital contract with a business partner. Both parties download a copy and store it on their computers. Six months later, a disagreement arises. One party presents a contract containing a different payment amount, while the other insists that the original agreement contained a different figure.

Both documents look legitimate. Both have the same filename. Both contain the same company logos, formatting, and signatures.

So, which version is authentic?

More importantly, can either party prove that the document has remained unchanged since the agreement was signed?

This is where file integrity, cryptographic hashing, digital signatures, trusted timestamps, and version history become essential.

These technologies provide different pieces of evidence. Together, they can create a reliable record of a document’s identity, authenticity, and history.

But there is an important distinction: Proving that a file has not changed is not necessarily the same as proving that it was never changed.

Let’s explore how these technologies work and how they can be combined to protect important digital documents.

1. The Problem: Digital Files Can Be Changed Without Leaving Obvious Evidence

Unlike physical documents, digital files can be modified without creating visible signs of alteration.

Someone can:

Change a payment amount in a PDF contract.
Replace a bank account number in an invoice.
Modify a clause in a legal agreement.
Remove or insert pages into a document.
Replace an original file with a modified version using the same filename.
Change the metadata associated with a document.
Replace a signed document with another file that looks almost identical.

Even the file’s creation date and modification date can be manipulated.

For example, imagine two files:

Employment_Agreement.pdf

They have identical filenames and almost identical appearances. However, one contains an additional clause that changes the employee’s compensation.

A filename cannot establish authenticity. A visual comparison might miss subtle modifications. File properties can also be unreliable.

To establish whether a document has changed, we need something more dependable than its appearance.

We need cryptographic evidence.

2. What Is a Cryptographic Hash?

A cryptographic hash is one of the simplest and most powerful ways to identify whether a digital file has changed.

A hashing algorithm takes the contents of a file and produces a fixed-length digital fingerprint.

For example, SHA-256 produces a 256-bit hash, normally represented as a 64-character hexadecimal string.

Imagine a contract containing the following sentence:

“Payment will be completed within 30 days.”

A hashing algorithm processes the entire file and generates a unique-looking fingerprint.

If someone changes the sentence to:

“Payment will be completed within 60 days.”

The resulting hash will be completely different.

<escape>Original file → SHA-256 → Original hash</escape>

<escape>Modified file → SHA-256 → Different hash</escape>

Even a very small modification, such as changing a single character, can produce a dramatically different hash.

This property is known as the avalanche effect.

Why Is Hashing Important?

Hashing allows two parties to independently calculate the fingerprint of a file and compare the results.

If the hashes match, there is extremely strong evidence that both files contain exactly the same bytes.

If the hashes differ, the files are not identical.

However, hashing has an important limitation.

A hash does not prove who created a file, who changed it, or when the change happened.

It only identifies the exact contents being hashed.

Anyone can calculate a new hash after modifying a document.

For this reason, hashing alone is not sufficient for establishing a trustworthy document history.

3. Digital Signatures: Proving Who Approved a Document

A cryptographic hash can identify a document, but it cannot independently establish who approved it.

This is where digital signatures become important.

A digital signature uses public-key cryptography to connect a document to a specific signing key.

The process generally works as follows:

The signer selects the final document.
A cryptographic hash is calculated.
The signer uses their private signing key to create a digital signature over that hash.
The document, signature, and relevant certificate information are distributed to the recipient.
The recipient uses the corresponding public key to verify the signature.

If the document changes after signing, signature verification will normally fail.

If the signature is valid and the certificate chain is trusted, the recipient gains evidence that the document was signed using the corresponding private key and has not been altered since signing.

What Does a Digital Signature Actually Prove?

A properly implemented and verified digital signature can provide evidence of:

Document integrity.
Use of a particular private signing key.
Association between the signing key and an identity, when supported by a trusted certificate or other reliable identity verification.
Approval of a specific document version.

However, there is an important distinction between a valid signature and proof of a person’s identity.

A valid signature does not automatically prove that a particular human personally signed the document.

The private key might have been compromised, shared, misused, or operated by an automated system.

Identity verification, key protection, certificate validity, and signing procedures all matter.

Digital signatures are therefore much stronger when combined with secure identity verification and reliable key management.

4. Trusted Timestamps: Proving When a Document Existed

Hashing establishes what a file contains.

Digital signatures help establish who signed it.

But another important question remains:

How can you prove when a particular version of a document existed?

A file’s internal creation date is not enough.

Computer clocks can be inaccurate. Metadata can be edited. Operating system timestamps can be modified.

A trusted timestamp provides stronger evidence.

A trusted timestamping service receives a cryptographic hash of a document and issues a digitally signed timestamp token.

The token typically contains:

The document’s hash.
The timestamp.
The timestamp authority’s identity.
A digital signature from the timestamp authority.

The timestamp authority uses a trusted time source and protects its signing key.

Later, anyone can verify the timestamp token and confirm that the corresponding document hash was presented to the timestamp authority at or before the recorded time.

For example:

A company signs an employment contract on 10 November 2026.

Immediately after signing, the company submits the document hash to a trusted timestamping authority.

The authority issues a timestamp token recording the time at which that hash was received.

Two years later, the company can present the original document and timestamp token.

An independent verifier can calculate the document’s hash and compare it with the hash inside the timestamp token.

If they match and the timestamp token is valid, there is evidence that this exact document existed no later than the recorded timestamp.

Why Is This Different From a File’s Creation Date?

Because the timestamp is cryptographically signed by an independent authority.

Changing the computer’s clock or editing the file’s metadata does not change the original timestamp token.

However, a timestamp does not prove that a document was created at that exact moment. It proves that the corresponding hash was presented to the timestamp authority at the recorded time, subject to the authority’s trustworthiness and timestamping policy.

5. Version History: Understanding Every Change

Hashing, signatures, and timestamps help establish the integrity of individual document versions.

But what happens when a document legitimately changes?

Businesses frequently update contracts, policies, invoices, specifications, and internal reports.

A reliable system should not simply overwrite the previous document.

Instead, it should maintain a verifiable version history.

Consider this example:

Version	Date	Description
V1	10 Nov 2026	Original contract created
V2	12 Nov 2026	Payment terms updated
V3	14 Nov 2026	Delivery conditions revised
V4	15 Nov 2026	Final version signed

Each version should have its own:

Unique version identifier.
Cryptographic hash.
Creation or registration timestamp.
Author or responsible account.
Change description.
Digital signature, where applicable.

The important principle is that previous versions should remain available rather than being silently replaced.

What Makes Version History Trustworthy?

A normal version history is not automatically reliable.

If an administrator can delete previous versions, modify timestamps, or rewrite the history database, the records may not provide sufficient independent evidence.

A stronger design can use:

Append-only event logs.
Cryptographic hash chaining.
Digital signatures on version records.
Independent timestamping.
Write-once or immutable storage.
External audit records.

In a hash-chained system, each new record contains the hash of the previous record.

For example:

<escape>Record 1 → Record 2 → Record 3 → Record 4</escape>

Each record depends cryptographically on the preceding record.

If someone modifies an earlier record, the subsequent hash relationships no longer match.

This makes unauthorized modification detectable.

However, hash chaining alone does not prevent an administrator from rebuilding an entirely new chain. Independent checkpoints, signatures, and external records are needed to make such manipulation more difficult to conceal.

6. Real-World Example: Protecting a Digital Contract

Let’s bring these technologies together.

Imagine that Company A signs a service agreement with Company B.

The agreement contains:

Contract value: $120,000.
Duration: 12 months.
Payment terms: 30 days.
Delivery deadline: 31 December 2026.

Both companies need confidence that the signed agreement cannot be secretly modified.

A properly designed document verification process could work as follows.

Step 1: Create the Original Document

Company A prepares the contract and generates the final PDF.

The document receives a unique identifier.

Step 2: Calculate the SHA-256 Hash

The system calculates the document’s SHA-256 fingerprint.

For illustration:

SHA256: 8f14e45fceea167a5a36dedd4bea2543...

This is an illustrative shortened value, not an actual hash of a contract.

Step 3: Sign the Document Digitally

The authorized representative signs the contract using a digital signing key.

The signature is linked to the document’s cryptographic contents.

Step 4: Obtain a Trusted Timestamp

The document hash or signature is submitted to a trusted timestamping authority.

The resulting timestamp token provides independent evidence that the signed document existed no later than the recorded time.

Step 5: Store the Document and Its Evidence

The system stores:

The original contract.
Its SHA-256 hash.
The digital signature.
The timestamp token.
The signer’s certificate and relevant validation information.
The document’s version identifier.

The previous evidence should be protected against unauthorized modification or deletion.

Step 6: Verify the Contract Later

Six months later, Company B receives another copy of the contract.

The verification system calculates its hash and compares it with the original registered hash.

If the hashes match, the file is byte-for-byte identical to the original registered version.

If the hashes differ, the system identifies an integrity mismatch.

The digital signature is also verified to establish whether the signature remains cryptographically valid.

The timestamp token is checked to establish whether the original hash was timestamped by the trusted authority.

Together, these checks provide a much stronger foundation for resolving disputes.

7. Hash vs. Digital Signature vs. Timestamp

Although these technologies are frequently mentioned together, they solve different problems.

Technology	Main Purpose	What It Establishes
Cryptographic Hash	File integrity	Whether two files have identical contents
Digital Signature	Authenticity and integrity	Whether a signature verifies against a particular document and public key
Trusted Timestamp	Time evidence	Whether a particular hash was presented at a recorded time
Version History	Change tracking	How registered document versions relate to each other
Immutable Storage	Record preservation	Resistance to unauthorized modification or deletion

No single technology provides a complete solution.

A hash cannot identify an author.

A digital signature does not automatically establish when a document was signed.

A timestamp does not establish that the signer had authority to approve the contract.

A version history does not guarantee that records cannot be manipulated.

Reliable document verification requires these mechanisms to work together.

8. Can Blockchain Prove That a File Was Never Changed?

Blockchain technology is sometimes presented as a solution to digital document integrity.

The underlying idea is straightforward.

Instead of relying entirely on a company’s internal database, a cryptographic hash can be recorded on a distributed ledger.

If the document is modified later, its new hash will not match the previously recorded value.

This can provide an independently verifiable record that a particular hash was committed to the ledger.

Blockchain can be useful for:

Recording document fingerprints.
Establishing independently verifiable checkpoints.
Maintaining distributed audit records.
Reducing dependence on a single organization’s database.
Verifying that a document matches a previously registered version.

However, blockchain does not automatically solve every document integrity problem.

It does not prove that the original document was truthful.

It does not independently verify the identity of the person who submitted it.

It does not guarantee that a document was never modified before its hash was registered.

It also does not prevent someone from deleting the original file.

A blockchain record can establish that a particular hash was recorded at a particular point in the ledger’s history. It cannot establish the complete history of a file before that point.

Blockchain can strengthen the evidence trail, but it cannot replace proper document signing, identity verification, secure storage, and timestamping.

9. The Hidden Risk: What Happens When the Original Evidence Disappears?

There is another problem that businesses often overlook.

A company might have a perfectly valid digital signature and timestamp today, but what happens 15 years later?

The original signing certificate might have expired.

The timestamping authority might no longer exist.

The cryptographic algorithm might become obsolete.

The document might be stored in a format that is difficult to verify.

The signing key might have been compromised after the document was signed.

Long-term verification therefore requires more than storing a PDF.

A robust archival strategy should preserve:

The original document.
The original digital signature.
The timestamp token.
Certificate chains.
Certificate revocation information, such as OCSP responses or CRLs where applicable.
Signature validation reports.
The algorithms and parameters used.
The complete version history.
Independent verification records.

For long-term preservation, organizations may also need to renew timestamps, revalidate signatures, and migrate cryptographic evidence before older algorithms become unsuitable.

This is particularly important for legal agreements, financial records, intellectual property, and regulated business documents.

10. The Future: Documents That Carry Their Own Proof

Traditionally, a document and its verification records are stored separately.

The file exists in one location. Its history exists in another. Its signature information may be embedded inside the PDF. Timestamp evidence may be stored in a separate database.

This fragmentation creates unnecessary complexity.

A more advanced approach is to treat every important document as a verifiable digital object.

Instead of storing only a file, the system maintains a complete evidence package containing:

The document itself.
Its cryptographic fingerprint.
Its version relationships.
Its digital signatures.
Its trusted timestamps.
Its authorization records.
Its verification history.

A user could upload a contract and immediately answer several important questions:

Is this the exact document that was originally signed?
Has its content changed since registration?
Who signed it, and can their signing identity be verified?
When was this version independently timestamped?
Which version came before it?
Was this version approved by the authorized parties?
Can its evidence still be independently verified?

This is a shift from simply storing documents to preserving their authenticity and history.

For organizations managing thousands of files across departments, suppliers, customers, and external partners, this capability could become an essential part of digital trust infrastructure.

Conclusion: Integrity Is Not the Same as History

Can you prove that a file was never changed?

The most accurate answer is that you can prove, with strong cryptographic evidence, that a particular file matches a previously registered version.

You can establish that a specific signing key signed that version. You can establish that its hash was presented to a trusted timestamping authority at a recorded time. You can also maintain a verifiable history of subsequent versions.

But none of these technologies, individually or together, can automatically prove that a file was never modified at any point before its first trustworthy registration.

That distinction matters.

The future of digital trust will not depend only on protecting files from unauthorized changes. It will depend on making the entire history of important digital records independently verifiable.

For contracts, financial agreements, business records, intellectual property, and sensitive company information, the question should no longer be simply:

“Where is the original file?”

It should be:

“Can we independently prove what this file contained, who approved it, when it existed, and whether its history can be trusted?”

Because in a digital world, keeping a document is easy.

Proving its integrity is what makes it valuable.