How does end-to-end encryption work when there is no server?

In most messaging apps, the server cannot read messages, but it still does two jobs that encryption depends on. It hands out public keys, so you can start a conversation with someone whose phone is switched off. And it stores and forwards the encrypted messages until they are collected.

Signal’s X3DH specification describes the first job directly: a recipient publishes keys to a server, and a sender uses them to send an encrypted first message while the recipient is offline. The MLS architecture document, RFC 9750, names the same two roles in general terms: an Authentication Service that binds identities to keys, and a Delivery Service that provides initial keying material and routes messages.

RFC 9750 also says MLS does not require either one to be a central server. It gives examples: some services rely on people comparing public keys by hand as their Authentication Service, and clients connected to a peer-to-peer network could run a decentralised Delivery Service by sending MLS messages over that network. Taking the server away does not change the cryptography. It changes who does those two jobs.

None of the core operations needs a network, let alone a server. They are calculations each device does on its own:

• Key pairs. Each device generates a private key that never leaves it and a public key it can share freely.
• Key agreement. With X25519, defined in RFC 7748, two devices combine their own private key with the other’s public key and arrive at the same shared secret, without sending that secret anywhere.
• Authenticated encryption. An AEAD cipher, as described in RFC 5116, encrypts a message and protects it against tampering in one step, so a relay that changes a byte causes decryption to fail.
• Signatures. With Ed25519, defined in RFC 8032, a device signs what it sends, and anyone holding its public key can check the signature.

Real protocols combine these and keep changing the keys as conversations go on, so that one stolen key exposes as little as possible. That works the same whether or not a server is involved.

Without a directory, keys travel with the devices themselves: inside discovery messages, in an invite, or across a table. The danger is that an attacker in the middle hands each side its own key instead of the real one, then decrypts and re-encrypts everything in between.

The X3DH specification is plain about this: if the parties do not authenticate each other’s keys, they get no cryptographic guarantee about who they are talking to. It suggests comparing key fingerprints by hand or scanning a QR code. Without a server, the common options are:

• Verify in person. Scan each other’s QR codes when you meet. This checks the key directly and needs no infrastructure.
• Trust on first use. Accept the first key you see for a contact and warn loudly if it ever changes.
• Derive the address from the key. If a device’s address is a hash of its public key, a signed message can be checked against the address with no lookup. This proves the same key is speaking, not who owns it.
• Carry signed credentials. An organisation can sign each device’s key in advance, and devices check that signature offline. RFC 9750 describes this kind of Authentication Service as logic inside the clients plus the issuing process.

Once a message is encrypted, any device can carry it. In a mesh, other devices pass it along hop by hop, as described in how a message crosses a mesh network, or hold it until the recipient comes into range, which is store and forward. RFC 9750 notes that MLS is designed to stay secure even when network elements, including the Delivery Service, are compromised, so the path a message takes does not have to be trusted.

What the server used to provide for free is asynchrony at first contact. Without a key directory, two devices usually need a moment of contact, or a trusted go-between, before the first encrypted message. After that, RFC 9750 notes that no MLS operation requires two members to be online at the same time.

For a group, a sender can encrypt a copy for each member, but that grows with the group. MLS, standardised as RFC 9420, gives the group a shared key that changes as members join, leave or update. Without a server to put changes in order, the app needs its own rule for which change wins when two members alter the group at once; RFC 9420 requires applications to have one.

Encryption hides content, not the fact of communication. RFC 9750 says MLS assumes the transport keeps metadata private from network observers. On a local radio network, nearby devices can still see that someone is transmitting, when, and roughly how much. What can go wrong with mesh messaging encryption covers those limits.