Key cache entries so that two servers and two users cannot read each other

[iderex]

One device can hold sessions for two servers, and one server can be used by two
people on the same device. A cache keyed only by item identifier hands the second
person the first person's library, and it does so silently, which is the worst
version of that failure.

What this produces

Every key namespaced by the server it came from and by the identity that fetched
it, so that the same identifier under a different session is a different entry.

Signing out removing the entries for that identity rather than leaving them for
whoever signs in next. Signing out itself is built in #114, which
expresses the removal in the keying this issue defines.

A key derivation that does not put a person's name or a server address into a
filename, since a cache directory is readable by anything else on the device that
can read files.

Done when

A test signs in as one identity, caches, signs out, signs in as a second, and
proves nothing from the first is readable. A test proves two servers holding the
same item identifier do not collide. A test proves no key material written to
storage contains a readable name or address. Blocked on #40, #6 and #101.

[iderex]

The construction landed as docs/decisions/0041-how-a-cache-key-is-built.md, on cf9705d.

A key is a cryptographic digest over five things written in a fixed order: a version tag, the server as the resolved identity, the account as the identifier the server gave back, the device identity, and the request. Each is written as its length in a fixed-width field followed by its bytes.

The length prefix is the whole of what 0006 left here, and the defect it prevents is invisible by inspection. With plain concatenation an account called ab with a request starting c produces the same string as an account called a with a request starting bc, and one of those two is a person who is not supposed to be reading it. A separator character does not fix that; it moves the problem to whichever part is allowed to contain the separator.

The digest is required to be cryptographic and used at full width, and the requirement comes from who the adversary is rather than from a preference. Part of the input is server-chosen, since an item identifier in a request came from an answer the server sent, and 0101 treats every byte from a server as untrusted whether the server is healthy or not. A non-cryptographic hash is refused by name, because it is what a developer reaches for when the word in front of them is "key" and it is chosen for speed against inputs nobody is choosing.

What the digest does not buy is stated in the record, because the two get conflated and the conflated version is what gets quoted later as a property this repository does not have. It removes readable values from anywhere a store puts a key, so a directory listing, a shared backup or a screenshot stops saying which servers a person uses. It hides nothing from somebody who can guess the input, since the parts are low entropy and anyone holding the device can compute a candidate and look for it. Separation between accounts is what the keying provides; confidentiality against whoever holds the device is not, and 0101 already says the core does not encrypt what it writes.

Two parts needed a rule of their own. Where a server offers no stable identity for itself, the server part falls back to the base address from 0028, and the cost is that two addresses reaching one server become two key spaces, which duplicates entries and never mixes them. That is the safe direction of the two. And a parameter that is absent is written differently from one that is present and empty, because they are different requests.

The version tag is inside the digest rather than beside it, which makes an old key space unreachable rather than misread when the construction changes. That is a different question from an entry written by another version carrying a different payload shape, which stays with #105.

One thing came out of writing this that is worth having before somebody meets it. This issue asks that signing out removes the entries for an identity, and 0068 already promises a caller that the core removes every entry under the key space for that server and account. The keying makes that set well defined and does not make it reachable: 0040 gives the store no listing, on purpose, and a digest does not reverse. So removal by key space needs the core's own record of which keys it wrote, which is the same bookkeeping 0040 hands to #42 for eviction. Without that index, #114 cannot complete a removal it has already been promised, and the shortest route to discovering it is somebody implementing sign-out and finding nothing to enumerate.

All three conditions here are untouched. Signing in as one identity, caching, signing out and proving nothing from the first is readable; proving two servers holding one item identifier do not collide; and proving no key material written to storage contains a readable name or address are statements about running code, and there is no language chosen, no build and no test command in this tree. The record also requires a cryptographic digest without naming the function or its width, because that depends on the toolchain in #11, so that part of the requirement is stated and unmet rather than satisfied. This stays open on all three.