Can my recipient prove the file they got hasn't been tampered with?

A buyer at a regional bank's M&A advisory desk emailed us last quarter with one specific worry. Her deal team had just sent a draft purchase agreement to the seller's counsel through a "secure share" link. The seller's counsel forwarded a redlined version back the next morning. Before opening it, she stopped and asked her IT lead: how do I actually know this file came back in one piece? Could a man-in-the-middle have changed three numbers? Could the seller's email-scanning gateway have re-saved it through some "safe attachments" rewriter and corrupted the signature blocks? She wasn't being paranoid. She was being a fiduciary.

This is the question almost no secure-link product can answer cleanly. Most vendors will tell the SENDER what was sent. Very few will let the RECIPIENT prove what they received hasn't been tampered with — between the sender's outbox and the moment the recipient saved the file to their desktop.

That's the gap this post is about.

Why this question gets dodged

When you ask a vendor "can my recipient prove the file wasn't tampered with," you usually get one of three answers, none of which are the answer you wanted.

The first answer is "we use TLS." TLS protects the bytes while they're crossing the network. It says nothing about what happened before TLS started or after TLS finished. It does not protect against a recipient's mail gateway rewriting the file. It does not protect against a sender's endpoint silently swapping the wrong PDF into the upload form. It is a transit protection, not an end-to-end integrity proof.

The second answer is "we hash the file and show the hash in the dashboard." This is closer to useful, but it's a sender-side claim. The recipient still has to trust that the dashboard accurately reflects what was sent, and that the bytes the recipient holds match the dashboard's hash. If the vendor's server is the thing computing and displaying the hash, the recipient is just trusting the vendor's word.

The third answer is "the file is encrypted." Encryption protects confidentiality. It doesn't, by itself, protect integrity. A scrambled file can still be corrupted, truncated, or partially overwritten. You need authenticated encryption — and you need the authenticator's output exposed to the recipient — for the recipient to actually verify integrity.

The honest position: most "secure share" products give the sender a receipt. They give the recipient a download button.

For HR moving a separation agreement, that asymmetry is uncomfortable. For an M&A advisor moving a signed LOI, it's a fiduciary problem.

What "recipient-side tamper-evidence" actually requires

Three things have to be true at once for a recipient to verify that what they got matches what was sent.

1. The integrity proof has to be computed before transmission, not afterward. A hash computed on the recipient's downloaded file proves nothing on its own — the attacker who tampered with the file would just recompute the hash.
2. The integrity proof has to be independent of the channel that delivered the bytes. If the only way to verify the file is to check a value the same server gave you, you're trusting the server. The proof needs to be anchored to something the recipient (or the recipient's auditor, or the recipient's lawyer's lawyer) can validate without re-asking the vendor.
3. The proof has to cover the exact bytes the recipient holds, not "a file we sent at some point." Versioning is the silent killer here. If the sender modified the file after the first send and the proof points at the second version, but the recipient downloaded the first, the proof matches nothing the recipient can hold.

CIPH4's zero-knowledge architecture was designed around all three. Files are encrypted client-side before they leave the browser, with authenticated encryption — meaning any tampering after the fact makes the bytes refuse to decrypt at all, loudly. The decryption key lives in the URL fragment that the server never sees. And for Enterprise shares, every successful retrieval emits a signed receipt the recipient can hand to their own legal team without consulting us.

That last piece is the part most vendors don't have.

The deletion receipt is the audit artifact

When a CIPH4 Enterprise drop is retrieved, viewed to its cap, and burned, the system emits a signed receipt. The signature is anchored to a server-side key whose public half is published openly. Anyone — the recipient, the recipient's general counsel, an auditor two years later — can take the receipt and validate it against the published key using our public verifier page without ever logging into CIPH4 or asking us for help.

The receipt captures:

• The exact identifier of the share.
• The hash of the ciphertext that was delivered. Not a hash of metadata, not a hash of the dashboard summary — the actual encrypted bytes the recipient downloaded.
• The timestamp the burn was finalized.
• The signature that proves the receipt came from CIPH4 and hasn't been edited (the receipt anchors to a position in the hash-chained audit log; the chain anchor is what binds the receipt to the share's actual lifecycle, not a separate plaintext-content hash).

A buyer in M&A due diligence asked us the obvious follow-up: "what stops you from re-signing a different receipt later and pretending it was the original?" The answer is the hash-chained audit log. Every share lifecycle event is written into a chain where each entry's hash includes the previous entry's hash. Any retroactive change would break the chain forward — every subsequent entry's hash would no longer validate, and the receipts you already hold would no longer verify against the chain they reference. The receipt in your hand becomes its own tamper-evidence.

This is the mechanism that lets the recipient's lawyer say, two years from now, in a deposition: "Here is the file. Here is the receipt. Here is the chain head. Anyone with a calculator can verify these match."

The scenarios that make this matter

Three buyer situations recur in our conversations.

M&A and the redline that came back wrong

The M&A advisory desk situation from the opening is real and it happens constantly. Draft documents bounce between buyer's counsel, seller's counsel, and the deal team, often through three or four mail gateways. Each gateway has its own "safe links" rewriter, its own attachment sandbox, its own quarantine policy. Any of them can silently re-encode a PDF, strip a digital signature, or — in pathological cases — substitute a cached older version.

The receipt is what lets the deal team say, definitively, "the version we received matches the version that was sent at 3:47pm on March 4th." Without it, you're reduced to comparing file hashes by hand and trusting that the hash on the screen is the hash you should be comparing against. With it, the proof is portable. The receipt travels with the file in your evidence binder. See our M&A due-diligence field guide for more on how this fits into a deal-room workflow.

Legal and the chain-of-custody requirement

Litigators and in-house counsel run into the integrity question hardest when documents are headed toward production. If a privilege log entry says "Document X, transmitted from A to B on date Y," opposing counsel can — and will — ask whether the document B received was the document A sent. "We use a secure portal" is not an answer. "Here is the signed receipt, here is the chain head, here is the verifier page anyone can run independently" is an answer. Our legal field guide walks through this in more depth.

IR / Security incidents and the breach disclosure window

During an active incident, the IR team is sending sensitive material — forensic images, log excerpts, draft disclosure language — to outside counsel, FBI liaisons, insurance counsel, and sometimes regulators, often in parallel. If any of those copies show up later in a court filing or a regulatory request, the IR lead needs to prove which version of the document went to which counterparty and that the version the counterparty produced matches what was sent. The receipt is the audit anchor. It also creates a clean record showing the bytes were destroyed after retrieval, which matters for the "we minimized further exposure" narrative.

What recipients see, in plain terms

The recipient experience isn't engineering-heavy. The recipient opens the link. The file decrypts in their browser. If anything was tampered with — a single byte changed in transit, a re-encoding by a mail gateway, an attempted substitution — the AES-256-GCM authenticated decryption fails and the file does not render. The recipient sees a decryption-failed message instead of the file, and knows immediately that what they were sent is not what arrived.

If decryption succeeds, the bytes are guaranteed to match what the sender encrypted. That's how authenticated encryption works: tampering and decryption are mutually exclusive outcomes.

Then, if the share is on an Enterprise plan, the recipient (or anyone they hand the receipt to) can confirm two additional things via the public verifier: that the receipt was issued by CIPH4 for that specific share, and that the chain hasn't been retroactively edited. Those are the two checks that turn "I received a file" into "I can prove I received this specific file from this specific sender at this specific time, and nobody can argue otherwise."

Most products give the recipient bytes. CIPH4 gives the recipient bytes plus a paper trail they can defend.

What this does NOT prove (the honest part)

The receipt proves the bytes the recipient got match the bytes the sender encrypted. It does not prove the sender meant to send THAT particular file. If the sender accidentally uploaded the wrong PDF, the receipt will faithfully confirm they sent the wrong PDF. The integrity proof is about transmission fidelity, not editorial judgment.

The receipt also doesn't prove the recipient's identity beyond the link-binding mechanism. If a recipient forwarded their access link before opening it, the receipt confirms a successful retrieval — it doesn't independently re-verify the human who actually clicked. For shares where recipient identity matters (which is most of them, for legal and M&A), CIPH4 supports identity-binding via magic-link verification before the share is openable. The verification event itself is recorded in the hash-chained audit log; the receipt's chain anchor lets an auditor trace back to those identity-verification rows, even though the verified identity isn't embedded in the receipt payload itself.

We mention this because the alternative — vendors who quietly let buyers assume their receipts prove more than they do — is how you end up in a deposition arguing about something a piece of math was never going to settle.

What to do next

If recipient-side tamper-evidence is something your team has been wishing for but couldn't articulate, the security architecture page and the public verifier are the two surfaces to look at first — the verifier in particular is something you can run against any receipt without an account.

If you want to talk through a specific use case (an M&A workflow, an IR retention pattern, a legal-hold requirement), book time with our team and bring the actual scenario. We'd rather hear "here's the thing my lawyer asked me last week" than walk through a generic demo.