Checksums and Data Integrity
A checksum is a short fingerprint of data that lets anyone detect corruption or confirm that bytes are exactly what they should be.
Proving the bytes are intact
Data can be corrupted in transit, in storage, or by a faulty copy. A checksum is a fixed-length value computed from data such that any change to the data almost certainly changes the checksum. By recording a file's checksum when it is created and recomputing it later, anyone can confirm the bytes have not changed, no trust required.
Checksums versus cryptographic hashes
Simple checksums like CRC32 catch accidental corruption cheaply but can be fooled deliberately. Cryptographic hashes such as SHA-256 are designed so that it is infeasible to find two inputs with the same output, so they detect both accidental and malicious changes. Scientific archives use cryptographic hashes because the record must be tamper-evident, not merely error-checked.
Uses
- Verify a download or copy transferred without error.
- Detect silent corruption in long-term storage (bit rot).
- Content-address data: use the hash as the identifier.
- Deduplicate: identical content has identical hashes.
Content addressing
When a hash is used as a data's identity, the identifier is a fingerprint of the exact bytes. Referring to data by hash makes the reference self-verifying: fetch the data, recompute the hash, and you know you got the right thing. This underpins robust versioning and provenance.
In the published record
The Kronos deposited datasets carry checksums so that a future reader can confirm the files match the originals exactly. Reproduction workflows check regenerated outputs against recorded hashes at the byte level where determinism allows, and against a stated tolerance where numerics require it. The checksum is what turns intact into provably intact.