Trust should be inspectable.

The routing server handles encrypted envelopes and the metadata required to deliver them. Where the encryption happens, however, is not the same on every surface, and the difference decides whether the operator can read your messages. We set it out per surface rather than averaging it into one claim.

Android — keys on the device

Identity and device private keys are generated and held on the phone. Sealing and opening happen there. Message plaintext, attachment keys, device private keys and local Vault contents never reach our servers.

Desktop (macOS, Linux) — keys on your machine

The desktop app is the Aura web interface in a native shell, driven by an Aura process that runs on your own computer as a local sidecar. That process holds your device private keys and performs the encryption locally. The trust boundary is comparable to Android: our servers do not hold the keys.

Hosted web at app.auratt.com — keys on our server

The browser is not the client. The page we serve at app.auratt.com contains no cryptographic implementation. The same Aura process that runs locally on desktop is, in the hosted deployment, a container on our infrastructure — and it is that server-side process which holds your device private keys and encrypts and decrypts on your behalf. Inbound envelopes are sent to it to be opened.

Every device has independent signing and encryption keys. A compromised or lost device can be revoked. Adding a routine device requires approval from an authorized existing device; catastrophic recovery uses a separate recovery key.

A sender needs an active permission route before delivery. Permissions can distinguish communication purposes, include limits, expire, and be revoked.

Encryption does not remove all metadata. Routing services can observe identifiers, timestamps, delivery state, object class, and ciphertext size. Production security claims also depend on deployment configuration and independent review.

• On hosted web, we are inside your trust boundary. See "Encryption boundaries" above. This is the single most important limitation on this page.
• Group messages are sealed per recipient, not with MLS. The sender encrypts the same message separately to every current member's devices. That is genuine per-recipient end-to-end encryption on Android and desktop, but it is not RFC 9420 MLS and does not provide post-compromise group security. An MLS engine exists in the source tree; no product feature uses it, deliberately.
• Calls are peer-to-peer DTLS-SRTP with authenticated signalling. Call recording is not implemented and is disabled in the server's capability response. This is not application-level media end-to-end encryption, and should not be read as a guarantee that would survive routing media through a future server-side mixer.
• Nothing here has been externally certified. No independent cryptographic or protocol review has been carried out. Our own internal assessment documents say so in the same words. Treat every claim on this page as an engineering description, not an attestation.
• macOS and Linux downloads are not code-signed or notarized. See the downloads page for what that means for you and how to verify a build by its SHA-256 instead.