Hash Chaining: Detecting Changes in a Process History

What hash chaining means

In a linear hash chain, each new hash value is calculated from both the entry's content and its predecessor's hash value. This makes the sequence part of the cryptographic binding.

If an earlier entry is subsequently changed, its recalculated hash no longer matches the value used in the following entry. The mismatch propagates along the subsequent chain. Whether an internally consistent chain still matches the earlier state depends on the protected reference value.

A hash is a fixed-length digital check value calculated from data of any length. NIST describes secure hash algorithms as methods whose digests can be used to detect changes to messages since the digest was generated.^[1] A hash does not encrypt the data and generally does not allow its content to be recovered.

How a simple hash chain is constructed

The first entry contains its operational data and a defined starting value. The first hash is calculated from this specified representation. The second entry contains its own data and the first entry's hash. Its calculation therefore binds both stages together. Each subsequent entry continues this principle.

In simplified form, the calculation can be expressed as:

Hash(n) = H(Daten(n) + Metadaten(n) + Hash(n−1))

The actual implementation requires unambiguous encoding. Fields, their order, data types, character encoding, time zone, and treatment of empty values must be defined. Otherwise, two systems may serialize the same operational content differently and produce different hashes.

In addition to the payload, the calculation should include all information whose undetected alteration is to be identified. This may include the event identifier, sequence number, time information, object reference, event type, and version identifier. Metadata that is not included is not protected by the chain.

An altered copy no longer matches the secured chain state

A fictional log contains entries E-1 through E-4. For each entry, the event identifier, position, time information, operational payload, and predecessor hash are bound using a defined encoding. After E-4, the final hash H-4 is separately protected against undetected replacement.

In a copy submitted later, the measurement value in E-3 has been changed. If the supplied hashes are retained, recalculation reveals a mismatch at that point. If all subsequent hashes are recalculated instead, the copy may become internally consistent again—but its final value no longer matches the previously protected H-4.

The comparison applies only to the bound representation. If the unit were not included, for example, the chain would not detect a change to it. Selecting the protected fields is therefore as important as the chaining formula.

A trustworthy anchor makes verification reliable

The current final hash summarizes the chained state. If this value is protected separately from the entries, later recalculation can be checked against it. For external data verification, that reference point must also be reliably accessible outside the originating system. Possible anchors include a signed checkpoint, a protected separate system, a hardware security module, or an external timestamp.

The anchor must correspond to the period under review. A final hash secured today does not retrospectively establish that the chain had the same state yesterday. Regular checkpoints limit the period during which an undetected complete recalculation would be possible.

RFC 5848 combines hash values, sequencing, and cryptographically signed blocks for signed syslog messages. The method is intended to support message integrity, origin authentication, and detection of missing messages, among other things.^[2] It illustrates that hashes form a more comprehensive body of evidence only when combined with keys, signatures, order, and verification rules.

A verification mismatch narrows the finding

A different recalculated value shows that the submitted verification input does not match the expected reference value. In the example, the investigation can start with the altered entry E-3. The cause remains unresolved: an unintended change, a transmission error, and deliberate intervention require different further evidence.

Verification should therefore identify the representation used, the segment checked, and the reference state consulted. “Chain valid” without these details leaves it unclear whether the comparison used only supplied values or actually checked against a protected earlier state.

Detecting missing and reordered entries

If the calculation includes the sequence number and previous hash, removing an entry can break the connection between its neighbors. Subsequently swapping entries also changes the calculation for the affected sequence. This requires verification to begin at the known starting point and to have a reliable end anchor.

Gaps can nevertheless arise in different ways. A number may be missing because an entry was deleted, a transfer was incomplete, or a sequence position was reserved but never written. Technical detection therefore does not replace an investigation of the operational circumstances.

A distributed system may not have a single global order. Separate chains per batch, task, device, or data stream may then be more appropriate. The architecture must define which unit forms a chain and how its anchors are brought together.

Which properties the hash algorithm needs

A cryptographic hash algorithm should always produce the same digest for the same input and yield a substantially different value even for small changes. Three resistance properties are particularly relevant to integrity verification:

• Preimage resistance: Given a hash, it should not be practically feasible to determine a matching original input.
• Second-preimage resistance: Given a known dataset, it should not be practically feasible to find another dataset with the same hash.
• Collision resistance: It should not be practically feasible to construct two different inputs with identical hashes.

Security depends on the algorithm and its parameters. A custom checksum method or an obsolete hash algorithm may generate values technically without providing adequate cryptographic strength. Algorithms must therefore be identifiable and replaceable.

FIPS 180-4 specifies the SHA-2 family, among other algorithms. On March 7, 2023, NIST decided to revise the standard and remove the SHA-1 specification from it.^[1] For a long-term architecture, this means retaining not only the hash value but also the algorithm, version, and any parameters used.

A change of hash method must make clear which previously protected state the new binding covers. Merely recalculating the data currently available would not, by itself, preserve the historical reference. RFC 4998 addresses the renewal of archive timestamps and hash-based evidence for long-term evidence preservation.^[4] The architecture must define how a chain state enters such a long-term procedure.

Hash chaining and append-only logs complement each other

An append-only log specifies that new entries are added and earlier entries are not overwritten within the intended application model. Hash chaining provides an additional verification layer: it can make discrepancies in the stored sequence visible.

The two principles are not identical. A log can be maintained on an append-only basis without cryptographic chaining. Conversely, a hash chain can be built over exported files, document versions, or other ordered data that is not itself organized as an event store.

The writing model answers which changes the application permits. Chaining answers whether the data available later still matches the secured hash values. For a reliable history, both layers must work together with permissions, backups, and operations.

Corrections must not rewrite the chain

A permissible correction should not alter the original entry and recalculate every subsequent hash. That would erase precisely the history the chain is intended to keep identifiable. Instead, the correction is appended as another entry at the end of the relevant sequence.

The correction event references the affected original entry and describes the new content, reason, identity, and, where applicable, review. Its own hash binds the correction into the continuing chain. The current state takes both operations into account.

An audit trail keeps operationally and regulatorily relevant changes traceable. Hash chaining can support its technical integrity, but does not automatically supply the required meaning. A cryptographically intact entry without an understandable reason for the change remains inadequate in substance.

Linear chain or hash tree: Verification effort differs

Verifying a later final hash in a linear hash chain often requires reprocessing many preceding entries. Merkle trees enable compact proofs for individual entries and for consistency between tree states, as RFC 9162 describes for Certificate Transparency.^[5] Such proofs can also be combined with signatures and timestamps.

Technical integrity is only one layer

Data integrity encompasses completeness, consistency, and accuracy throughout the data lifecycle. Hash chaining supports the detection of subsequent discrepancies, but does not answer whether the original value was captured correctly.

Missing events may also remain undetected if they never entered the chain. Capture rules, interface controls, roles, time sources, backups, and restoration tests therefore remain necessary. Even the strongest cryptography cannot protect an operation the system did not record.

What hash chaining does not do

• It does not prevent changes. It can make a discrepancy detectable during verification.
• It does not prove substantive accuracy. Incorrect source data can be correctly chained.
• It does not automatically identify who caused a change. Authentication, signatures, and permission logs are needed for that.
• It is not a blockchain. Distribution, consensus, and a shared ledger are additional properties. ^[3]
• It does not remain secure without maintenance. Algorithms, keys, and long-term evidence must be monitored and renewed.

Only what is included in the binding is protected

The copy in the example can be compared with the earlier state only because the representation used for verification is defined and H-4 was protected separately. An internally consistent sequence alone would not be enough.

Assessing hash chaining therefore requires examining three specific elements: the bound fields, the ordered sequence, and the secured reference state. Together, they determine which changes later verification can detect.