How tamper-evidence actually works under the hood

Tamper-evident, not tamper-proof

First, an important distinction. "Tamper-proof" would mean a document can't be changed — which is impossible; anyone can edit a file. "Tamper-evident" means something more useful and achievable: any change can be detected. A tamper-evident document doesn't stop you from altering it, but the moment you do, the alteration announces itself. That's the property we're after, and it's built entirely from cryptography — no locks, no DRM, just math that refuses to lie.

Step one: fingerprint the document

The foundation is hashing. When a document is finalized, the signing software runs it through a cryptographic hash function — commonly SHA-256 — which reduces the entire file to a fixed 256-bit fingerprint, written as 64 hexadecimal characters.

Two properties make this the perfect tamper detector:

• Deterministic: the same bytes always produce the same hash, so it can be recomputed and compared anytime.
• Avalanche effect: change a single bit anywhere in the document and roughly half the hash bits flip. The new fingerprint looks totally unrelated. There's no partial match — a document is either identical (same hash) or altered (different hash).

So the hash captures the document's exact state at signing. If the hash still matches later, nothing changed. But a hash alone has a weakness: an attacker who edits the document could just recompute and substitute the new hash. We need to stop that.

Step two: seal the fingerprint so it can't be swapped

This is where the private key comes in. Instead of storing the hash in the open, the signer's software encrypts the hash with their private key. That encrypted hash is the digital signature. To read it back, you need the corresponding public key — which lives in the signer's certificate.

Now the attack is blocked. To forge a valid document, a tamperer would need to (a) alter the content, (b) compute the new hash, and (c) re-encrypt that hash with the signer's private key. But they don't have the private key — only the signer does. Without it, any hash they insert won't decrypt correctly against the public key, and verification fails. The hash proves what the document was; the private-key encryption proves who vouched for it and stops the fingerprint from being quietly replaced.

Step three: wrap it in a digital seal

For PDFs, all of this is packaged into a standardized structure called PKCS#7 (also known as CMS — Cryptographic Message Syntax). This seal, embedded inside the PDF, bundles together:

• The encrypted hash (the signature itself)
• The signer's certificate and its chain up to a trusted root
• Metadata like the signing time and, ideally, a trusted timestamp

Because the seal is a recognized standard, any compliant PDF reader knows how to open it and run the checks.

The clever part: byte-range signing

Here's a subtlety unique to signing a file that has to contain its own signature. You can't hash the whole PDF including the signature — the signature isn't there yet when you compute the hash, and adding it would change the file. PDF signing solves this with a byte range: the signature covers specific ranges of the file, leaving a reserved gap where the signature bytes get inserted.

The important consequence: the signed byte ranges typically cover essentially the entire document except the signature placeholder. So if anyone modifies text, images, form fields, or hidden metadata anywhere in those ranges after signing, the recomputed hash won't match the sealed one, and the reader flags the document as changed. This is also how PDF readers can tell you "the document has been altered since it was signed."

Putting verification together

When someone opens a signed document, the reader silently runs a checklist:

1. Recompute the hash of the signed byte ranges.
2. Decrypt the sealed hash using the public key from the signer's certificate.
3. Compare the two. Match means the content is untouched; mismatch means tampering.
4. Validate the certificate chain up to a trusted root (for PDFs, often via the Adobe Approved Trust List).
5. Check the timestamp and revocation status to confirm the signature was valid when made.

Pass all five, and the reader shows a trust banner. Fail any, and it warns you. No trust required — everything is verified.

Why an audit trail complements the seal

The cryptographic seal proves the document is unchanged. A tamper-evident audit trail and certificate of completion add the surrounding context — who signed, when, from what IP and device, and how they were authenticated — and record the document's hash so the integrity proof is preserved alongside the story of the signing. Together they make a signature that can defend both its content and its circumstances.

How PearSign implements it

PearSign fingerprints each completed document with a SHA-256 hash and seals it with an AATL-backed digital certificate using standard PDF signing. Any later change — even a single character or a hidden metadata field — breaks the hash match and fails the seal, so the tampering surfaces automatically in common PDF readers. The certificate of completion records the same hash, keeping the proof portable and self-contained.

FAQ

What is the difference between tamper-proof and tamper-evident?

Tamper-proof would mean a document can't be changed at all, which isn't realistic for digital files. Tamper-evident means any change can be detected. A tamper-evident document doesn't prevent edits, but cryptography ensures that the moment one is made, it becomes visible through a broken hash or a failed digital seal.

How does hashing make tampering detectable?

A cryptographic hash like SHA-256 turns a document into a unique fixed-length fingerprint. Because the function is deterministic and extremely sensitive to change, even a one-character edit produces a completely different fingerprint. Recording the hash at signing means anyone can recompute it later and instantly see whether the document was altered.

Why is the hash encrypted with a private key?

Encrypting the hash with the signer's private key stops an attacker from simply editing the document and substituting a fresh hash. Without the private key — which only the signer holds — any replacement hash won't validate against the signer's public key, so tampering fails verification. This also ties the document to a verified identity.

What is PKCS#7 in PDF signing?

PKCS#7 (also called CMS) is the standard structure that packages a digital signature inside a PDF. It bundles the encrypted hash, the signer's certificate and trust chain, and metadata like the signing time into one embedded seal that any compliant PDF reader can open and verify.

How can a PDF reader tell a document was changed after signing?

PDF signatures cover defined byte ranges spanning nearly the entire file except the signature placeholder. When you open the document, the reader recomputes the hash of those ranges and compares it to the sealed hash. If they don't match — because text, images, fields, or metadata were altered — the reader reports that the document has changed since it was signed.