Defining the checked data
Verification needs an algorithm, coverage boundary and treatment of the check field itself. A reader applies the same convention, but distinct data can still yield the same value.
For example, gzip checks uncompressed bytes with CRC-32, whereas the Internet checksum uses 16-bit one’s-complement addition. These values are not interchangeable, and excluded fields gain no protection from a check over other bytes.
End-around carry in the Internet checksum
RFC1071 pairs bytes into 16-bit words and adds them with end-around carry. Generation clears the field and stores the complemented sum; verification includes that field and accepts an all-ones sum. Odd-length input pads the final group as specified.
Preserving byte parity permits grouping, reordering and wider accumulation before folding. Those properties enable speedups but also leave some rearrangements or compensating changes indistinguishable. Speed does not imply sensitivity to every error pattern.
References: [1]
Incremental updates need the correct arithmetic
A small field change can update the check without rereading everything. One’s-complement arithmetic has positive and negative zero, so ordinary-looking algebra can fail at boundaries. RFC1624 corrects an earlier incremental formula.
A successful check excludes only discrepancies the method detects. An active attacker may change the data and check together, so authentication needs a keyed mechanism or another suitable construction. Recovery, backups and correction remain separate tasks.