File 003 · The Blueprint

Don’t trust us. Check the math.

Most companies ask you to trust them. We'd rather show our work. This page is the actual design — the key hierarchy, the flows, the guarantees, and the parts we can't protect yet, stated just as plainly.

Last updated: October 2026 · Written by humans, checked against the code.

§ 01 · The System at a Glance

A courier who can’t open the safe.

Unlike Mail is a client for the mailbox you already own. The Windows and Android apps talk to Google, Microsoft or Zoho directly to read and send your mail. Our Rust server is a courier for the rest: it takes part in signing in and carries the safe, and we designed the job so the courier never holds a key to it at rest (§ 07 says what it does hold, and for how long). Everything we persist about your mailbox’s access is ciphertext sealed under keys that only exist on your devices.

fig. 01 · shapeThe apps talk to your provider directly; the server carries sign-in and keys — and the database is opaque to everyone.

flowchart LR
  D["your device<br/><small>the keys</small>"] -- "reads and sends mail, direct" --> P["Google · Microsoft · Zoho<br/><small>your mailbox</small>"]
  D -- "sign-in · wrapped keys · billing" --> S["our Rust server<br/><small>carries the safe</small>"]
  S -- "opaque ciphertext at rest" --> DB@{ shape: cyl, label: "Postgres" }

§ 02 · Two Locks, Two Problems

Two different things need protecting.

Security claims get slippery when they blur what, exactly, is being protected. We protect two distinct things, with two distinct mechanisms:

The credential that can read your mailbox. Signing in gives the app an OAuth token from your provider — long-lived, full-mailbox scope. It is the crown jewel. The apps keep it in your device’s secure storage; for the web version, until it is retired, Part I is how our server stores its copy so that even we can’t use it without you.
The mail itself. Messages between Unlike Mail users are sealed end-to-end with post-quantum cryptography — Part II. Mail you exchange with people not on Unlike Mail is ordinary email, and we say so out loud (see what we can’t protect).

§ 03 · Part I — Token Custody

The client-side envelope.

Every key that matters is derived or unwrapped on your device, and wraps the next key down. At rest, the server stores blobs it cannot read.

Read more about zero-knowledge encryption.

fig. 02 · key hierarchyThe KEK never leaves your device. The server never stores a key that opens anything at rest.

flowchart LR
  PP["passphrase<br/><small>client only</small>"] -- "Argon2id + salt" --> KEK["KEK<br/><small>client only</small>"]
  PK["passkey PRF<br/><small>one per device, hardware-gated</small>"] -- "wraps" --> KEK
  KEK -- "wraps" --> DEK["DEK<br/><small>random 256-bit</small>"]
  DEK -- "AES-256-GCM" --> CT["stored ciphertext<br/><small>Postgres</small>"]

The KEK (key-encryption key) is derived from your passphrase with Argon2id — deterministic given the stored salt, so the same passphrase yields the same KEK on any device, and no key ever needs to be transferred between devices. The KEK wraps a random DEK (data-encryption key), which seals what we store. Each of your devices additionally wraps the KEK under its passkey’s PRF output, so day-to-day unlocking is one biometric gesture — no secret typed, nothing to keylog.

Read more about why Argon2id resists GPU guessing.

Who holds what

Where	What it holds	For how long
Postgres	Wrapped DEK, per-device wrapped KEKs, KDF salts, sealed tokens & keys — all opaque ciphertext	At rest, permanently useless without you
Your device	The KEK and unwrapped private keys, in the app	While unlocked
Server RAM	The working key for the mailboxes you are signed in to (and, for the retiring web version, a live mailbox token)	Until you sign out, go idle, or the server restarts

The guarantee ladder

“Encrypted” is doing a lot of work in most marketing. Here’s the actual ladder, and where we sit on it:

Level	The server’s relationship to your data	DB leak	Live-server compromise
L1	Encrypted at rest with a server key	Safe	Server can always decrypt — theatre
L2	Password envelope, but the server unwraps it	Safe	Server briefly holds the master key
L3 — where we are	Client-side envelope; the server holds no key at rest, only ciphertext, plus a working key in memory while you use a mailbox (and a live token for the retiring web version)	Useless to a thief	Only mailboxes in active use at that moment

No recovery. On purpose.

There is no master key, no “contact support to restore access,” no backdoor we could be forced to use. Lose every enrolled device and the passphrase, and your sealed history is gone — you re-connect your mailbox and start fresh. A recovery path for you would be a recovery path for anyone. We chose the version where mathematics doesn’t negotiate.

§ 04 · Part II — Sealing the Mail

OpenPGP’s idea. Post-quantum math.

The model is the one that made PGP legendary — every user has a keypair; you seal to the recipient’s public key; only their private key opens it. We kept the idea and replaced the math: ML-KEM-1024, the NIST-standardized post-quantum key-encapsulation mechanism (FIPS 203), hybridized with AES-256-GCM for the payload.

Read more about AES-256-GCM authenticated encryption.

At account creation, your device mints a unique ML-KEM keypair.
Your public key goes into the server-side key registry — that’s what a public key is for.
Your private key is wrapped under your KEK and only ever unwrapped on your devices. The registry holds locks, never keys.

fig. 03 · sealing a messageThe subject line is sealed too — a lesson the industry learned the hard way.

flowchart LR
  subgraph SEND["SEND · sealed on your device"]
    direction TB
    REG@{ shape: cyl, label: "public-key registry" }
    REG -- "their public key" --> E["ML-KEM-1024<br/>encapsulate"]
    E -- "shared secret" --> SS["AES-256-GCM<br/><small>seals body + subject</small>"]
    SS --> CT["ciphertext"]
  end
  subgraph READ["READ · opened on theirs"]
    direction TB
    T["their device"] -- "ML-KEM decapsulate<br/><small>private key, on-device</small>" --> M["plaintext<br/><small>only they read it</small>"]
  end
  SEND -- "rides your provider<br/><small>they carry it, can't open it</small>" --> READ

To your provider, a sealed message is an ordinary email whose contents happen to be noise. They transport it, store it, and learn nothing. Decapsulation happens on the recipient’s device — the shared secret is never on the wire and never on our server.

Read more about what end-to-end encryption protects.

Why post-quantum, today

Encrypted traffic is being recorded now to be broken later — the “harvest now, decrypt later” problem. Classical key exchange will not survive a cryptographically relevant quantum computer; lattice-based ML-KEM is built to. Sealing with it today means the mail you send this year isn’t next decade’s breach. We’d rather future-proof now than apologize later.

Read more about post-quantum cryptography.

§ 05 · Passkey-First Trust

Hardware you own, not a password you remember.

Day-to-day, Unlike Mail unlocks with a passkey — your fingerprint, face, or security key, evaluated by hardware. The passkey’s PRF output unwraps your KEK; the KEK unwraps everything else. You type no secret, so there is no secret to phish, keylog, or reuse from a leaked password dump.

Read more about FIDO2 passwordless authentication.

Enrolling a new device

With your passphrase — enter it once; the new device derives the same KEK (same salt, same Argon2id), registers its own passkey, and never asks again.
With a device you already trust — scan an authorization QR / code from any enrolled device and the credential is shared to the new one. No secret typed anywhere, trust flows hardware-to-hardware.

“Brute force isn’t on the menu.” The keys that matter are unwrapped by hardware-backed credentials — there is nothing to guess, so a weak password doesn’t become a weak vault. The one human-memorable secret in the system, the passphrase, is stretched through Argon2id: memory-hard by design, so offline guessing is priced in gigabytes of RAM per attempt, not luck. Your security leans on the hardware in your pocket, not on your creativity with special characters.

§ 06 · Threat Model

What must hold. In writing.

#	Claim	Why it holds
T1	A database leak is useless	A full dump yields wrapped keys and ciphertext. No key that opens them exists server-side.
T2	The server holds no key for the at-rest data	The KEK never reaches us; working keys sit in memory only while you use a mailbox, and are dropped when you sign out, go idle or the server restarts. A copy of the stored data can’t unlock the store.

§ 07 · The Honest Part

What we can’t protect — and won’t pretend to.

Residual risks · stated, not spun

Mail with people who aren’t on Unlike Mail is ordinary email. Sealing needs both ends. A message to a friend on ordinary webmail lives in plaintext at their provider, like all their other mail. We seal what can be sealed and never imply otherwise.

Services that host your mailbox can do one thing we can’t. Because they store the mail, they can encrypt all of it at rest against themselves — including a message from a stranger who has never heard of them. We hold none of your mail, which is exactly why your address stays yours, and exactly why our guarantee covers the messages both ends agree to seal rather than every byte in the box. That is a real trade, and the right one for most people, but it is a trade.

Read more about encryption at rest and in transit.

Our server takes part in signing in. Each time an app starts or you add a mailbox, the app sends our server a short-lived access token so we can confirm the mailbox is yours; the server checks it and does not keep it, and the app keeps the long-lived sign-in on your device. A Zoho sign-in and every Zoho token refresh pass through our server, which adds the secret Zoho requires and keeps nothing. While you are signed in, the server holds your working key in memory, until you sign out, go idle or it restarts. The web version, until it is retired, also leaves the refresh token with our server, encrypted under a key only your passphrase unlocks, and a live token in memory. A live compromise of the running server could therefore touch the mailboxes of people signed in at that moment — never the stored data.

Gmail notifications name the mailbox. Google’s push service tells our server that a Gmail mailbox has something new, and that notice carries the mailbox address — never the message.

Losing everything means losing sealed history. No recovery is a feature with a cost, and the cost is yours to know about up front.

Every one of these has a plan or a reason. None of them has a euphemism.

§ 08 · The Stack

Built with things that don’t break.

Layer	Technology	Why
Mail sealing	ML-KEM-1024 + AES-256-GCM	NIST-standardized post-quantum KEM, hybrid AEAD payload.
Key derivation	Argon2id	Memory-hard. Guessing priced in RAM, not luck.
Device trust	WebAuthn passkeys (PRF)	Hardware-gated key unwrapping. Phishing-proof by construction.
Client core	Rust	Memory-safe crypto. One buffer overflow and it’s all theatre.
Server	Rust (Axum)	Carries the safe. Fast, typed, boring on purpose.
Apps	Rust + Tauri	Windows and Android. Native performance. Your RAM isn’t free real estate.
Transport	TLS	In-transit protection to your provider and to us.

Every dependency is locked to an exact version, and the crypto core is memory-safe Rust. When you build a vault, you don’t use cardboard.

§ 09 · Trajectory

Where this goes next.

Apple, later. Windows and Android are the apps today. An Apple version is not built yet, and has no date.
Provider reach. Google, Microsoft, and Zoho all sign in directly on Windows and Android.

Questions this page didn’t answer live in the FAQ, and the promises it makes are restated formally on Compliance & Trust.

Try 30 Days Free — No Card Compliance & Trust →