Securing Audit Logs: Detecting Withheld Records in Hash Chains

The "Tip Truncation" Problem in Hash Chains

Hash chains, where each record includes the hash of its predecessor, effectively detect alterations or deletions of *existing* records. If an entry in the middle of a chain is changed or removed, subsequent hashes will no longer match, making the tampering evident. This provides strong integrity guarantees for the data that has been *published* and *received* by a verifier. However, a significant vulnerability arises when the publisher can decide *which* records to publish. The article refers to this as "tip truncation," where the newest record, often the most critical (e.g., a negative audit finding or a poor benchmark result), is simply withheld from publication. Because there is no successor record to link to it, this omission is silent and undetectable by merely inspecting the received chain.

Ineffective Repairs and Their Limitations

• Publishing to Two Independent Places (Mirroring): While mirroring helps detect divergence (different content in different locations), it fails against non-publication. If the same malicious publisher controls both feeds, they can simply withhold the problematic record from *both*, resulting in perfectly agreeing but incomplete mirrored chains.
• Adding More Cryptography (Signatures): Signing a transcript over the entire sequence proves *who* approved *those specific bytes*. However, it cannot prove that *other bytes should have existed* or were produced and then suppressed. A signature over silence remains silence; it doesn't create an obligation for future records.

Effective Solutions: Forward Commitments and External Attestation

To counter tip truncation, the article proposes two primary mechanisms:

1. Forward Commitments with Deadlines: The current record commits, in advance, to the existence of the next record by a specific deadline. This commitment is signed into the current record alongside its payload and predecessor hash. If the deadline passes and the successor record is not published, the silence itself becomes an observable event, detectable by any verifier holding the current record. The crucial aspect is that this deadline must be chosen *before* the content of the next record is known and cannot be unilaterally changed afterward.
2. Leveraging Accidental External Ordering: The strongest form of independence comes from records written for unrelated purposes by third parties. For example, if a code change review record is produced by an independent reviewer (for their own objectives) and links to a commit hash, and the developer's internal change record also links to the same hash, then the ordering and existence claims can be verified using the independent platform's clock and metadata. This provides an external, unsteered attestation, making it harder to suppress or falsify events related to that commit.