Aster Mail – End-to-end encrypted email with post-quantum cryptography(astermail.org)
astermail.org
Aster Mail – End-to-end encrypted email with post-quantum cryptography
https://astermail.org/
7 comments
Hi HN. We have been building a quantum-safe, end-to-end encrypted email service where we, by design, cannot read your mail. Very few encrypted email services have post-quantum cryptography in production that works with any encrypted email provider, not just their own users. Client-side encryption with post-quantum cryptography, zero-access architecture, fully open source under AGPL v3, our servers are located in Germany. We have officially released, and you can create your account at: https://astermail.org/
We built Aster Mail because we wanted end-to-end encrypted email that's actually private. All encryption and decryption happens client-side. We encrypt email content, subjects, contacts, folder structure, search indices, timestamps, and attachment data before anything touches our servers. Minimal routing metadata (sender/recipient addresses) is required for SMTP delivery, but we encrypt everything we can beyond that. On top of standard PGP, we include post-quantum cryptography by default, protecting against store-now-decrypt-later attacks.
Aster's feature set includes things like: free aliases & ghost aliases (auto-generated anonymous addresses), free custom domains, encrypted contacts with device syncing, burn-after-read messages, scheduled send, email snooze, encrypted search, and subscription management.
We ran a closed beta since early Feb and have gone through 150+ revision cycles based on tester feedback, so the product is stable and feature-complete. The entire codebase is public on GitHub and licensed under AGPL v3, and our team is here in the comments to answer questions about how it works.
Longer term, Aster is building a full encrypted communications suite with drive, chat, and authenticator. Aster Mail is currently available on Web, Windows/Mac, Linux, and will be available soon on iOS/Android.
Side note, since it'll come up: "why not just use Proton?" Proton's architecture exposes metadata to the server, which means it can be handed over in response to legal requests, and has been, repeatedly. Aster encrypts email content, subjects, contacts, and most metadata client-side. Between Aster users, we use a Signal-inspired protocol (X3DH + Double Ratchet + ML-KEM-768) that provides forward secrecy, so even if keys are compromised in the future, past messages stay protected. External emails use RSA-4096 PGP. Our architecture is designed so that even under legal compulsion, there's very little useful data to hand over.
We're not anti-Proton. We just think there should be an alternative that actually protects users' privacy and is practical, in an increasingly monitored world.
We built Aster Mail because we wanted end-to-end encrypted email that's actually private. All encryption and decryption happens client-side. We encrypt email content, subjects, contacts, folder structure, search indices, timestamps, and attachment data before anything touches our servers. Minimal routing metadata (sender/recipient addresses) is required for SMTP delivery, but we encrypt everything we can beyond that. On top of standard PGP, we include post-quantum cryptography by default, protecting against store-now-decrypt-later attacks.
Aster's feature set includes things like: free aliases & ghost aliases (auto-generated anonymous addresses), free custom domains, encrypted contacts with device syncing, burn-after-read messages, scheduled send, email snooze, encrypted search, and subscription management.
We ran a closed beta since early Feb and have gone through 150+ revision cycles based on tester feedback, so the product is stable and feature-complete. The entire codebase is public on GitHub and licensed under AGPL v3, and our team is here in the comments to answer questions about how it works.
Longer term, Aster is building a full encrypted communications suite with drive, chat, and authenticator. Aster Mail is currently available on Web, Windows/Mac, Linux, and will be available soon on iOS/Android.
Side note, since it'll come up: "why not just use Proton?" Proton's architecture exposes metadata to the server, which means it can be handed over in response to legal requests, and has been, repeatedly. Aster encrypts email content, subjects, contacts, and most metadata client-side. Between Aster users, we use a Signal-inspired protocol (X3DH + Double Ratchet + ML-KEM-768) that provides forward secrecy, so even if keys are compromised in the future, past messages stay protected. External emails use RSA-4096 PGP. Our architecture is designed so that even under legal compulsion, there's very little useful data to hand over.
We're not anti-Proton. We just think there should be an alternative that actually protects users' privacy and is practical, in an increasingly monitored world.
Based in Florida (?), United States. Subject to the US surveillance laws and obligated not to report on government access requests, whether legal or illegal.
No thank you, Proton or Tuta would be a better alternative.
No thank you, Proton or Tuta would be a better alternative.
This is definitely a fair concern, and something that we have thought thoroughly about, but let me clarify some things:
Our architecture makes jurisdiction less relevant than it would be for a traditional email provider. All email content, subjects, attachments, contacts, etc are encrypted client-side, locally, before they reach our servers, and you hold the keys, not us.
If we ever were to receive a legal request, we could only hand over encrypted blobs and routing metadata (sender/recipient addresses, timestamps), the same metadata any email provider in any country would have.
We maintain a warrant canary at https://astermail.org/notices/canary.txt, and we have a full transparency report at https://astermail.org/transparency. We have never received a secret government subpoena, national security letter, or a gag order to date.
Our architecture makes jurisdiction less relevant than it would be for a traditional email provider. All email content, subjects, attachments, contacts, etc are encrypted client-side, locally, before they reach our servers, and you hold the keys, not us.
If we ever were to receive a legal request, we could only hand over encrypted blobs and routing metadata (sender/recipient addresses, timestamps), the same metadata any email provider in any country would have.
We maintain a warrant canary at https://astermail.org/notices/canary.txt, and we have a full transparency report at https://astermail.org/transparency. We have never received a secret government subpoena, national security letter, or a gag order to date.
We had a discussion at LeT, where privacy focussed email provider (Aster Mail) used client side validation for restricted email address, and a user bypassed to create restricted email address Did you moved all such things from Client side to server side? or are you using the same client side validations?
Yes, we did see the thread shortly after it was posted, and we did move the restricted email address validation to the server side. The client-side check is still there in the UX layer, but it is no longer the security boundary. Thank you for bringing it up here.
cool, just asked when i saw the post.
My concerns:
* rumored to be founded by Roblox exploiters
* some commits on GitHub are insanely large 1,000 file commits. And they claim to have a team but all contributions are the same individual (seems vibe coded)
* Claude.md is git-ignored
* huge security flaws on first launch (no server side checks for things, like an LLM would do)
I’m going to watch how this develops, good luck!