> For the complete documentation index, see [llms.txt](https://docs.gotempest.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gotempest.app/accounts-vaults-and-privacy/end-to-end-encryption.md).

# 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

```mermaid
flowchart TD
    P[Master Password] --> K[Argon2id with random salt and stored parameters]
    K --> U[AES-256-GCM unwraps account private key]
    E[Encrypted account private key] --> U
    U --> V[ECIES unwraps vault key]
    W[Vault key wrapped for account public key] --> V
    V --> D[XSalsa20-Poly1305 decrypts vault documents]
    C[Encrypted document payloads] --> D
```

| Layer                        | Current implementation                                                   | Purpose                                                            |
| ---------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------ |
| 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](/accounts-vaults-and-privacy/vault-history.md).

## Protection on the local machine

Local encrypted storage adds protection against **some** local compromise scenarios. Its strength depends on what the attacker can access.

| Attacker's access                                                                                   | Protection and limits                                                                                                              |
| --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| 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](/accounts-vaults-and-privacy/where-tempest-stores-credentials.md).

## 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 [Storm AI](/ai-and-automation/tempest-ai-assistant.md).

## 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](/accounts-vaults-and-privacy/resetting-password.md). Removing a shared-vault member can stop future authorized access but cannot erase keys or plaintext they already copied.

## See also

* [How Tempest Protects Your Privacy](/accounts-vaults-and-privacy/how-tempest-protect-your-privacy.md)
* [Where Tempest Stores Your Credentials](/accounts-vaults-and-privacy/where-tempest-stores-credentials.md)
* [Accounts & Multiple Accounts](/accounts-vaults-and-privacy/accounts-and-vaults.md)