Checksum: detecting accidental data corruption
A checksum is a small, fixed-size value computed from a block of data and stored alongside it so that corruption can be detected later. You compute the checksum when the data is written, and you recompute it when the data is read back; if the two differ, the data changed. In ZIP the checksum is CRC-32, stored for every entry, and it is what produces the familiar "bad CRC" error when a file did not arrive intact.
The key idea — and the one people get wrong — is that a checksum proves integrity, not authenticity. It reliably catches accidental damage: a truncated download, a bad disk sector, a noisy transfer. It does not stop an attacker who deliberately changes the data, because anyone can recompute a matching checksum. That boundary is what separates a checksum from a cryptographic hash or a signature.
How a checksum is computed
A checksum works by folding the entire data block down to a small value using a deterministic function — usually some form of polynomial division or arithmetic over the bytes. The function is keyless: there is no secret, only a well-known algorithm, so anyone can compute the same result from the same bytes. ZIP’s CRC-32 divides the data by a fixed generator polynomial and takes the 32-bit remainder; the classic Unix sum command simply adds up the bytes. Both turn arbitrary input into a short fingerprint.
Because the output is small, many different inputs can share the same checksum — these are called collisions, and they are mathematically inevitable. The design goal is not to avoid collisions entirely but to make accidental collisions astronomically unlikely, so that a random change (a flipped bit, a dropped block) almost never produces a matching checksum. A 32-bit CRC is good enough at this that a random corruption landing on a matching value is vanishingly improbable.
Checksums vs cryptographic hashes
A checksum and a cryptographic hash (like SHA-256) look similar — both are fixed-size fingerprints of data — but they are engineered for different threats. A CRC or sum is designed to catch accidental, random errors cheaply and fast; it is linear and easy to manipulate. A cryptographic hash is designed to resist deliberate manipulation: finding an input that produces a chosen hash, or two inputs with the same hash, must be computationally infeasible. CRC-32 fails that test trivially.
That is why you can use a CRC to verify a file survived a download, but you must not use it to verify a file came from who you think and was not tampered with. For authenticity you need a cryptographic hash published over a trusted channel, or better, a digital signature. ZIP’s CRC-32 is an integrity tool; treating a passing CRC as proof of authenticity is a category error.
Where ZIP uses its checksum
ZIP records a CRC-32 for every entry, computed over the entry’s uncompressed data and stored in both the local file header and the central directory. On extraction the tool decompresses the entry, recomputes the CRC over the recovered bytes, and compares it to the stored value. A match means the data is intact; a mismatch means corruption crept in somewhere — the compressed stream, the decompression, or the storage — and extraction is flagged for that file.
This runs for every entry regardless of compression method: a Stored entry and a DEFLATE-compressed entry are checked the same way, because the CRC is over the original data, not the compressed bytes. Integrity is independent of how the bytes were encoded.
When a checksum is not enough
A checksum answers one question: "did the bytes change by accident?" It cannot answer "did someone tamper with this?" or "who created this?" For those you need cryptography layered on top — digital signatures (like the META-INF signatures on signed JARs and APKs), or authenticated encryption such as ZIP’s WinZip AES extension. A zip bomb will pass every checksum perfectly: it is not corrupt, it is just maliciously large. The checksum confirms integrity; threat assessment is a separate concern, covered under security and privacy.
Frequently asked questions
What is a checksum?
A checksum is a small fixed-size value computed from a block of data and stored with it, so corruption can be detected by recomputing and comparing. ZIP uses CRC-32, a 32-bit value computed over each entry’s uncompressed data. A matching checksum means the bytes are intact; a mismatch means they changed. Checksums catch accidental damage, not deliberate tampering.
Is a checksum the same as a hash?
They look similar but serve different purposes. A checksum like CRC-32 is designed to catch accidental, random errors cheaply and is easy to manipulate. A cryptographic hash like SHA-256 is designed to resist deliberate manipulation — finding an input for a chosen hash, or two inputs with the same hash, must be infeasible. Use a checksum for integrity and a cryptographic hash or signature for authenticity.
Why does ZIP use CRC-32?
Because CRC-32 reliably detects accidental corruption — a truncated download, a bad sector, a noisy transfer — at very low cost, and that is exactly what an archive needs per entry. It is computed over each entry’s uncompressed data and verified on extraction. It is not cryptographic, so it is unsuitable for tamper detection, but it is an excellent integrity check.
Can a checksum detect tampering?
No. A checksum is keyless and (for CRC) linear, so an attacker who changes the data can simply recompute a matching checksum and the archive will verify cleanly. Checksums detect accidental, random corruption reliably but provide no protection against a deliberate attacker. For tamper-resistance you need digital signatures or authenticated encryption.
What does a CRC error mean?
It means the CRC-32 the tool computed over the decompressed data does not match the value stored in the archive. That is an integrity error pointing to accidental corruption — a partial download, a failing disk, or a damaged copy. Re-downloading or re-copying the archive typically resolves it; it is not a security event.