Eon Phoenix

What is Eon Phoenix?

Eon Phoenix is a native mail client that speaks ordinary IMAP/SMTP but adds a hybrid post-quantum encryption layer, so that the mail server never sees the content of a message. It ships in two builds from one core: a desktop client (Wails: Go backend, React frontend) for macOS, Windows and Linux, and a Gio client (pure Go, no webview) that runs on Android and on the desktop. Both converge two streams of communication into one inbox:

• Email — regular correspondence over standard IMAP/SMTP, reaching anyone with an email address.
• D-Mail (Discrete Mail) — an always-encrypted, chat-style direct message that rides on the same email address, shown in the inbox as a threaded conversation rather than a message list.

The cryptographic foundation

Every protected message is sealed hybrid: a post-quantum KEM plus X25519 for confidentiality, ML-DSA-87 plus Ed25519 for authenticity, AES-256-GCM over the body, sign-then-encrypt. Breaking the scheme requires breaking both the post-quantum and the classical primitive.

Which post-quantum algorithm seals a given message is not fixed. An identity publishes its whole key set, and a sender picks the strongest algorithm the recipient also publishes as active — preference order is compiled into the client, with family diversity ranked above the security level inside one family. One message can address recipients with different key sets, because the algorithm lives in the per-recipient block of the envelope rather than in a suite name.

Adding or retiring an algorithm leaves the fingerprint unchanged, does not trigger the key-change flow and does not invalidate a pin. A retired key keeps decrypting; it is only no longer offered to senders. Messages sealed before crypto agility (envelope v1, ML-KEM-1024) stay readable.

Key discovery

To encrypt to a contact, Eon Phoenix needs to find their public key. It does this through Codex, a small per-domain directory service: a sender’s client resolves the recipient’s domain to a keyserver, fetches the recipient’s key bundle, and verifies it before trusting it — all automatically, with no manual key exchange for domains that run their own Codex instance. Contacts on providers that don’t run their own keyserver (Gmail, Outlook, and similar) are reached through an open-enrollment Codex instance instead, using an email-challenge to prove mailbox ownership.

Two audiences, two sets of docs

This documentation is split by who is reading it:

• Client — for anyone using the Eon Phoenix app to read and send mail: installing the app, adding accounts, sending and receiving encrypted mail, using D-Mail, and verifying a contact’s key.
• Codex Server — for the sysadmin installing and operating a Codex directory keyserver for a mail domain: deployment, configuration, and day-to-day operations.

If you only use the app, start with Client. If you’re standing up a keyserver for your organization’s domain, start with Codex Server.

Status

Eon Phoenix ships open-core: the mail/D-Mail engine and cryptographic implementation (Phoenix-core) are open source (AGPL-3.0), so the implementation can be independently reviewed. The current release covers the three encryption schemes (PGP/MIME, S/MIME, Eon-PQC), D-Mail, and Codex discovery/publish/trust-on-first-use.

Beta builds are published per version for five platforms: macOS arm64 and amd64, Linux amd64, Windows amd64, and Android arm64 (APK). Windows builds are Authenticode signed; the macOS build is not signed yet, so Gatekeeper still warns on first open, and the Android APK carries a test key. Real-world interop with other mail clients (Thunderbird, Apple Mail) over PGP/S-MIME has not yet been broadly tested.