Secure Messaging
Secure Messaging
Section titled “Secure Messaging”For interactive private conversation — chat, calls, file sharing with people you actually communicate with day-to-day — a modern end-to-end-encrypted (E2EE) messenger is the right tool. PGP-encrypted email is a much weaker channel for this use case (see Why not just email + PGP? below).
This page covers the major options, how to choose between them, and what each one’s tradeoffs are.
The 2026 Recommendation in One Line
Section titled “The 2026 Recommendation in One Line”| Your priority | Pick |
|---|---|
| Safe default — audited, mainstream, used by journalists and professionals | Signal |
| Maximum metadata resistance — no identifiers, no central registry | SimpleX |
| Federation + self-hosting — rooms, bridges, IRC-style multi-channel | Matrix / Element (used by this community) |
| P2P, no servers, hostile-network resilient | Briar |
Why not just email + PGP?
Section titled “Why not just email + PGP?”Even with PGP, email is fundamentally a weaker E2EE channel than modern messengers. The canonical critiques in the security community are Latacora’s “The PGP Problem” (2019) and Filippo Valsorda’s “I’m giving up on PGP” (2016). The technical picture in 2026:
- No forward secrecy. PGP uses long-lived keypairs. If your private key is ever compromised (laptop seized, malware, lost device), all past encrypted messages become readable retroactively. Signal-class messengers use ephemeral session keys (Double Ratchet protocol) so past messages stay protected even if current keys leak.
- No post-compromise security. Same issue going forward — a compromised PGP key keeps decrypting messages until you manually rotate. Modern protocols self-heal: after a single ratchet step, future messages are safe even if old keys were exposed.
- Metadata in plaintext. Email envelopes (To, From, Date, Message-ID, mail server hop log) are visible to your provider, the recipient’s provider, anyone watching the network, and anyone with subpoena access to SMTP logs. Subject lines aren’t encrypted by standard PGP at all. Signal’s “sealed sender” hides who’s talking to whom even from Signal itself. SimpleX has no user identifiers at all.
- HTML rendering attack surface. The EFAIL vulnerability (2018) demonstrated malicious HTML email exfiltrating decrypted PGP plaintext via remote image loading and CBC-mode gadgets. Many clients still render HTML. Modern messengers don’t have an HTML layer to attack.
- Long-lived keys. PGP keys typically last years; rotation is rare in practice. A breach of an old key is permanent damage. Messengers rotate keys automatically.
- No deniability. PGP signatures are non-repudiable by design — anyone with your public key can prove you signed something, forever. For sources, whistleblowers, or anyone who values plausible deniability of past statements, that’s the opposite of what you want. The Signal Protocol provides cryptographic deniability.
- No message padding. Encrypted email leaks message size, which can fingerprint content (a 47-byte ciphertext is “yes”; a 152-byte ciphertext is something longer). Signal pads to fixed size.
- Bad UX → frequent errors. Famously, users PGP-encrypt to wrong keys, send unencrypted by mistake, or click past “no key found” warnings. The error surface in PGP email is large.
What PGP email is still good for
Section titled “What PGP email is still good for”This isn’t “stop using PGP.” PGP/OpenPGP is still the right tool for:
- Software release signing — package maintainers, tarball signatures (where non-repudiation is the feature, not the bug)
- Git commit signing — same reasoning; you want a permanent record that this signature came from this identity
- Identity attestation — keysigning at events, web-of-trust assertions
- Async signed messages between organizations that can’t share a messenger app
- Encrypted files at rest between known correspondents with desktop GPG setups
For setup, see SSH & GPG Keys and Email Hardening Guide.
The Major Options
Section titled “The Major Options”Signal — the safe default
Section titled “Signal — the safe default”- Who runs it: Signal Foundation (US non-profit, funded by donations + the Brian Acton/WhatsApp founder grant).
- Crypto: Signal Protocol (Double Ratchet + X3DH) — the gold-standard E2EE protocol. WhatsApp, Google Messages (RCS), and Skype all license it.
- Identifiers: Phone number historically required; usernames added in 2024 so you can chat without sharing your number. The number is still used for sign-up.
- Metadata: Sealed sender hides recipient metadata from Signal itself.
- Open source: Server and clients fully open source.
- Trade-offs: Centralized server (US-based), still requires a phone number for registration, no federation.
- When to pick: Everyone, by default, unless you have a specific reason to choose something else.
SimpleX Chat — strongest metadata resistance
Section titled “SimpleX Chat — strongest metadata resistance”- Who runs it: SimpleX Chat Ltd (UK), funded by venture + grants.
- Crypto: Double Ratchet + custom queue model — every conversation uses pairwise per-queue keys, no global identifier.
- Identifiers: None. No phone, no email, no username. Conversations start by exchanging a one-time invite link or QR code out-of-band.
- Metadata: No graph of who-talks-to-whom on any server. The protocol routes through user-chosen relays.
- Open source: Fully FOSS (AGPL).
- Trade-offs: Younger, smaller user base, less polish than Signal. UX of “no contacts list” is unfamiliar.
- When to pick: When metadata resistance is the priority — journalists with sources, activists, anyone whose threat model includes “an adversary can compel disclosure from a service provider.”
See the dedicated SimpleX page for community-specific setup.
Matrix / Element — federated, self-hostable
Section titled “Matrix / Element — federated, self-hostable”- Who runs it: Element / Matrix.org Foundation. Anyone can run a server.
- Crypto: Olm (1:1) + Megolm (group) — peer-reviewed, audit’d protocols. Per-room E2EE.
- Identifiers: Matrix ID (
@user:server.tld), homeserver-bound. - Metadata: Visible to your homeserver and the homeservers of people you talk to. Federation means the trust surface is your homeserver, not a single corporate provider.
- Open source: Fully FOSS (Apache 2.0). Multiple client implementations.
- Trade-offs: More complex than Signal. Heavier client. Federation is also a complication: metadata visibility is reduced compared to centralized services only if you trust your homeserver.
- When to pick: When you want federation, self-hosting, group/room semantics (think IRC or Slack with E2EE), bridges to other networks. The IrregularChat community uses Matrix as its primary group-chat platform — see Element / Matrix Messenger.
Briar — P2P, no servers
Section titled “Briar — P2P, no servers”- Who runs it: Briar Project (non-profit, UK/Germany).
- Crypto: Direct peer-to-peer over Tor; no central server. Can also fall back to local Wi-Fi or Bluetooth for hostile-network or no-connectivity scenarios.
- Identifiers: Contact key exchanged via QR code in person, or via Briar’s mailbox feature.
- Metadata: Strongest of the list — no server to subpoena.
- Open source: Fully FOSS.
- Trade-offs: Android-only currently. Both parties have to be online simultaneously for direct delivery (mailbox feature mitigates this). UX is bare-bones.
- When to pick: Highest-threat scenarios. Protests in countries with internet shutdowns. Field operations.
WhatsApp, iMessage — limited recommendation
Section titled “WhatsApp, iMessage — limited recommendation”- WhatsApp — E2EE via the Signal Protocol, but the client is closed source, owned by Meta, and metadata goes to Meta (who talks to whom, when, how often, group membership). Better than no encryption, but Meta is not a party you should trust with your social graph.
- iMessage — E2EE within the Apple ecosystem, but Apple-controlled, closed source, metadata to Apple. Same trade-off as WhatsApp at a different gatekeeper.
- When to pick: When the people you want to reach are already on these platforms and the message content alone (not the metadata) is what you need to protect. Don’t use either for high-stakes communication.
Decision Matrix
Section titled “Decision Matrix”| Threat model / priority | Recommended |
|---|---|
| ”I just want to chat privately” | Signal |
| ”Need to talk to journalists / sources without revealing the relationship” | SimpleX or Briar |
| ”Want federation / self-hosted / our community already uses this” | Matrix / Element |
| ”Need pseudonymity over hostile networks” | SimpleX (anonymous) or Briar (P2P over Tor) |
| “Need to coordinate during an internet shutdown / over Bluetooth” | Briar |
| ”Have to reach people on Meta/Apple platforms” | WhatsApp / iMessage (with the caveats above) |
Notes on Apps Not on the List
Section titled “Notes on Apps Not on the List”Session — survived, but on a skeleton team
Section titled “Session — survived, but on a skeleton team”Session (onion-routed messenger, no phone number) appeared on earlier versions of this page. We’ve removed it from the active recommendations because of a 2026 sustainability crisis:
- April 9, 2026 — The Session Technology Foundation announced it could not cover its ~$1M annual operating cost and would shut down all servers on July 8, 2026 without emergency funding. All paid staff were laid off that day. Hacker News thread.
- June 2026 — Following a community donation drive, the shutdown was cancelled. Session now continues under a skeleton team led by Chief Software Architect Jason Rhinelander, with a stated runway “into 2027.” See getsession.org/donate — “A path forward for Session”.
- The Session Network (the onion-routing layer Session migrated to from Oxen in May 2025) runs on independent node operators paid via Session Token, so the routing infrastructure is decoupled from Foundation funding and survives regardless.
Why we removed it from the recommendations: even though Session didn’t die, the picture is qualitatively different from Signal or SimpleX — one architect on a charity runway is not the same as a foundation with multi-year funding. For new adopters, the migration risk if the runway runs out is real, and Session has no message export tool (the recovery phrase only restores the Session ID; only the last ~14 days of messages re-sync after account restore — by design). Existing Session users should plan an exit if they value continuity.
If you specifically need network-level metadata resistance without running Tor manually, SimpleX (anonymous queues) or Briar (P2P over Tor) are the current recommendations.
What about email then?
Section titled “What about email then?”Use email + PGP for:
- Signing software releases, tarballs, package metadata
- Signing Git commits for verified provenance
- Long-lived identity attestation (non-repudiation is the feature)
- Async signed/encrypted messages across organizational boundaries where you can’t share a messenger
Don’t use email + PGP for ongoing real-time conversation that needs to stay private. For that, pick a messenger from the list above.
See the Email Hardening Guide → Email Encryption for the email-side picture, and SSH & GPG Keys for key generation and hardware-key setup.
See Also
Section titled “See Also”- SimpleX — IrregularChat community SimpleX setup
- Element / Matrix Messenger — our community Matrix configuration
- Mobile Hardening Guide — securing the device you read these messages on
- Email Hardening Guide — when email is the right tool
- SSH & GPG Keys — software and hardware key setup
- MFA Guide — protect the accounts that own your messaging identities