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.
Who it protects you from: whoever attacks your communications. MILITAR is not meant to shelter the criminal, but to keep you from becoming their victim.
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 phone's database, encrypted
AvailableYour conversations stored on the phone live in an encrypted database (SQLCipher), and its key lives in the Android keystore, not inside the database. The content was already encrypted, but the metadata was not: who you talk to, when, and how many messages were visible to anyone who pulled the files off the phone. Not anymore.
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. 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: on by default for all one-to-one conversations since version 0.10. It was disabled in 3.0.120 because of a race condition when encrypting two messages in a row, now fixed. Group rooms do not have it yet: they encrypt one copy per member with the previous encryption (ECIES v2).
Known limitations (compared with the best in the field)
The strongest privacy-focused messengers are today's cryptographic benchmark. These are the real differences versus that benchmark, and what we are doing about them.
Forward secrecy
AvailableEvery message is encrypted with a different key that is discarded immediately (X3DH + Double Ratchet). If someone steals your key tomorrow, they cannot open what you wrote yesterday. Active in one-to-one conversations and in your own copy of what you send. Group rooms do not have it yet.
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.
Specifically, today the NAME of an attached file is stored unencrypted on the central server (the content itself is encrypted). A name like "january-payroll.pdf" says a lot, so we tell you rather than keep quiet about it: encrypting it alongside the content is on the work list. If it matters to you, rename the file before sending it.
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.
Where your files actually rest
AvailableIf you use one of OUR nodes, your photos, videos and attachments do not stay on that machine's disk: they rest in a Backblaze object store, in Canada. They are encrypted on your phone before they leave, so that provider only sees noise and cannot open anything. But it does see each file's size, when it is uploaded and how often it is downloaded: that is metadata, and we would rather tell you. If that is not good enough for you, run your own node: then your files stay wherever you decide and we are not involved.
Post-quantum cryptography
Under evaluationWe don't yet use cryptography resistant to quantum computers. It matters because of "harvest now, decrypt later": someone could store your traffic today and decrypt it years from now. The hybrid approach (Kyber-style) is already being deployed across the sector and it is on our radar.
Our commitment
This page will be updated as we close each point. We do not promise to match the best tomorrow; we promise to tell you exactly where we stand.