Content-Addressed Storage: What a Content ID Can Verify

Content-addressed storage (CAS) lets you retrieve data by its content, not its location. A content ID (CID) can verify that the data you receive is exactly the data you requested, and that it has not been altered, corrupted, or substituted. This is the core promise of CAS: the address itself is a cryptographic fingerprint of the content.

Formula

The number of blocks is simply the file size divided by the block size, rounded up:

Number of blocks = ⌈file size / block size⌉

Where file size is in bytes, block size is in bytes, and ⌈⌉ means round up to the nearest integer. The SHA-256 hash is computed by a cryptographic algorithm; its output is a 64-character hexadecimal string. The calculator above computes the block count; the hash itself is typically generated by software (e.g., IPFS, Git, or a tool like `sha256sum`).

Worked Example

Using the defaults: file size = 1,000,000 bytes, block size = 262,144 bytes (256 KiB).

1. Divide: 1,000,000 / 262,144 ≈ 3.8147
2. Round up: ⌈3.8147⌉ = 4 blocks

So a 1 MB file is split into 4 blocks. The actual SHA-256 hash of the entire file would be a 64-character hex string, unique to that exact byte sequence.

Background: From Location to Content

Traditional storage systems use location-addressed references: you ask for “file at path /home/user/report.pdf� or “sector 1234 on disk.� The address tells you where to look, but says nothing about what you’ll find there. If the file is modified, the path stays the same—you might get a different version without knowing.

Content addressing flips this. The identifier (the CID) is derived from the content itself, typically by hashing the data with a cryptographic hash function like SHA-256. The CID is the hash (or a base-encoded form of it). When you request a CID, the system verifies that the data it finds hashes to that CID. If the data has been altered, the hash won’t match, and the system rejects it.

How a Content ID Verifies Integrity

When you fetch data by CID, the verification process is:

1. Retrieve the data from the network or disk.
2. Compute the hash of the retrieved data using the same algorithm that generated the CID.
3. Compare the computed hash to the CID.
4. If they match, the data is authentic and unmodified. If they don’t, the data is corrupted or malicious.

This verifies integrity (data hasn’t changed) and authenticity (data is what was originally addressed). It does not verify who created the data or whether the content is true—only that it is exactly the byte sequence that was originally hashed.

What a CID Can and Cannot Verify

Can verify:

• Data integrity – no accidental corruption during transfer or storage.
• No tampering – if someone changes even one bit, the hash changes.
• Deduplication – identical content produces the same CID, so storage can be deduplicated.
• Immutable references – once a CID is published, the content it points to cannot change (unless you deliberately create a new CID).

Cannot verify:

• Provenance – who created the data or when.
• Semantic correctness – whether the data is factually true or useful.
• That the CID is “officialâ€� – anyone can create a CID for any content.

How to Choose a Hash Function

Not all content IDs are created equal. The hash function determines the security and length of the CID. Common choices:

• SHA-256 – 256-bit output, widely used, considered secure. Used in IPFS, Git, and many blockchains.
• SHA-1 – 160-bit output, now considered weak (collision attacks are possible). Avoid for new systems.
• BLAKE3 – fast, 256-bit output, increasingly popular.

For most applications, SHA-256 is the safe default. The CID length grows with the hash size; a SHA-256 CID in base32 is about 59 characters.

Common Problems and Misconceptions

“The CID tells me the file is safe.� No—it only tells you the file is unchanged. A malicious file can still have a valid CID.

“Content addressing is only for blockchains.� No—it’s used in file systems (IPFS), version control (Git), backup systems, and even in some databases.

“If I change the file, the CID changes.� Yes, that’s by design. To update content, you create a new CID and update the reference.

“CIDs are human-readable.� Not really. They are long strings of base32 or base58 characters. They are meant for machines, not humans.

Comparison: Content vs. Location Addressing

Location addressing is simple and fast: you know exactly where to go. But it breaks when files move, are renamed, or are modified without updating references. Content addressing is self-verifying and works across distributed systems, but it requires a lookup step (a DHT or a database) to find where the content is stored. It also makes in-place edits impossible—you must create a new version.

Costs and Trade-offs

Content addressing adds computational overhead: hashing every block costs CPU time. For large files, this can be noticeable. Storage overhead is minimal—just the hash itself (32 bytes for SHA-256). The bigger cost is in the lookup infrastructure: a distributed hash table (DHT) or a central index is needed to map CIDs to locations. This is why CAS is not always the best choice for local, single-disk storage where location addressing is simpler and faster.

Safety and Security Considerations

Content addressing is not a security silver bullet. An attacker can create a CID for malicious content and trick you into fetching it. To establish trust, you need additional mechanisms: signed CIDs, a trusted publisher, or a reputation system. Also, hash collisions are theoretically possible (though astronomically unlikely with SHA-256). For high-security applications, use a hash with at least 256 bits of output and keep the hash function updated as cryptanalysis advances.

Alternatives to Content Addressing

If you need mutable references, you can use a content-addressable layer on top of location addressing (e.g., a database that maps keys to CIDs). Or you can use a pointer system like a symbolic link, but that loses the integrity guarantee. Another alternative is merkle trees, where the root hash verifies the entire tree—this is a form of content addressing used in Git and many blockchains.

Frequently Asked Questions

How is a content ID different from a URL?

A URL points to a location (e.g., a server and path). A content ID is a hash of the content itself. If the content moves to a different URL, the URL changes, but the CID stays the same. If the content changes, the CID changes, but the URL might not.

Can a content ID be used to verify the author of a file?

No. A CID only verifies the exact byte content. To verify authorship, you need a digital signature from the author, which is a separate mechanism.

Does content addressing prevent data loss?

No. It helps detect corruption, but if the data is deleted from all storage locations, the CID becomes unresolvable. You still need backups and redundancy.

Is content addressing used in everyday applications?

Yes. Git uses SHA-1 (and now SHA-256) to address commits. IPFS uses CIDs for files. Many package managers (like npm) use integrity hashes. Even some operating systems use content addressing for package management.

Can I generate a content ID for any file?

Yes, you can run a hash function (like SHA-256) on any file to get a content ID. But for it to be useful in a CAS system, the system must be able to find the file by that hash.

What happens if two different files have the same content ID?

That would be a hash collision, which is extremely unlikely with a strong hash like SHA-256. If it happens, the system would treat them as the same file, which could cause confusion. This is why cryptographically secure hashes are essential.

Related

• UA702 Circuit: What the Op Amp Does and What to Check
• How Long Do iPhones Last Before You Need to Replace One?
• Replacement Fuse Compatibility: What to Check

in t | File size (bytes) | bytes | 1000000 | 1 | 1000000000000
in d | Block size (bytes) | bytes | 262144 | 1 | 1000000000
out blocks | Number of blocks | - | ceil(t / d) | 0
out sha256 | SHA-256 hash (hex) | - | - | 0