How Aster encrypts your email

A reasonable question we hear a lot is: what exactly does Aster protect, and what can you still see?

We built Aster around a simple principle — your email should be yours, not ours. That means encryption by default, keys that stay under your control, and being honest about the places where we do see metadata. This post covers the full picture, including the parts that are less flattering.

Your password never leaves your device

Everything starts with your password, and the first important thing to know is that we never see it. When you type your password, it stays on your device. We do not transmit it. We do not hash it server-side and compare. None of that.

Instead, your password is the root of your entire encryption system. We use PBKDF2-SHA-256 with 310,000 iterations to derive an encryption key locally. That key is what unlocks your private keys, which live in your encrypted vault. The vault is the only thing we store — and it is already ciphertext by the time it reaches us.

When you log out, we zero out the key material in memory. When your session times out, same thing. Nothing sensitive persists on disk in plaintext on your device either.

For verifying your password at login, we use Argon2id — the memory-hard hashing function recommended by OWASP and widely considered the current gold standard. Our configuration uses 128MB of memory and 3 iterations of work, which makes brute-force attacks computationally expensive even if someone obtained our database.

How your private keys are protected

Your PGP private key is what decrypts the email that arrives in your inbox. Protecting it well is the whole ballgame.

We generate your key pair on your device using EdDSA (Ed25519) as the primary signing key and ECDH over Curve25519 as the encryption subkey. These are modern elliptic curve algorithms that offer strong security with small key sizes and fast operations. We also support RSA-4096 for compatibility with legacy clients.

The private key is encrypted before it ever touches our servers. We derive an encryption key from your password hash using HKDF-SHA-256 with the context string astermail-pgp-key-encryption-v1, then encrypt your private key with AES-256-GCM using a randomly generated 12-byte nonce. That encrypted blob is what we store. We cannot decrypt it. There is no backdoor, no recovery path on our end, and no mechanism to access it without your password.

Your public key is stored in plaintext — that is by design. Public keys need to be discoverable so that other people can encrypt mail to you. We publish them via WKD (Web Key Directory) so that any compatible email client can find them automatically.

Aster-to-Aster encryption: the double ratchet

When you send a message to another Aster user, something more sophisticated than plain PGP takes over: a Double Ratchet protocol, layered on top of an X3DH (Extended Triple Diffie-Hellman) key exchange.

If you have used Signal, you have used something very similar. Every message derives a new encryption key from the previous one. If a key is ever compromised, only messages encrypted with that specific key are exposed — not your entire history, and not your future messages. This property is called forward secrecy and break-in recovery, and it is a meaningful improvement over static PGP.

On top of the standard Diffie-Hellman key exchange, we also incorporate ML-KEM-768, a post-quantum key encapsulation mechanism finalized by NIST in 2024. The concern this addresses is called “harvest now, decrypt later” — an adversary records your encrypted traffic today and hopes to decrypt it in a decade once quantum computers are capable of breaking classical elliptic curve cryptography. ML-KEM-768 is designed to remain secure even against quantum hardware, so messages sent today stay private in that future.

Encrypting email to external recipients

When you send to a Gmail, Outlook, or any non-Aster address, we fall back to OpenPGP with SEIPDV2 — the modern Symmetric Encrypted Integrity Protected Data format using AES-256 in OCB mode. If the recipient’s key only supports older formats, we fall back to SEIPDV1 automatically. The encryption still happens before the message leaves your device.

We discover the recipient’s public key automatically by checking WKD, our local cache of previously received Autocrypt headers, and public keyservers. If we cannot find a key, we tell you before you send.

For external recipients who have PGP keys, the message body and attachments are encrypted. The subject line is protected via RFC 2231 protected headers — the outer MIME envelope shows “Encrypted Message” and the real subject is encrypted inside the payload. For recipients without PGP keys, the message is sent as standard SMTP with TLS in transit, which is the same baseline security as any other email provider.

What happens on our servers

By the time email arrives at our infrastructure, it is already ciphertext. We store the encrypted envelope as a binary blob in the database, accompanied by a nonce. We cannot read it.

Attachments are stored the same way — the file data and the attachment metadata are both encrypted separately, each with their own nonce.

Your contacts, your draft emails, your folder structure, your preferences, and your recovery key — all encrypted at rest with AES-256-GCM before storage. The search index is encrypted too; we use a scheme that lets your client query it without us being able to read the underlying email IDs.

Our servers run on Hetzner infrastructure in Germany, within the EU. Data stored there is subject to GDPR protections, which means stricter legal standards than US-based hosting.

What we can see: the honest part

Encryption protects content. It does not eliminate metadata, and we want to be clear about what metadata exists.

We store the following in plaintext:

Your username. This is your email address. It has to be — we need it to route mail to you, and it is inherently public in the email system.

Timestamps. We know when an email arrived. We know when you created or modified it. This is unavoidable for a mail system that needs to sort your inbox.

Read and folder state. Whether a message is read, starred, archived, trashed, or marked as spam is stored as a flag we can see. These are boolean values, not content, but they are metadata.

Message size. We store how large each message is in bytes. This is used for storage accounting and quota enforcement.

Attachment count. Whether a message has attachments and how many — not the content, not the names, just the count.

DKIM, SPF, and DMARC verification status. When inbound mail arrives, we check whether it passes standard email authentication. The result of that check is stored.

Session metadata. When you log in, we record your device type, browser family, and operating system in your session record. We use this to show you active sessions in your account security settings. We do not record your IP address permanently — it is used for rate limiting and then discarded.

The reason this metadata exists is practical: we need some of it to run a mail service. Timestamps are required for sorting. Read state is required for the unread count badge. Username is required for routing. We have tried to keep the plaintext footprint as small as possible while still building a product that actually works.

What a legal order can and cannot compel

We are a US-based company, which means we are subject to US law. This is worth addressing directly.

If we received a valid legal order — a subpoena, a National Security Letter, or a court order — we would be compelled to hand over what we have. What we have is: your username, timestamps, read/folder flags, message size, attachment counts, session device info, and the encrypted ciphertext blobs.

We do not have your private key. We do not have your password. We cannot decrypt your email content, your contacts, your attachments, or your preferences. A court order cannot compel us to produce information we do not possess.

Subject lines for inbound mail pass through a staging area briefly before being processed and encrypted. We do not retain them in plaintext after processing. Outbound subject lines are encrypted before they enter the queue.

We publish a warrant canary and transparency report. If that canary changes, you will know something has happened.

Third parties we work with

We use three external services that touch your data in some form:

Stripe handles payments. If you pay for a plan, your payment information goes to Stripe. We see only whether a subscription is active — no card details.

Cloudflare sits in front of our infrastructure for DDoS protection. This means Cloudflare sees request metadata, including your IP address, before traffic reaches our servers. The content of your requests is encrypted in transit.

Hetzner is where our servers physically run. They host the machines that store your encrypted data. They cannot read it — they see encrypted blobs — but they are a party in the chain. We chose Hetzner specifically because they are based in Germany, under German and EU law, which offers meaningful legal protections that US-based hosting does not.

We do not use analytics, tracking pixels, ad networks, or third-party telemetry scripts. We have no interest in profiling you.

Verifying this yourself

We are open source. The code behind Aster Mail, including the encryption stack, is available on our GitHub. You do not have to take our word for any of this — you can read the implementation.

The frontend encryption code lives primarily in src/services/crypto/ and src/utils/email_crypto.ts. The backend cryptography library is in aster-crypto/, a standalone Rust crate. The database schema, which shows exactly what is and is not stored encrypted, is in the migrations directory.

If you find something that contradicts what we have said here, we want to know. Reach out through our security contact or open an issue on GitHub.

The short version

Your email content, attachments, contacts, drafts, preferences, and keys are encrypted and we cannot read them. What we can see is limited to: your username, timestamps, read state, message size, and session device info. We do not have a backdoor, we do not store your password, and a legal order cannot unlock your inbox for us because we do not hold the keys.

That is the design, and that is what the code does. Go check.

Try Aster Mail free