Protected against computers that don't exist yet

Aurora uses post-quantum cryptography, the same class of algorithms governments are adopting for their most sensitive communications. A message intercepted today could be stored and decrypted years from now once quantum computing matures; Aurora's encryption is designed to stay sealed against that.

Every primitive below pairs a post-quantum algorithm with a proven classical one, so an attacker has to break both (old technology and future technology) to get anywhere. Tap each to read its history and a plain-English explanation.

KYBER-1024 + X25519

+

Post-quantum key exchange, resistant to both classical and quantum attacks.

Kyber was developed by cryptographers across Europe and the US and selected by NIST in 2022 as the first standardised post-quantum key-encapsulation algorithm, after six years of global competition. X25519 is a classical algorithm designed by Daniel J. Bernstein in 2005, trusted and used by Signal, WhatsApp, and TLS.

When you and another person first connect, your phones perform a handshake that establishes a shared secret only the two of you ever hold. Kyber makes that handshake resistant to quantum computers; X25519 covers classical threats. Using both means neither old nor future technology can break it: two locks on the same door, each needing a different kind of key.

Why it matters. If someone records your encrypted traffic today and stores it, they still cannot read it later — not even with a future quantum computer — because the session key exchange itself is shielded by Kyber. This defeats the "harvest now, decrypt later" attack, where an adversary banks intercepted data and waits for the technology to catch up.

XCHACHA20-POLY1305

+

Authenticated symmetric encryption for every message, using a key that never leaves your devices.

ChaCha20 was designed by Daniel J. Bernstein in 2008 as a faster, more robust alternative to AES. XChaCha20 extends it with a larger nonce so no two messages are ever encrypted the same way, and Poly1305 is an authenticator that detects any tampering. The combination secures HTTPS traffic for billions of users.

This is what actually scrambles your messages. Once a shared secret exists between two devices, every message (text, photo, video) is sealed with it before it leaves your phone. The scrambled version is what crosses the internet. Without the secret, which exists only on your devices, it is indistinguishable from random noise.

Why it matters. XChaCha20 is a stream cipher chosen because it's exceptionally fast on mobile processors, and its 192-bit nonce makes it virtually immune to nonce reuse — a subtle implementation mistake that has broken other systems' encryption. Poly1305 then acts as a tamper seal: if even one bit of a message is altered in transit, the receiving phone detects it and rejects the message.

DILITHIUM-3 + ED25519

+

Post-quantum signatures that verify every message comes from the right device.

Dilithium (ML-DSA) was developed alongside Kyber and standardised by NIST in 2024 as a primary post-quantum signature scheme. Ed25519, designed by Bernstein and colleagues in 2011, is used by SSH, Signal, and most modern security infrastructure to verify identity.

Encryption hides what you say; signatures prove who said it. Each device's check-ins and pairing messages are signed with a key only it holds, and the other phone checks that signature before trusting them. If anything was altered in transit, the check fails and the message is rejected. No one can impersonate you or tamper with your words undetected.

Why it matters. This is the layer that stops a man-in-the-middle — someone on the network pretending to be your contact. Because every check-in and pairing message is signed by a key only your contact's device holds, you can be mathematically certain a message came from their specific device and wasn't forged or altered by anything sitting in between.

HARDWARE-BACKED KEY STORAGE

+

Your identity and database keys are protected by the phone's secure hardware.

The Android Keystore, expanded in Android 6.0 with hardware-backed storage, can hold keys inside a dedicated security chip (a Trusted Execution Environment) that operates independently of the main processor, so even a compromised OS cannot read them.

Aurora's post-quantum keys are large, too large to live inside the Keystore chip directly, so they're stored encrypted on disk under a master key that is held in the hardware-backed Keystore, and the local database is encrypted the same way. The keys are only ever unlocked in memory when the app needs them; they never exist on disk as readable files. Even with full access to your phone's storage, an attacker finds only ciphertext.

Why it matters. If your phone is lost or stolen, or an app gains access to its storage, it finds only scrambled data — your messages and keys at rest are unreadable without the master key, which is sealed in hardware that even a compromised operating system cannot read out. The honest limit: while the app is open and actively in use, the keys it's working with are decrypted in normal memory, so this protects data at rest — not a phone that is already fully compromised and running. No storage encryption can.

What the service cannot see

Most apps are vague about what they observe. We prefer to be exact.

Your message content
Who you are talking to
Photos or videos you share
Your name or identity
Your location
Your contact list

What it can tell, honestly. To wake your phone when someone messages you, the rendezvous server keeps a lightweight connection and a 15-minute record of your Node ID and IP address. So it can tell that your device is reachable — never your messages, your media, or who you are, and it keeps no logs. Because nothing is logged, it does not retain when or how often you talk; a malicious operator watching live could infer some timing from when a device comes online, but content, media, and identities stay sealed regardless. If compelled by a court order to surrender your conversations, it could not: they exist only on your device. When two devices connect, they punch a direct peer-to-peer path (WebRTC/ICE, helped by a self-hosted STUN mirror that only reflects a device's own address and never carries traffic), preferring IPv6 and falling back to IPv4 — so the server stays out of the message path. Two phones both on strict carrier NAT with no IPv6 may not reach each other directly yet; the app says so honestly, and a volunteer peer-relay (ShadowMesh) for that case is planned. See the limits we're explicit about in How it works, and the full threat model.

For security researchers

Aurora is fully open source and is being prepared for independent review. It has not yet had a third-party security audit — scrutiny is welcome, and good-faith reports make it safer. Please report privately rather than opening a public issue.

Email christiancorrea26@gmail.com. The full policy, scope, supported versions, and safe-harbor terms are in the security policy.

Audit documentation

Everything is verifiable on GitHub under AGPL-3.0.