Email Reborn: Post-Quantum encryption over the mailbox you already have

End-to-end encrypted email has existed for thirty years and is barely used. PGP puts key management on the user; S/MIME puts a CA and an enrolment process on the organisation and still stops at its border; the modern alternatives require both parties to move to the same provider. Substituting ML-KEM for RSA in any of those changes the algorithm and not the deployment. At the same time, mail is the workload where harvest-now-decrypt-later is least hypothetical: it is archived for years by both parties and by everything in between.

This talk covers the engineering of Eon Phoenix Mail, a client that encrypts over an existing mailbox — IMAP/SMTP, including hosted consumer and enterprise providers — with no new address and no server-side change, and what that constraint forced. It is free software under AGPL-3.0: clients, message envelope and directory server are all in the open, and the cryptographic claims in this talk can be read back in the source.

Cryptographic construction. A hybrid envelope: ML-KEM-1024 with X25519 for key establishment, ML-DSA-87 with Ed25519 verified under logical AND for authenticity, AES-256-GCM for content. The KEK derives from HKDF-SHA256 over both shared secrets plus the KEM ciphertext and ephemeral public key, with domain separation per use; sign-then-encrypt, one content key wrapped per recipient, so multi-recipient and group conversations fall out of the same structure.

Implementation decisions. Two independent implementations of the same wire format — one on OpenSSL 3.5, one pure-Go — with byte-identical key encodings and a cross-implementation interop test, because the FIPS story and the cgo-free mobile and Windows builds pull in opposite directions. FIPS 203/204 known-answer vectors run in CI. One build-tag collision with the Go standard library silently disabled AES hardware acceleration: 115 MB/s against 1976 MB/s, with every test still green.

Design decisions worth arguing about. Protection is chosen per message rather than per product, across five levels from ordinary mail to a read requiring a second party's cooperation, with self-erase and metadata suppression as separate stackable switches from a single registry both user interfaces derive from. Recipients without the client get ordinary mail instead of a blocked send. Metadata is treated as its own axis, with an explicit list of what the design does not hide: the domain pair, the gateways themselves, and traffic volume.

Failures, in detail, because they are the transferable part: SRV-based key discovery that resolved on every desktop and never on mobile; key rotation that destroyed previously received mail; an in-band key header large enough to push short messages into spam classification; and a directory lookup that queried the sender's domain instead of the recipient's.

Audience: implementers migrating a deployed protocol to post-quantum primitives, where key distribution, graceful degradation and metadata are harder than the KEM. Everything shown is running code under an open licence, so any part of it can be taken and reused.