CRC32 Checksum

CRC32: it catches accidental corruption, not malicious tampering

What CRC32 actually is

CRC treats the data as a binary polynomial and divides it by a fixed generator polynomial; the remainder is the checksum. CRC32 produces 32 bits, shown as 8 hexadecimal characters.

Its design goal is to detect accidental bit errors from transmission and storage at very low cost. It is guaranteed to catch every single-bit error, every burst error up to 32 bits long, and the vast majority of longer bursts. That is exactly why it shows up in Ethernet frames, ZIP and PNG files, gzip streams, and essentially every flash and disk controller: in those environments the errors are random, not crafted by an adversary.

Why it is not a security control

CRC32 is linear: CRC(a ⊕ b) = CRC(a) ⊕ CRC(b) after adjusting for length. That means an attacker can compute directly which bytes to append so the modified data keeps the identical CRC — no brute force, just a single arithmetic step.

On top of that, the output is only 32 bits, so a blind guess succeeds with probability 1 in 2³². That sounds tiny, but it poses no obstacle whatsoever to an automated attack.

So: CRC32 can tell you "the downloaded file was corrupted in transit", never "the file was swapped by an attacker". For the second question you need SHA-256 or a digital signature.

CRC32 next to related ideas

Variants and implementation details

Several CRC32 parameters vary by context, which is why two implementations can return different values for the same input:

• Generator polynomial: the most common is 0xEDB88320 (the reflected form, corresponding to 0x04C11DB7), known as CRC-32/ISO-HDLC and used by ZIP and PNG; CRC-32/BZIP2 uses a different set of parameters.
• Initial value: commonly 0xFFFFFFFF.
• Input and output reflection: whether each byte's bit order is reversed.
• Final XOR value: commonly 0xFFFFFFFF.

If the checksum you compute disagrees with a tool or a publisher, check these parameters before assuming the data is corrupt. Because the parameters are a convention rather than part of the value, two parties exchanging CRCs must agree on them separately; a parameter mismatch is the most common reason a checksum appears not to verify. This tool uses the same set as ZIP and PNG (CRC-32/ISO-HDLC) and shows both hexadecimal and decimal forms.