How End-to-End Encryption Works on Cleus

Your conversations with an AI are some of the most personal data you'll ever type. On Cleus, premium users can turn on zero-access encryption — a mode where your messages are encrypted on your own device with a key that never leaves it, so what's stored on our servers is ciphertext we cannot read. This post is a transparent, technical look at exactly how it works, what it protects, and — just as importantly — what it doesn't.

What "zero-access" actually means

Most apps encrypt data "in transit" (HTTPS) and "at rest" (disk encryption). That's table stakes, but in both cases the service still holds the keys and can read your data. Zero-access encryption is stronger: the encryption key is derived from a passphrase only you know, on your device. The server stores only the encrypted blob and never sees the passphrase or the key.

The result: your plaintext exists in exactly three places — on your device, briefly in memory while a request is being processed, and at the AI model that generates the reply. It is never written to our database in readable form. (More on that third place below — we're not going to hand-wave it.)

The threat model

Encryption is only meaningful if you know what it defends against. Zero-access encryption on Cleus is designed to protect you from:

• A database breach — if our storage were ever compromised, an attacker gets ciphertext, not your conversations.
• Insider access — no Cleus employee can open an encrypted chat and read it.
• Broad data requests — we can't hand over what we can't decrypt.

It is not a defense against malware on your own device, a compromised browser, or someone who has your passphrase. Client-side encryption moves the trust boundary to your device — which is exactly where you want it.

The key system: a "wrapped DEK"

Under the hood Cleus uses the same battle-tested pattern as password managers like 1Password and Proton — a wrapped Data Encryption Key. Here's the whole model in one diagram:

codeCopy
  passphrase ──PBKDF2-SHA256──> KEK_pass ─┐
                                          ├─ AES-GCM wrap ─> DEK (random 256-bit)
  recovery code ──HKDF-SHA256──> KEK_rec ─┘                   │
                                                              └─ encrypts every message

Three keys are doing the work:

1. The DEK (Data Encryption Key) — a random 256-bit key generated on your device. This is what actually encrypts your messages, using AES-256-GCM (authenticated encryption, so tampering is detectable). Because it's random, it's never guessable.

2. A passphrase-derived key (KEK_pass) — your passphrase is stretched into a key using PBKDF2-SHA256 with 310,000 iterations (the OWASP-recommended floor) and a random salt. This deliberately-slow derivation makes brute-forcing your passphrase enormously expensive.

3. A recovery-derived key (KEK_recovery) — a one-time recovery code (160 bits of entropy, shown as a 32-character code) is expanded via HKDF-SHA256 into a second key.

The clever part: the DEK is wrapped (encrypted) twice — once by KEK_pass and once by KEK_recovery — and only the two wrapped copies are stored. Either your passphrase or your recovery code can unwrap the DEK. Lose both, and the data is unrecoverable — by design, including by us.

This design also means changing your passphrase is instant: we just re-wrap the same DEK with a new passphrase-derived key. None of your messages need to be re-encrypted.

The life of an encrypted message

Here's what happens end to end when you send a message in an encrypted chat:

1. On your device, the message is encrypted with the DEK using AES-256-GCM. A fresh random 12-byte nonce (IV) is generated per message, and the ciphertext is bound to a version tag so it can't be silently swapped between contexts.
2. What gets sent and stored looks like this — note content is empty and the real payload lives in enc:

jsonCopy
{ "role": "user", "content": "", "enc": "v1:<iv>:<ciphertext>", "e2ee": true }

3. To generate a reply, encrypted turns take a completely separate, stateless path. Normal Cleus replies are produced by a server-side database trigger that reads your history in plaintext — that trigger is explicitly disabled for encrypted chats. Instead, your device decrypts the recent history locally and sends it to a stateless streaming endpoint that generates the reply and streams it back without persisting anything or logging content.
4. Back on your device, the reply is encrypted with your DEK before it's stored. The server only ever files away ciphertext.

Your passphrase and DEK never travel over the network. The unlocked DEK is held only in memory for the session, so closing the tab means you re-enter your passphrase next time.

What encryption can — and can't — do

We'd rather be straight with you than market past the truth.

What it does: everything stored in our database for an encrypted chat is ciphertext we cannot read. Breaches, insiders, and blanket data requests all hit a wall.

The honest caveat: to generate a reply, the model has to see your words. That means your plaintext prompt reaches our AI model provider at inference time — it isn't stored by Cleus, but it does leave your device to be processed. True, literal end-to-end encryption (where no one in the middle can read anything) requires a Zero Data Retention guarantee from the model provider so that nothing is retained or logged on their side. That's why we describe this feature precisely as zero-access encryption — Cleus has zero access to your stored conversations — rather than implying the model itself is blindfolded. It's a meaningful, real protection; we just won't overstate its reach.

Current limits (v1)

To keep the guarantees airtight, encrypted mode is intentionally scoped in its first version:

• Premium (subscribed) users only.
• Plain chat only — server-side tools that need to read your content (web search, image generation, agent workflows, vision/image understanding) are off in encrypted chats. If you pick one of those models, it falls back to a standard text model.
• No file attachments yet.

These aren't permanent; they're the honest boundary of what can be done without the server reading your content today.

How to turn it on

1. Open Cleus and make sure you're on a premium plan.
2. In a chat, use the lock toggle next to the send button to enable encryption.
3. Create a passphrase — choose something strong and memorable; it never leaves your device and cannot be reset by us.
4. Save your recovery code somewhere safe. It's the only other way back into your encrypted chats if you forget the passphrase.

That's it. Encrypted chats show a lock indicator, and everything from that point is encrypted on your device before it's ever sent.

FAQ

If I forget my passphrase, can Cleus recover my chats? No — that's the point. Use your recovery code. If both are lost, the encrypted messages are permanently unreadable, including by us.

Does encryption slow anything down? No noticeable difference. AES-GCM is hardware-accelerated; the only deliberately slow step is deriving the key from your passphrase, which happens once per unlock.

Can I use the AI agent, web search, or image generation in an encrypted chat? Not in v1 — those need server-side access to your content. Use a normal chat for those, or an encrypted chat for private text conversations.

Is my passphrase stored anywhere? Never. It's used on your device to derive a key and is then discarded from memory. We only store two encrypted copies of your random data key.

---

Privacy shouldn't be a marketing checkbox. Zero-access encryption on Cleus is a concrete, standards-based design — random 256-bit keys, AES-GCM, PBKDF2, a wrapped-DEK model — with an honest boundary we're happy to explain. Open Cleus, go premium, and flip the lock.