Non-Repudiation: Proving Who Sent What

Here is the situation the fancy word is really about. A partner calls and says, "We never sent you that file." Or the reverse: "We never received the file you claim you sent." Money, a deadline, or a contract now hangs on the answer, and everyone is looking at you — the person who runs the transfers — to say what actually happened. What do you have? A vague memory, a log you hope still exists, and a sinking feeling.

Non-repudiation is the property that keeps you out of that corner. Strip away the syllables and it means this: the ability to show, with evidence strong enough that the other side cannot credibly deny it, who sent or received what, and when. This article translates the concept into the parts an administrator actually assembles, is honest about how much that evidence is worth in a real dispute, and draws the important line between what technology proves and what a court or contract decides. This is part of our Signatures & Receipts series, and it ties together the signatures, logs, and receipts the other articles cover.

What "Non-Repudiation" Actually Means

To repudiate something is to deny it — to disown a message, a file, or an action. Non-repudiation, then, is simply making that denial fail. If you can produce evidence that a specific party sent a specific file at a specific time, and that evidence is hard to argue with, they cannot successfully repudiate it. The word sounds like cryptography, and cryptography helps, but the goal is older than computers: it is the digital version of a signed, witnessed delivery receipt.

Notice there are two directions, and they need different evidence. Non-repudiation of origin answers "who created and sent this?" — the sender cannot deny authorship. Non-repudiation of receipt answers "who received it?" — the recipient cannot deny it arrived. A digital signature is strong for the first. The second needs something to come back from the receiver, which is the whole subject of proof of delivery. Keeping the two straight tells you which evidence you are actually missing when a dispute lands.

It Is Evidence Strength, Not a Force Field

The most useful mental shift is to stop thinking of non-repudiation as a yes/no guarantee and start thinking of it as how hard your evidence is to deny. Nothing you build makes it physically impossible for someone to say "that wasn't us." What good evidence does is make that denial expensive, implausible, and ultimately unconvincing to whoever is judging the dispute.

This matters because the alternative — believing a signature is an unbreakable force field — leads to sloppy thinking. A private key can be stolen. A password can be shared. An account can be used by someone other than its owner. Each of those gives a determined party a story to tell. Strong non-repudiation does not pretend those stories are impossible; it stacks up enough independent evidence that the stories stop being believable. A signed file plus a verification log plus a returned receipt plus correlated timestamps at both ends is a lot to explain away all at once.

It helps to picture a balance. On one side sits the denial; on the other, your evidence. A lone log entry barely tips the scale — easy to wave away as a glitch or a misconfiguration. Add a signature and the balance shifts. Add a receipt from the other party's own system, and timestamps from both ends that agree, and the denial is now arguing against its opponent's records and its own. You are never proving that a "that wasn't us" is impossible; you are making one side of the balance too heavy to lift.

The Evidence Elements

Non-repudiation is assembled, not bought. These are the building blocks, and each answers a different question a skeptic will ask.

• Digital signatures answer "who produced these exact bytes?" A valid signature over a file ties that content to a private key — and if you have confirmed whose key it is, to a party. This is your strongest single piece of origin evidence. Our article on digital signatures covers exactly what it does and does not establish.
• Logs answer "what happened, and in what order?" Connection, authentication, the filename, the byte count, the result — recorded at the time by a system with no stake in the later argument. Logs turn a fuzzy recollection into a timeline. Our pillar on transfer logging and audit trails goes deep on making these trustworthy.
• Hashes answer "which exact version of the file?" Recording a file's hash at send and at receipt lets you later prove the bytes matched — or prove they didn't. Without a recorded hash, "the file was different" becomes an argument nobody can settle.
• Receipts answer "did the other side actually get it?" A confirmation file or, better, a signed acknowledgment coming back from the receiver is what converts "we sent it" into "they received it." This is non-repudiation of receipt, and it is covered in proof-of-delivery patterns.
• Timestamps answer "when?" Every other element carries a time, and a dispute is usually a timeline. If your clocks are unsynchronized, your timeline is mush — which is why timestamps, clocks, and evidence quality gets its own article.

The power is in the combination. Any one element has a counter-story; together they corroborate each other. A signature says who; a log says when; a hash says which bytes; a receipt says it landed; timestamps line them all up. When those agree across two independent systems, denial runs out of room.

Technical Proof vs Legal Proof: The Honest Gap

Here is where careful administrators earn their trust, because it is tempting to oversell. A digital signature gives you a technical fact: the private key matching this public key produced this content. That is real and valuable. But a dispute that reaches lawyers turns on a legal question: is this party responsible for what that key did? Those are not the same statement, and the space between them is where honest practice lives.

Several things live in that gap. Was the key genuinely bound to the party — did you ever confirm the fingerprint, or just assume? Was the private key under the owner's sole control, or could it have been stolen or shared? Did an agreement exist saying that signatures from this key count as that party's commitments? Technology cannot answer those; process, contracts, and sometimes courts do. A signature is powerful evidence within a framework of trust and agreement, and much weaker as a naked artifact with no story around it.

This is not a reason to skip the technical work — strong technical evidence is what makes the legal case easy instead of hopeless. It is a reason to be precise about what you are claiming. "Our records show a good signature from the key we confirmed as the partner's, over these exact bytes, logged at this time, with a matching receipt" is a truthful, powerful statement. "This proves beyond doubt they are legally liable" is a claim above your pay grade, and above the technology's. When the stakes justify it, that is the moment to bring in legal and compliance rather than freelancing the interpretation.

The Weak Links That Undermine Good Evidence

Even a well-designed trail has soft spots, and naming them keeps you honest about how strong your case really is:

• Unprotected private keys. If the signing key can be read by many people or systems, every signature it ever made inherits that doubt. Guard it as tightly as a credential that moves money.
• Shared and service accounts. When several people or jobs log in as one account, "who did it" blurs. One account per person or per job keeps the answer sharp.
• Unsynchronized clocks. Timestamps that disagree across systems turn a clean timeline into an argument. Sync everything to a reliable time source.
• Retention gaps. Logs that have rotated away, receipts nobody saved, public keys long since deleted — each is a hole you discover only when you reach for the evidence and it is gone.
• Unconfirmed keys. A signature checked against a key you never confirmed proves only that whoever supplied the key signed the file. Confirm fingerprints out of band, or the whole chain rests on an assumption.

Each weak link has a cheap fix applied in advance and no fix at all applied after a dispute has started. That asymmetry is the entire argument for doing this work before you need it.

Building Non-Repudiation Into a Flow

You cannot manufacture evidence after a dispute; you can only collect what your flow was already producing. So the work is designing the flow to leave a strong trail as a matter of routine. Use this checklist when you set up or review a transfer that might ever be argued over:

Non-repudiation design checklist
---------------------------------
[ ] Sign outbound files with a key whose fingerprint the partner has confirmed
[ ] Verify inbound files, and LOG the result (which key, pass or fail)
[ ] Capture a receipt when the far side accepts a file
      (a confirmation file, or a signed acknowledgment)
[ ] Log both ends: connection, authentication, filename, byte count,
      hash, and timestamp
[ ] Record each file's hash so "which exact bytes" is always answerable
[ ] Keep every clock synchronized so timestamps line up across systems
[ ] Retain signatures, receipts, logs, AND public keys long enough
      to outlast any realistic dispute window
[ ] Document who can access each transfer account, so
      "someone else did it" is a bounded question, not an open one

Two items on that list quietly matter more than they look. Retaining the public keys is one people forget: a signature you can no longer verify, because the key is gone, proves nothing months later. Bounding account access is the other — the fewer people and systems that could have used an account, the weaker the "it must have been someone else" defense becomes. Where signing is part of the outbound job, a scheduled client such as Sysax FTP Automation with OpenPGP support can produce those signatures on every run, so the trail is generated automatically rather than depending on anyone remembering.

Repudiation Scenarios and What Answers Them

The fastest way to see whether a flow has good non-repudiation is to rehearse the denials and check that you hold an answer for each. Here are the common claims and the evidence that meets them:

Run this exercise on a flow before a dispute, not during one. Any row where your honest answer is "we don't have that" is a gap you can close now, cheaply, while nobody is angry. The last row is the humbling one: account-based evidence is only as strong as how tightly you control who can use the account, which is why least privilege and good authentication are quietly part of non-repudiation too.

A Worked Dispute, Start to Finish

Picture a logistics partner insisting they never received last night's manifest, and attaching a late fee to the claim. You open the flow's evidence. Your send log shows the file uploaded to their endpoint, with its hash and a timestamp. Your outbound job signed the file, and you retained that signature. Crucially, their system was set up to drop a signed acknowledgment back into your pickup folder when it ingested the file — and there it is: a signed receipt naming the file, its hash, and their receive time, signed by the key whose fingerprint you confirmed at onboarding.

You verify the receipt: good signature, matching hash. Now three independent pieces — your send log, your retained file and its signature, and their signed acknowledgment — agree on the filename, the exact bytes, and a consistent timeline. The "we never received it" claim collapses, not because any single artifact is unbreakable, but because all three would have to be wrong together, and they corroborate one another.

Notice what made this painless: nothing was assembled in a scramble after the call. The flow produced every piece automatically, and retention kept it reachable. Strip out one habit — no returned receipt, or no retained signature, or clocks so far out of sync that the timeline is ambiguous — and the same dispute becomes a stalemate of assertions. Non-repudiation is precisely that difference between "here is the evidence" and "it is our word against theirs."

When Structured Receipts Are Worth It

For most internal and partner transfers, the do-it-yourself trail — sign, verify, log, receipt, retain — is proportionate and effective. But some relationships, particularly regulated business-to-business exchanges, benefit from a protocol that bakes signed receipts into every message as a standard. That is what the AS2 protocol's signed delivery receipts provide, and our Group I article on the AS2 MDN as proof of delivery explains how they work. The trade-off between rolling your own receipts and adopting a receipt-carrying protocol is the subject of the next article; the short version is to match the ceremony to the stakes and to what your partner requires.

Putting It Together

Non-repudiation is not a product you switch on; it is a habit of leaving evidence. Understand the two directions — proving origin and proving receipt — and gather the elements that speak to each: signatures for who, logs for what and when, hashes for which bytes, receipts for did-it-land, timestamps to line it all up. Be honest that this evidence is strength, not certainty, and that the leap from "the key did this" to "this party is liable" is a legal one you support rather than settle. Design the flow to produce the trail automatically, rehearse the denials in advance, and keep everything — including the public keys — long enough to matter.

From here, proof-of-delivery patterns outside AS2 shows how to get receipt evidence on ordinary channels, and building an evidence pack for a disputed transfer walks through assembling all of this into something that holds up months later.

Frequently Asked Questions