Defence

End-to-End Encryption Without a Central Server

28 March 2026 · 12 min read

Most “end-to-end encrypted” platforms still rely on central servers for key exchange, message routing, and user directory services. That central server is a single point of failure — and in adversarial environments, a single point of compromise. This article walks through what we’ve learned building communications platforms that genuinely have no trusted third party in the loop.

We built a communications platform that eliminates the central server entirely. No directory service. No relay. No trusted third party. Every node in the network is equal. Here’s how, and why it matters.

The Trust Problem With Conventional E2E

In a traditional E2E system like Signal, the server doesn’t see your message content, but it does see who you’re talking to, when, and how often. This metadata is often more valuable than the content itself. Beyond that, the server:

Manages your keys — distributing public keys between users, which means it can substitute keys it controls (a classic active-MitM scenario).
Routes your messages — meaning it knows every conversation graph.
Holds the off-switch — if the server is compromised, subpoenaed, or simply goes offline, your communications stop.

For defence applications, all three of these are unacceptable. The network must function even when infrastructure is degraded, untrusted, or actively adversarial. That means genuine peer-to-peer — not “P2P with a directory server,” not “P2P with a STUN relay,” but a system where no node is more privileged than any other.

P2P Identity and Key Exchange

Without a central key server, peers need to establish shared secrets directly. Our protocol uses a layered approach:

Long-term identity keys — distributed out of band before deployment (printed QR codes, hardware tokens, classified deployment procedures). These prove identity but are never used directly to encrypt messages.
Ephemeral Diffie-Hellman key exchange — performed at session start to derive a per-session shared secret. Uses Curve25519 by default; we’ve also tested with NIST P-256 and X448 for clients with specific cryptographic suite requirements.
Per-message symmetric keys — derived from the session secret using HKDF, ratcheted forward with each message exchanged.

This layered structure delivers forward secrecy (compromising current keys doesn’t decrypt past messages) and post-compromise security (compromising past keys doesn’t decrypt future messages once the ratchet has advanced). These are the same properties that make the Signal Protocol robust — we’ve adapted them for a P2P topology.

Mesh Routing Without Trust

In a P2P network, you can’t assume direct connectivity between all peers. Messages may need to traverse multiple hops. Each hop sees only the encrypted payload and the next destination — never the original sender, never the final recipient, never the message content.

Our routing layer uses:

A gossip protocol for peer discovery. Peers exchange signed routing tables, allowing the network to converge on consistent topology without a central coordinator.
A modified Kademlia DHT for efficient message routing. Each peer is responsible for a portion of the address space; messages addressed to unknown peers are forwarded toward closer matches in DHT space.
Onion-style layered encryption for routing privacy. Each hop only learns the next destination, similar in spirit to Tor but adapted for our specific threat model.

Peers can join and leave the network without disruption. The routing layer is self-healing — when a peer disappears, neighbouring peers automatically rebuild routing entries through alternative paths.

NAT Traversal in Defence Environments

Most consumer P2P protocols assume hole-punching through home-network NATs. Defence environments are different: enterprise firewalls, jurisdictional boundaries, and air-gapped segments make standard NAT traversal techniques unreliable.

Our approach uses three layers:

Direct peer connections — when network topology allows, peers connect directly using their long-term identity to authenticate.
Peer-mediated relay — when direct connection fails, any third peer can act as a temporary relay. Relays only see encrypted payloads; they cannot read messages or identify endpoints. Any peer in the network can serve this role — there’s no privileged relay infrastructure.
Store-and-forward queuing — if no path exists at all, messages queue locally until any path opens, then transmit automatically.

Offline and Disrupted Operations

Networks fail. Especially in the field. Our platform handles disruption gracefully:

Messages are stored locally and forwarded when connectivity resumes. Local storage uses authenticated encryption with keys derived from device-bound material.
Peers synchronise message history when they reconnect, using Merkle-tree summaries to identify missing messages without transferring everything.
The network self-heals as nodes come and go. Routing tables update via gossip without requiring manual intervention.
No message is ever lost — delivery is guaranteed once any path exists between sender and recipient, however indirect or delayed.
Configurable expiry — messages can be marked with TTL values to limit their lifetime in store-and-forward queues, important for operations where stale intel becomes counter-productive.

This isn’t theoretical. We’ve deployed this in environments where network availability is measured in minutes per day, not nines of uptime — and the platform continues delivering messages reliably.

Threat Model and What We Don’t Protect Against

Honest engineering requires being clear about limits. Our threat model assumes:

Passive network adversaries can observe all traffic but not decrypt content. Protected.
Active network adversaries can inject, delay, drop, or reorder traffic. Protected for confidentiality and integrity; some availability degradation under sustained attack.
Compromised individual peers can see their own conversations but cannot decrypt messages routed through them. Protected.
Compromised long-term identity keys — protected for past messages (forward secrecy) but allow future impersonation until keys are revoked.

We don’t protect against:

Compromised endpoints — if the device itself is compromised, all bets are off. Endpoint security is a separate engineering problem.
Traffic analysis at scale — a global passive adversary observing all network traffic can still infer communication patterns from timing and volume, even with onion routing.
Coercion — if an attacker can compel a user to reveal keys or decrypt messages, the cryptography doesn’t help.

Documenting limits clearly is part of building trustworthy systems. The cryptographic community has produced enough “military-grade encryption” marketing material; engineering honesty is more useful.

Audit and Code Review

Cryptographic code is famously easy to get wrong. Our practice is:

Use vetted primitives — libsodium for core cryptographic operations, never hand-rolled algorithms.
Test vectors — comprehensive test suites against known-answer vectors from NIST, RFC, and academic references.
Independent code review — cryptographic code reviewed by engineers who didn’t write it, ideally specialists in the relevant primitives.
Formal verification where applicable — key exchange and authentication state machines benefit significantly from formal methods.

We offer independent security review as part of our defence engineering services for clients building their own secure communications systems.

Working With Us

If you’re building communications for environments where you can’t trust the infrastructure — defence, journalism, NGO operations in hostile regions, or any context where central servers create unacceptable risk — let’s talk. NDAs signed before sensitive context is shared.

For our broader work on defence software, encrypted communications, and embedded systems, see our Defence sector page.