Skip to content

Glossary

Content addressing

Content addressing identifies a digital object by a digest of its bytes rather than solely by its storage location.

Provenance and citation

Content addressing derives an identifier from the content of a digital object, usually with a cryptographic hash. Identical bytes produce the same digest under the same algorithm, and changing the bytes ordinarily changes the digest. The algorithm and representation are part of the meaning: a reformatted PDF or re-encoded image can have different bytes while conveying similar information.

In practice, a digest can tie a citation or review decision to a particular file version and detect accidental or unauthorized modification. The file still needs metadata describing its origin, acquisition and interpretation. A digest cannot recover missing content by itself, and it cannot establish who authored the bytes. Long-term records should retain the algorithm name and support migration if an algorithm becomes unsuitable.

For defensible evidence, content addressing helps distinguish a stable version from a mutable URL. A retained source copy supplies the bytes; chain of custody records handling; provenance connects the version to claims and transformations. Content identity is valuable, but it is not the same as factual truth or source authority.

Example

A Halden Therapeutics AG (fictional) filing copy has a recorded SHA-256 digest, so a reviewer can check that the later file matches the reviewed bytes.

How a digest names an object

Content addressing computes a cryptographic hash of an object's bytes and uses the digest as the object's name. The hash functions in common use are specified in the NIST Secure Hash Standard, FIPS 180-4, which includes SHA-256. A good hash function makes it infeasible in practice to find two different objects with the same digest or to alter an object without changing its digest, so the name doubles as an integrity check. The IETF specification RFC 6920 defines a standard URI form for names based on hashes. Distributed storage systems such as IPFS build addresses from digests, and the Git version-control system stores every object under the hash of its content. The Wikipedia article summarises the general idea of content-addressable storage.

Two properties follow. Identical content gets the same name wherever it is stored, so duplicates are detected for free. And a reference by digest is a reference to exact bytes, not to whatever a location currently holds, which is why it suits evidence: a citation that includes the digest of the retained copy lets any later reader confirm that the copy is the one that was cited.

What a digest does not tell you

A digest proves that bytes are unchanged; it does not prove that they are true, authentic or complete, and it does not say who made them. A digest also names one serialisation. The same data in JSON with a different key order or whitespace has a different digest, so for structured data one must first canonicalise, for example with the JSON Canonicalization Scheme in RFC 8785, before hashing. And the digest of a rendered page changes with every dynamic element, so a digest of the page is only useful for a stored copy, not for the live URL.

To establish when a digest existed or who vouched for it, add a trusted timestamp or a signature, as discussed under chain of custody. Choose the hash function with an eye to its lifetime: functions weaken over time, so record the algorithm with the digest and be prepared to re-hash retained material with a stronger function while the originals are still available.

A worked example

A team retains a regulator's PDF notice about Halden Therapeutics AG (fictional). On capture it computes the SHA-256 digest of the file and stores the file under that digest in an object store configured to refuse overwrites. The decision memo cites the digest, the original URL and the retrieval time. Later the regulator posts a corrected notice at the same URL. The new file has a different digest and is stored as a second object. The memo still resolves to the original bytes, and a short note records that a corrected version exists, with its own digest. A reviewer comparing the two sees the exact differences. A system that named the file by its URL would have shown the corrected notice and silently invalidated the memo's basis.

Checks a reviewer can run

Recompute the digest of a sample of stored objects and compare with the recorded value. Confirm that the store rejects overwrites of an existing digest with different bytes. Confirm that the algorithm is recorded with each digest. Confirm that structured data are canonicalised before hashing, by hashing the same data serialised two ways. Confirm that citations carry the digest, and that a citation resolves to the object by digest without relying on the original URL.

Related terms and boundaries

Content addressing identifies bytes, and a canonical identifier identifies an entity. It is the mechanism behind trustworthy retained source copies, a building block of chain of custody, and the antidote to link rot, because the name does not depend on where the object lives.

Common misreadings

  • Treating a digest as proof of authorship or truth.
  • Omitting the hash algorithm.
  • Assuming semantically equivalent files have identical hashes.

Related terms

Appears in

  • Retaining source copies

    Preserve the material actually read, subject to rights, and bind its citation with a content digest.

Found an error on this page? See corrections for what counts as one, how to report it and the dated log.

Enquiry

Where does "Content addressing" bear on a decision of yours?

This entry sits under provenance and citation. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.

Or write to [email protected] in your own words.