End-to-End Encryption (E2EE)

Tempest's end-to-end encryption explained — threat model, key derivation, per-record encryption, conflict-free sync, and what the server cannot see.

Tempest is end-to-end encrypted. Your SSH keys, passwords, snippets, and connection metadata are encrypted on your device with a key derived from your vault password — a key that never leaves your device — before anything reaches our sync servers. We literally cannot decrypt your data, even if compelled to. This is the same security architecture as 1Password, Bitwarden, Signal, and ProtonMail.

This page goes into the cryptographic detail. For the high-level pitch, see How Tempest Protects Your Privacy.

Threat model

E2EE is a defense against specific attackers. Tempest's E2EE defends against:

Attacker	Defended?	How
Tempest server breach	✅	Server only stores ciphertext; no keys to leak
Tempest employees	✅	Same — we never see plaintext
Network MITM (TLS terminator, ISP, etc.)	✅	Records are already ciphertext before TLS
Government request for "the user's data"	✅	We can hand over only what we have — encrypted blobs
Malware on your device	❌	Once your vault is unlocked locally, malware with that scope can read it
You forgetting your vault password	❌	Recovery would require us to hold a key — defeating E2EE

The last two are inherent to any zero-knowledge system. Tempest can't recover a forgotten vault password — see Reset Your Tempest Password.

Key derivation: vault password → encryption key

When you set a vault password, Tempest derives a 256-bit symmetric key:

key = BLAKE2b(vault_password, salt, output_length=32, person="tempest-vault-v1")

• BLAKE2b is a fast, modern cryptographic hash — RFC 7693, used in WireGuard, Argon2's reference, and many others.

• The salt is generated per vault and stored locally (it's also synced as part of the encrypted profile so a new device can re-derive the same key).

• The person field domain-separates this hash from any other use — a defense-in-depth measure so the same password used elsewhere can't accidentally produce the same key.

The resulting key never leaves your device. It's held in process memory while Tempest is unlocked and zeroed when you sign out.

Per-record encryption: xsalsa20poly1305

Each document in your vault (a host, a snippet, a keychain entry, etc.) is encrypted independently:

ciphertext = secretbox.encrypt(plaintext, nonce, key)

Where secretbox is a standard authenticated symmetric encryption primitive:

• xsalsa20 stream cipher — confidentiality

• Poly1305 MAC — authenticity / tamper detection

• 24-byte random nonce per record — no nonce reuse risk

Per-record encryption (rather than encrypting the whole vault as one blob) means:

• Sync replicates only the documents that changed — not gigabytes per edit

• A damaged record doesn't corrupt the rest

• Conflict resolution can happen at the per-document level without ever decrypting

Sync transport: TLS over ciphertext

Encrypted records are then transported over TLS 1.3 between your device and Tempest's sync servers. TLS gives us:

• Forward secrecy on the wire

• Server identity verification (so you can't be MITMed onto a fake Tempest)

• Defense-in-depth — even if the E2EE were ever broken, an attacker would also need to break TLS to passively observe

The double encryption is intentional: TLS protects the protocol, E2EE protects the contents.

Conflict-free sync without decryption

Tempest sync uses a multi-master replication protocol designed for offline-first apps. The server treats each E2EE document as an opaque blob with:

• A document ID

• A revision counter

• The encrypted body

When two devices edit the same document offline and then sync, the server records both revisions and lets the client decide how to merge — without the server ever seeing the contents. This is unusual for a sync system and is a key reason Tempest can offer real-time multi-device sync without compromising E2EE.

What the server does see

A small amount of operational metadata is necessarily plaintext:

Visible to server	Why
Sync account email	We need to know which account the document belongs to
Document IDs and revision counters	The sync engine matches revisions across devices
Approximate document sizes	Quota enforcement
Device public keys (for Tempest Push routing)	We need to deliver notifications to specific devices
Last-sync timestamps	Diagnostics and "is this device still active?"

We never see hostnames, usernames, passwords, key contents, snippet text, or any other connection detail.

What the server cannot see

• Anything inside any encrypted document (hosts, keys, certs, snippets, keychain entries, sftp bookmarks…)

• Your vault password

• The derived encryption key

• Plaintext of Tempest Push notification payloads (these are E2EE'd to your other devices' public keys before submission)

Comparison to other security models

Model	Server can read your data?	Recovery if password lost?
No encryption (typical SaaS)	Yes	Yes — admin reset
Server-side encryption at rest (most cloud DBs)	Yes (key managed by provider)	Yes
Encryption in transit only (HTTPS but plaintext at rest)	Yes	Yes
End-to-end encryption (Tempest, 1Password, Bitwarden)	No	No

The trade-off is explicit: lose the password, lose the data — in exchange for the strongest possible privacy guarantee.

Tempest Push notifications and E2EE

When Tempest Push sends a notification from one of your devices to another, the payload is encrypted to the receiving device's public key before hitting our notification relay. APNs / FCM see only:

• A target device token

• A small ciphertext (decrypted on-device into the actual notification text)

We never see the snippet that ran, the host that failed, or the user-readable notification message.

Limitations and roadmap

• Local malware: any process running as you with disk + memory access can read your vault while it's unlocked. Use OS-level disk encryption (FileVault, BitLocker, LUKS) and don't run untrusted code as your user.

• Quantum threat for stored ciphertext: xsalsa20 is symmetric and not currently considered broken by Shor's algorithm. The vault's protection against future quantum attacks is acceptable.

• Open source: the crypto implementation will be open-sourced for independent audit — see How Tempest Protects Your Privacy.

See also

• How Tempest Protects Your Privacy — the high-level overview

• Reset Your Tempest Password — what happens when you forget

• Post-Quantum SSH Algorithms — the transport protocol's PQ story