ungovernable.tech

[ EXPLAINER ][ SECURE MESSAGING ]

Encrypted Messaging

Also End-to-End Encryption, E2EE, Secure Messaging.

Encrypted messaging makes sure only the intended recipients can read your communications.

Usable updated 2026-10-25 6 min read
Contents

What this section is about

Encrypted messaging makes sure only the intended recipients can read your communications. Not the platform, not your ISP, not anyone intercepting traffic. Modern E2EE goes beyond TLS to provide forward secrecy (compromise of a long-term key does not expose past session keys), post-compromise security (a compromised session heals after subsequent rounds), and varying degrees of metadata protection.

This section covers:

  • Signal Protocol — the reference asynchronous E2EE design (X3DH/PQXDH + Double Ratchet + Sesame).
  • Matrix — federated chat with Olm/Megolm; MLS profile in development.
  • Nostr — public-key-rooted broadcast protocol; encrypted DMs via NIP-44, gift-wrapped DMs via NIP-17, group E2EE via Marmot Protocol (MLS over Nostr).
  • Metadata-resistant designs — SimpleX, Session, Cwtch, Briar.

"Every company or individual is one court order away from needing to decide how long they are willing to spend behind bars for not sharing the data with the government." — Ungovernable.tech

The metadata problem

Encryption protects content. Metadata often reveals more:

Data type Example Risk
Who Alice → Bob Social graph
When Timestamp Pattern of life
Where IP address Location
How Device, client Fingerprinting
Size Message length Traffic analysis

Truly private systems address metadata, not just content.

Key technologies

Signal Protocol

The reference for asynchronous E2EE messaging. Deployed by Signal, WhatsApp (default since April 2016), Google Messages RCS (since 2020), and Meta's Messenger and Instagram DMs (rolled out 2023-2024 using a Signal-Protocol-derived design).

Core components:

  • Double Ratchet — per-message key evolution; forward secrecy plus post-compromise security.
  • X3DH (Extended Triple DH) — asynchronous initial key agreement. Replaced in Signal by PQXDH (initially X25519 + CRYSTALS-Kyber-1024) in 2023.
  • Sesame — session management for multi-device.

How it works:

  1. Alice and Bob exchange long-term and one-time prekeys via the server.
  2. PQXDH/X3DH derives an initial shared secret asynchronously.
  3. Double Ratchet evolves a fresh key per message; deleted message keys protect past traffic; recovery after compromise requires fresh ratchet contributions that the attacker no longer observes.

Limitations:

  • Signal app itself requires a phone number (metadata).
  • Centralized servers (Signal, WhatsApp).
  • Sealed sender hides the sender identity inside the envelope; the service still sees the recipient.

Matrix

A federated chat protocol with E2EE via Olm (1:1) and Megolm (groups).

Architecture:

  • Homeservers store message history; users pick or self-host one.
  • Bridges connect to IRC, Slack, Discord, XMPP, etc.
  • Element’s predecessor Riot enabled E2EE by default for new private rooms in May 2020. Public rooms remain unencrypted by design.
  • MLS profile (RFC 9420) in development to replace Megolm for groups.

Trade-offs:

  • Pros: federated, open-source, rich room model, bridging.
  • Cons: large per-user state, history-visibility trade-offs, server learns metadata (room membership, timing, device list).

Nostr

"Notes and Other Stuff Transmitted by Relays" — a public-key-rooted protocol where the user is their secp256k1 keypair (npub/nsec, BIP-340 Schnorr). Public events (kind 1 notes, profile metadata, reactions) are signed but unencrypted by design — they're meant to be public posts. Encrypted communication uses dedicated event kinds.

Architecture:

  • Keys: npub (public) / nsec (private), Schnorr over secp256k1.
  • Relays: simple WebSocket message brokers; anyone can run one.
  • Clients: any app that knows the protocol; clients verify signatures themselves.

Encryption layers:

Use case Mechanism Notes
Public posts Signed only Public broadcast is the design goal
Direct messages (legacy) NIP-04 — ECDH + AES-256-CBC Deprecated; metadata leaks recipient
Direct messages (current) NIP-44 v2 — secp256k1 ECDH → ChaCha20 + HMAC-SHA-256 Versioned format with padding
Metadata-protected DMs NIP-17 + NIP-59 gift-wrap Wraps NIP-44 content in a randomly-keyed envelope; relays cannot link sender
Group messaging Marmot Protocol — MLS (RFC 9420) over Nostr Forward secrecy + post-compromise security; KeyPackages kind 30443, gift-wrapped Welcomes kind 1059, encrypted group events kind 445

Trade-offs:

  • Pros: censorship-resistant by relay redundancy; key-rooted identity (no phone, no server account); client and relay diversity; composes with Lightning zaps and other key-bound protocols.
  • Cons: legacy DMs (NIP-04) leak who-talks-to-whom to relays; NIP-17 hides the sender inside a gift wrap but still exposes its recipient tag; no built-in spam control; relay discovery is application-defined.

Resources:

SimpleX

A messaging protocol designed for metadata resistance. Detailed in SimpleX.

Features:

  • No global user identifiers — addressable by per-conversation queue addresses on relay servers.
  • Onion-routed connections to relays (with optional Tor).
  • No address-book correlation; the recipient's invite link is delivered out of band.

Trade-offs:

  • Pros: relays cannot link conversations to a single user; no social graph centralized anywhere.
  • Cons: still requires out-of-band invite delivery; smaller ecosystem; UX cost of no contact discovery.

Session

Session uses public-key identifiers and onion-routed delivery without phone-number registration. Its threat model and protocol differ from Signal’s; consult the metadata-resistance comparison for transport trade-offs.

Cwtch

Tor v3 onion services as messaging substrate (Cwtch). Each user runs an onion service; conversations are direct hidden-service-to-hidden-service. Group servers are untrusted relays — they see encrypted blobs, not content or membership. Built by Open Privacy Research Society with explicit metadata-resistance research grounding.

Wire (MLS)

Wire is a Swiss / German enterprise messenger and the canonical production reference deployment of MLS (RFC 9420), alongside Cisco Webex (Wire MLS). A different group protocol from Signal — Wire's earlier Proteus protocol ran in parallel for a decade before the MLS migration in 2022.

Network comparison

Protocol Metadata Decentralized E2EE Open source
Signal Poor (phone number) No Yes (PQXDH + Double Ratchet) Yes (clients + server)
WhatsApp Poor (phone number) No Yes (Signal Protocol since 2016) Closed-source clients; protocol documented
Matrix Moderate (server learns metadata) Yes (federated) Default-on for private rooms (Olm/Megolm) Yes
Nostr Mixed — public posts are public; DMs depend on NIP used Yes (relay-based) Public posts: no (by design). DMs: NIP-44 / NIP-17. Groups: Marmot Protocol (MLS) Yes
SimpleX Good (no user IDs) Partial (relays + clients) Yes (Double Ratchet) Yes
Session Good (no phone, onion-routed) Yes (distributed service nodes) Yes; protocol differs from Signal Yes
Briar Good (Tor + LAN + BLE + USB transports) Yes (peer-to-peer) Yes (BTP, Bramble) Yes
Cwtch Good (Tor v3 hidden services) Yes (peer-to-peer) Yes Yes

Clients

Centralized E2EE

Client Platform Protocol Notes
Signal All Signal Protocol Reference implementation
WhatsApp All Signal Protocol Default-on E2EE since 2016

Federated / decentralized

Client Platform Protocol Notes
Element / Element X All Matrix Reference Matrix client; Element X is the current rewrite
Damus iOS, macOS Nostr Largest iOS Nostr client
Primal iOS, Android, web Nostr Reads + DMs + zaps; Primal cache server optional
Amethyst Android Nostr Most full-featured Android client
Nostur iOS Nostr Long-running iOS Nostr client
Coracle Web Nostr Web-first; experimental NIPs

Metadata-resistant

Client Platform Protocol Notes
SimpleX Chat All SimpleX No user IDs; per-queue routing
Session All Session / Oxen Onion-routed; X25519 identity
Cwtch All Tor v3 hidden services Peer-to-peer over Tor
Briar Android, desktop (alpha) Bramble (BTP/BSP/BQP) Tor + Bluetooth + Wi-Fi LAN + USB

Trade-offs

Strengths

  • Content privacy — only sender and receiver can read.
  • Forward secrecy and post-compromise security in Signal-family designs.
  • Censorship resistance via relay redundancy (Nostr) or transport diversity (Briar).
  • Self-sovereign identity (Nostr, Pubky, did:key).

Limitations

  • Metadata leaks — most platforms still expose who and when to the server or relay.
  • Endpoint compromise — E2EE does not help if the device is malware.
  • Identity binding — verifying that a key belongs to the intended human is out-of-band work.
  • Jurisdiction — app-store and provider availability varies.

Primary sources

Two newer MLS-based projects on Nostr identities: White Noise, a relay-native messenger built on Marmot, and Cordn, group messaging through a coordinator you can run yourself.

For a current comparison of identifiers, metadata, encryption defaults and readiness, see Choosing a private messenger. Additional entries cover Delta Chat, XMPP with OMEMO, Jami, Tox, Quiet and Veilid.

Page history

Updated
2026-10-25
Origin
Compiled from the ungovernable.tech research notes.
Improve this page
Suggest an edit — issues and pull requests are welcome.