Security with no server to trust

Every session is end-to-end encrypted. Identity keys never leave the device. Nothing in the path can read what it carries, and nothing has to be reachable for two devices to trust each other. This page states the model, its controls, and its limits the way our published threat model does.

Read the threat model Report a vulnerability

Diagram: one message travels from unit-07 to unit-12 through a relay. The sender and recipient phones show the plaintext. The relay holds only a sealed frame it cannot open. A device in radio range sees only the two addresses on the frame. Offline Protocol runs no server in the path.

One message, as each party in the path sees it. The relay carries a sealed frame it cannot open. A device in radio range sees the two addresses and nothing more. No server is in the path to see anything at all.

RFC 9420MLS on every session, by default
Ed25519keys generated and held on the device
0servers in the local message path
48 hto acknowledge a vulnerability report

The boundary is the session, not the infrastructure

One server holds everythingA conventional system concentrates risk. One host stores the data, brokers the identities, and routes the messages, so one breach or one outage compromises everything attached to it.

Keys stay on the deviceEach device generates its own Ed25519 key in platform secure storage and never transmits it. An address is derived from the key, so two devices verify each other directly, with nothing to look up.

Every party in between sees lessA relay or gateway forwards sealed payloads it cannot open and routes by envelope. Only the members of a session can decrypt, so carrying traffic for the mesh exposes nothing of it.

What protects what

Each layer, the control that guards it, and the standard behind it. The full list of controls and the attack each one answers is in the threat model.

LayerProtectionStandard
Session contentEncrypted end to end with MLS. Only session members hold the keys, and a hostile relay cannot recover them.RFC 9420
IdentityA peer's address is derived from its public key, so presenting the key proves the address. No certificate authority, no lookup, no trust on first use.Ed25519
Control framesSigned with a canonical payload, domain separation, and a freshness window, so a captured frame cannot be replayed later or for another purpose.Signed and bounded
Service callsRequest and response bodies sealed in the MLS session between the two devices once it is confirmed, on 0.29 and later. Discovery, and a first request to a provider never met, stay signed and readable by the devices that carry them.RFC 9420, or signed
Group membershipEvery member's identity is bound to its MLS leaf and checked against the wire sender, so a member cannot speak as another member and a relay cannot re-attribute a message.Leaf binding
Data at restThe outbox, the pending-decryption queue, and the deduplication set are sealed records in platform secure storage. On a host with no platform keystore, the keys that seal them live in the built-in file store, sealed with ChaCha20-Poly1305 under an operator-supplied store key. A restart loses nothing and exposes nothing.Keychain and Keystore, or a store key
TelemetryOff until enabled with a key. Then one endpoint fixed at build time, TLS 1.2 or 1.3 trusting only the roots of the authorities that issue the ingest's certificate (since 0.30.0), and no field that can carry content, addresses, or names.Opt-in, scrubbed

The end-to-end boundary is the only one that survives a hostile relay, and it is the one every other control exists to protect. Sessions are keyed to OfflineID identities, and the mesh carries only what those keys have sealed.

Built for adverse conditions

Jamming and shutdown

When one transport is jammed or an internet link drops, the switch fails over to another radio. The mesh degrades path by path instead of going dark.

Lost links and moving devices

Multi-hop routing with acknowledgement, retry, and deduplication reroutes around a device that leaves. Delivery is confirmed, not assumed.

Fully offline operation

Identity, routing, and discovery run with zero connectivity. There is no server whose loss takes the network down and no lookup that must succeed for two devices to trust each other.

What it does not do

A security page that lists only strengths is not one. These are the non-goals and the residual risks, stated as the threat model states them.

LimitWhat it means for you
AnonymitySender and recipient addresses are visible on every mesh frame. The protocol protects content, not the fact of communication.
Traffic analysisNo padding, no cover traffic, no timing defence. Who talks to whom, and when, is inferable by anyone in radio range.
A compromised deviceThe protocol assumes platform secure storage holds. Root on the device means everything on it.
Your application against itselfThe SDK refuses forged control frames and attacker-chosen identifiers at its public surface, but it does not defend an application from its own code.
Relay answersSix relay-originated answer types are not authenticated by the protocol. A hostile relay can forge them. This is stated as residual risk R1 in the threat model.
GatewaysA gateway a device attaches to sees who is in its zone and is not authenticated for delivery. Residual risk R10.

Offline Protocol is a connectivity, identity, and coordination layer. It does not replace your organization's operational security, endpoint hardening, or key-custody policy. It gives you a transport and trust model that assumes the network can fail and keeps working when it does.

Reporting a vulnerability

We follow coordinated disclosure. Security fixes land on the current release line, and every channel shares one version number: the git tag, the npm package, and the crates.

StepWhat happens
ReportEmail security@offlineprotocol.com with the affected component, steps to reproduce, and the impact you have assessed. Do not open a public issue.
Within 48 hoursWe acknowledge the report.
Within 7 daysWe return an assessment and a remediation timeline, and work it with you.
On releaseThe fix ships on the current release line, and you are credited in the release notes unless you prefer not to be.
security@offlineprotocol.com Scope and safe harbor Conformance vectors

Security FAQ

Is Offline Protocol end-to-end encrypted?

Yes. Every session is encrypted with MLS (RFC 9420), the IETF standard for group messaging security. Only the members of a session hold the keys to decrypt its traffic, and those keys never leave the device that generated them.

What can a relay see?

Ciphertext, and the addresses on the envelope. Relays forward MLS-encrypted payloads without the keys to open them and route by envelope, not content. A device relaying traffic for others cannot read it.

Does the protocol send anything to a server?

Local mesh traffic stays local. Messages between nearby devices travel peer to peer, end-to-end encrypted with MLS, and identity verification, routing, and service discovery happen device to device. Hosted services are opt-in and store only what they need: the internet relay carries sealed messages between devices that are far apart, OfflineID keeps accounts, and telemetry, off until your app enables it with a key from the developer portal, uploads scrubbed event summaries over TLS with no message content and no addresses. What each service keeps is set out in our privacy policy.

How are identities verified with no connectivity?

A peer's address is derived from its Ed25519 public key. Presenting the key proves the address, so verification needs no lookup, no certificate authority, and no round trip. A mismatch is refused and reported.

Are service discovery calls encrypted?

Calls are, once a session exists. Since SDK 0.29, a service request or response between two devices on 0.29 or later is sealed inside their MLS session as soon as it is confirmed, and the provider sees the requester that MLS authenticated. Discovery queries and answers, the first request to a provider a device has never met, and calls to older devices are control messages signed with the sender's Ed25519 key: attributable and tamper-evident, and readable by the devices that carry them. The HTTP front always carries a call inside an MLS-encrypted message.

What happens if a device is lost or a key is compromised?

Sessions with the affected peer are re-keyed, issued credentials expire on their fixed lifetime, and a reinstalled device binds a fresh key to the account through the hosted directory, so the account moves to the new key. Verifiers that work offline pick up the change the next time they refresh the credential.

How do I report a security issue?

Email security@offlineprotocol.com. We acknowledge within 48 hours, return an assessment and a remediation timeline within 7 days, and credit researchers in the release notes unless they prefer otherwise. Please do not disclose publicly until a fix is available.

Which versions receive security fixes?

The current release line, 0.31.x. A fix ships in the next release on that line, under one version number across the npm package, the crates on crates.io, the PyPI package, and the git tag.

Do apps that use telemetry need to update?

Yes, if they call enableTelemetry on SDK 0.26.0 to 0.29.0. Those versions trusted the whole bundled Mozilla root set for the telemetry upload, which still included an eMudhra root withdrawn after the October 2026 key compromise, so someone holding one of those keys on the network path could have read the telemetry API key and the batches. SDK 0.30.0 and later trust only the roots the ingest uses. Apps that never enable telemetry are not affected, and mesh traffic, which MLS protects end to end, was never part of it.

Put the security model in front of your team. Evaluations run 4 to 16 weeks.

Book an evaluation How offline identity works