Security
Cryptography you can read line by line.
This page is the public-facing summary. The complete security specification is available under NDA and includes message-flow diagrams, threat model, and key-rotation procedures.
The cryptographic stack
Well-known primitives. Implemented carefully. Tested in production.
- 01
Identity and device keys
Each device generates an Ed25519 identity keypair on first launch. The private key is stored in the operating system's secure keystore (iOS Secure Enclave, Android Keystore / StrongBox where available) and never leaves the device in plaintext. The public key is uploaded as part of device registration; it is the root of trust for that device for as long as the device exists.
- 02
X3DH session establishment
When Alice first messages Bob, her device fetches Bob's public identity key, signed prekey, and one-time prekey from the server. A four-way Diffie-Hellman computation produces an initial shared secret. The one-time prekey is consumed on first use, giving forward secrecy even if Bob's long-term key is later compromised.
- 03
Double Ratchet
After the X3DH handshake, every message advances two ratchets: a Diffie-Hellman ratchet that updates whenever direction reverses, and a symmetric chain ratchet that advances per message. Old chain keys are deleted immediately after use. Compromise of the current state cannot decrypt past traffic, and is overwritten on the next exchange.
- 04
Group messaging with Sender Keys
For groups, each sender encrypts once with their Sender Key rather than once per recipient. Membership changes (add, remove, role change) rotate the Sender Key for affected members. The server cannot enumerate group membership beyond the device IDs it routes envelopes to.
- 05
Files and voice notes
Each file is encrypted with a random 32-byte key under XChaCha20-Poly1305 in a streamed, per-chunk construction (256 KB chunks). The chunked design supports large files without buffering plaintext in memory. The file key itself is delivered inside the Double Ratchet envelope; the server never sees it.
- 06
Calls
Call signaling (SDP, ICE candidates) travels inside the Double Ratchet envelope. Media uses standard DTLS-SRTP between the participants. For groups, a self-hosted SFU forwards encrypted media. It does not decrypt, transcode, or record. Group key material is established between participants out-of-band of the SFU.
- 07
Server-side posture
The server is a Go binary with PostgreSQL and Redis. It stores: device records (public keys), encrypted envelopes (ciphertext blobs), routing metadata (sender, recipient, timestamp, size). It does not store: plaintext, decryption keys, message content, file content. A full database compromise yields ciphertext envelopes whose keys are not present.
- 08
What an audit covers
On request, we provide: source access for the cryptographic modules, test vectors for the X3DH and Double Ratchet implementation, the threat model, the deployment-hardening checklist, and the SBOM. Customer-led audits are welcomed and a recurring feature of public-sector procurement.
What we ship
Recent engineering work.
Three recent commits give the texture. We pick reliability over surface area.
- Calls
Proactive network-switch handling
The client detects Wi-Fi to cellular transitions and triggers an ICE restart before the call drops. Most consumer apps require a manual retry; ours hands off mid-call.
- Calls
Native lock-screen integration
Incoming calls surface through CallKit on iOS and ConnectionService on Android. Users answer from the lock screen with the native UI, including ringtone and call-quality reporting.
- Media
Hardware-accelerated video with variable playback
Inline video plays at 1×, 1.5×, and 2× with smooth orientation handling. Decoded on device, never streamed through a server.
Frequently asked, technical
Questions a CISO will reach for.
-
01 Can Amana operate fully offline?
Yes. The air-gap deployment runs on a private LAN with no internet egress: internal CA for TLS, private TURN, ntfy for push, internal DNS. We ship the same binaries that run in connected environments.
-
02 What happens if a device is lost or seized?
Device-bound keys live in the OS keychain (iOS Secure Enclave, Android Keystore). They are not extractable. On wipe, the keys are destroyed and the history that depended on them is unrecoverable. By design. Remote wipe is supported via an existing trusted device.
-
03 Is the cryptography audited?
Amana uses well-known primitives (X3DH, Double Ratchet, Sender Keys, XSalsa20-Poly1305, XChaCha20-Poly1305), implemented via the audited tweetnacl library. A full security specification is available under NDA, and we welcome customer-side audits.
-
04 Can it run on FIPS-validated hardware?
Yes. The Go backend and database tier run on standard Linux; deployment on FIPS 140-validated kernels or HSM-backed key storage is supported. The mobile clients use platform-native key stores (iOS Secure Enclave, Android StrongBox) for device keys.
-
05 How do you handle key compromise?
The Double Ratchet provides post-compromise security: even if a key is exfiltrated, the next message exchange ratchets it forward and the attacker loses access. Device revocation is initiated from an existing trusted device and propagates over the encrypted channel.
-
06 What is the disaster-recovery story?
Server-side: standard PostgreSQL backup, plus encrypted-envelope replication. Because messages are encrypted at the source, a backup of the database is a backup of ciphertext. It cannot be turned into plaintext without device keys, which are not in the backup.
-
07 Can you integrate with our identity provider?
SAML and OIDC integration is supported for user onboarding and administrative roles. Per-user encryption keys remain device-local; the IdP authorises account creation but does not hold message keys.
-
08 What is the patch SLA?
For deployed customers, critical patches are delivered within 72 hours of disclosure; non-critical patches on a monthly cadence. Air-gapped customers receive signed update bundles for offline application.
Talk to us
Thirty minutes with the people who built it.
Not a sales bench. The engineers who wrote the protocol take the meeting, hear the constraint, and tell you honestly whether Amana fits.
contact@amana.app