Archivehashing
Content Addressing Is a Cache Key and a Contract
Hashing bytes to name them gives you free deduplication, immutable caching, and a verification step — if you keep the name honest.
- Published
- Reading time
- 1 min read
Content addressing replaces "where is it?" with "what is it?". The identifier is derived from the bytes, so the same content has the same name everywhere, and a fetch can be verified without trusting the transport.
Three useful consequences
- Immutable caching. A URL containing the digest can be cached forever; the bytes behind it cannot change without changing the URL.
- Deduplication. Identical blobs collapse into one object, across tenants if the hash is strong enough.
- Integrity on read. A client hashing the response detects corruption and tampering without a signature.
Two ways it goes wrong
Chunking sensitivity. Whole-file hashing gives poor dedup for large files that shift by a byte. Content-defined chunking (rolling hash boundaries) fixes this by making chunk boundaries depend on content, not offsets.
Trusting the name at write time. If the server accepts a client-supplied digest without recomputing it, an attacker can poison the store: name A maps to bytes B, and every future fetch of A is corrupt. Always hash on ingest.
Takeaway: the digest is a promise. Verify it when writing and when reading; anything less is just a filename with extra steps.