Matching Digests Do Not Identify the Seller Who Created a File

A file digest can be useful in a used-equipment transaction, but matching digests and identifying an author answer different questions. A digest comparison supplies evidence about the compared file contents under the chosen algorithm and comparison method. It does not identify who created the file or establish the truth of statements inside it. This article separates integrity comparison, attribution and marketplace claims, so a buyer can ask for the evidence appropriate to each conclusion.

What a Digest Actually Establishes

NIST describes hash functions as mapping a message to a fixed-length digest. To interpret a comparison, a reviewer should know which algorithm and which inputs were used. A difference in computed digests indicates a difference under that comparison; a match is not mathematical proof that no distinct input could share the digest. The result is useful evidence for an integrity check, with limits that should remain explicit.

The same NIST discussion describes collision resistance as making it computationally infeasible to find different inputs with the same hash. That is a security property, not a claim about the person who supplied a file. It should not be read as a universal guarantee for every algorithm bearing a hash label. A transaction record should identify the method and trusted comparison value rather than infer authorship from the existence of a digest.

Why Digest Equality Does Not Identify a Seller

A possible misunderstanding in marketplace conversations runs like this: "If the digest matches, the seller must have provided the original file." This inference is flawed in several ways. First, a digest is public information. Anyone who possesses a file can compute its digest and publish it. A seller can publish a digest without being the author of the file; a buyer can compute a digest without having any relationship to the seller. Second, identical files can be produced independently. Two parties can generate the same configuration file from the same template, or receive the same standard document from a manufacturer, without any transfer between them. Digest equality supplies a comparison result, subject to the algorithm’s limits; it does not explain how the files came to be associated.

From the definition of a hash function and the property of collision resistance, it follows that a digest comparison alone does not identify an author, explain a change, or prove a claim made within a file. This inference is worth stating explicitly. It does not say that digest comparison is useless—it is clearly useful for integrity checking. It says that digest comparison, by itself, answers none of the three questions that transaction records most need to answer: Who created this content? What changed between versions? What does this file assert about the equipment? Each of these questions requires additional information beyond the digest.

Where Attribution Actually Comes From

If digests do not identify authors, what does? The answer lies in provenance descriptions—structured records that connect entities (files, equipment, reports) to activities (calibration, inspection, handover) and agents (people, organizations, systems). The W3C PROV Primer introduces entities, activities, and agents for describing provenance: things, processes involving things, and responsible actors. These concepts provide one way to organise attribution statements. An entity is the thing being described—a file, a robot controller, a calibration certificate. An activity is the process that produced, modified, or transferred the entity. An agent is the actor responsible for the activity.

When a used-equipment transaction record includes provenance information, it can answer attribution questions that a digest alone cannot. For example, a record might state that a particular calibration report (entity) was generated by a calibration activity performed on a specific date by a named technician (agent). The digest of the report confirms that the file has not been altered since the activity was recorded; the provenance description identifies who performed the activity and when. Both pieces are necessary; neither substitutes for the other.

The Difference Between Recording and Proving

There is a subtle but important distinction between writing a provenance description and establishing that the description is true. Provenance descriptions record relationships; writing such a description does not itself establish that every assertion is true. This point is critical for marketplace trust. A seller can write a provenance record claiming that a file was produced by a particular activity at a particular time. The buyer can verify that the record is well-formed and internally consistent. But the buyer cannot, from the record alone, verify that the claimed activity actually occurred as described. Additional evidence—independent logs, witness statements, cross-referenced documentation—is needed to corroborate the provenance assertions.

A provenance assertion should remain an assertion until its supporting evidence is evaluated. The technical articles offer related reading, but navigation to an explanation cannot verify a particular transaction. A record that attributes a file to an actor can be examined and challenged; its structured appearance does not make it self-certifying.

Applying This to Marketplace Claims

Consider a hypothetical scenario: a seller in a used-robot marketplace publishes a configuration file for a controller along with its digest and a brief provenance note stating that the file was exported from the controller before shipment. The buyer computes the digest and finds a match. What has been established? The buyer has observed a matching digest, subject to the algorithm, comparison procedure and trust in the published reference value. The buyer does not yet know whether the file accurately reflects the controller's actual configuration at the time of export, whether the export activity occurred as described, or whether the seller was the agent who performed the export. These are marketplace claims—assertions about the equipment and the transaction—that require more than digest comparison and more than a single provenance assertion.

For a transaction record, an editorial approach is to keep integrity comparisons, provenance assertions and corroborating documents in separate fields. The article archive can be used to find further explanations of those concepts, rather than being treated as a repository of verified buyer records. Keeping the fields distinct makes it clearer which question each piece of evidence addresses and which question still needs an answer.

Questions Worth Asking Before Trusting a File

Rather than asking "Does the digest match?" as the sole verification step, buyers and record-keepers might consider a sequence of more informative questions. First, what does this file describe, and is it the right kind of document for the claim being made? Second, what provenance information accompanies it, and does it connect the file to a specific activity and agent? Third, can the provenance assertions be corroborated by other records—maintenance logs, inspection reports, shipping documents? Fourth, who computed the published digest, and was that computation performed in a context that the buyer can evaluate? Fifth, does the marketplace platform provide any mechanism for disputing or annotating provenance claims?

These questions do not require advanced technical infrastructure. They require a clear understanding of what different types of evidence can and cannot establish. A digest is an integrity tool, not an attribution tool. A provenance description is a structured claim, not a self-verifying proof. A marketplace claim is an assertion that deserves scrutiny, not a fact merely because it is written down. Keeping these distinctions visible in transaction records—through careful annotation, explicit labeling of evidence types, and honest acknowledgment of what remains unverified—makes the records more useful and more trustworthy than any single cryptographic check could achieve on its own.