End-to-End Encryption (E2EE)
How Tempest protects vault contents with account-key wrapping, independent vault keys and per-record encryption, and where those protections stop.
Tempest encrypts synced vault contents before they reach the sync database. Hosts, credentials, SSH key material and Drive document bodies are encrypted with the vault's key. The sync service stores encrypted content and key envelopes, not the plaintext vault key.
Current v3 encryption separates the password protecting your account's private key from the independent key encrypting a vault. Older v1/v2 vaults remain compatible and may use a legacy unlock flow. Do not treat an older “password directly encrypts every document” explanation as the current v3 model.
The v3 key chain
Password protection
Argon2id; salt and parameters stored with the encrypted private-key blob
Derive a key-encryption key from the Master Password.
Account private-key envelope
AES-256-GCM
Protect the account private key.
Vault-key envelope
ECIES: P-256 ECDH, HKDF-SHA256 and AES-256-GCM
Wrap an independent 32-byte vault key for an account's public key.
Vault document payload
XSalsa20-Poly1305 secretbox, with a fresh 24-byte random nonce
Encrypt and authenticate each document independently.
The document payload is Base64-encoded nonce plus encrypted content. Document identity is checked when opening a record to detect ciphertext moved onto a different document ID.
For a shared vault, each authorized recipient can receive the vault key encrypted for their own account public key. This supports shared access without handing every member the same account private key or Master Password. Authorized recipients can still read the shared content: E2EE protects it from the sync service, not from a person granted the decryption key.
Changing the Master Password in v3 re-wraps the account private key; it does not rotate the vault key or re-encrypt every document. It is therefore not a substitute for rotating credentials exposed to an attacker, or for revoking access to already copied plaintext/keys.
Server-visible metadata
The sync and account services need some plaintext metadata: account identifiers, email, server/vault/team membership and permissions, public keys, encrypted key envelopes, document IDs, revision information, payload sizes and timestamps.
Recent document creation/update timestamps are stored outside the encrypted document body. E2EE does not hide those timestamps or the existence, size and timing of updates. It protects the content within the encrypted payload.
Network connections still use HTTPS/TLS in addition to content encryption. A sync administrator can affect availability, delete records or remove historical revision bodies. E2EE does not make sync storage a permanent archive; see Vault History.
Protection on the local machine
Local encrypted storage adds protection against some local compromise scenarios. Its strength depends on what the attacker can access.
Copies encrypted vault database files without keys
Document contents remain encrypted. IDs and other stored metadata may remain visible.
Copies account secret files, but cannot obtain the host master key from the OS credential store
The account secrets remain sealed, including cached vault keys and tokens.
Steals an OS-locked device
OS disk encryption and credential-store protections can add protection; the result depends on device configuration and the attack.
Reads a fallback master.key together with the sealed account files
Can unseal cached secrets. File permissions protect against other unprivileged users, not a process able to read both files.
Controls your OS user, an unlocked Tempest process, its memory or permitted credential-store access
May obtain keys, tokens or plaintext. There is no guarantee against this degree of compromise.
Controls a web-mode backend host
That host is a decryption endpoint and must be trusted; browser-session isolation is not protection against its administrator.
Keeping the host master key in Keychain, Credential Manager or an equivalent store makes stealing only application data less useful. It does not imply a biometric prompt on every read, hardware-backed protection on every platform, or protection from all malware running as you. See Local Credential Storage.
Trust boundaries
The sync server and the machine that decrypts your vault are different trust boundaries. In native desktop/mobile/CLI use, decryption happens in the local native vault host. In current Web Mode, the vault host runs in the standalone backend. That backend can process decrypted data for the browser and sessions; protect it as you would a workstation holding credentials.
AI providers and notification destinations are further recipients when you choose to send them data. Vault E2EE does not encrypt a prompt away from the model processing it. Apple Intelligence On device and Cloud (PCC) also have different data paths; see Tempest AI Assistant.
Lost passwords and shared access
Resetting account sign-in does not magically decrypt an encrypted account private key. Preserve access on an already unlocked trusted device before signing out or clearing local storage if you have lost your Master Password. Recovery depends on which keys and authorized access remain available; support cannot derive the missing decryption key from stored ciphertext.
For current password-change and recovery steps, see Passwords & Recovery. Removing a shared-vault member can stop future authorized access but cannot erase keys or plaintext they already copied.
See also
Last updated