Security status and roadmap
Security isn't a box you tick: it's a state that changes. Here we tell you, without embellishment, what protects you today, what we do NOT have yet, and what we're working on. We'd rather you hear it from us.
What protects you today
End-to-end encryption on your device
AvailablePlaintext only ever exists on the phones. The sender encrypts with the recipient's public key (ECIES: ECDH over P-256 + AES-GCM, with the AES key derived via HKDF-SHA256 and the ephemeral key bound as AAD) and only the recipient, with their private key, can decrypt. Neither the central server nor the node sees the content.
No phone number
AvailableWe don't ask for your phone number, so there's no link to your real identity and no surface for SIM-swapping. Your identity is a user code, not a number. To provide the service we do need an email address, but it can be anonymous: even on the free plan you can use MILITAR without revealing who you are.
Your mailbox on your own node
AvailableMessages and files (already encrypted) rest on a node you can run yourself. It lowers the value of attacking the central infrastructure and gives you sovereignty over retention and purging.
The private key never leaves the device
AvailableThe private key is generated and kept on the phone (Android secure storage). It is never uploaded to the server.
Key backup and recovery
AvailableYou can export your key or email it to yourself (protected by a security question only you know) and restore it on another phone: you recover the SAME identity and can read your messages again. And if a contact loses their key, you can resend them your shared history re-encrypted with their new key. Since it's E2E encryption, losing the key without a backup is irreversible — that's why we insist you back it up.
Key verification between users (anti-MITM)
AvailableSince the central server hands out public keys, you need to be able to check that your contact's is the real one. Now you can: in each conversation, a "safety number" you both compute ON THE PHONE from your keys and compare by QR or out loud. It's computed on the device, not on the server, so not even we can fake it; it also warns you if a contact's key changes.
How we protect history: Double Ratchet
Each text message uses a new key derived by the ratchet. It activates between two up-to-date users; if the other doesn't have it, the previous encryption is used automatically.
Current status: Double Ratchet is TEMPORARILY DISABLED again. We turned it on by default in version 3.0.119 after fixing the cause of an earlier failure, but real delivery and decryption problems showed up in production (a race condition when encrypting two messages in quick succession in the same conversation), so we switched it off again in 3.0.120 while we validate it more carefully. Meanwhile, every message stays end-to-end encrypted with an ephemeral key (ECIES v2).
Known limitations (compared with the best in the field)
Signal is today's cryptographic benchmark. These are the real differences versus it, and what we're doing about each.
Forward secrecy
In progressWe're implementing "Double Ratchet" (the same mechanism as Signal): every message would be encrypted with a key that's discarded right after, derived from a fresh key exchange (X3DH). We turned it on by default in version 3.0.119 but found real delivery and decryption problems in production, so we've switched it off again while we debug it more carefully. Every message stays end-to-end encrypted with an ephemeral key (ECIES v2), which doesn't have that issue.
Metadata: distributed, not eliminated
In progressContent is encrypted, but the central server knows who exists and which node they're on, and the node sees who deposits/collects and when. It isn't a single server that sees everything, but it isn't "zero metadata" either. We're working on "sealed sender" techniques so the node doesn't know who's sending.
External audit and open source
In progressWe've already published the protocol specification and are opening the client and node code (AGPL-3.0 license) so anyone can review it. An independent audit is still pending. In security, "trust our word" isn't enough.
Post-quantum cryptography
Under evaluationWe don't yet use cryptography resistant to quantum computers. It matters because of "harvest now, decrypt later". We're following the hybrid approach (Kyber-style) that Signal already deploys and have it on the radar.
Platforms: Android only for now
Under evaluationToday there's only an Android app. iOS and desktop (and multi-device use) are pending. We say so, so nobody buys expectations we don't yet meet.
Our commitment
This page will be updated as we close each point. We don't promise to be Signal tomorrow; we promise to tell the truth about where we are today. If the privacy of your conversations is critical against a well-resourced adversary, right now Signal is more robust and we recommend it without hesitation.