What Crypto protects. And what it does not.

A1 · Someone listening on the wire

Internet provider, transit operator, probe on a cable.

They read nothing. The content of your messages is end-to-end encrypted, and that works today. Messages travel inside packets that are all the same size, which hides how long they really are. What they can still see: that you connect to a Crypto server, and when. Erasing that trace needs a larger relay network, which we do not have yet (limit L1).

A2 · The server holding your messages until you fetch them

Including when seized by a court or broken into.

Your messages wait there as encrypted blocks of identical size, filed under an identifier that says nothing about you and changes with every directory epoch. Without the recipient’s private key, whoever runs that server cannot read them, and a third party can neither collect them nor delete them remotely. What the host can do, however: lose or destroy the mail it holds — which shows up as a non-delivery, not as a leak. What they can still see today: the IP addresses that deposit and collect, therefore who exchanges with whom. That is limit L1, the most important item on this page.

A3 · A few network servers held by an adversary

Machines in the mixing network controlled by an attacker.

A server knows where a packet came from, where it goes next and which step of the route it is at — the hop number travels in the clear — but it never sees both ends at once. Since version 2.3.0 (13 September 2026), each relay authenticates the part of the header that describes the steps after it: a marker a single server slipped in to recognise the packet further down the route is caught by the first honest relay that follows. Two residuals remain on record in our register: relays still accept the old format until the --strict-header-v3 option is set across the whole fleet, and two colluding servers that immediately follow each other on a route keep a marking channel that this authentication cannot close — which never links the entry to the exit of the same route. Two servers on the same route cannot belong to the same operator, or to the same address block; but the operator label is currently declared by the relay itself and signed as-is by the authority, and that is one of the two findings still open in our register. Admitting a new server already requires two authorities out of three to agree, across three separate hosts; but those three authorities belong to the same person, and registration there is locked behind a token. These defences are written and tested. They will only take effect once the network has enough independent servers to build a route.

A4 · Someone who intercepts and tampers

Interception, replay of an old message, key substitution.

The official list of servers is signed, remembered by your app, and an older version is refused. Since version 2.4.1 (15 September 2026), the key of the authority that signs it can be replaced without a new binary: the authority publishes the chain of its successors, each link signed by both the old key and the new one, and the app moves forward as a ratchet from an anchor it remembers — once the new key is adopted, an old key that had leaked can no longer name a successor to it. What this does not cover: the very first contact, which still rests on the key built into the app, with no certificate co-signed by several authorities. No rotation has taken place in production yet. A server’s registration is bound to the full exchange that produced it, so it cannot be replayed elsewhere. Access to call servers is signed and verified. And if a contact’s key changes, the app tells you by showing a new safety number, which you can compare with them over another channel.

A5 · Theft or seizure of your device

Someone has the disk in hand, outside an open session.

Everything the app keeps on disk is encrypted. The key is derived from your password by a function deliberately made slow and memory-hungry, which makes mass guessing very expensive. Erasing destroys the database, the logs, the working copies, the recovery key and the network identity. Your past messages stay unreadable even if your current key is stolen, and after a one-off break-in the following exchanges become protected again. All of this assumes a locked or powered-off device, and a strong password.

A6 · Pressure applied to the vendor

Court order, acquisition, commercial pressure.

In the self-hosted edition you install everything at your site: the directory, the relays, the mailboxes and the call servers. No data passes through us, so there is nothing to demand from us. And since the network code is public, you can compare what your servers run with what we publish; the app itself is proprietary. Note: if you use the servers we operate rather than your own, this protection does not apply, and limits L1 and L2 do.

Current state of the deployment. The mixing network, the part meant to make it impossible to tell who writes to whom, does not carry traffic yet. It needs relays held by operators independent of one another, a different one at every step of the route, so at least three: route selection refuses, by construction, two relays it cannot prove belong to different people. Today every relay is run by one person, the project's author. The directory is signed by three separate authorities, two of which must agree to admit a relay — but those three authorities also belong to that person. The quorum stops one leaked or compromised authority key acting alone; it does not stop a single operator declaring their own relays to all three. This is not a matter of how many machines or address ranges there are; it is a matter of different people, and we have one. In the meantime your messages go through a mailbox, and whoever runs that server can see which IP addresses exchange, and when. The app states this plainly, with the label "Mailbox only". The content itself stays end-to-end encrypted and unreadable to that operator. This protection will only come into effect as independent relays join the network.

Permanent limit. Voice does not travel through the mixing network and never will: it cannot tolerate the added delay. A call goes through a relay server, ours by default, yours if you host it. That relay hides your IP address from the person you are calling, but whoever runs it knows both addresses, the time and the duration of the call. This is the same model as other encrypted messengers. The conversation itself stays end-to-end encrypted: what is not protected is the fact that the two of you spoke.

Spyware, keylogger, screen capture, administrator access: on a compromised machine, what is displayed and what is typed can be read before it is ever encrypted. No messenger fixes that. The fact that your past messages stay protected limits the damage over time, it does not cancel it. Endpoint security remains your perimeter.

Screenshot, forwarding, testimony: the legitimate recipient of a message can always pass it on. No protocol repairs misplaced trust. What they can prove, however, depends on the case. A direct message is deniable: its authenticity rests on a key the two of you share, so your correspondent knows you wrote it but cannot demonstrate that to a third party — they could have forged it themselves. A group message is not: it carries your signature, which is needed so that no member can impersonate another, and that signature remains attributable to you. If deniability matters to you, write directly, not in a channel. We would rather say so here than have you find out in court.

Once the network does carry traffic, one threat will remain: if a single actor controls the entry, the exit and enough of the middle, they can line up the timings and work out who talks to whom. Diversity rules make that control expensive; only a large number of relays held by different people makes it improbable. Anonymity grows with the size of the network: a tiny deployment protects less than a federated one.

Watching someone with very distinctive habits for long enough eventually yields clues, even without reading a single message: the other explanations get ruled out one by one. Cover traffic, the fake messages sent constantly to drown the real ones, makes that work far more expensive. It does not make it impossible. We would rather write it here than let you discover it.

Shared calendars, room bookings, e-mail on the side, access badges: if the meeting is visible elsewhere, its secrecy no longer depends on us. Our perimeter ends at the messages and calls carried by the Gotham network.

An adversary can record encrypted traffic today hoping to decrypt it in ten years, once quantum computers exist. The content of your messages is protected against that by an extra layer of encryption (ML-KEM-768, combined with X25519), negotiated when each session opens. Since version 2.3.0 (13 September 2026), that layer is locked in: the invitation link is signed as a whole by the identity key of whoever issues it, post-quantum parameter included, and the responder enforces its own announcement — an intermediary who stripped that layer out of the negotiation makes the exchange fail instead of silently downgrading it. What stays outside this protection: the transport, which relies on classical cryptography at every hop between relays. It covers what you say, not the path the packet takes. And the app does not yet show, inside a conversation, whether that layer is active.

Every exposed surface is bounded: capped memory, rate limits, rejection of messages already seen, and any reachable crash is treated as a defect to fix. An attacker with overwhelming network capacity can still make the service unavailable. What they cannot do is read anything.

Current state. The macOS and Windows builds do not carry a vendor signature yet. Your system therefore shows a warning on first launch, and it cannot confirm to you that the file really comes from us. Until this is fixed, download the app only from our official pages.

We publish our limits because you would find them anyway.

Your security team will audit this product before buying it, and that is their job. This document saves them time. The adversarial audit and the network source code do the rest.