Genuinely Secure Instant Messaging

Genuinely Secure Instant Messaging

Three layers of encryption. No keys on the server, and none in the browser once the window is closed. A reverse proxy in a jurisdiction your adversary cannot reach, and no public address at all once the mesh is in place.
This is how to build messaging for people who genuinely need it to stay private.

Who This Is For

Most people choose a messaging app because everyone they know is already on it, and for arranging dinner that is a perfectly sensible basis. This post is for governments, embassies, state bodies, political parties, campaigns and organisations whose conversations are worth a foreign intelligence service's time. Their adversary is not a curious neighbour or an opportunistic criminal. It is a state with legal powers, security services and the patience to use both.

For those people the question is not whether an app encrypts messages. Almost all of them do. The question is who else is in the chain between one person's keyboard and another's screen, and what each of them could be made to hand over.

The record shows why it matters. Over the years governments, officials, journalists and politicians have all had their messages exposed: a senior national security group chat that included a journalist by mistake, a head of government's phone found to be carrying commercial spyware, a former minister's entire message history passed to a newspaper. Every one of them was damaging, some ended careers, and some shifted the political balance of the day. Almost none of them involved anyone breaking the encryption.

What follows is a technical overview of one way to do it properly, for anyone who feels the need. It is not the only way, and it is not a product: every component is open, and any competent team can build it.

Where the Popular Apps Fall Short

None of what follows says these apps are bad. They are well engineered, and for the people they are built for they do the job. They do, however, carry flaws that are inherent to what they are, and no setting inside the app can remove them.

WhatsApp

WhatsApp uses the Signal protocol, and messages are end-to-end encrypted in transit. The keys and the message history live on the phone, and the phone backs up to Google Drive on Android or iCloud on an iPhone. WhatsApp's own end-to-end encrypted backup exists, but it is optional, and a backup without it sits with the cloud provider in a form the provider can read, and therefore in a form anyone who can compel the provider can read.

Apple's strongest protection is no shelter either. In February 2025 Apple withdrew Advanced Data Protection for iCloud from UK users, following what was widely reported as a technical capability notice from the Home Office under the Investigatory Powers Act 2016. Whatever the merits of that case, it shows that the protection on a cloud backup is something a government can have removed. Google Drive, by default, holds files in a form Google itself can open.

Then there is the metadata. Even where the content is safe, the operator knows who talks to whom, when, how often and from where, all tied to a phone number, and frequently to an uploaded address book. For an embassy, the pattern of contacts can be worth as much as the content.

Signal

Signal is the best of the consumer options. Its protocol is sound, it collects very little, and its code is open. It is still only an app, and the app runs on a phone, which in most cases means Android, where the operating system, the app store and the update channel all belong to someone else. Messages have to be decrypted to be read, so they sit in plain text on the handset, and any compromise of the operating system reads them after decryption without ever touching the encryption. Commercial spyware sold to governments has done exactly that, repeatedly.

Signal also needs a phone number to register, runs as a single central service under one jurisdiction, and cannot realistically be run on your own infrastructure. However good the people running it are, you are relying on them, their hosting and their legal position.

The Common Thread

In each case the encryption is not the weak point. Everything around it is: someone else's platform, someone else's handset ecosystem, someone else's cloud and someone else's jurisdiction. Every one of those is a party that can be pressured, compromised or compelled, and none of them answers to you.

Doing It Properly

The answer is to own every link in the chain and to make sure that no single link holds anything worth taking. The building blocks are open and mature. Matrix is an open standard for encrypted messaging, and Synapse is its reference server, which you can run yourself. Around it sit four further pieces: a reverse proxy somewhere in the world, a thin web client, keys held on hardware by the user, and finally a private mesh network that hides the whole thing from the internet.

A Hardened Synapse Server

The server is where the messages are stored, so it is built on the assumption that one day someone else will have it in their hands. What they find should be useless.

• No logging. Synapse logs at error level only, to nowhere persistent, and the operating system journal is kept in memory. There is no record of who connected, when, or from where, so there is nothing to subpoena and nothing to steal.
• Present only the proxy's IP. Synapse listens on a private tunnel address and nothing else. The site it sits in has no inbound ports open at all: the server reaches out to the proxy, never the other way round. The only address the world ever sees is the proxy's.
• No keys on the server. Encryption is on by default for every room, so the server stores ciphertext. The encrypted key backup it holds can only be opened with the user's recovery key, which the server never sees. The server has a signing key for its own identity, and nothing that can decrypt a single message.
• No federation, unless it is between Synapse servers you also control. Federation copies rooms, members and history onto other people's servers, which is exactly what this design exists to prevent.
• Closed registration. Accounts are issued by an administrator, never created by visitors.
• Nothing that leaks by being helpful. No link previews (the server would fetch every link you discuss), no presence, no public room directory, no lookup by phone number or email, and no reporting to anyone.
• Retention. Messages and media are purged after a set period, so the history that exists is only as long as it needs to be.
• Encrypted disks and a minimal host. Full disk encryption, nothing installed that the server does not need, and the administration interface unreachable from the proxy.

Most of that is a handful of lines in Synapse's configuration:

listeners:
  - port: 8008
    bind_addresses: ['100.89.1.10']
    type: http
    x_forwarded: true
    resources:
      - names: [client]

federation_domain_whitelist: []
trusted_key_servers: []
enable_registration: false
encryption_enabled_by_default_for_room_type: all
url_preview_enabled: false
presence:
  enabled: false
allow_public_rooms_without_auth: false
allow_public_rooms_over_federation: false
require_auth_for_profile_requests: true
report_stats: false
session_lifetime: 12h
retention:
  enabled: true
  default_policy:
    max_lifetime: 30d

The Reverse Proxy

The reverse proxy is the only part of the system anyone outside can see. It terminates the client's TLS connection and passes requests down an encrypted tunnel to Synapse. It keeps no access log and no error log worth the name, and it stores nothing: no messages, no accounts, no media. It is built from configuration and can be destroyed and rebuilt somewhere else in minutes.

Seize it, and you have a TLS certificate and a tunnel address. The traffic that passed through it was end-to-end encrypted before it arrived, and nothing was written down.

Breaking the Chain: Jurisdiction

Assume you are an embassy. The host government wants to know what you are saying, and so do several others. Each of them can use its own security services to lean on the providers within its reach: to hand over what they hold, to watch a connection, or to put something into a system that should not be there. Some of that is done through the courts. Some of it is not.

So the proxy, the one visible part of the system, belongs somewhere those governments cannot reach. The right answer is specific to each case, but the principle always holds. Take a Russian embassy in Washington. The United States can lean on any American provider, and Russia's own networks may well be of interest to American state actors, so neither end of the obvious path is safe. A proxy in North Korea frustrates both: no American provider to pressure, and no infrastructure an American agency is likely to be inside. Few readers will have that particular problem, but the reasoning carries over to any of them.

• Out of your adversary's legal reach, with no treaty, intelligence-sharing arrangement or commercial dependency that lets them in through the back door.
• Not one of your adversary's natural targets, so that their own security services are not already sitting on the network.
• No mandatory data retention, and a provider with no reason to cooperate with anyone who asks.
• Different from the server's jurisdiction, so that pressure on one end does not reach the other.

Because the proxy holds nothing, jurisdiction is not protecting the content. It protects the fact that you are talking at all, when, and how much, and it stops anyone switching the service off by asking a friendly provider.

Keys Live With the User

Matrix encryption works with public and private key pairs: each device has its own, and each user has cross-signing keys that vouch for their devices. The private halves have to be with the client, because that is where messages are encrypted and decrypted. In this design the client keeps nothing, so the keys have to be brought to it at the start of every session, and they come from hardware the user carries.

That hardware can be an encrypted USB stick holding the user's recovery key, or a FIDO2 security key whose PRF extension derives the secret that unlocks the encrypted key backup. Either way, a session looks like this:

• Sign in with the hardware present.
• Unlock. The hardware releases the key, the client opens the key backup held encrypted on the server, and the room keys are held in memory only.
• Talk. Messages are decrypted in the browser and nowhere else.
• Close the window. The keys, the session and the history are gone from the machine.

Sessions are deliberately short. Access tokens expire quickly, an idle session ends itself, and every new session needs the hardware again. Matrix Authentication Service, paired with an identity provider that supports hardware keys, gives you that control in front of Synapse.

The Thin Client

The client is a web application, Element Web or something leaner, served from your own infrastructure rather than anyone's public instance. It carries a strict content security policy, loads nothing from third parties and reports to no one. It runs in a private window or a throwaway browser profile, so everything the browser would normally keep, its database, local storage and cache, is discarded when the window closes.

Audio, video, images and documents are sent as messages, encrypted exactly like text. Live voice and video calls are possible too, relayed through a TURN server that can sit remotely like the proxy, but that is a subject for another day.

The Endpoint

One weakness this design shares with every other: a compromised machine can read whatever is on its screen. Nothing on the server side can fix that, so the endpoint is part of the design. The machine used for this should be dedicated, hardened and used for nothing else.

For anyone who needs to carry it, a Linux phone such as a Jolla handset running Sailfish OS is a strong option. It sits outside both the Google and Apple ecosystems, and their app stores, update channels and cloud backups along with them. A full treatment is beyond this post, but it is worth serious consideration.

Closing the Door: a WireGuard Mesh

The last step removes the proxy from the public internet altogether. Every client joins a private WireGuard mesh, and the proxy listens only on its mesh address, something like 100.89.1.2. That address comes from the 100.64.0.0/10 range set aside for carrier-grade NAT, which is not routed on the internet and is unlikely to clash with any home or office network a user connects from.

With the mesh in place the proxy needs no public web port at all. All that faces the internet is a WireGuard UDP port, and WireGuard does not answer any packet that is not from a known peer key. Scan it and there is nothing there. It also wraps the whole conversation in a third layer of encryption, around the TLS, around the end-to-end encryption.

Joining the mesh needs more than a username and password. It needs MFA: a username, a password and a TOTP code, so a stolen password alone gets nobody onto the mesh. A managed mesh such as NetBird goes further still, with posture checks (operating system version, client version, location, a required process running) and peer approval, which bind access to specific approved devices rather than to whoever holds the credentials.

Out-of-Band Confirmation

For the genuinely cautious, and in this field caution is usually earned, the final step can be taken off the network altogether. The user's hardware key produces a first TOTP code, and that code yields three words. The user then calls a named colleague, who asks whether one particular word is among them. If it is, the colleague issues a second TOTP code with a 30 second life, and only the two codes together unlock the device onto the mesh.

For most organisations that is too much. For the people this post is written for, things go wrong often enough to justify it: a stolen hardware key, a stolen password and a compromised laptop together still fail at a human voice that knows who should be calling, and when.

What an Attacker Gets

The Point

Consumer messaging is built for convenience at enormous scale, and the trade-offs that come with it are reasonable for most people. They are not reasonable for anyone whose conversations are worth a state's effort. For them, secure messaging means owning every link in the chain, putting the one visible link where their adversary cannot reach it, keeping the keys in their own hands, and leaving nothing of value at any single point.

Own the chain, and there is nothing to hand over.