People often assume "end-to-end encrypted" means a conversation is automatically safe from impersonation. It isn't — not on its own. Encryption guarantees that whatever key exchange happened, only the two parties holding the matching private keys can read the traffic. It says nothing about whether those two parties are actually who they claim to be. That's a separate problem, and it has a separate solution: key verification, usually shown to you as a safety number.
The gap encryption alone doesn't close
Every encrypted session starts with a key exchange — in SimXmil's case, an ECDH exchange on curve P-256, detailed in the encryption docs. Both sides generate keys, exchange public keys, and derive a shared secret. The math is sound. But the exchange still depends on receiving the correct public key for the person you're talking to, and that delivery step happens through a server neither of you fully controls.
This is the textbook setup for a man-in-the-middle attack: if something in the middle can substitute its own public key during that exchange, the encryption is still "working" in the sense that everything gets encrypted — just with keys that route through an unwanted third party first. Both endpoints would see a perfectly normal, encrypted conversation. The math never breaks. What breaks is the assumption about who's on the other end.
What a safety number actually is
A safety number is a long numeric string derived from a cryptographic hash of both participants' public keys, formatted into readable groups of digits. It's not a secret — it doesn't need to be. Its job is simpler: if the same conversation, viewed from both devices, produces the same safety number, that mathematically confirms both devices hold the exact same pair of public keys with nothing substituted in between.
If a man-in-the-middle were present, the two sides of the conversation would each be talking to the attacker's keys instead of each other's real keys — and the safety numbers computed on each device would not match. That mismatch is the entire point: it turns an invisible cryptographic property into something a person can actually check with their own eyes.
Why the comparison has to happen out of band
This is the part people skip, and skipping it is what makes verification pointless. If you ask "hey, what's your safety number?" inside the same chat you're trying to verify, and an attacker is sitting in the middle of that chat, they can simply forward you their own matching number instead of your contact's real one. The channel you use to compare has to be one the attacker doesn't also control.
In practice that means: read the numbers aloud on a phone call, compare them in person, or exchange them over a different app or channel entirely. It only has to happen once per contact under normal circumstances — after that, an unexpected change in the number is your signal to check again.
Verifying a contact in SimXmil
Open a conversation, go to its Key Verification screen, and you'll see the safety number computed for that specific session. Walk your contact through opening the same screen on their end. Read the digits to each other over a voice call, or sit down together and compare them directly. If they match exactly, the session is confirmed end-to-end — no substituted keys, no unexpected party in the middle.
From that point on, if the number ever changes without an explanation your contact can confirm (a new device, a reinstall), that's worth a quick re-check before you go back to trusting the conversation with anything sensitive.
Who this matters most for — and why it's still worth doing otherwise
Journalists confirming a source, activists coordinating in adversarial environments, and anyone handling information where a substituted identity would carry real consequences should treat verification as a routine step, not an optional extra. But the honest advice applies more broadly than that: verifying a handful of important contacts once — a partner, a lawyer, a close collaborator — costs a few minutes and removes an entire category of theoretical attack from those specific conversations, permanently, for as long as the keys don't change.
Key verification is one layer in a broader design; for the mechanics of how each message itself gets a distinct key on top of a verified session, see the Double Ratchet explainer. For the full list of privacy and security tools available alongside messaging, see Features.