What does "end-to-end encrypted" really mean

What does “end-to-end encrypted” really mean

Every encrypted email service will tell you that their service is “encrypted,” and they’ll stop there. That phrase covers a lot, and it lets a provider avoid the only question that matters: what specifically is encrypted, and what are they still able to see from their side?

This post will cover both questions and provide an exact list of what leaves your device encrypted and what our servers are able to read, along with an honest explanation of why each piece in the second list is required. If you want to verify any of it, you can head over to our GitHub organization and read the source code.

How our encryption works

The first time you sign in to our service, your client will generate an OpenPGP key pair locally on your device. We use openpgp.js with ECC keys - Ed25519 for signing and Curve25519 for encryption - along with AES-256-GCM for symmetric encryption. Your private key will never leave your device in a usable form. It is wrapped with a key derived from your password using PBKDF2-SHA-256 at 310,000 iterations. The unwrapped key will only ever exist in memory, which we zeroize as soon as we are finished with it.

For Aster-to-Aster messages, we run a hybrid X3DH key agreement over P-256 ECDH, combined with ML-KEM-768, a lattice-based post-quantum KEM standardized by NIST in 2024. On top of that, we run a Double Ratchet protocol. Each message gets its own key, and old keys cannot decrypt new messages even if a future one is compromised.

What we encrypt

Everything listed below is encrypted on the client side. By the time it reaches our servers it is stored as opaque ciphertext, meaning that we cannot read it under any circumstance, including a valid legal order: bodies, subjects, attachment data, filenames (for mail you compose), contacts, folders, labels, drafts, search, aliases, block list, and ratchet state.

If a field could ever say something personal about you, then we end-to-end encrypt. Encrypted subject lines are a great example. Proton actually stores subject lines in plain text, so a subject like “hiv test results” or “senior engineer at Acme” is oftentimes a lot more revealing than the body in the message.

This is why we treat unencrypted subject lines as a privacy leak. This is why we designed it from the start.

One important caveat about bodies: this section describes mail that originated on an Aster device. Mail that arrives from outside Aster is a separate case, handled in the section below. Aster-to-Aster mail is encrypted on your device and is never plain text on our side.

What we cannot encrypt, and why

This is the biggest part that a lot of providers skip over. An email service cannot genuinely operate without some metadata in the clear. Pretending otherwise would be dishonest. This is the complete list and why each item exists.

Your email address

Your address, for example you@astermail.org, has to be readable by us. SMTP servers around the Internet need to know where to deliver your mail, and that means our DNS, our MX server, and our routing layer all need a non-encrypted handle. There is no version of email that receives messages from the outside world without a readable address.

Recipient addresses on outbound mail to non-Aster providers

Whenever you send to a friend@example.com, that address has to be visible to the outbound SMTP service so the message can be routed correctly. It is not visible to anyone after delivery, but during delivery it has to exist in the clear by the same logic as your own address.

For Aster-to-Aster messages, the message body itself is end-to-end encrypted before it leaves your device - the server never holds a readable copy of the content regardless of how routing works.

Server-side timestamps and sizes

Our database records when each message was delivered and how large the encrypted blob is. Your client also writes its own encrypted copy of those values, but the server needs its own measurements so mail can be sorted, paginated, and counted against your quota. We do not pad messages to a fixed size. Doing that would multiply storage costs for every user in order to obscure a coarse signal that is rarely useful to a real attacker.

IP address at connection time

When your client opens a TCP connection to our API, our edge will inevitably see your IP. We do not store it. Our audit logs record a keyed BLAKE3 hash of your IP, not the IP itself, so it is usable for abuse detection and cannot be reversed into a list of where you have been.

Rate limiting holds the raw IP in memory for the duration of the request and then drops it afterwards. If you want to hide your IP from us entirely, please run Aster over a VPN or Tor. That is not a workaround; that’s just the system working how it was designed.

Inbound mail from non-Aster providers

When someone outside Aster sends you a message, it arrives at our SMTP server in whatever form their sending server transmitted it. In transit, it is plain text or opportunistic TLS, and we do not control either end of that. There is no way to make standard inbound SMTP end-to-end encrypted from the sender’s side - the keys do not exist on their end. That is true for every email provider, including us.

What changed in June 2026 is what happens the moment that message arrives. Instead of writing the envelope to your mailbox as received, the server now immediately encrypts the full envelope - subject, body, headers, everything - before it is written to your inbox. Once the message is delivered, the raw bytes in the temporary staging buffer are wiped. Your private key never leaves your device, which means we hold a blob we cannot open.

For accounts that have initialized quantum-safe keys (most active users already have them), we use a post-quantum hybrid scheme: a fresh ephemeral P-256 key pair is generated for each incoming message, an ECDH exchange is performed against your stored P-256 public key, and simultaneously an ML-KEM-768 encapsulation is performed against your stored ML-KEM-768 public key. Both shared secrets are combined through HKDF-SHA-256 to derive an AES-256-GCM key, and only ciphertext plus the two public components are stored. This construction means a quantum computer that could break elliptic curve cryptography still could not read your mail, because it would also need to break the lattice-based ML-KEM-768.

For accounts still being upgraded to quantum-safe keys, we use P-256 ECDH-only with the same HKDF and AES-256-GCM construction.

The short version: inbound external mail is zero-access encrypted at rest. We store ciphertext. The server cannot read it.

This requires your account to have quantum-safe messaging keys set up. Most active users already have them - they are generated automatically when you first send or receive Aster-to-Aster mail, or when you log in with a current client. You can confirm this in your security settings. For accounts that have not yet generated those keys, inbound mail continues to arrive as before, with no delivery failures, while the keys are initialized on your next login.

The only way to also make the message unreadable on its way to us is for the sender to encrypt to your OpenPGP public key before sending. We publish your public key via WKD at /.well-known/openpgpkey, so any client that supports WKD can fetch it and encrypt to you directly. If the sender does that, the message arrives at our server already as PGP ciphertext - our encryption layer wraps around what is already ciphertext.

We do not train spam models, search indexes, or any other learned system on the content of inbound mail. Access to the database is restricted to a small set of operators and audited.

Message state flags

We store whether each message is read, starred, archived, trashed, marked as spam, or pinned as server-side flags. These are required so that your inbox state syncs correctly across devices and sessions. They are boolean values - they tell us nothing about what a message says - but they are metadata we can see.

Account-level facts

We are also able to see which plan you are on, your storage quota, the date you created your account, and whether the account is active or has been suspended. These exist because billing and account management require them to function correctly, and none of them will ever say anything about the content of your private mail.

Recovery email, if you set one

A recovery email is an unavoidable exception to end-to-end encryption, because the whole point of it is for us to send you a message when you cannot sign in. If you set a recovery address, your client encrypts a copy to your own key for you to see in settings, and we also store a separately encrypted copy that our server can read at password-reset time. Both copies live in our database encrypted at rest; the server-readable copy is decrypted only when an authenticated reset flow needs to dispatch a recovery letter, and never written to logs. If you do not set a recovery email, no such record exists for your account. This is the one piece of personally identifying contact information we can see, and only because you chose to give it to us.

What we do not collect at all

To be explicit, here is what does not exist anywhere in our service.

Phone numbers: we do not require one at sign up, and we do not ask for one.

Real names. We will never ask you for your real name. Your display name is whatever you put.

Analytics, telemetry, or behavioral logging. We do not have Sentry, Mixpanel, and no first-party event pipeline.

Advertising identifiers, fingerprints, or behavioral profiles.

Plain text message content for spam training. Our spam decisions run on connection-level signals like sender reputation and not on anything that requires reading your mail.

Here is what a subpoena to Aster could actually produce

People often ask this directly, so here is a direct answer: If we receive a valid legal order for a specific Aster account, the most we can hand over is:

• The account’s username/email address and the creation date
• Plan and billing metadata
• The server-side timestamps and sizes of currently stored messages
• Read/starred/archived/trashed/spam/pinned state for each message
• The recovery email address on file, if the user set one
• For accounts with quantum-safe keys set up: encrypted ciphertext of inbound external mail, which we cannot read - same category as Aster-to-Aster mail. Attachment filenames and content types for inbound mail are stored as readable metadata alongside the ciphertext.
• For accounts without quantum-safe keys yet: inbound mail as delivered by the sending server (subject, body, and headers, unless the sender encrypted to your public key via WKD)
• For Aster-to-Aster mail and any locally composed content: the encrypted ciphertext only, which is mathematically useless without the keys which we do not have

For Aster-to-Aster mail, anything composed on an Aster device, and inbound external mail on accounts with quantum-safe keys set up, we cannot produce content, subjects, attachments, contacts, folders, or search history. The keys required to decrypt that data exist only on the user’s devices. This is not a policy choice we could ever reverse - it is how the architecture works. For accounts that have not yet initialized quantum-safe keys, inbound external mail remains the one category where we can produce readable content if compelled.

We also publish a warrant canary and transparency report at astermail.org/transparency, and we will always fight overbroad requests where we can.

TLS, in transit

Every connection between your device and our servers uses TLS 1.3. This is in addition to the application-layer encryption, and it is not a substitute for it. The TLS will keep timestamps, sizes, and routing information from being legible to anyone sniffing the message. The message content itself is always ciphertext regardless.

For any outbound mail to non-Aster providers, we use opportunistic TLS on SMTP. This is the strongest available protection given how the wider email ecosystem truly works. Aster-to-Aster mail will never leave our infrastructure as plain text, because it was never plain text on our end to begin with.

Summary

End-to-end encryption cannot hide that an email exists. It also cannot hide when it was delivered, how big it was, or which address it traveled between, especially when one of those addresses lives on another provider’s server. Anyone who tells you otherwise is lying and selling you something.

What it can do, and what we do, is make the content of your mail mathematically inaccessible to anyone other than you and your recipient, including us. That now covers mail arriving from outside Aster as well - the server encrypts it to your public key before writing anything to disk, so we hold ciphertext we cannot read. Mail that was already in your inbox before June 2026 was stored under the old model; if that matters to you, you can verify the change in our open source code. It is worth knowing exactly where the line falls, and we would rather show you than blur it.