Victoria's Code STA / 01
GCS — build log

Sealing the Black Box: Making the Tape Tamper-Evident

The recorder is append-only, which makes it honest but not tamper-evident. It still trusts whoever holds the file. This post chains every event to the last, so changing any past entry breaks the whole chain after it. There is no quiet edit.

My recorder is append-only. That makes it honest, but not yet tamper-evident, and it took me a while to notice the difference. An append-only log still trusts whoever holds the file — if someone can reach the raw storage, they can rewrite it and the log itself won't complain. This post closes that gap: an edit is now detectable, even by someone with full access to the file.

The tape doesn't just record. It proves it wasn't touched.

Append-only isn't enough

Append-only is a policy, enforced by my code and my database. But a policy assumes the attacker plays inside my system. A real adversary would bypass the app entirely and edit the storage directly. Against that, "the code won't let you" means nothing.

What you want is a record where any change — to any past event — is mathematically obvious, without needing to trust the storage, the app, or the person holding the disk.

The idea: chain every event to the last

Each event carries a fingerprint of its own contents and the fingerprint of the event before it. Every entry seals in the entire history that came before it. Parang tanikala (like a chain) — each link locks onto the previous one.

Change any past event, even a single character, and its fingerprint changes — which breaks the next event's reference to it, which breaks the one after that, all the way to the end. One tiny edit invalidates the entire rest of the chain. There is no quiet edit.

You don't have to trust the file. You verify the chain. If it's intact, the history is intact — every event, in order, unaltered.

Detect, not prevent

An honest distinction I want to keep straight, kasi (because) it would be easy to oversell this: it makes tampering evident, not impossible. Someone with full disk access can still overwrite the whole tape. What they can't do is change part of it and have it still verify — and they can't forge a valid continuation without the signing key.

That's the right bar for a black box. A flight recorder doesn't stop a crash. It guarantees that afterward, the record you pull is the truth.

Signing the endpoints

The chain proves internal consistency. Signing proves origin. The tape is periodically signed, so a verifier can confirm the record came from this station and not a convincing forgery. Chain gives you "nothing was edited." Signature gives you "and it genuinely came from here."

This is the same zero-trust posture from the comms work, pointed inward: assume the storage is hostile, and make correctness verifiable rather than assumed.
Restricted section

The hash chain and signing cadence

Same key as the other GCS posts — or request access below.

Request access

Build log entry. Apache-2.0. Part of the multi-domain GCS build log.
Comments

Thoughts?

Comments are threads on GitHub, so a GitHub account is needed to post. No account? Email me instead — I read everything.