Hash, signature, attestation and provenance: what’s the difference?

The previous chapter introduced the need for evidence. Here we clarify the objects we encountered: hash, attestation, provenance, signature. The order matters: first identify the content, then the claim, the kind of information it carries, and finally what lets us authenticate it.

1 — Hash: which content are we talking about?

A hash connects bytes to a computed value, also called a digest. For our archive:

SHA256(payment-service-4.7.2.tar.gz)
→ 3a16...9f21

The calculation is deterministic: the same bytes produce the same digest. A change normally produces a different digest. The values in this chapter are fictional and abbreviated; a complete SHA-256 digest contains 64 hexadecimal characters.

The comparison concerns content identity, under the security assumptions of the cryptographic hash. It tells us neither why the bytes differ nor which file is legitimate. Two archives containing the same sources may differ because of recorded timestamps or compression, for example.

A hash identifies the content. It does not identify its history.

Its role in our mental model is specific: allowing a statement to identify the content concerned, independently of its name. The author, builder and process cannot be inferred from the digest.

2 — Attestation: what are we claiming about that content?

An attestation carries a structured claim about a subject. The digest identifies that subject; the claim says what we are declaring about it.

Simplified conceptual example, not a normative format:

{
  "subject": {
    "name": "payment-service-4.7.2.tar.gz",
    "sha256": "3a16...9f21"
  },
  "claim": {
    "tests": "passed"
  }
}

The same subject could have several claims associated with it: tests passed, release approved, built from a specific commit. Identifying the archive is therefore not enough: we must read what is being claimed.

Our example specifies neither the test suite nor its execution conditions. Its structure makes it easier to read, without supplying that missing information. It is not a usable in-toto Statement; we will examine the actual structure in the next chapter.

An attestation thus answers a different question from a hash. It gives us a claim to examine, whose precision, completeness and truth still need assessment.

3 — Provenance: what do we know about production?

Provenance is a category of information concerning an artifact’s origin or production. It may describe sources, the commit, builder, parameters, dependencies or materials, process and environment.

Compare two claims about the same digest:

• “The release tests passed” describes an evaluation.
• “This artifact was produced from this commit by this builder” describes production: it is a provenance claim.

Provenance can be carried by an attestation. Not every attestation is provenance.

Provenance therefore belongs within the declared information. It is not an extra envelope wrapped around a signature. Here is the statement portion of an attestation containing production information:

This view introduces the in-toto structure: subject identifies the archive, predicateType indicates the kind of claim, and predicate carries the associated data. The word “provenance” is a teaching label here: the real format identifies the type using a URI. The data and display are simplified and do not reproduce an official provenance schema.

SLSA provides, among other things, a provenance model, which we will study in chapter 04. Provenance is a broader concept than that particular model.

4 — Signature: which key stands behind the claim?

We now know what needs signing: a specific statement about identified content.

MESSAGE + PRIVATE KEY → SIGNATURE
MESSAGE + SIGNATURE + PUBLIC KEY → VERIFICATION

Under the cryptographic scheme’s assumptions, a signature lets us verify the relationship between signed content and a key, along with that content’s integrity. The private key is used for signing; the public key enables verification.

Two decisions remain distinct: is the signature valid with this key? And why do we accept this key for this delivery? A key is not automatically a person, a company or a legitimate authority. The trust model defines its acceptance and permitted uses.

Pay attention to the scope of the signature, too: signing the message protects the message. If the archive changes while the message stays intact, the signature can remain valid. Comparing the archive with the declared digest reveals the mismatch.

5 — The four mechanisms side by side

Mechanism	Main question	What it connects	What it does not guarantee
Hash	Which content are we talking about?	Bytes to a computed digest.	Legitimate origin, authorship or safe content.
Attestation	What is being claimed about this object?	A subject to a structured claim.	A true, complete or signed claim.
Provenance	How was this artifact produced?	An artifact to its declared production conditions.	A true or complete account.
Signature	Which key stands behind this statement, and has the statement changed?	The exact signed content to a key, under the relevant cryptographic assumptions.	The key’s authority or the truth of the statement.

These mechanisms are not four levels of certainty. Each establishes or describes a different relationship. Finding a digest in a document does not mean that document describes production; finding a signature does not tell us whether its key is accepted.

6 — Four distinctions to keep

• VALID HASH ≠ LEGITIMATE ORIGIN. An attacker can correctly compute a digest for malicious-payment-service.tar.gz. Accepting the reference remains a separate decision.
• ATTESTED ≠ TRUE. Putting a claim into structured fields does not make it accurate.
• SIGNED ≠ TRUE. “All tests passed” can be signed even if the system tested the wrong commit or an insufficient suite.
• VALID SIGNATURE ≠ TRUSTED SIGNER. A valid signature with an unknown key does not authorize that key to speak for the supplier.

Cryptography can make a claim verifiable. It does not turn a claim into truth.

These limits do not make the checks useless. They let us describe their scope without confusing integrity, attribution, authorization and an accurate account of events.

7 — A map of relationships and checks

The artifact yields the digest that identifies the subject. The attestation connects that subject to a claim; in our example, the claim contains provenance. The signature covers the signed representation of that statement. The recipient then checks these relationships against their references and trust policy.

Every part of the document is already present before signing. The movement guides our reading of the relationships; it does not depict a document being progressively built. Encodings and the signature envelope are omitted. Provenance appears inside the statement, never as a stage added after signing.

Each check can produce a different result. Keep the four comparison cases, assuming an unchanged reference digest and a single authorized key:

Case	Archive digest	Message signature	Authorized key
Reference package	Matches	Valid	Yes
Only the archive changes	Differs	Still valid	Yes
Test result changed in the message, without signing again	Matches	Invalid	Yes
Same message signed again with another key	Matches	Valid with that other key	No

This table does not deliver a security verdict. It identifies where a relationship changes. Provenance enables further comparisons: is the declared commit the expected one? Is the builder accepted? These checks do not replay the recorded events.

8 — What about Continuum Attest?

Continuum Attest 0.1.0 combines several of these mechanisms to record information about pipeline execution and support its verification through receipts. Signing is explicitly enabled; recomputing hashes from the workspace is a separate check. These capabilities guarantee neither the truth of every statement nor software security.

9 — The model to remember, then the object to open

• Hash identifies content.
• Attestation carries a structured claim about a subject.
• Provenance describes information about its production or origin.
• Signature lets us check the signed content and its relationship to a key; accepting that key depends on the trust model.

An attestation needs a structure to identify its subject, indicate the kind of claim and carry the associated data. In the in-toto Statement, we will find subject, predicateType and predicate.

That is precisely what we will open in the next chapter: after discovering the problem in chapter 01 and clarifying the concepts here, we will examine an actual attestation. Chapter 04 will then explore SLSA Provenance.

03 — Anatomy of an in-toto attestation