How the vault works

What we are defending against

Three situations shape every decision below. A sync server that stores your data and should never be able to read it. A stolen laptop, where the database file is in someone else’s hands. And an attacker with that file offline, running guesses against it as fast as hardware allows.

The third is the one that decides the key derivation, because it is the only one where the attacker’s budget, rather than your password, sets the pace.

Argon2id, not a fast hash

Your master password is stretched into a 32-byte key with Argon2id at 64 MiB of memory, three passes, four lanes. Memory is the point: a GPU can run enormous numbers of hash operations in parallel, but it cannot give each of them 64 MiB of fast memory. That turns a wide parallel attack back into a narrow one.

For comparison, a PBKDF2-SHA256 derivation at a thousand iterations — still a common default — costs an attacker under a millisecond per guess and parallelises almost perfectly. Argon2id at these parameters takes roughly 130 ms on a laptop and resists exactly that parallelism.

The parameters are recorded alongside the vault, so raising them later affects new derivations while existing vaults still open.

Every record sealed on its own

Each vault has its own random 32-byte key, wrapped under the master key. Records are encrypted with XChaCha20-Poly1305 using a fresh 24-byte nonce, and the record’s own identity — its type, its vault and its id — is bound in as associated data.

That last part matters more than it sounds. Without it, anyone holding the ciphertext could move a valid encrypted blob to a different record and the client would accept it. With it, a relabelled record simply fails to open.

Sharing without handing over a key

Each account has an X25519 keypair. Sharing a vault seals its key to the recipient’s public key, so a server can broker who has access to what while never holding a key that opens anything.

Revoking access removes the sealed copy. Anyone who has already read the data has read it — no system can undo that — but nothing new encrypts to them again.

Host keys, pinned

The first time Termiyo sees a server it shows you the key and its SHA-256 fingerprint, and pins what you accept. Every reconnect is checked against that pin.

When a key changes, Termiyo says so plainly rather than burying it: a rebuilt server and an intercepted connection look identical to software, and only you know which one you were expecting.

Where the secrets actually live

Connections run in a separate process from the interface. The window that draws your terminal has no network access, no filesystem access, and never receives a password or a private key — it asks to connect to a saved host by name, and a different process decides what that means.

Anything shown in the interface is redacted first. Saving a record back with a masked field leaves the stored secret untouched.