Evaluate without asking our permission.

Download the app

The first time you open it, Windows and macOS will show a warning. That is expected: our installers are not yet signed with Microsoft or Apple. On Windows, click “More info”, then “Run anyway”. On macOS, the system will call the app “damaged”: it is not, your browser simply attached a quarantine tag to it. Right-click then “Open” does not clear that. Drag the app into Applications, then remove the tag from Terminal with xattr -dr com.apple.quarantine /Applications/Crypto.app. That command removes nothing else on your machine. Linux shows no warning. Since that warning tells you nothing about whether the file is genuine, check its fingerprint instead: every release lists the expected fingerprint of each file and the command that compares them. Later updates are properly signed: the app refuses any update whose signature is not ours.

The network components (the authority that keeps the directory, the relays, the mailboxes, the servers that carry call audio) install from the public Gotham repository under the AGPLv3 free-software licence: anyone can read that code, check it and host it. The client application and the enterprise features fall under a separate commercial licence and their code is not public.

What's new

Current version: 2.4.1, released on 15 September 2026. The last three releases are summarised below, newest first; F-xx numbers refer to the internal vulnerability register. The app updates itself: it checks GitHub every 6 hours and installs only what carries our signature.

1. 2.4.1 · 15 September 2026

   No database migration, no compatibility break: this version arrives through the automatic update and needs nothing on the network side.

   • Authority key rotation (F-23). The authority can now publish a chain of transitions in which the old key and the new one sign the same statement. The app moves forward as a ratchet from an anchor it keeps: once the new key is adopted, an old key that had leaked can no longer name a successor for it. What this does not cover: the very first contact, which still rests on the key compiled into the app. No authority serves a transition in production to date.
   • rustls fix (RUSTSEC-2026-0285). The TLS library moves from 0.23.39 to 0.23.45 in the app. It carries the QUIC handshakes to the relays and the HTTPS of updates; the network's link encryption (Noise XK) was not affected. The published relay binary (v0.12.0) still embeds the old version.
   • Rotatable enrolment token. The authority accepts a token file (--enroll-token-file, one token per line, all valid), which makes it possible to change the token without a simultaneous step across the whole fleet; it refuses to start if that file is readable by the group or by everyone. This token identifies the fleet, not an operator: it brings nothing against F-14.
   • Rendezvous reception repaired. The tunnel introduced in 2.4.0 delivered nothing: the missing test showed it, the defect is fixed and the test stays. Verified in-process against local relays, not against the live fleet.

   Register as of 15 September 2026: 56 vulnerabilities fixed, 13 reduced, 2 open. The two that remain, F-14 and F-46, are the same defect seen from two sides: a relay's operator label is declared by the relay itself and nothing verifies it.

2. 2.4.0 · 15 September 2026

   Database migration v35 → v36, irreversible: a database opened by 2.4.0 no longer opens with 2.3.0. Back up the whole profile folder before updating.

   • Invitation links valid for 3 days (F-53), down from 180, counted from their creation. An older link is refused and its key is purged.
   • Single mix delay (F-68). Until now each anonymity mode emitted its own delay, readable by the first relay, which could thus sort traffic by setting. The three modes now emit the same value, 500 ms per hop. The cover-traffic rate, however, still distinguishes the modes (on average one cover packet every 15 s, 10 s or 5 s).
   • Rendezvous reception (F-07, reduced). A client behind NAT can receive over the mixnet: it opens a tunnel to a rendezvous relay, which sees its address and its rhythm, while the mailbox host sees only a reply block with no IP address. The property falls if the rendezvous relay and the mailbox host are the same operator, which is the case on the current network (F-14).
   • Rotating mailbox addresses. A mailbox address is an opaque hash of the recipient's public key that changes with each epoch of the signed directory (keyed on its valid_after field, never on the local clock). The sender deposits at the current epoch; the recipient reads the current epoch, the previous one and the old permanent address. Consequence: a message deposited for a contact still on 2.3.0 and offline does not reach them until they update.
   • Editing, deletion and reactions in groups (F-61). Each action is signed by its author on a distinct domain and verified on receipt; a deletion can also come from a moderator (MODERATE permission).

3. 2.3.0 · 13 September 2026

   Compatibility break. A 2.2.0 client and a 2.3.0 client can no longer open a conversation, in either direction; conversations already established keep working. Database migration v34 → v35, irreversible. Three changes grouped on purpose to make only one:

   • Sphinx header version 3 (F-01, reduced). Each hop's authentication code covered only one segment of the header, the hop's own; it now covers that segment and every one after it, which closes the tagging channel between a colluding entry relay and exit relay for v3 packets. Residual: relays still accept the v2 header until the --strict-header-v3 flag is set across the whole fleet, and two consecutive colluding relays keep a channel that this code cannot close.
   • Invitation link signed in full (F-21, F-24, F-28). The identity-key signature now covers the whole link: ephemeral key, Gotham routing key, ML-KEM post-quantum key and header-rotation flag. Removing the post-quantum field invalidates the signature, and the responder enforces the scheme it announced: no more silent post-quantum downgrade. A link without a signature is refused, so links shared before 2.3.0 stop working; regenerating one costs a click.
   • X3DH v2. The session-key derivation changes domain (Crypto_X3DH_v2); the exchange remains hybrid X25519 + ML-KEM-768, followed by a Double Ratchet.
   • Relays. The published relay binary (v0.12.0) carries the v3 header, still accepts v2 and gains a persistent replay cache (--replay-cache-path) that survives restarts. Relays must be updated before clients: against an old relay, a 2.3.0 client routes nothing.

For your evaluation file

Missing a document you cannot find here, an architecture file or answers to a security questionnaire? Write to us: an engineer replies.