Is Aster Safe If It's Based in the US?

Aster is based in the United States, but here is how and why we keep your mail private.

A reasonable question we get asked a lot is why would somebody trust a US-based privacy company with their private mail? Given that Aster Privacy (Aster Communications Inc) is a Delaware C corporation operated out of Orlando, Florida, and the United States has the CLOUD Act, FISA Section 702, and National Security Letters issued under a gag order. This is a fair concern and the lessons of Lavabit mean that we should not try to hide this through marketing language and we should be transparent about it. The honest truth is that being a U.S. company would matter a great deal if we actually held the keys to our users’ private mail, and that matters very little because we do not.

Where Aster’s servers are located

All of our mail servers and infrastructure run on Hetzner in Falkenstein, Germany. This includes the database that holds your account, the storage that holds your encrypted mail, and the backups that hold both are all located on infrastructure within the European Union. None of this infrastructure is based in the U.S., and all of it sits under the protection of GDPR

The CLOUD Act, however, is clear that a physical location by itself is not a defense. The U.S. company can be compelled to produce data it has possession, custody, or control over, regardless of where that data physically is located. The question that actually matters is not where the servers are, but what we, as the U.S. entity, are able to see and read.

What a US court could compel Aster to hand over

It’s always worth being skeptical of any privacy company that claims to have nothing on its users, because every email service has to hold some plain text somewhere in order to deliver the mail. The honest answer for Aster is that we hold three categories of plain text data, each for a specific reason to make our service operational.

The first is your account record, which contains your username, display name, signup date, last login, and current plan tier. The second is country-level login data, where we record the country you logged in from along with the hash of your IP (hashed on the client side). Never the IP itself in plain text.

The third one, and the one that matters most for public disclosure, is email routing metadata, in specific, where your mail is sent to and where it is coming from.

When an email arrives at our servers from outside Aster, we have to process the envelope information required by the SMTP protocol. This means that we can see the recipient address (who it is being sent to) and the sender address (where it came from). This same limitation applies when you send mail to external addresses. This is an inherent limitation of the SMTP standard. Every email provider, including other encrypted providers, has this same exact limitation.

What a US court cannot compel Aster to hand over

For everything outside of that recent window, we cannot read your mail, ever. The reason is more technical rather than legal.

Whenever you set your password, the client will derive a key from it. That key is used to encrypt your OpenPGP private key, with the resulting encrypted blob being what we store on our servers. Your password is never sent to our servers in plain text, and your private key will never leave your device in a usable form.

Without your password, your private key on our servers is just cipher text. Without your private key, your mail in our database is also cipher text

Once your client has finished processing an incoming message, the message will live in our database as a single encrypted envelope containing the body, the subject, the attachments, every header sealed inside one ciphertext blob encrypted to your vault key.

Drafts work the same way. Contacts are encrypted under your key in a separate table. Folder names are encrypted so the server sees only opaque tokens, and the search index is encrypted so we only see hashed search tokens. We can never see the keywords or the matches. We could not decrypt this for a court even if we tried, and the requesting party could not decrypt it without your password, which we do not have and will never have.

This is the main part of the architecture that makes U.S. jurisdiction matter less than most people will assume. We are not protected by being abroad, because we are not abroad. We are protected by not having the keys, which is the only protection that holds together whenever the law of the land says that the company has to hand over whatever it has and whatever it can.

The bigger question: compelled software updates

A more subtle attack any web-based service has to confront is that a court could attempt to compel us to ship a malicious software update to a single targeted user, designed to exfiltrate that user’s password the next time they log in.

Our main protection against compelled backdoors or any sort of legal pressure is operational and not just cryptographic.

We have published all of our source code on our GitHub organization under various licenses. We keep a very tight grip on the development process, and every change gets reviewed internally before it is published to our production server.

That being said, we are still not perfect yet. Right now, we do not sign our desktop binaries, we do not offer reproducible builds, and we do not maintain a transparency log where someone could independently verify that the app running on your computer matches our public source code.

These improvements are at the very top of our roadmap. Getting them done is the single biggest thing we can do to move beyond “you’ll just have to trust us” to “if we ever betrayed that trust, anyone could prove it.”

Being a US company does not make us safe, and not being a US company would not make us safe either, as the recent pressure on Tutanota in Germany demonstrates. What makes a privacy service worth using is whether the architecture is built such that the people running it could not betray you even if they wanted to, and whether they tell you the truth about the gaps that remain. If we ever fail at either, this site is where we will say so.