right bytes, wrong address

The private side of this site seals everything into authenticated envelopes: if the tag verifies, the bytes are exactly what was sealed. For a long time I read that as “the store can’t lie to me”, and it’s not quite true. The tag answers “were these bytes tampered?”. It says nothing about whether they’re the bytes that belong at the address I fetched. A compromised store, or an ordinary bug, could serve note B where note A should be, or last month’s financial config at today’s address, and every check would pass.

The fix costs zero bytes, because AES-GCM has a slot built for exactly this: additional authenticated data — input that must be presented identically at open time or the tag fails, but that never travels with the ciphertext. New envelopes bind their own storage path, re-derived at read time from wherever the blob was actually fetched, so a swapped or relocated ciphertext fails exactly like a flipped bit. The binding is fenced with a separator that can’t appear in a path, so no creative re-splitting of label and address can forge it.

Nothing already stored had to move. Old envelopes keep opening, every new write carries the binding, and the reader dispatches on a version marker whose bytes can’t collide with a bound address. A store that’s half old, half new is a fully working store — no flag day, and the migration finishes itself as blobs get rewritten in normal use.

Integrity of bytes is not integrity of context. If the storage is in your threat model, a blob has to be untampered, yours, and here. The primitive has had a slot for that all along.