Post-quantum email encryption: what we actually protect

Nisdos Mail now protects the most valuable key in a device-custody mailbox with encryption built to outlast quantum computers. That is one key — not the whole mailbox — and the distance between those two claims is what this page is about.

The specifics, for anyone who wants them: when a browser enrols a device, the key it generates is now an ML-KEM-768 ⊕ X25519 hybrid instead of plain X25519. Your stored messages are not covered yet. Below is why that order was the right one, and what is still missing.

What is post-quantum encryption protecting against?

A copy of today’s ciphertext, opened in twenty years. The attack is called harvest now, decrypt later, and it does not require a quantum computer to exist yet — only that someone store your encrypted data now and wait.

Shor’s algorithm, run on a large enough quantum computer, recovers a private key from an X25519 or RSA public key. Nobody has that machine. Anyone who can copy ciphertext today — a cloud operator, a subpoena, a stolen backup, a misconfigured bucket — can hold it until somebody does. Symmetric encryption is not in the same position: Grover’s algorithm only halves the effective key length, and a 256-bit key absorbs that with room left over.

Email is close to the worst case for this threat, because a mailbox is an archive and not a session. Web traffic is transient; mail is kept on purpose. A contract, a diagnosis, a legal thread, an account-recovery link that still works — the things worth encrypting in 2026 are frequently the same things worth reading in 2045.

Which part of a Nisdos Mail mailbox is post-quantum today?

The device key, which is the wrap around the mailbox keyring. Nothing else.

A device-custody mailbox has three layers of keys, and “wrapped” below just means locked inside another key. Each message body is encrypted with its own random key. That message key is wrapped to the mailbox’s current generation key, which is the key everything arriving today is encrypted to. And the keyring — the small bundle holding every generation the mailbox has ever had, plus the Ed25519 seed that authorises new devices — is wrapped separately to each enrolled device’s key.

What	Algorithm	Quantum-safe
Message body	ChaCha20-Poly1305	Yes, it is symmetric
Per-message key wrap, to the mailbox generation key	X25519	No
Keyring wrap, to each enrolled device key	ML-KEM-768 ⊕ X25519	Yes

We moved the third row first for two reasons. The wrapped keyring is the highest-value ciphertext in the system: it holds every key generation the mailbox has had and the seed that authorises devices, and it sits in our database next to the public key it was wrapped to, for as long as the mailbox exists. One break there is total — all mail, past and future, plus the ability to enrol a new device and be handed the mailbox legitimately.

It is also the only wrap where both halves are client work. The browser wraps the keyring, the browser unwraps it, and our server relays bytes it cannot read. Changing the algorithm there required agreement from nothing else.

Why isn’t my stored mail post-quantum yet?

Because our delivery path is Rust, and the Rust age implementation cannot encrypt to a post-quantum recipient.

Every inbound message is encrypted on our MX host at delivery, to the mailbox’s public key. That is the mechanism that lets a device-custody mailbox receive mail we cannot read afterwards, and it runs through the age crate, which is X25519-only for identities in both 0.11 and 0.12. Version 0.12 did add post-quantum recipients — but only a tagged ML-KEM-768 ⊕ P-256 form, encryption-only, and nothing in either language can decrypt it. The browser library ships the matching recipient class with no identity class to pair with it.

We could define the missing half ourselves. We would then own a non-standard key encoding for the most valuable bytes in the product, and produce .age files that the standard age and rage tools cannot open — which is one of the reasons we chose age to begin with. Waiting for an untagged mlkem768x25519 identity on both sides is the cheaper correct answer, and the check that enforces X25519 on mailbox generations says exactly that, in a comment, for whoever gets there first.

So here is the gap, stated plainly. An adversary who copies the encrypted objects out of your storage today and has a working quantum computer in 2045 can read those messages: each object’s header carries an X25519 ephemeral key, and breaking it yields that object’s file key. The keyring stays out of reach, so they cannot enrol a device or follow the mailbox forward — but the archive they copied opens. We would rather write that sentence than let a headline imply the opposite.

Why not use the old and the new encryption together?

Because two wraps of the same key are weakest-link, not belt-and-braces. If a file key is wrapped to an X25519 recipient and to a hybrid recipient, an attacker breaks whichever is easier and gets identical plaintext. Two DKIM signatures work the opposite way — a verifier accepts either, so the second one strictly adds. Key encapsulation gives you the worse of the two.

Going post-quantum on message wraps is therefore a hard switch rather than an addition: a new key generation that new mail is encrypted to, with older generations still readable through the keyring. It also needs a ceremony we do not have yet. Today a new generation is minted only when you revoke a device, because revocation and rotation are one operation; a post-quantum switch is structurally that operation minus the tombstone.

What does post-quantum encryption cost?

Size, not speed. ML-KEM is fast. Its keys are simply large: ML-KEM-768’s encapsulation key is 1184 bytes, and age’s hybrid recipient carries that plus a 32-byte X25519 point — 1216 bytes, which encode to a roughly 1,950-character age1pq1… string.

That is about 60 times the length of a classical age recipient, and it changed real code. A device lookup keyed by the device’s own public key can no longer put that key in a URL, so those requests carry it in a body instead. When a device is revoked we now clear its public key along with its wrapped keyring, because 1.9 KB per retired device kept forever is dead weight plus a device identifier nobody needs.

If the per-message wraps go hybrid later, the cost lands per object: roughly 1.5 KB of extra header on every stored message, which is about 150 MB on a 100,000-message mailbox. Worth doing. Worth pricing first.

What does none of this protect?

Transport and metadata, the same as before. Mail moves between providers over SMTP with hop-by-hop TLS, and the key exchange there is whatever the two servers agree on — MTAs run well behind browsers on hybrid key exchange. Envelope data (who wrote to whom, when, through which relays) is visible to every hop regardless of what happens at rest. Inbound mail also arrives as plaintext, which is why device custody is zero-access and not zero-knowledge: we handle a message on arrival, then cannot read it again.

Device custody itself is still in beta. Keys are generated in your browser, our copy of the mailbox key is erased when you enrol, and there is no recovery scheme yet — lose every enrolled device today and the mail is gone. Shamir-split recovery is the next item on that list, and until it ships, that trade is the tier.

Existing enrolments are not invalidated by any of this. The client dispatches on the identity type, so an X25519 device keeps working and becomes hybrid the next time it enrols.

The question worth asking anyone announcing post-quantum email: which ciphertext did you make hybrid? If the answer is the transport, they upgraded the one part nobody was archiving.