Password-protected, quantum-safe messages to anyone

The hardest part of encrypted email has never been protecting the messages between people who both care about privacy. When both sides have keys and both clients know what to do, the system works. The hardest part is protecting messages to the rest of the world - Gmail, Outlook, Apple Mail.

Most people you email have not configured anything. They do not have PGP keys, and if you try to send them an encrypted message, Aster will tell you it cannot find their keys and ask what you want to do instead. The common answer to that question is to give up and send in plain text. That is what we decided to fix.

What Secure View does

Whenever you send a message to a recipient outside of Aster, you can choose to send it as a Secure View instead of standard email. Your client encrypts the message content on your device, sends the ciphertext to our server, and generates a time-limited link. The recipient gets an email containing only that link, a brief explanation, and an expiry notice. The actual message body, subject line, and any attachments never travel outbound in that email at all.

When the recipient opens the link, they see a page asking for a password. They enter the password you shared with them through a separate channel, and their browser derives the decryption key. The message decrypts inside their browser. Our server delivers only the ciphertext - their browser does the decryption. We never see the message content in plain text.

The link expires after the window you set. Options are 1 hour, 24 hours, 7 days, or a custom window. After expiry, the ciphertext is deleted from our servers. Failed password attempts trigger a lockout to prevent brute-force attacks.

Quantum-safe

The encryption Aster uses for Secure View is not just AES-256. The key derivation for the per-message encryption key incorporates ML-KEM-768, the post-quantum key encapsulation mechanism standardized by NIST in 2024.

The concern this addresses is harvest-now-decrypt-later attacks. An adversary could capture the encrypted message blob today and wait for quantum hardware to mature. With classical encryption alone, that is a realistic threat for anything sensitive enough to be worth storing. ML-KEM-768 is lattice-based and designed to remain secure against quantum attacks. A message you send today stays private in that future scenario.

This encryption applies to the content, subject line, and any attachments. All of it is encrypted with the same construction before it reaches our servers.

How to share the password

This is the part we want to be clear about.

Secure View does not solve the key exchange problem. You still have to get the password to your recipient through a separate channel. If you send it in the same email as the link, you have rendered Secure View useless. The password needs to travel through a secure communications channel that is separate from the link.

A phone call, an encrypted text message, or an in-person conversation all work. Any channel that is not the same email carrying the link gives you a meaningful separation. The attacker who intercepts the link still only has the ciphertext.

Aster does not automate this for you. Building a system that exchanges a secret key with an arbitrary recipient who has no prior relationship with your encryption infrastructure is a genuinely hard problem. What we can do is give you a strong, encrypted container and let you handle the handshake through whichever secure channel you trust.

How this compares to Aster-to-Aster encryption

When you send a message to another Aster user, it is encrypted on your device with their public key before it leaves. Our server holds only ciphertext and has no ability to read it. The recipient’s device decrypts it locally, and the server is not involved in that step.

Secure View is different. The ciphertext lives on our servers until the lease expires, and we cannot decrypt it without the password, but we are holding the encrypted blob.

What Secure View gives you over standard outbound email:

• The message body never travels in plain text to an external recipient.
• The subject is encrypted.
• Attachments are encrypted.
• The content is not present in the receiving server logs.
• There is no risk of the message sitting in a Gmail inbox, readable by Google systems.

What it does not give you is the same guarantee as Aster-to-Aster messages, where the server is a pure relay and the keys never touch it. If your recipient is on Aster, send them a regular message. Use Secure View when you need to reach someone outside of Aster.

Attachments

Attachments are included in the Secure View encryption. The file data and filenames are both encrypted separately before storage, each with its own nonce. The recipient downloads the ciphertext through the same Secure View page, and the browser decrypts it locally before the download completes.

The attachment count visible to our server is zero until the recipient decrypts and their client renders the message. At no point do we store an unencrypted filename or file contents.

What happens on expiry

When a Secure View link expires, the ciphertext is fully wiped from our servers. The link stops resolving, and if the recipient did not open it in time, the message is completely gone. There is no way to recover it, and there is no way to extend an expired link. No server-side copy is retained.

If you need to reach them again, send a new Secure View message. The ciphertext from the first one is not kept.