Lockbox: end-to-end encrypted mail

Lockbox mail makes a message readable only by its recipient — the mail server, the relay, and anyone who later reads the stored copy all see ciphertext. It reuses SithBit’s sealed-box encryption (the same crypto_box_seal that protects on-chain mail bodies) but applies it client-side, over ordinary email: the SithBit plugin seals the body before it leaves your machine and unseals it after it arrives, so lockbox mail rides your existing email account with no SithBit mail server in the path.

It is also fully automatic. Once you and a correspondent both have the plugin, there is no button to press and nothing to remember — every message between you is sealed and reopened transparently, the same way TLS quietly protects a web page. This is the single best reason to run the Thunderbird extension or the Outlook add-in instead of a plain IMAP/POP/SMTP account in your everyday mail client: the plugin is the only way to get true end-to-end encryption, and it costs you nothing to keep it turned on.

Why it matters: who can read your mail without it

Every SithBit mailbox lives on a domain whose authority runs the mail server behind it — for a custom domain, that’s often your employer or whoever administers acme.com, not you. Without lockbox, that operator can read your mail in the clear:

Your IMAP / POP client fetches each message body from the operator’s own storage, and that copy is kept as plaintext — it has to be, so the server can hand it back to you on request. The separate, sealed copy that gets pinned to IPFS is computed from that plaintext at delivery time; it protects the public copy on IPFS, not the one sitting on your operator’s disk.
For mail relayed in from ordinary SMTP, the same operator also sees the envelope and headers in the clear — see the domain authority is fully trusted for relayed mail.

None of this is a bug — it’s the same trust model every traditional mail server already has (an IT admin can read mail on a company Exchange server, Gmail’s operator can technically read Gmail), and SithBit documents it honestly rather than pretending otherwise; see what’s public and private for the full picture. But it means that on-chain sealing alone protects you from the public internet, not from whoever runs your own mail domain.

Lockbox closes exactly that gap. Because sealing happens on your device before the message ever reaches a server — yours or anyone else’s — your own domain’s operator never holds a plaintext copy to begin with. There is nothing on their disk to subpoena, leak, or simply read.

How it works

Sending. When you send a message, the plugin:

Resolves each recipient to a wallet — a raw wallet address, or a alias — using only a public Solana RPC endpoint.
Looks up the recipient’s published encryption key (or falls back to sealing straight to their wallet address).
Packs the message into a small JSON envelope — the text body plus, when the sending client supplies them, rich HTML and any attachments, so everything seals and travels as one unit — then seals that envelope to the key and replaces the message body with an ASCII-armored block:
```
-----BEGIN SITHBIT SEALED MESSAGE-----
Version: 1
To: alice

…base64 sealed body…
-----END SITHBIT SEALED MESSAGE-----
```
The envelope is capped at 12 MiB, measured before sealing; a larger message is refused with a clear error rather than silently truncated. The headroom exists because the payload inflates twice on the wire — attachment bytes ride as base64 inside the envelope, and the sealed result is base64-armored again, roughly ×1.78 combined — so 12 MiB of raw content still clears the SMTP server’s default 25 MiB message-size limit. Messages sealed by earlier plugin versions carried the bare body with no envelope; they remain readable — opening simply falls back to treating the unsealed bytes as the text body.

All three steps run automatically on every send — there is no compose-time toggle to find or forget. A recipient without the plugin sees this block plus a short notice telling them how to read it — never a broken message.

Receiving. The recipient’s plugin automatically detects the armored block, unseals it with their wallet, and shows the plaintext — again, with no action from the reader beyond opening the message as usual. Ordinary (non-lockbox) mail is passed through untouched.

The recoverable reading key

Standard S/MIME and PGP have a painful weakness: lose the private key and your archived mail is gone, and using more than one device means hand-copying key files. SithBit derives your reading key from your wallet instead.

Your wallet signs one fixed, domain-separated message; that signature is run through a KDF to produce your X25519 reading key. Because the signature is deterministic, any device holding your wallet reproduces the exact same reading key — including a signing-only hardware wallet — with nothing to back up. Publish its public half once:

sithbit mailbox set-key --derive

Senders then seal to that published key. The trade-off is forward secrecy: the derived key never changes, so if it’s ever compromised, every message ever sealed to it — past and future — is readable. A random delegated key you rotate periodically (sithbit mailbox key) limits a compromise to whatever was sealed under that one key; older mail sealed under a previous, now-discarded key stays safe. If you prefer that protection over never needing a backup, keep generating a random delegated key instead.

Trade-off. Anyone who can trick your wallet into signing this exact message can reconstruct your reading key, so approve the signing prompt only in the SithBit plugin. See the threat model.

Autocrypt-style key discovery

Sealing to a recipient means first knowing their key. The plugin can always learn it from the chain (that lookup is the second step of Sending above), but a chain round-trip on every send is avoidable when the two sides have already exchanged mail. Borrowing the idea behind OpenPGP’s Autocrypt, the plugins advertise the sender’s key in an ordinary mail header and quietly remember it on the receiving end — so a reply to someone who has written to you seals without touching the chain at all.

The header. Outgoing lockbox mail carries a SithBit-specific header:

X-SithBit-Key: v=1; wallet=<base58 wallet>; key=<base58 X25519 key>

It names the sender’s wallet and their published X25519 reading key. The header is emitted opportunistically: the plugin adds it only when the sender resolves to a published key, and its absence never blocks or fails a send.

Both ends participate. The Thunderbird extension sets the header as the message is composed; the Outlook add-in sets it as the message is sent. On the receiving side, both plugins read the header off displayed mail and cache the wallet → key pair. A later send to that same wallet is served straight from the cache — no fresh RPC lookup — while the plugin still knows the sender is SithBit-capable.

The chain stays the source of truth. The header and its cache are a convenience and a “this sender speaks SithBit” signal, not an authority. The published key lives on-chain (set with sithbit mailbox set-key), and any send can fall back to the chain lookup — so a reply seals correctly even if no header was ever seen.

Not OpenPGP Autocrypt. This borrows Autocrypt’s shape — advertise your key in a header, remember peers’ keys from received mail — but it is a separate, SithBit-only mechanism. The advertised key is an X25519 reading key, not a PGP key, and the header does not interoperate with real Autocrypt or any OpenPGP client.

Limitations. Only the wallet named in the header is remembered, so the cache short-circuits future sends addressed to that bare wallet or to wallet@host — an alias-addressed reply such as [email protected] still resolves through the chain, because the header advertises the wallet, not the alias. Thunderbird caches when a message is displayed; Outlook has no event for “message read”, so its read-caching rides the task pane loading on an opened message. In every case a cache miss simply falls back to the normal chain lookup.

What v1 does — and does not — do

Both ends need the plugin. Lockbox is end-to-end encryption between SithBit users, not a way to send encrypted mail to someone running plain Apple Mail. (S/MIME interop for plugin-less recipients is a possible later layer.)
Recipients must be SithBit-native. Lockbox seals to a raw wallet address, a global alias, or a domain-scoped user@verified-domain address. A verified domain’s authority can map user@its-domain to a wallet, and that mapping takes precedence over the global namespace — so [email protected] reaches the wallet acme.com’s authority designated, while a bare alice (or an alice@… with no domain-scoped mapping) still resolves through the global namespace. See Domain-scoped aliases. A recipient that can’t be resolved is reported as unsupported and the message is sent as ordinary plaintext.
All-or-nothing per message. If any recipient can’t be sealed to, nothing is sealed — the message goes as plaintext rather than leaking who could and could not be reached. A message to several SithBit recipients carries one sealed block per recipient.
The plugins seal the body only — for now. The sealed payload is a structured envelope that can carry rich HTML and attachments alongside the text body as a single sealed unit. The current Thunderbird and Outlook plugins, however, still hand it only the plaintext body — reading the composed HTML and attachments out of the host mail client is a planned addition, and HTML/attachment support in the plugins arrives with it.

Relationship to on-chain mail

Lockbox mail and on-chain SithBit mail solve the same privacy problem from two directions. On-chain mail seals the body server-side at delivery time and stores that ciphertext on IPFS, but — as covered above — the operator’s own mailbox copy stays plaintext so IMAP/POP can serve it back to you. Lockbox mail seals client-side instead, so the operator never sees plaintext in the first place — at the cost of requiring the plugin on both ends. See what’s public and private for the full picture.

Keyboard shortcuts