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, along with RSA 4096 for the key pair and 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 that mixes X25519 with ML-KEM-768, a lattice-based post-quantum KEM standardized by NIST in 2024. On top of that, we run Double Ratchet with the same construction that Signal uses. 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, attachments, filenames, contacts, folders, labels, drafts, search, aliases, block list, and ratchet state. Along with every flag on a message: read, starred, archived, trashed, spam, pinned.

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. Even fields that look like natural metadata are end-to-end encrypted, whether a message is read or starred, the attachment count, the size that your client has measured, or the timestamp.

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, we do something different. The recipient is referenced by an encrypted routing token, not by a literal email address. The message body and its routing target are not linkable by anybody who could be watching our database.

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 salted 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

This is the most important caveat in this whole post, and we want to state it plainly rather than hide it behind “encrypted” wording. 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; the keys do not exist on the sender’s side.

What this means concretely: an inbound message from a non-Aster provider is written into our database as the envelope we received, not as ciphertext wrapped to your public key. Our infrastructure has the technical ability to read it. Aster-to-Aster mail is different - it is sealed on the sender’s device, our server never holds a readable copy, and the entries below the section on Aster-to-Aster routing tokens describe how that works.

The only standards-compliant way to make inbound mail unreadable 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, and only your device can decrypt it.

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. None of that is the same as end-to-end encryption, and we will not pretend it is.

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
• The recovery email address on file, if the user set one
• Inbound mail from non-Aster providers, as it was delivered to us 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 and anything composed on an Aster device, we cannot produce content, subjects, attachments, contacts, folders, search history, or even the read/starred state of messages. The keys required to decrypt that data exist only on the user’s devices, and this is not a policy decision that we could ever reverse. It is how the architecture is created. Inbound mail from non-Aster providers is the exception noted above and is 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 mail you compose on an Aster device mathematically inaccessible to anyone other than you and your recipient, including us. Mail that arrives from outside Aster does not have that property, because the sender never had your key; we covered the implications of that above. It is worth knowing exactly where the line falls, and we would rather show you than blur it.