OPSEC52 / Week 15 — Secure messenger choice: Signal vs SimpleX vs Matrix
Every serious messenger encrypts content now, so encryption is no longer the thing that separates them. What separates them is what each one is forced to keep about you anyway: whether it demands a phone number, what routing its servers log, and whether the design leaks your contact graph even when the ciphertext is flawless. Last week showed the envelope betrays you; this week is about which envelope is smallest.
Threat model: the messenger operator, whoever hosts its servers, and anyone who subpoenas, coerces, or breaches them. All the apps here are end-to-end encrypted, so the real question is not “can they read my messages” — it’s “what identifiers and routing metadata does this tool structurally retain, and how much of my social graph can be rebuilt from it.” A phone-number requirement or a chatty federation protocol gives up that graph no matter how strong the content crypto is.
Judge a messenger on three axes, not on the encryption badge
Almost everyone with a modern messenger uses the same crypto lineage (the Signal/Double-Ratchet protocol or something close). So “it’s end-to-end encrypted” tells you almost nothing about your metadata exposure. Judge on these instead:
- Identifier required. Does it force a phone number (a KYC-anchored, carrier-logged, cash-or-crypto-purchase-traceable identity) or does it let you exist as a random key?
- Server model and retention. Centralized, federated, or peer/onion-routed — and what does the routing layer have to store to deliver a message?
- Graph resistance by design. Even under perfect content encryption, can the operator see who talks to whom? That’s the crown jewel and the whole point.
Signal — best-in-class content, phone-number anchor
Signal is the honest default. Its cryptography is the reference standard, and sealed sender hides the sender field from Signal’s own servers for established contacts. Retention is genuinely minimal — repeated subpoenas have returned little more than account-creation and last-connection dates.
The weakness is structural: Signal requires a phone number. That number welds every “private” chat to a SIM, a carrier record, and whatever KYC bought the SIM. Sealed sender protects the envelope’s from line but the registration identifier still exists. Signal is an excellent choice for content secrecy and for most people’s threat models — but if your adversary can subpoena a carrier, the phone number is the thread they pull. If you use it for anything sensitive, register with a non-KYC number bought with cash or crypto, never your real SIM.
SimpleX — no identifiers at all
SimpleX is the strongest metadata posture of the mainstream options because it has no user identifiers whatsoever — no phone number, no username, not even an account ID. Instead of “users who have addresses,” it uses per-contact, one-time message queues; there is no central directory of who you are, so there is no global graph for a server to hand over. Even if you run a relay, it sees unlinkable queues, not “Alice talks to Bob.”
Trade-offs: a smaller network (you have to bring your contacts), a slightly rougher UX, and you must actually route it over Tor to hide your IP from the relays. But for the “who talks to whom” problem — the one that gets people killed — SimpleX is the closest to structurally solving it.
Matrix — federated and powerful, but metadata-heavy
Matrix (Element) is genuinely useful: federated, self-hostable, great for communities. But be clear-eyed — its content is E2E encrypted while its metadata is not, and there’s a lot of it. Room membership, timestamps, reactions, and profile data are visible to your homeserver, and federation spreads that metadata across every server a room touches. A room with participants on ten homeservers means ten operators can see the membership and timing. Matrix is the worst graph-resistance of the three by default.
If Matrix fits your use case, self-host your homeserver so at least your own account’s metadata isn’t sitting on someone else’s box, and understand that anyone you talk to on a public homeserver is still a leak. Great for open community ops; poor for hiding a sensitive contact graph.
The honorable mentions
- Session — no phone number, onion-routed over its own network so servers never see your IP. Good identifier and network posture; smaller ecosystem, and it made cryptographic trade-offs (historically dropping forward secrecy) worth reading up on.
- Cwtch — Tor-native, metadata-resistant, peer-to-peer. Excellent posture, most technical to run.
The discipline: match the messenger to the threat model
- Sensitive contact graph → no phone anchor. SimpleX, Session, or Cwtch. Not Signal-with-your-real-number, and not public Matrix.
- Mass-market secrecy for normal contacts → Signal, ideally on a burner number.
- Community / group ops where the membership is already public → Matrix, self-hosted.
- Always route over Tor or a trusted VPN so the relay logs an exit, not your home IP.
- Compartmentalize by circle. Don’t let one messenger identity bridge your activist, financial, and personal graphs into one joinable cluster — the same rule as Week 2.
Common mistakes
- Choosing by popularity. The most-installed app is optimized for reach, not for holding the least about you.
- “It’s encrypted, so I’m anonymous.” Encryption is the content; the graph is the metadata. Different problem, different tool.
- Using Matrix for a sensitive graph without self-hosting. Federation is a feature for communities and a liability for secrecy.
- Anchoring a “private” messenger to your real phone number. One KYC’d SIM undoes the best crypto in the app.
- One identity across all circles. It re-joins the very graph you split up.
See also
- xmr.club listings: privacy messengers and no-KYC number sources — the practical tools for shrinking the envelope.
- Adjacent OPSEC52 weeks: Week 14 — message metadata, Week 4 — the VPN/Tor stack, Week 2 — identity compartmentalization.
OPSEC52 is xmr.club’s weekly OPSEC series. Series index: /opsec. Curated by Cyber Satoshi