Uses of Checksum

A checksum works because a small, fixed-size number is derived deterministically from every bit of a payload, so the receiver (or the storage layer) can recompute that number from the bytes it actually holds and compare: if a single bit changed anywhere, the recomputed value almost certainly won't match, and the mismatch is the signal that the data is no longer what was written or sent.

Everything checksums are "used for" is one variation on that recompute-and-compare loop. What differs from use to use is who recomputes, when, and what threat the comparison is meant to catch — and that last point is where most real-world mistakes (including the classic password myth) come from.

A worked trace: the 16-bit Internet checksum

This is the checksum in IPv4, TCP, and UDP headers (RFC 1071). It is a one's-complement sum: add the 16-bit words, and whenever the running total overflows 16 bits, add the carry bit back in ("end-around carry"). The sender stores the complement of that sum, chosen so that the receiver's total — data plus stored checksum — comes out to all ones.

Take four data words: 0x0001, 0xF203, 0xF4F5, 0xF6F7.

Folded sum = 0xDDF2. The transmitted checksum is its one's complement: ~0xDDF2 = 0x220D.

Clean receive. The receiver sums the four data words and the checksum: 0xDDF2 + 0x220D = 0xFFFF. Complement is 0x0000 → no error, accept.

One flipped bit. Suppose 0xF4F5 arrives as 0xF4D5 (one bit flipped). The data now folds to 0xDDD2; adding the unchanged checksum gives 0xDDD2 + 0x220D = 0xFFDF, whose complement is 0x0020 ≠ 0 → error detected, reject. That single non-zero result is the entire value the checksum delivers.

Where this loop actually shows up

The legitimate uses collapse into three families, each just relocating "who recomputes and when":

• Integrity in transit. Every layer stacks its own: Ethernet frames carry a 32-bit CRC (the Frame Check Sequence), IP/TCP/UDP carry the Internet checksum above, and application downloads publish a SHA-256 next to the file. A packet whose recomputed value fails is dropped, and TCP's acknowledgement machinery retransmits it. This is one mechanism repeated at every hop, not seven different tricks.
• Integrity at rest (bit rot). Disks silently flip bits over months. ZFS and Btrfs store a checksum per block; PostgreSQL and InnoDB store one per page. On every read the layer recomputes and compares, so corruption surfaces as a loud error instead of silently poisoned query results — and on redundant storage the bad copy is repaired from a good replica.
• Content addressing & deduplication. Git names every object by the hash of its contents; rsync and backup systems skip blocks whose hashes already exist; storage layers drop duplicate chunks that hash identically. Here the checksum is used as an identity, not just an alarm — same digest is treated as “same content.” This is the correct reading of the old “prevent duplicates” bullet: it works only with a collision-resistant hash, never CRC32.

Fixing the password myth (why the naive version is wrong)

The original page claimed systems “store the checksum of a password instead of the password.” Storing a bare digest of a password is a real, exploited vulnerability, and a checksum is the wrong primitive for three independent reasons:

• No salt → rainbow tables. If everyone's password maps to the same digest, an attacker precomputes digests for billions of common passwords once and cracks your whole leaked table by lookup. Correct password storage salts each entry with unique random bytes so identical passwords produce different stored values.
• Too fast → brute force. CRC32 and even SHA-256 are designed to be blazing fast; a GPU tries billions per second. Password storage must be deliberately slow and memory-hard. That is the entire purpose of bcrypt, scrypt, and Argon2 — a tunable cost factor so each guess costs the attacker real time and RAM.
• Checksums have easy collisions. A CRC32 has ~4 billion outputs; collisions are trivial to construct, so an attacker could log in with a different string that checksums to the same value. Password verification needs collision resistance CRC never offered.

Correct statement: passwords are stored as a salted, slow key-derivation hash (Argon2id today), not a checksum. The login flow superficially resembles recompute-and-compare, but the threat model is an adversary with your database, not a flipped bit — and that changes the required primitive entirely.

When to use it, and when NOT to

Reach for a plain checksum (CRC32, Adler-32, Internet checksum) when the signal you're chasing is accidental corruption from noisy channels, cosmic rays, or aging disks, and you want detection that costs almost nothing per byte. The decision hinges on one question: is the party who might alter the data an adversary, or just physics?

Choose a checksum when the enemy is noise and you control both ends — TCP segments, disk blocks, backup integrity. Prefer a cryptographic hash when an attacker might substitute a lookalike file and you can publish the expected digest somewhere they can't touch (a signed release page). Prefer HMAC or a signature when the attacker can also see and rewrite the digest in flight — a checksum or bare hash gives zero protection there, because they simply recompute it over their forged payload. Prefer a password KDF the moment the secret is a human password. Using CRC32 where you needed HMAC is a real breach class, not a micro-optimization.

Pitfalls

• Mistaking a checksum for tamper protection. A checksum sent alongside the data stops nothing malicious: an attacker edits the payload and rewrites the checksum. This is the single most common conceptual error — integrity against noise is not integrity against an adversary.
• CRC collisions for identity/dedup. Using a 32-bit CRC as a content key means ~1-in-4-billion odds two different blocks collide and one silently overwrites the other. Use a wide cryptographic hash for content addressing; reserve CRC for error detection.
• The undetectable error patterns. The Internet checksum misses any set of changes that cancel out in the sum — swap two bytes, or flip bits that offset, and it passes. CRC32 is far stronger against burst errors, which is exactly why link layers use CRC, not a plain sum.
• Checksum offloaded, then corrupted after. NICs compute/verify TCP checksums in hardware; the packet is then DMA'd and handled in RAM, where a bad memory module can corrupt it after the check passed. End-to-end checks (application-level SHA) exist precisely because per-hop checks don't cover the gaps between hops.
• Truncating or reusing a strong hash as if strength scaled down. Taking the first 4 bytes of SHA-256 gives you a 32-bit collision space again; the strength lives in the full width.

Takeaways

• Every use of a checksum is the same recompute-and-compare loop; only who recomputes and which threat they fear changes.
• Checksums detect accidental corruption cheaply — in flight (TCP, Ethernet CRC), at rest (ZFS, DB page checksums), and as content identity (Git, dedup, with a strong hash).
• They provide no protection against a deliberate attacker; that requires a keyed MAC or a signature, because a plain checksum or hash can be recomputed over forged data.
• Never store passwords as a checksum. Passwords need a salted, deliberately slow KDF (Argon2id, bcrypt) — a different tool for a different threat model.

Re-authored and deepened for this guide. Worked example follows RFC 1071 (“Computing the Internet Checksum”); CRC behavior from Koopman's cyclic-redundancy-check work; storage-integrity examples from the ZFS and PostgreSQL documentation; password-storage guidance from OWASP's Password Storage Cheat Sheet and the Argon2 (RFC 9106) and bcrypt specifications. The password-verification claim in the original page was incorrect and has been replaced.