Treating bits as polynomial coefficients
CRC interprets message bits as binary polynomial coefficients and computes a remainder under a generator polynomial. Addition and subtraction are XOR without integer carries, unlike an ordinary byte sum.
A basic width-w model appends w zeros before division. Verification recomputes the check value or tests a prescribed residue. Initial values, reflection and final XOR in actual formats mean that residue is not universally zero.
References: [1]
A width does not identify a CRC variant
A full convention specifies polynomial, register initialization, input and output reflection, and final XOR. Saying “32-bit CRC” does not ensure agreement; stored byte order must also match the format.
A gzip member stores a CRC-32 of the uncompressed data, and RFC1952 supplies a table-based example. Different acceleration techniques can implement the same function only when parameters and processing conventions agree.
Detecting errors is not authenticating origin
In the basic model, error patterns divisible by the generator can pass undetected. Detection properties depend on the polynomial and error pattern; passing a CRC is not proof that no change occurred.
The public calculation has no secret key. Someone changing both message and check value can recompute a matching result; active forgery requires an appropriate authentication mechanism. CRC also does not automatically locate or repair the error.