a client container with one or two volumes

the client container reached the main branch: the package itself, a profile that keeps a contact card in a volume, and two commands, jimichi vault init and jimichi vault show. the running -peer client does not use it yet and still keeps its identity only in memory. the container does not enter the numbers on the research page.

one file, two regions

the container is one file of a constant size: a salt and two sealed regions. each volume sits in a region of its own under its own password, and a written volume holds one thing, the contact card of the peer. a region without a volume holds an empty volume, sealed by the same code under a random key that is thrown away at once, and which region a volume takes is random. the file has no header, no version and no nonce: its size is the whole format.

jimichi vault init takes one or two contact cards, generates a password for every volume itself and prints them once. jimichi vault show reads a password on stdin and prints the own card that volume derives and the hash of its contact card, never the number of volumes or the region that opened.

no key in the file, and what that does not mean

the file holds no key material in any form, not even encrypted. the identity key and the fetch capability are derived from the volume key at every opening, through the same crypto interface as the rest of the system, on both suites. this is a statement about the bytes of the file, not about strength: the file with the password of a volume reproduces both, so against seizure of the file together with the password the container is as strong as a key stored under that password. the password without the file gives nothing, since the salt exists only in the file.

a card built from a volume cannot be told from the card of a client without a container, under the assumptions on the key derivation, so neither the contact nor the mailbox learns about the container from it.

written once

the file is written exactly once, at creation, through a temporary file and a hard link, when every volume already has its contact card. there is no write after that, and an opening only reads. so every state of the file after creation is the same byte for byte, and a write retried after a failure writes the same bytes again: seizures on different days, backups and synchronisation give nothing beyond one state. a hard link never replaces a file, so no existing container is overwritten.

the price of a single write: a new contact or a new password means a new container, a new identity and a new introduction, and the contact card of a second volume is needed already at creation.

what is claimed

the file in one state and the password of one volume do not show whether a second volume exists. this rests on stated assumptions about the password stretch, the aead with a one-time key and the key derivation, and on reasoning, not a formal proof. it holds only for a generated password of the second volume, which is why jimichi vault init makes the passwords itself; with -stdin a user gives their own, and the command warns that the claim is not made for them.
the states of the file after creation are the same byte for byte.
a changed volume does not open: every region is sealed under an aead, and the region number and the salt enter the keys, so a flipped bit or swapped regions make the opening fail, and a file of another size is refused as not a container.

what is not claimed

a password a person chose, on either suite, since such a password lies within an offline search. on gost a guess is also cheaper than on c25519, the stretch needing no memory; by how much is not measured.
the printed password: jimichi vault init prints a generated password once, and terminal history and redirected output are outside the claim.
immunity against coercion. every container has two regions, so a coercer who knows the software will demand a second password. the second volume is a cover story, and the story holds only while it is used: an idle queue of the decoy at the mailbox or a decoy contact that never answers gives it away.
a surrendered password. with the file it gives the identity key, the fetch capability and the contact card of that volume for the whole life of the container, and there is no rotation or revocation.
the filesystem and the drive. timestamps show when the container was made and when it was opened, and how many traces of the creation are kept by journals, shadow copies, wear-leveling and trim is not measured. a temporary file left by a creation killed before its link is another container with its own salt; it is removed at the next start, but removal does not wipe the blocks on the drive.
an active adversary between seizures. replacing the other region with a fresh empty volume does not disturb the decoy, while to the owner of the second volume it looks like a wrong password; a container recreated on the same device then shows at the next seizure that a second volume existed.
a running device: copies of the password, its stretch and the identity key in library memory, which can reach swap and the page file.
that the file without a password looks like random bytes holds only under an assumption that is not proven for kuznyechik-mgm. even so, a seizer learns that it is a container: the command line that names it, its path and its constant size give it away; what is hidden is whether it holds one volume or two.

how it was checked

vault tests: an empty volume and a volume are sealed by one code, the region without a volume does not open under a zero key and gets a new key at every creation, a wrong password and a missing volume give one error with the same number of provider calls, and the place of a volume is random.
neither the file nor the opened regions hold any byte of the identity key, the fetch capability, the intermediate keys or the password.
openings change no byte of the file, a second write is refused, a retry after a refused link writes the same bytes, and an existing file is never replaced.
a changed bit of the salt or of a region, swapped regions, truncation and extension make the opening fail.
golden values of the password stretch at the production cost of both suites.

the -peer client that keeps its identity in the container across restarts, and the measurement of the property: a distinguisher of one volume from two and a trace of the file states (#20). that client will have limits of its own: a constant fetch capability is a constant queue, by which the mailbox will link every run with that container. then the measurement topology of the end-to-end path (#47) and the attack blocks: key extraction from memory dumps (#24), node compromise (#117) and a timing watermark (#116).

the full list is on the limits page and in limitations, the format in architecture, the keys and the argument in crypto, the threats and countermeasures in the threat model.