Comms OPSEC: Signal, SimpleX and Session Technically Compared

Before arguing which messenger is 'more secure', define who you are playing against. Signal protects message content well with the Double Ratchet protocol, but the server still knows a phone number exists and when it connects. SimpleX has no user identifiers at all, only ephemeral SMP queues. Session routes everything through a network of 2000+ Oxen service nodes with 5-7 node swarms per conversation. These are three completely different metadata models, three different trade-offs in latency, deniability and subpoena resistance. Anyone treating them as equivalent has not read a single whitepaper, and will pick the wrong tool for the adversary that actually matters.

The metadata threat model comes first

Content confidentiality is the easy part; every serious messenger already encrypts the payload end-to-end. The hard part is metadata: who talked to whom, when, how often, from which network. A nation-state adversary with lawful access to a carrier does not need to break AES-256 to map your source network, it correlates connection timestamps and IP addresses. So the first question is never 'is it E2EE', it is 'what does the server retain, and what can a subpoena or a passive network observer extract'. Write down your adversary tier before you install anything, exactly as you would document it in a personal threat model.

Concretely, split adversaries into three buckets. Bucket one is opportunistic: an abusive ex, a doxxing mob, a curious colleague; almost any modern messenger defeats them. Bucket two is corporate or civil litigation: subpoenas, discovery, a private investigator; here the retained-metadata question decides everything. Bucket three is a resourced state actor with passive collection and legal compulsion; here you need traffic-analysis resistance, not just encryption. Signal, SimpleX and Session sit at different points on this ladder, and the correct choice is whichever one breaks the specific capability your bucket-two or bucket-three adversary relies on.

Signal: Double Ratchet and the phone-number tax

Signal remains the gold standard for content. Double Ratchet combines X3DH key agreement with symmetric KDF chains, providing per-message forward secrecy and post-compromise security: compromise a single message key and neither past nor future messages fall. Sealed Sender removes the sender identifier from the envelope the server sees, and Private Contact Discovery runs inside Intel SGX over hashed phone numbers. SGX is not magic, it has a documented side-channel record including LVI and AEPIC Leak, so treat it as defence in depth, not a guarantee. For bucket-one and most bucket-two threats, Signal covers about 80% of scenarios with minimal friction.

The structural weakness is the phone number. Since 2024 usernames make the number optional for discovery, but registration still binds an account to a SIM, and that SIM is a durable correlation axis a carrier or a SIM-swap attacker can exploit. Mitigate it: register on a dedicated number you control, enable the PIN with Registration Lock so an attacker who swaps your SIM cannot re-register your account, disable SMS fallback, and if the Android cloud backup is on, protect it with a long random passphrase rather than the default 4-digit PIN. Verify safety numbers out of band for any contact that matters, because that is the only real MITM defence at the moment of first contact.

SimpleX: no identity, only queues

SimpleX flips the problem on its head: there is no account and no global user identifier. Every contact is served by a pair of unidirectional SMP (Simplex Messaging Protocol) queues with separate Curve25519 keys, and the client mints per-connection ephemeral identities. The relay sees opaque bytes moving between queues and cannot tell who talks to whom, a property the authors call queue unlinkability. Files travel over XFTP with end-to-end encryption and fixed-size chunks, which frustrates size-based traffic analysis. For single-source journalism or radical compartmentalization, SimpleX is the technically strongest metadata model shipping today.

The cost is operational, and it is real. There is no server-side account to restore, so key material lives on the device and manual backups are your responsibility; lose the phone without a backup and the identities are gone. Contact discovery is invite-only via one-time links or QR codes, which is a feature for unlinkability but adds friction. To remove the last centralisation point, self-host your own SMP and XFTP servers and configure the client to use them, or rotate across several community relays. Mobile UX is improving but still rougher than Signal, so budget time to train non-technical contacts before an operation, not during it.

Session: onion routing without forward secrecy

Session forked from the Signal Protocol but replaced Double Ratchet with a session-protocol variant that deliberately gives up per-message forward secrecy in exchange for multi-device support without a central server. Messages rest encrypted in Oxen Service Node Network swarms for up to 14 days, and the client wraps them in Lokinet-style onion routing across three hops. There is no phone and no email; identity is an Ed25519-derived Session ID. The honest trade-off: without forward secrecy, compromising the long-term key exposes stored history, and the Oxen network is far smaller than Tor, leaving a larger correlation surface for a global observer.

So Session is not a strict upgrade over Signal; it is a different balance. It wins when registration anonymity matters more than perfect forward secrecy, for example an international activist group whose members cannot expose a phone number or email under any circumstances and can tolerate multi-second latency. It pairs naturally with the network hygiene discussed in real Tor anonymity. Use a fresh Session ID per operation, never reuse one across compartments, and remember that the absence of PFS means you must treat every stored message as recoverable if the device is later seized and the key extracted.

Latency and subpoena: the numbers

Practical comparison, measured on a 200 Mbps residential link. Signal delivers in roughly 200-400 ms, SimpleX in 400-900 ms depending on the SMP relay, and Session in 1.5-3.5 seconds because of swarm traversal and onion hops. On retained metadata under legal compulsion: Signal has repeatedly answered US grand-jury subpoenas (2016, 2021) with only account-creation date and last-connection timestamp, because that is all it stores. SimpleX has nothing to hand over beyond opaque queue bytes with no linkage. Session stores in a distributed swarm with no central operator to serve at all, which is a legal-process story more than a technical one.

Read those numbers as a decision function, not a scoreboard. If your adversary is a civil subpoena, Signal's minimal retention is already sufficient and the latency win is worth it. If your adversary can compel or coerce a relay operator, SimpleX's unlinkable queues and self-hosting remove the single point they would target. If your adversary is a legal jurisdiction that can pressure any identifiable operator, Session's operator-less swarm changes the shape of the request. And remember that network metadata leaks far more than file metadata ever will, so pair any of these with the discipline in metadata hygiene.

Self-hosting and running your own relay

For SimpleX, self-hosting is the highest-leverage hardening step: deploy smp-server and xftp-server on a VPS paid in Monero, expose them over their native TLS transport, publish the address as a private relay to your contacts, and you have removed the last party that could ever be asked to log anything. Keep the host minimal, disable password SSH in favour of keys, and treat the relay like any exposed service with a firewall and unattended security updates. Signal does not support self-hosting the production network, so there the equivalent hardening is Registration Lock, username-only discovery, and disciplined device hygiene rather than infrastructure control.

Common operational mistakes

The failures I see in red-team work and training are almost never cryptographic. They are: reusing one Signal number across an operational and a personal identity; enabling Signal Android cloud backup behind a weak 4-digit PIN; leaving SimpleX on a default community relay with no rotation despite the feature existing; and treating a Session ID as anonymous while connecting from the same residential IP without Tor. No messenger repairs an operational OPSEC failure of the kind described in personal security for high-visibility targets. The tool is a component; the discipline around it is the control.

Two more recurring errors deserve a name. First, skipping key verification: an unverified safety number or fingerprint means a relay-level or provisioning MITM can sit between you and your contact undetected, so verify out of band for anything sensitive. Second, mixing compartments on one device: a single phone holding your research persona's SimpleX and your real Signal will eventually cross them through a notification, a screenshot, or a backup that syncs both. Separate physical devices, or at minimum separate hardened profiles, are the only reliable boundary; software labels are not.

Hardening checklist

Signal: register on a dedicated number, set the PIN and enable Registration Lock, switch to username-only discovery, disable SMS fallback, protect any backup with a long passphrase, verify safety numbers for sensitive contacts, and enable disappearing messages between 1 hour and 7 days by context. SimpleX: prefer self-hosted or rotated relays, back up keys to encrypted storage, verify security codes, and never reuse a contact link. Session: fresh Session ID per operation, no cross-compartment reuse, and never rely on stored-message secrecy after device seizure. Across all three: one physical device per compartment, and auto-delete tuned to the operation, never left on forever.

FAQ

Is Signal enough for a journalist protecting a source? For content, yes; for source-network metadata against a resourced adversary, not by itself. Signal reveals that two numbers connected and when, which can be enough to burn a source through correlation, so a high-risk source contact belongs on SimpleX with a self-hosted relay, or on Signal reached only over Tor from a compartmented device. Does self-hosting a SimpleX relay make me a target? Running a relay is a normal service; the risk is operational hygiene of the host, not the mere fact of hosting, and the unlinkability property means the relay itself learns little even about your own traffic.

Which one should a beginner start with? Signal, because a tool your contacts actually use beats a theoretically superior tool nobody adopts; graduate specific high-risk relationships to SimpleX as your operational maturity grows. And does disappearing-message timing matter? Yes: an aggressive auto-delete limits what a seized or compromised device can reveal after the fact, so treat retention as an attack surface and set it deliberately per conversation rather than accepting the default.

Conclusion

Pick the messenger by the metadata model you need to break, not by this month's security headline. Signal for daily communication with strong forward secrecy and a mature ecosystem; SimpleX for a source who cannot have an identity-bound account, ideally on a self-hosted relay paid in Monero; Session for an international group that cannot expose phone or email and accepts latency. In every case, enable auto-delete on a context-appropriate timer, verify keys out of band, and keep one physical device per compartment identity. The cryptography is solved; your operational discipline is the variable that decides whether it protects you.