Skip to main content

Checksums

A checksum is a small, fixed-size value computed from a block of data and used to detect accidental corruption — a bit flipped by a noisy cable, a packet mangled in transit, a file that got truncated mid-transfer. The idea is deliberately simple: run the data through a function, keep the result alongside the data, and if the receiver recomputes the same function and gets a different answer, something changed along the way.

Checksums show up at nearly every layer of the OSI Model at once, quietly running underneath almost everything else this module covers: Ethernet frames carry a CRC at Layer 2, IP and TCP/UDP headers carry their own checksums at Layers 3 and 4, and applications often add their own on top at Layer 7. Corruption can be introduced at any one of those layers, so integrity checking happens at more than one of them independently rather than trusting a single layer to catch everything.

How it works​

System Design Lab

The sender computes the checksum once and transmits it alongside the data. The receiver recomputes the same function over the data it actually received and compares the two values. A mismatch proves the data changed in transit; a match is strong evidence (not an absolute guarantee, depending on the algorithm) that it didn't.

Checksums vs. cryptographic hashes​

This is the distinction most worth being precise about in an interview: a checksum and a cryptographic hash solve related but different problems.

  • Checksums (parity bits, Fletcher's checksum, CRC-32) are designed to be fast to compute and good at catching accidental, random corruption — exactly the kind introduced by flaky hardware or network noise. They are not designed to resist a deliberate adversary: given a target checksum, it's often computationally easy to construct a different payload that produces the same value.
  • Cryptographic hashes (SHA-256 and similar) are deliberately slower and designed so that finding two different inputs with the same output (a collision) is computationally infeasible. That property is what makes them suitable for security-sensitive integrity checks — verifying a downloaded file hasn't been tampered with, not just accidentally corrupted.

The practical rule: use a cheap checksum when you only need to catch random bit errors efficiently (which is all a network protocol layer typically needs), and use a cryptographic hash when an adversary might deliberately try to produce a matching value.

Where checksums show up in real systems​

  • Network protocols — IP, TCP, and UDP headers each carry a checksum covering (at least) their own header, catching corruption introduced by a bad link or a buggy piece of network hardware before the payload is even handed up to the application.
  • File transfer and downloads — published SHA256SUMS files alongside software downloads let you verify a file wasn't corrupted (or, given the algorithm choice, tampered with) in transit.
  • Data replication — when comparing whether two replicas actually hold identical data, checksums (often over ranges or entire tables) are far cheaper than shipping and diffing the raw data itself; see Data Replication.
  • Storage systems — filesystems and databases that care about "bit rot" (slow, silent disk-level corruption) store checksums alongside blocks specifically to catch corruption that would otherwise go unnoticed until the data is read and found to be wrong.

It's worth noticing the family resemblance to other lightweight, probabilistic techniques covered elsewhere in this course: a checksum trades perfect certainty for cheap computation, in the same spirit as a Bloom Filter trading a small false-positive rate for constant-time membership checks. Neither is "wrong" — they're both deliberate engineering trades of a small, well-understood error rate for a large gain in speed or space.

Why this matters in an interview​

If a design involves verifying that data arrived intact or that two copies match, naming "checksum" as the mechanism — and being ready to say whether a simple checksum or a cryptographic hash is appropriate — is a concrete, checkable detail that's easy to skip past. It's a small piece of vocabulary, but it signals you're thinking about integrity as an explicit property of the design, not an assumption.

Using checksums (vs. cryptographic hashes) for integrity: pros and cons​

Pros

  • Very cheap to compute — suitable for running on every packet or block without meaningful overhead
  • Effective at catching the random, accidental corruption that hardware and networks actually produce
  • Small fixed size regardless of how much data it's protecting

Cons

  • Not designed to resist deliberate tampering — collisions can often be engineered on purpose
  • A match is evidence of integrity, not a mathematical guarantee, depending on the algorithm's strength
  • Wrong tool for security-sensitive verification, where a cryptographic hash is required instead

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.