Content-addressable Storage
Abbreviation: CAS. Also known as: content addressing, content-addressed storage.
Storing each object under a name derived from a hash of its bytes, so identical content has one address and any change creates a new one.
Synthetic dataExamples on this page use synthetic data created for illustration.
Definition
Content-addressable storage names each stored object by a hash of its bytes instead of by a chosen file name. Identical content gets the same address, so duplicates collapse into one copy, and any change to the content produces a new address.
In plain terms
In an ordinary file system the name says nothing about the content: a file can be changed and keep its name. In content-addressed storage the name is a fingerprint of the content. To read an object you ask for its fingerprint; to check it, you hash what you received and compare.
This gives deduplication and tamper evidence for free, and it makes stored evidence easy to cite: a reference to an address always means exactly those bytes. The version control system Git stores its objects this way.
Example
Two stored snapshots of a page, using SHA-256 (first 12 hex characters shown):
| Content | Address |
|---|---|
price: 19.99 | 7b440f3a6ce5… |
price: 19.99 (saved again) | 7b440f3a6ce5… (same: stored once) |
price: 19.98 | 635700e91e9d… (one character differs: a new, unrelated address) |
A report that cites 7b440f3a6ce5… can never silently start pointing at different content.
Common misunderstandings
- “A hash is encryption.” A hash does not hide content and cannot be “decrypted”; it only fingerprints it.
- “It proves who wrote the data.” It proves the bytes are unchanged, not their origin; that needs a signature.
- “Hash collisions are a practical worry.” With a modern hash such as SHA-256, accidental collisions are not a realistic concern.
References
- Scott Chacon, Ben Straub. Git Internals: Git Objects . Pro Git.
- FIPS PUB 180-4: Secure Hash Standard (SHS) . NIST, 2015.