Checksum

The sender hashes the file, publishes the hash, and the recipient hashes what arrived. Equal hashes mean the bytes match, within the collision risk of the algorithm. RFC 3230 calls the HTTP version an instance digest: it covers the body, not the headers.

Length is a weaker test. A truncated file fails a size check. A file of the right length with a flipped bit passes it. FTP, in RFC 959, can finish a transfer and say so without a digest. The 226 reply means the data connection closed after the copy, not that the bytes match. Operators who treat that reply as integrity are skipping the check.

A publisher posts `firmware-4.2.bin`, 180,441,088 bytes, and SHA-256 `9c2e…`. The download reports 180,441,088 bytes. A local SHA-256 ends in `a71b…`. The file is the right size and the wrong object: a mirror served an older build, or a proxy cached the wrong key. Shipping stops. A second case is the multipart ETag. S3's ETag for a multipart object is not a whole-file MD5. Checking the download against that ETag fails a good file. The portable check is the SHA-256 the publisher computed before the upload.

Algorithm choice is part of the term. CRC-32 catches accidental line noise. MD5 and SHA-1 are broken for adversarial collision. A checksum that has to stop a swapped file needs SHA-256 or stronger, and it has to travel on a channel the attacker does not control. Publishing the hash on the same page an attacker can edit does not help. BEP 3 puts a hash on every piece so a bad peer is dropped at piece boundaries instead of after a 4 GB download.

People say checksum, hash, and digest for the same step. The useful distinctions are what was hashed (chunk, part, or whole file), which algorithm, and where the expected value came from.