Category: Digital Preservation
Checksum
Also known as: digital fingerprint
Simply put
A checksum is a small value calculated from the contents of a file or message that acts like a digital fingerprint for that data. If even a single byte of the file changes, the recalculated checksum will differ from the original, which signals that the data may have been altered or corrupted. Comparing checksums taken at different times therefore helps confirm whether digital content has remained unchanged.
Formal definition
A checksum is a value computed from a block of digital data by a function whose output depends on the contents of that data, used to detect accidental errors or unauthorized manipulation. In recordkeeping and digital preservation contexts, checksums support fixity: a checksum generated at the point of capture can be recomputed and compared over time to verify that a record's bitstream has retained its integrity through storage, transfer, or migration. Because even a minimal change to the underlying data typically produces a substantially different checksum value, checksums provide evidence relevant to the integrity and, by extension, the authenticity of a record. Note that a checksum verifies bit-level fixity only; it does not by itself establish provenance, and the strength of manipulation detection depends on the algorithm used, which falls outside the scope of this definition.
Why it matters
For records managers and digital preservation practitioners, the enduring value of a digital record depends on being able to demonstrate that its content has not changed since capture. Checksums provide a practical, evidence-based mechanism for making this demonstration. By generating a checksum when a record is first captured and recomputing it at later points, an organization can detect whether the underlying bitstream has been altered during storage, transfer, or migration. This supports the integrity property that distinguishes an authoritative record from an unverified copy, and it underpins fixity monitoring within a broader digital preservation strategy.
Who it's relevant to
Digital preservation practitioners
Those responsible for maintaining records over the long term rely on checksums as a core fixity tool, recomputing and comparing values across storage cycles and migrations to detect bit-level corruption before it compromises the usability of preserved content.
Records managers
Records managers use checksum evidence to support claims about a record's integrity, helping to distinguish an authoritative record whose bitstream is demonstrably unchanged from copies or drafts whose fixity has not been verified. Checksums address integrity at the bit level and do not, on their own, establish provenance or authenticity in full.
IT and storage administrators
Administrators managing repositories, backups, and transfers can incorporate checksum verification into workflows to confirm that files have been copied or moved without accidental error, flagging any discrepancy for remediation.
Compliance and audit staff
Where an organization must show that records have not been tampered with or degraded, checksum comparisons offer supporting evidence of integrity over time, though the strength of manipulation detection depends on the algorithm chosen, which is a separate consideration.
Inside Checksum
Fixed-length value
A checksum is a value, typically of fixed length, computed from the contents of a file or data set by applying an algorithm. The value serves as a compact representation derived from the underlying bytes.
Hashing or checksum algorithm
The method used to generate the value, ranging from simple checksum functions to cryptographic hash functions. The choice of algorithm affects how reliably differences in content are detected, and some older algorithms are now considered weaker for detecting deliberate tampering.
Integrity verification function
The primary purpose in recordkeeping contexts is to support the integrity property of a record by allowing later recalculation and comparison. If the recomputed value matches the stored value, the content is generally taken to be unchanged; a mismatch indicates that some change has occurred.
Stored reference value
The originally computed checksum retained as a point of comparison, often held alongside metadata about the record. Its usefulness depends on the reference value itself being protected against alteration or loss.
Scope of coverage
A checksum verifies the bitstream it was computed over. It typically does not, on its own, establish who created content, when, or whether the content is authentic in the recordkeeping sense, which depends on additional metadata and controls.
Common questions
Answers to the questions practitioners most commonly ask about Checksum.
Does a checksum guarantee that a record is authentic or genuine?
No. A checksum supports verification of integrity by helping detect whether the bit-level content of a record has changed since the checksum was generated. It does not, on its own, establish authenticity in the recordkeeping sense, which concerns whether a record is what it purports to be and was created or captured by the purported source. Authenticity typically depends on additional contextual controls, metadata, and evidence about the record's origin and custody, so a matching checksum should be understood as one contributing indicator rather than proof of genuineness.
Is a checksum the same as a digital signature or a form of encryption?
No, these serve different purposes and should not be conflated. A checksum is intended to detect unintentional or accidental changes to content, but a plain checksum offers no protection against a deliberate actor who can recompute the value after altering the record. A digital signature typically binds an identity to content and can support both integrity and origin claims, while encryption is concerned with confidentiality by restricting who can read the content. Depending on organizational policy and risk, these mechanisms may be used together, but a checksum by itself does not provide the assurances associated with signatures or encryption.
At what points in the records lifecycle should checksums typically be generated and verified?
In many implementations, a checksum is generated at or near the point of capture, so that a baseline value exists for the record as first brought under control. Verification is then often performed at defined intervals, at points of transfer between systems or custodians, and before actions such as migration or disposition. The precise timing depends on organizational policy, the value and risk profile of the records, and the capabilities of the systems involved, so practices vary considerably across environments.
What should an organization do when a checksum verification fails?
A verification failure indicates that the current content no longer matches the previously recorded checksum, which may signal corruption, unintended alteration, or an error in the verification process itself. Typical responses, depending on organizational policy, include isolating the affected record, investigating the cause, and considering restoration from a verified copy or backup where one exists. Because a failure can have implications for the reliability and usability of a record, it is often advisable to document the event and the remediation steps taken.
How does checksum use relate to migration and format transformation of records?
During migration between systems or transformation between formats, checksums are often used to confirm that the content being moved has not been altered in transit. It is important to note that a checksum verifies the specific bitstream it was calculated over, so if a format transformation intentionally changes the underlying bits, the original checksum will no longer match the transformed object. In such cases organizations typically record the original checksum, capture a new checksum for the transformed version, and retain documentation linking the two to preserve an auditable chain.
Should checksum values be stored with the record or kept separately, and how might they be documented?
Approaches vary depending on system design and organizational policy. Checksum values are commonly retained as metadata associated with the record and may also be held in a separate register or audit log so that the record and its integrity evidence do not depend solely on a single store. Documenting the algorithm used, the date of generation, and the outcomes of subsequent verifications can help support the ongoing integrity and usability of the record over time, though the specific documentation practices adopted differ across environments.
Common misconceptions
A matching checksum proves a record is authentic and reliable.
A checksum primarily supports integrity by indicating that content has not changed since the value was computed. Authenticity and reliability are distinct properties that depend on evidence of origin, context, and controls over creation and capture, which a checksum alone does not establish.
Any checksum guarantees that tampering will be detected.
Simpler checksum algorithms are designed mainly to catch accidental corruption and may be weaker against deliberate manipulation. The level of assurance depends on the algorithm chosen and on protecting the stored reference value; no single method should be treated as an absolute guarantee.
A checksum confirms that a file is still usable or readable.
A checksum only reflects whether the underlying bitstream matches its reference value. Usability also depends on factors such as format viability and available software, so an unchanged checksum does not by itself demonstrate that a record remains usable over time.
Best practices
Generate a checksum at the point of capture or ingest and record it alongside the record's metadata, so a reliable reference value exists from the outset.
Protect the stored reference value against alteration or loss, since integrity checking is only meaningful if the comparison value is itself trustworthy.
Select an algorithm appropriate to the risk, recognizing that simpler checksums suit accidental-corruption detection while stronger cryptographic hashes are generally preferred where deliberate tampering is a concern.
Recompute and compare checksums on a periodic basis and after transfers or migrations, and document the results as evidence supporting the integrity property of the records.
Treat checksum verification as one control among several rather than as standalone proof of authenticity or reliability, complementing it with controls over creation, capture, and access.
Establish a defined response for checksum mismatches, including investigation, restoration from a trusted copy where available, and recording of the event.