How it works

A plain-English walk through the design, including the limits we are clear about.

Aurora starts from a single principle: the people who build a messenger should be incapable of reading your conversations, not merely promising that they won't. Most apps ask you to trust a company. Aurora is arranged so that there is very little to trust in the first place, because the parts that could betray you simply never hold your messages. This page explains how that works, in order, and where the honest boundaries are.

The shape of the system

Your messages travel directly from your phone to the other person's phone, encrypted the whole way. There is one small piece of shared infrastructure, a rendezvous server, and its only job is to help two phones discover each other's current address on the internet. It is never in the path of a message. Encryption, delivery, calls, and media all happen between the two devices and nowhere else.

Your identity is a key, not an account

The first time you open Aurora, your phone generates its own cryptographic keys. You are never asked for a name, a phone number, or an email, and no account is created anywhere. Your address on the network, called a Node ID, is derived directly from your public keys. Because the address is computed from the keys, anyone can check that a given address truly belongs to a given set of keys, and no one can take your address by presenting different keys.

Those private keys stay on your device. They are protected by the phone's hardware-backed Keystore. The post-quantum keys are larger than the secure chip can hold directly, so they are stored encrypted under a master key that does live in that chip, and they are unlocked only in memory when the app needs them. They never exist on disk as readable files, and they never leave your phone.

How two people connect

Pairing follows a recognition-then-verify flow, designed so that a stranger cannot quietly insert themselves between you.

• Scan. You scan the other person's QR code. Scanning it in person is the strongest option, because an in-person code cannot be tampered with on the way to you, but the code can also be shared as an image and scanned from the gallery.
• Accept or reject. A scan does not silently create a contact. The other device shows an incoming request and chooses to accept or reject it.
• Verify. Each phone then displays its own short verification code, and you each enter the one shown on the other's screen. The codes are computed independently on both devices from the shared secret, so if anyone had slipped into the middle, the two sides would hold different secrets and the codes would not match. The codes are never sent over the network.

The handshake behind that flow is forward-secret. When you pair, your phone fetches the other person's signed prekey bundle and combines three keys: their long-term identity key, a medium-term signed prekey, and a single-use one-time prekey. The one-time prekey is destroyed the moment it is used. This means that even an attacker who recorded your handshake and later stole your device's long-term key still cannot rebuild the conversation, because the ephemeral piece that also protected it no longer exists.

The encryption

Most encrypted apps rely on mathematics that a future quantum computer could break. Aurora pairs today's proven algorithms with the new post-quantum standards, so an attacker has to defeat both the classical and the quantum-era piece at the same time.

• Key agreement: Kyber-1024 (post-quantum) together with X25519 (classical).
• Signatures: Dilithium-3 (post-quantum) together with Ed25519 (classical), where both must verify.
• Message encryption: XChaCha20-Poly1305, the authenticated cipher used by leading privacy tools.

Every message also draws a fresh key from a one-way chain that ratchets forward and discards the old key after use. A key recovered from a phone today therefore cannot unlock yesterday's messages. A plain-English tour of each algorithm, with its history, lives on the Security page.

The server that knows almost nothing

To deliver a message, your phone needs the recipient's current internet address. The rendezvous server helps with exactly that, and nothing more.

• It holds a temporary map of Node ID to IP address that expires after 15 minutes, and it keeps no logs.
• When you look someone up, it returns their address mixed with nine decoys, so a lookup cannot be used to harvest other people's addresses.
• It carries a small encrypted mailbox for pairing and call-setup signals. Only the rightful owner can read or empty it, because every drain is signed by the key behind that Node ID.
• It can nudge a phone to wake up and come online. That nudge is a single contentless signal, never any message content.
• It hands out the signed prekey bundles used by the forward-secret handshake. It stores only public keys, never any private key and never any message.

The connection to the server runs over TLS, and the app pins the server's certificate, so it cannot be intercepted even by a rogue certificate authority. The server is open source and self-hostable, has no third-party runtime dependencies, and writes no logs beyond a brief startup message.

How messages travel

Text, photos, videos, and voice notes go straight from one phone to the other over an encrypted direct connection. If the recipient is offline, the message waits on your device and is delivered the moment they come back, rather than being parked on a server. Media is also encrypted at rest with a key that never leaves your device.

There is an optional feature called ShadowMesh. When you turn it on, your traffic is routed through one peer relay hop for extra metadata privacy, and your device helps relay encrypted fragments for others. A relay can never read what passes through it. ShadowMesh is off by default, and Aurora works fully without it.

Calls

Voice and video calls are end-to-end encrypted and connect peer-to-peer. The call-setup messages are sealed, so the server sees only ciphertext, and once a call connects, the audio and video flow directly between the two phones. There are no call logs and no recording.

If your phone is lost or taken

• The entire local database is encrypted, with the key held behind the device's hardware Keystore.
• A decoy PIN opens a clean, empty-looking version of the app, giving you plausible deniability under pressure.
• An optional duress mode wipes everything instead. Wiping means destroying the keys, which turns the data left on disk into unrecoverable noise instantly.
• Screenshots and the recent-apps preview are blocked across the app.
• An encrypted, passphrase-protected backup lets you move to a new phone, and only you hold the passphrase.

Open and verifiable

You do not have to take any of this on faith. Aurora is released under the GNU Affero General Public License (AGPL-3.0), so the application and the rendezvous server are fully open for anyone to read, audit, and run. Because the AGPL also covers software offered as a network service, anyone who runs a modified Aurora server has to publish their changes, and each server exposes a source link for that reason. The code lives on GitHub.

What we deliberately don't claim

A privacy app that oversells itself is not private, so here are the limits stated plainly.

• No self-healing after device compromise yet. Each message draws a fresh, single-use key, but a conversation currently rests on one root secret established at pairing. Past messages stay protected, but someone who fully compromised a phone's current state could follow that conversation forward until you re-pair. A continuous re-keying ratchet that recovers from this is the next planned step.
• This is pre-alpha. It is an early, experimental build, it is not yet performance-optimized, and the database format is still changing between versions.
• The server learns reachability. To wake your phone, the server can tell that your device is online and what its IP address is. That is never message content, and it is never logged, but it is not nothing.
• No third-party audit yet. The cryptography is carefully built from standard primitives, but it has not been independently audited. Until it has, do not rely on Aurora for life-and-death threat models.

Questions are welcome at christiancorrea26@gmail.com.