Chapter 2Cryptographic Provenance

§2.1 Scope

Provenance is a verifiable account of who did what, in what order, and when, that a third party can check without trusting the party that produced it. The word is borrowed from art and archives, where it means the documented chain of custody of an object; here the object is a record, a file, a commit, or an action, and the documentation is cryptographic. The chapter defines the objects, gives the constructions used in this library and in SSX360's tooling, and states the criteria by which evidence is graded.

§2.2 Definitions

A message $m$ is a byte string: the exact contents of a file, a record, or a serialised action. Its digest is

where $H$ is SHA-256 [RFC6234]. Two messages with the same digest are, for practical purposes, the same message; a digest therefore names a message without containing it.

A signature $\sigma ={\mathrm{Sign}}_{sk}(m)$ is produced with a secret key and checked with the corresponding public key by ${\mathrm{Verify}}_{pk}(m,\sigma )$. Ed25519 [RFC8032], [BDLSY12] is used throughout this library. The constructions that follow are signature-agnostic: the platform's tooling also supports the post-quantum signature schemes ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), and a receipt records which scheme signed it. Signing a digest rather than the message itself is equivalent under the assumptions above and is what is done in practice.

A receipt is a signed record of one action. In the form used here it contains the actor's identifier $A$, the actor's sequence number $n_A$, a timestamp $t$, the digest $d$ of the action's serialised content, and the previous chain head $h_{i-1}$:

A ledger is an append-only sequence of receipts. Its chain head after $i$ receipts is

The construction is that of Haber and Stornetta [HS91]; the use of a tree rather than a chain, where many receipts must be committed at once, follows Merkle [M87].

§2.3 Append-only ledgers and gap detection

A signed receipt proves what an actor said. It does not prove that the actor said nothing else. An adversary who controls the store can drop receipts, and a reader who sees only the survivors has no way to know. Per-actor sequence numbers close this hole. Each actor numbers its receipts $1,2,3,\dots$ without gaps, and a verifier, having collected every receipt it can find for actor $A$, checks that the set of sequence numbers is $\{1,\dots ,\max n_A\}$. A missing number is a gap, and a gap is evidence of withholding, whatever the explanation.

The chain head makes the same guarantee across actors and across time. Because $h_i$ commits to every earlier receipt, a signature over any head commits to the whole prefix. Publishing heads periodically, or exchanging them with a counterparty, turns the ledger into something that cannot be rewritten without the rewrite being detectable from a single stale head.

A verifier for such a ledger checks, for each receipt, that the signature verifies under the actor's public key, that the receipt's $h_{i-1}$ equals the recomputed head of the prefix, that the recomputed $h_i$ equals the stored head, and that sequence numbers are contiguous per actor. It reports the first failure and stops. By the convention of §1.2 the verifier is written independently of the writer.

§2.4 Signing at the point of creation

The moment at which a signature is made matters as much as the key that makes it. A signature applied when a record is created binds the record to its author at the time of the act. A signature applied later, over a record that has been sitting in a store, binds only the signer's later belief about what the record was. The difference is the whole content of provenance.

Matrix Scroll, the open-source protocol described under Software, applies this principle to software development: it signs each commit at commit time with the developer's Ed25519 key, records the result in a form that continuous-integration systems can check, and gates pipelines on that verification. The same principle applies to laboratory measurements, where the receipt is written by the acquisition software at the moment the spectrum is saved (§3.5), and to the findings in this library, each of which is released with its digest and, where signed, a signature over that digest.

§2.5 Independence

Provenance evidence is only as good as the independence of the party checking it. Three rules follow. The verifier holds no signing keys for the systems it verifies. The verification criteria are published, so that anyone can apply them and reach the same verdict. And the verifier's implementation is separate from the writer's, so that shared defects do not cancel. These rules are a standing constraint on SSX360's work and on the tooling released from it.

§2.6 MCV-1

MCV-1 is an open, versioned, framework-agnostic set of criteria for machine-verifiable evidence. It does not prescribe a system; it states what a record must satisfy for a verifier to grade it, and it grades records by the three evidence properties of §1.5:

The levels are cumulative. MCV-1 sits beneath whatever framework an organisation is assessed against; it says nothing about policy and everything about whether the evidence offered for a policy can be checked by a machine. Its text is published by SSX360.

§2.7 Application in this library

Every finding released here is published with its Markdown source and the SHA-256 digest of that source, computed over the exact bytes served. Where a finding is signed, the Ed25519 signature is made over the ASCII hexadecimal digest and printed beneath it; the public key is given under Citing. Corrections change the digest, and are recorded in the Errata. The procedure for verifying a finding is given in Finding 2026.1 and summarised under Help.