Non-Repudiation: What a Signature Proves, and What It Doesn't

Two months after a large payment goes out, the person whose name sits on the approval says they never approved it. Your logs disagree. Whether that ends the argument or starts a long and expensive one was decided months earlier, by whoever designed the approval flow.

Non-repudiation is the property that makes a denial fail. Confidentiality, integrity and availability describe the state of information. This one is about a person, and it has to survive being challenged months later.

An audit log is not proof

A log says the system recorded that user X did this. That sounds conclusive until someone contests it, at which point there are three easy answers: your log is wrong, someone tampered with it, or my account was used by somebody else. None of them are unreasonable. Unless the record is cryptographically bound to something only that one person controls, the denial stays credible and the log does not settle anything.

This is the difference between accountability and non-repudiation. Logs give you the first. The second has to be engineered in advance, because you cannot go back and bind evidence to an action after the argument has started.

It is also what separates non-repudiation from authenticity. Authenticity establishes who you are dealing with at the time. Non-repudiation is the durable version of that idea: the proof still has to stand up months later, in front of someone with every reason to deny it.

Four things have to hold together

Non-repudiation is not a single mechanism. It is four things bound into one claim, and removing any of them hands the denial back its credibility:

Who?        Identity      a certificate ties the key to a named person
What?       Integrity     a hash fixes exactly what was signed
Only them?  Sole control  only that person can use the private key
When?       Trusted time  a timestamp fixes the moment it happened

Three of these are usually present because the technology supplies them. The one that goes missing is sole control, and it goes missing for organizational reasons rather than technical ones: the signing key lives in a shared service account, or a vendor holds and operates it, or it sits unprotected on a laptop where malware can take it. In each case more than one party could have produced the signature, so the signature proves the act happened but not who is accountable for it.

Trusted time looks like a technicality until someone claims they signed after their certificate was revoked. Then it becomes the whole case.

Why a shared key can never do it

If two systems exchange messages protected by a shared secret, such as an HMAC, the tag proves the message was not altered and that it came from someone holding the key. It cannot prove which of the two. Both parties hold the same secret, so either could have produced any tag, and no third party can tell them apart.

Non-repudiation requires asymmetry: a secret held by exactly one accountable party. That is not a detail of the algorithm, it is the entire mechanism.

The question worth asking about non-repudiation

When a project reports that transactions are signed and therefore non-repudiable, there is one question that separates the claim from the reality: who holds the signing key, and can you show that only the accountable person could have used it?

If the answer involves a shared account, a key the vendor can operate, or a key with no hardware protection, then you have signed transactions. You do not have undeniable ones, and it is worth saying so plainly before a dispute does it for you. Escrowing a signing key is the clearest version of this mistake: escrow destroys sole control by definition, which is why signing keys and encryption keys should never be governed by the same policy.

Non-repudiation is not a product you buy or a setting you turn on. It is something you either engineered before the dispute, or you did not.

Frequently asked questions

What is non-repudiation?

Non-repudiation is the property that makes a denial fail. Confidentiality, integrity and availability describe the state of information, while this one is about a person and has to survive being challenged months after the act. It is the durable form of authenticity: authenticity establishes who you are dealing with at the time, and non-repudiation still has to stand up later, in front of someone with every reason to deny it.

Is an audit log enough to prove someone approved something?

No. A log says the system recorded that a named user did this, which sounds conclusive until it is contested, at which point there are three easy answers: the log is wrong, someone tampered with it, or the account was used by somebody else. None of those is unreasonable. Unless the record is cryptographically bound to something only that one person controls, the denial stays credible. Logs give you accountability, while non-repudiation has to be engineered in advance, because you cannot bind evidence to an action after the argument has started.

What does non-repudiation actually require?

Four things bound into a single claim, and removing any one of them hands the denial back its credibility. Identity, so a certificate ties the key to a named person. Integrity, so a hash fixes exactly what was signed. Sole control, so only that person can use the private key. And trusted time, so a timestamp fixes the moment it happened. Three are usually present because the technology supplies them, and the one that goes missing is sole control, which fails for organizational reasons rather than technical ones.

Why can a shared key or an HMAC not provide non-repudiation?

Because both parties hold the same secret, so either could have produced any tag and no third party can tell them apart. The tag proves the message was not altered and that it came from someone holding the key, but never which someone. Non-repudiation requires asymmetry: a secret held by exactly one accountable party. That is not a detail of the algorithm, it is the entire mechanism.

Does escrowing a signing key affect non-repudiation?

It destroys it by definition, because escrow means a second party can obtain and use the key, and that removes the sole control the whole claim rests on. This is why signing keys and encryption keys should never be governed by the same policy. Escrow is often correct for an encryption key, where losing the key means losing the data, and always wrong for a signing key, where a signature somebody else could have produced proves the act happened but not who is accountable for it.