What Is a Checksum? How CRC, Luhn, and SHA-256 Detect Errors

Every Ethernet frame you have ever sent carries a 32-bit checksum. The frame check sequence at the end of each frame is a CRC-32 value computed over the payload, and the receiving network card drops the frame silently if the value does not match. This has been happening continuously since IEEE 802.3 standardized the practice in 1983.

So what is a checksum, exactly? It is a small value computed from a block of data, designed to detect accidental changes from noise, corruption, or transmission errors. The key word is accidental. A checksum is not a security mechanism. Anyone can recompute a CRC and forge a matching value. For tamper resistance you need a cryptographic hash or a MAC.

This post covers the common checksum families: cyclic redundancy checks like CRC-32 and CRC-64, the mod-10 Luhn algorithm on your credit card, ISBN check digits, and where cryptographic hashes fit. I work through a Luhn calculation step by step. You can test any of these with the checksum calculator as you read.

A checksum detects accidental errors. It does not detect deliberate tampering. This distinction matters more than any other point in this post.

Error detection works because transmission and storage corruption is random. A flipped bit in a network frame or a bad sector on a disk produces a value that almost certainly does not match the stored checksum. The receiver recomputes the checksum, compares it to the transmitted value, and discards the data if they differ.

Tamper detection is a different problem. An attacker who changes the data can also recompute the checksum and substitute the new value. CRC-32, Adler-32, and Luhn all fail here. They are public algorithms with no secret key. A cryptographic hash like SHA-256 resists this because finding an input that produces a specific hash output is computationally infeasible, but even a bare hash can be recomputed by an attacker. For true tamper resistance you need a keyed MAC such as HMAC, which mixes a secret key into the hash computation.

The OWASP Cheat Sheet Series covers this distinction in its data integrity guidance. The short version: use CRC for accidental errors, use HMAC for adversarial tamper detection.

Cyclic redundancy check algorithms treat the data as a polynomial over the binary field GF(2) and divide it by a fixed generator polynomial. The remainder of that division is the CRC value. This is polynomial long division where addition and subtraction are both XOR.

CRC-32 uses a specific 33-bit generator polynomial. The result is a 32-bit value appended to the data. The receiver performs the same division and checks whether the remainder is zero. CRC is standardized in ISO/IEC 13239, and CRC-32 specifically appears in Ethernet frame check sequences, zlib compressed streams (RFC 1950), PNG chunks, and gzip headers (RFC 1952).

RFC 1950, the ZLIB Compressed Data Format Specification, also defines the Adler-32 checksum as an alternative. Adler-32 is simpler and faster than CRC-32 on weak hardware but detects fewer error patterns. The RFC describes it as "an extension and improvement of the Fletcher checksum."

CRC detects burst errors up to the polynomial degree very effectively. CRC-32 catches all burst errors of 32 bits or fewer, and over 99.99% of longer bursts. It does not catch all possible errors, and it provides zero security against intentional modification.

The Luhn algorithm is a mod-10 checksum invented by Hans Peter Luhn at IBM. He filed the patent in 1954, and it was granted as US Patent 2,950,048 on August 23, 1960. The patent title is "Computer for Verifying Numbers," and it describes a mechanical device with belts and slots for computing check digits.

Luhn's algorithm validates credit card numbers, IMEI codes on mobile phones, and various identification numbers. It catches all single-digit errors and most transposition errors (it misses adjacent transpositions of 0 and 9, which produce the same mod-10 result).

Here is a worked Luhn calculation for the number 79927398713:

``` Number: 7 9 9 2 7 3 9 8 7 1 3 Position: 11 10 9 8 7 6 5 4 3 2 1 (from right)

Double every second digit from the right (positions 2, 4, 6, 8, 10): Position 2: 1 x 2 = 2 Position 4: 8 x 2 = 16 -> 1 + 6 = 7 Position 6: 3 x 2 = 6 Position 8: 2 x 2 = 4 Position 10: 9 x 2 = 18 -> 1 + 8 = 9

Undoubled digits (positions 1, 3, 5, 7, 9, 11): 3, 7, 9, 7, 9, 7

Sum all processed digits: 7 + 9 + 9 + 4 + 7 + 6 + 9 + 7 + 7 + 2 + 3 = 70

70 mod 10 = 0 -> Valid checksum ```

The check digit (the final 3) is chosen so that the total sum is divisible by 10. You can verify any credit card number with the Luhn algorithm tool.

Book identifiers use two different check digit schemes. ISBN-10 uses a weighted sum modulo 11. Each digit is multiplied by its position (10 for the first digit, down to 1 for the last), and the sum must be divisible by 11. The check digit can be 0 through 10, with X representing 10.

ISBN-13 uses the same mod-10 scheme as EAN-13 and UPC-A barcodes. Digits are multiplied by alternating weights of 1 and 3, and the check digit makes the total divisible by 10. This is similar to Luhn but with a different weighting pattern.

These schemes catch transcription errors. A librarian typing an ISBN into a catalog system gets immediate feedback if a digit is wrong. They do not catch deliberate fraud, since anyone can compute the correct check digit for a fabricated number. You can validate book numbers with the ISBN-13 checksum tool.

A cryptographic hash like SHA-256 can serve as a checksum with tamper resistance. If you publish the SHA-256 hash of a file alongside the file itself, anyone can verify that their copy matches by recomputing the hash. If a single bit changes, the hash changes completely.

The difference between SHA-256 and CRC-32 is collision resistance. Finding two inputs that produce the same CRC-32 is trivial. Finding two inputs that produce the same SHA-256 is computationally infeasible, which is what makes it useful for software integrity verification, blockchain commitments, and digital signatures.

SHA-256 is defined in FIPS 180-4, the Secure Hash Standard published by NIST. The standard specifies the SHA-2 family of hash functions, including SHA-256 and SHA-512. BLAKE3 is a newer alternative that produces 256-bit hashes and runs significantly faster on modern hardware while maintaining collision resistance.

The tradeoff is speed and output size. CRC-32 produces 4 bytes and runs in nanoseconds. SHA-256 produces 32 bytes and runs slower. For error detection on a network frame, CRC-32 is the right choice. For verifying that a downloaded installer has not been modified, SHA-256 is the right choice. You can generate SHA-256 values with the SHA-256 hash generator.

Every checksum algorithm in this post detects accidental errors. Only the cryptographic hashes resist deliberate modification, and even those need a key (via HMAC) to protect against an attacker who can recompute the hash.

CRC-32 has a 32-bit output. The probability that a random corruption passes the check is 1 in 2^32, or about 1 in 4.3 billion. For most network and storage applications that is sufficient. For long-lived archival storage, consider CRC-64, which drops the false-pass probability to 1 in 1.8 x 10^19.

Luhn catches single-digit errors and most transpositions. It does not catch swapped non-adjacent digits, and it does not catch errors where two digits are both wrong in compensating ways. It is a validation check, not a security control.

Adler-32 is weaker than CRC-32 for short messages. For messages under 128 bytes, Adler-32 can miss certain error patterns that CRC-32 would catch. RFC 1950 acknowledges this tradeoff and allows either algorithm in zlib streams.

Checksums detect accidental corruption. Cryptographic hashes detect intentional modification. The two problems look similar but require different tools. Use CRC-32 for network frames and compressed data. Use Luhn for credit card validation. When an adversary might modify the data, reach for SHA-256 or HMAC instead. Compute and verify any of these with the checksum calculator.