Key concepts

A small vocabulary that the rest of the docs assumes.

Vault and entries

Your vault is the logical set of entries you can read. An entry is one stored secret: a login, a card, an identity, an SSH key, a passkey, a note, and many others. See Entry types for the full list.

Every change to an entry creates a new immutable entry version, identified by a ULID and signed by the device that wrote it. History is append-only; "editing" an entry means publishing a newer version, and optimistic concurrency stops two devices from silently clobbering each other.

Device

A device is one install of open-secret (a browser profile with the extension, or the web app in a given browser). Each device generates and holds two keypairs that never leave it:

• an auth keypair (ML-DSA-65 ‖ Ed25519), your login credential. The device proves possession by signing a server challenge.
• an encryption keypair (ML-KEM-768 ‖ X25519), how other devices seal entry ciphertext to this device.

The server stores only the public halves.

Unlock password vs. auth keypair

These are easy to confuse, so keep them distinct:

• The auth keypair is what logs you in to the server. It's a key, not something you type.
• The unlock password is a local secret you choose. It never goes to the server. It wraps your device's private keys at rest (Argon2id + authenticated encryption) so that someone with file-system access to a locked install still can't use your keys. You type it to unlock the device after it's been locked.

Pairing a new device

A new install generates its own keypairs and shows its public keys (as a code/QR). An already-trusted device registers them with the server (AttachDevice) and vouches for them with a signed attestation. The human moving the code between devices is the trusted channel, there is no server-issued pairing code to phish.

Recipients and signers

Because each entry version is encrypted per device, two device sets matter when writing:

• Recipients, every active device that should be able to read the entry (all of your devices, plus the devices of anyone you've shared it with). The writer seals a separate ciphertext for each. Revoked devices are dropped from this set.
• Signers, the devices whose signatures are trusted to verify an entry version. A device that signed a version before it was revoked stays a valid signer, so its past versions still verify.

Trusted-device chain

Trust is not "whatever the server says." Each device carries an attestation signed by its parent device, forming a tree rooted at your first device. A client rebuilds the chain from its own install outward and trusts only devices reachable over verified attestation edges. A malicious server that injects a fake device can't forge a valid attestation, so the fake device never enters your trusted set.

Removing a device updates this set: revoking keeps it as a valid signer for the versions it already signed, while deleting drops it entirely and is refused while anything still depends on it. See Delete vs. revoke.

Device backup file

A passphrase-encrypted file containing this device's keypairs, which you download at first setup (and can re-export later). It never touches the server. With the file and its passphrase you can restore your vault on a fresh install, your keys decrypt whatever the server is storing for you. It's an independent recovery factor: you don't need another device or the operator to use it.

Operator backup

Optionally, the operator can configure a backup public key. With per-user opt-in, each entry version is sealed a second time to that key, and the operator (holding the matching private key offline) can recover a user who has lost every device and their backup file. It's the last-resort recovery factor, alongside the device backup file and any other paired device, see Backing up & recovering.