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

Conventional providers do more with your mail than store it: most marketing mail carries a tracking pixel that reports when and where you opened it, and the largest provider has been fined by a national regulator for advertising inside the inbox without consent. Lockbox is the opposite posture: the message is sealed on your device, your operator never sees plaintext, and there is nothing in the stored copy to read, mine, or serve.

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.

Large attachments offload instead of hitting that cap when the sending client has an IPFS pin service configured. Before the cap is measured, each attachment over 1.5 MiB (an eighth of the ceiling, derived from it rather than configured) is individually encrypted, pinned to IPFS, and replaced inside the envelope by a small reference — the content id, the decryption key, and the plaintext size. The key rides inside the sealed envelope and the reference carries no URL: a content id is permanent where a gateway hostname is not, so the recipient fetches from their own configured gateway and old mail never expires with the sender’s domain. Without a pin service nothing changes: attachments seal inline exactly as before, and an over-cap message is refused. Configuring the pin service is the on/off switch — there is no second setting to disagree with it.

Concretely, “configured” means a pin service URL has been saved in the client’s connection settings, not merely that the field shows a value: the settings pane pre-fills it with the loopback development default, so saving connection settings at all arms the offload, while a client whose settings have never been saved keeps sealing inline. That distinction is deliberate — the pin URL always reads as something, so arming on the value alone would point every install at a port that usually has nothing behind it, and turn a large-attachment send that seals fine today into a failure.

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 web clients’ shared mail reader — the webmail app, the Chrome extension popup, and the Outlook task pane — opens sealed messages the same way. With your wallet unlocked, a sealed message shows its decrypted text (and rich HTML, through the same sandboxed view as ordinary mail) with a notice line naming what happened; locked, it shows the armored block with a hint to unlock, and a message sealed to a different recipient says so instead of failing. The envelope’s attachments are listed under Sealed attachments with a per-file download: an attachment that traveled inside the envelope decodes on your device, and an offloaded one (see the sending step above) is fetched from your own configured IPFS gateway and decrypted locally — the gateway sees only ciphertext and a content id, never the key, and a fetch whose bytes do not match the size the sealed message declares is refused rather than saved.

The Thunderbird extension opens sealed mail in Thunderbird’s own message pane, so there is no separate reading surface to switch to. Two differences follow from where that pane runs, and both are deliberate. First, the reading needs the SithBit tab open with your wallet unlocked: the message pane itself never holds your wallet, and instead hands the sealed block to that tab to open — so key material stays in one place. With the tab closed or locked, the message shows the armored block and a line telling you to unlock. Second, an opened message shows its text only: unlike the web clients, which render a sealed message’s rich HTML inside the same sandboxed view they use for ordinary mail, the Thunderbird message pane has no such sandbox, so sender-authored HTML is not rendered there at all. Sealed attachments are listed with a per-file save, and behave exactly as described above.

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 bob@acme.com 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 or a global alias. Alias resolution is domain-blind — the suffix is parsed off and ignored, so alice, alice@acme.com, and alice@anything.example all seal to whoever holds the global alice. This is load-bearing, not incidental: sealing follows resolution, so if any third party could redefine which wallet an address names, it would thereby choose which key your browser seals to. No domain authority can. 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, the rich HTML, and the attachments. Both the Thunderbird and Outlook plugins read the composed message out of the host mail client and hand the whole thing to the envelope, so formatting and attachments seal and travel as one unit. Attachment bytes ride inside the sealed envelope, which is why the originals are detached from the outgoing message once the seal succeeds — a recipient without the plugin sees the armored block and no attachments, rather than the files in the clear beside it.
Two things a message can contain that stop it being sealed. Both fail closed: the message is sent exactly as you typed it, unencrypted, and the plugin tells you why. It is never sent partly sealed.
- Inline (embedded) images. A pasted or dragged-in image lives in the message body as a cid: reference rather than as an attachment, and neither host’s plugin API can enumerate those parts — so the plugin cannot seal them, and rewriting the body around them would either destroy the image or leave it readable beside a sealed body. Attach the images as files instead and the message seals normally.
- Cloud attachments and attached messages. A OneDrive-style cloud attachment is a link, not bytes, and a forwarded .eml item is handed to the plugin in a form that carries no bytes either. Download and re-attach either one as an ordinary file to seal 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