Writer computes a fingerprint. Reader recomputes and compares.
A checksum is 16 to 256 bits kept with the data. Equal means “almost certainly unchanged”; different means “definitely changed”.
Does a checksum repair the damage?
Bad: “It fixes flipped bits”
That’s error correction: ECC memory, erasure coding. They add enough redundancy to rebuild.
Good: It only notices
The good bytes come from a retransmission or another replica.
540
corrupted packets a day that slip past TCP
One server, 100,000 packets a second. On a bad path, 1 in 16 million hides an error from TCP. Add a CRC-32: one every 22,000 years.
Reorder the words. TCP’s sum doesn’t notice.
The Internet checksum adds 16-bit words, and addition ignores order. A CRC divides instead, mixing every bit into the result.
An MIT network checksummed every hop. Source files still came out corrupted.
The cause
One gateway swapped byte pairs while copying between buffers, then checksummed the damage. Every check passed. Only an end-to-end check catches that.
Pick the check by what you’re guarding against
Accidents: CRC-32C, close to free with the CPU instruction. Names and dedupe keys: SHA-256, about 16 times costlier. Attackers: HMAC, which adds a secret key.
Three ways a checksum vouches for bad data
- Computed after the damage, so it certifies garbage
- Stored inside its own block, so a misplaced block matches
- Used against attackers, who just recompute it
Remember
Compute a CRC-32C at the source, store it with the data, and verify it on every read and copy. Per-hop checks make retries rare; only the end-to-end check makes the result correct.