How Elusive protects your mail.
The full technical picture: the ciphers we use, how keys are generated and stored, what metadata we minimize, and an honest account of what this design does not defend against.
01 Overview
Every new account is end-to-end by default. An OpenPGP keypair is generated in your browser at signup, and the private key never leaves it in a form we can use. We hold only your public key and passphrase-locked copies of the private one, so we can encrypt incoming mail to you but cannot read your stored mail. You can switch to server-managed later if you would rather we hold the key.
Nothing here is hand-rolled. Encryption uses OpenPGP.js, an audited, standards-based library, running the same WebAssembly build we ship to your browser. We do not invent primitives, and we try never to overstate what they buy you.
The honest headline: in keyfile mode we store nothing that can decrypt your mail. If you lose your key and passphrase, it is gone, and we cannot recover it. That is the design working as intended, not a gap.
02 Encryption modes
New accounts start end-to-end. You can switch modes any time from settings, and switching re-encrypts your whole mailbox.
| Mode | Who holds the key | We can read your mail | Recovery |
|---|---|---|---|
| End-to-end, stored (default) | You; we keep a locked copy | No | Recovery code |
| End-to-end, keyfile | You, only you | No | None, by design |
| Server-managed | Elusive (MASTER_KEY) | Yes, at rest | Password reset |
Server-managed is appropriate when your threat model is disk theft or casual snooping, not the operator. The two end-to-end modes differ only in custody: whether we store a passphrase-locked copy of your key for convenience, or hold nothing at all.
03 Cryptographic primitives
The exact algorithms and parameters in use today.
04 Key management & custody
In end-to-end mode, your keypair is generated in your browser with OpenPGP.js. The private key is immediately locked with your passphrase using Argon2id, and only leaves your device in that locked form. Here is exactly what the server stores in each custody option.
| Item | Stored (end-to-end, stored) | Stored (keyfile) |
|---|---|---|
| Public key | yes | yes |
| Private key, password-locked | yes | no |
| Private key, recovery-locked | yes | no |
| SHA-256 of recovery code | yes | no |
| Anything that decrypts your mail | no | no |
Fingerprint pinning (TOFU)
On first sight, your browser pins your public-key fingerprint in local storage. If the server ever serves a different fingerprint for your account, the app raises a full-width warning and asks you not to trust the session until you verify the key out of band. This is a trust-on-first-use check against a silent key swap.
Recovery
A high-entropy recovery code, shown once, unlocks a second recovery-locked copy of your private key.
A reset proves knowledge of the code with SHA-256(code), so the server can verify you
without ever seeing the code and without being able to unlock the key itself. Keyfile mode has no
recovery path at all.
05 Metadata minimization
End-to-end mode encrypts subject lines as well as bodies. To stop ciphertext length from leaking message size, plaintext is padded into fixed buckets before encryption. The wire format is a length prefix followed by the text, padded up to the next bucket, and the browser strips it on decrypt.
We still see delivery metadata, because delivery needs it: who a message is from and to, and when it arrived. We do not pretend otherwise. See the threat model below.
06 Account & transport controls
These apply in every mode.
| Control | Mechanism |
|---|---|
| Two-factor | TOTP, RFC 6238, verified server-side with a ±1 step skew |
| CSRF | SameSite=strict cookies plus a per-session token on authenticated state-changing requests |
| Content Security Policy | script-src 'self' 'wasm-unsafe-eval'; connect-src 'self'; object-src 'none' |
| Session cookies | httpOnly, secure in production, SameSite=strict, 12-hour lifetime |
| Auth rate limiting | 10 attempts per 15 minutes per client |
| Logging | Requests, emails and message contents are never written to disk or console |
| Transport | HTTPS only; outbound mail uses STARTTLS where the receiving server supports it |
The 'wasm-unsafe-eval' directive exists solely so the self-hosted OpenPGP.js bundle can
instantiate its Argon2 WebAssembly. It permits WASM compilation, not JavaScript eval().
07 Disposable mail
Disposable aliases are built to leave no residue. Each carries either a timer or a burn-on-read flag.
- Timed. The alias and all of its mail are deleted once the timer, from one minute up to 24 hours, elapses. Expiry is enforced server-side on every mailbox read.
- Burn on read. The moment a message to the alias is opened, the alias and every message it holds are deleted in the same request. A 24-hour safety expiry also applies, so an alias that is never opened still cleans itself up.
Deletion is a real row delete, not a hidden archive. In end-to-end mode the mail was unreadable to us the whole time it existed.
08 Threat model
Security is only meaningful against a stated adversary. Here is what this design defends against, and what it does not.
- A stolen disk or database. Everything at rest is ciphertext.
- The operator reading your mail, in end-to-end mode. We hold no usable key.
- A silent key swap, caught by fingerprint pinning.
- Password guessing, slowed by Argon2id and bcrypt, and rate limiting.
- A malicious or compromised server sending you bad browser code. All webmail shares this, and because Elusive is not open source you cannot yet verify the code you run.
- Us reading a message the instant it arrives. We receive standard email as plaintext, then seal it to your key, so "we cannot read it" is true of your stored mail, not of a message in flight.
- Metadata analysis. We can see who you talk to and when.
- The receiving side of mail sent to non-Elusive addresses.
- Future key compromise unlocking old mail. There is no forward secrecy yet.
No independent audit yet. Until someone outside Elusive has reviewed this, everything here is our claim and not anyone else's verification. A published audit, signed apps that close the webmail trust gap, and forward secrecy through key rotation are the next items on the roadmap.
09 Responsible disclosure
If you believe you have found a vulnerability, we want to hear about it before anyone else does. Report it privately with enough detail to reproduce, and give us a reasonable window to fix it before any public writeup. We will not pursue good-faith research that respects user privacy and avoids data destruction. When a fix ships, this page and our disclosures change to match.