Encrypted messaging on ARPOKRAT

Encrypted Messaging Apps Compared 2026: Encryption Is No Longer Enough

Thu, 10 Sep 2026 00:00:00 +0000

Open WhatsApp, Telegram, Signal, Messenger, Google Messages. Every one of these apps now displays the same promise somewhere in its interface: end-to-end encryption. The phrase has become a standard sales argument, on a par with “no contract” from a mobile operator. It no longer separates anything, precisely because it has become true almost everywhere.

And yet these apps have nothing in common. One demands your phone number and hands the courts the list of people who have you in their address book. Another literally knows nothing about you, not even that an account exists. Between the two, some fifteen projects make very different trade-offs, and none of them explains those trade-offs clearly on its home page.

End-to-end encryption means that the content of your messages is unreadable to the intermediary carrying them. That is an important achievement, and it would be absurd to play it down. But it says nothing about what that same intermediary learns outside the content: that you wrote, to whom, at what time, from which IP address, how often, in which groups, with which phone number attached to your legal identity.

Encryption protects what you say. It does not protect the fact that you said it, nor to whom, nor when, nor from where.

This article does not draw up a ranking. There is no best messenger in the absolute, because there is no generic adversary. What this piece offers is first a grid of seven criteria that lets you judge any application, including ones that do not exist yet, then an honest profile for each of the fourteen apps selected, and finally recommendations by threat profile. Every profile includes a section devoted to what the app does not protect, without exception, including our own.

The seven criteria that replace encryption

This section is the most important one in the article. If you read only one, read this one: it will let you judge any messenger yourself, including those released after this text is published.

End-to-end encryption, a settled matter that no longer separates anyone

The Signal protocol, published in 2013 and formally analysed by cryptography researchers ever since, has become the de facto standard. WhatsApp has used it since 2016, Google Messages uses it, Messenger uses it. The cryptographic debate is largely closed for the content of one-to-one conversations.

The questions that remain useful are no longer about the presence of encryption but about its terms. Is it on by default or do you have to ask for it? Does it cover groups or only two-party exchanges? Does it cover backups, or do those go off to Google and Apple in the clear? Is there forward secrecy, meaning a regular rotation of keys guaranteeing that the compromise of a key today does not give access to yesterday’s messages?

Those questions still separate apps. The presence of the word “encrypted” on a marketing page does not.

Metadata, what the service knows without reading your messages

In May 2014, during a public debate at Johns Hopkins University against the legal scholar David Cole, former NSA and CIA director Michael Hayden uttered a line that has become famous. Cole had just quoted former NSA general counsel Stewart Baker, according to whom “metadata absolutely tells you everything about somebody’s life, and if you have enough metadata you don’t really need content”. Hayden replied, approvingly: “We kill people based on metadata.” He immediately added that this was not what the American domestic collection programmes did, a qualification that has to be restored to be honest. It changes nothing essential: the most senior American intelligence official publicly confirmed that metadata is enough for lethal decisions.

Metadata, in a messenger, is everything that is not the content: who writes to whom, at what time, from which IP address, how often, in which groups, with what file size. Reconstructing a link between a journalist and a source does not require reading their exchanges. It is enough to observe that they started writing to each other three days before an investigation was published. The same reasoning applies to a lawyer and a client, a doctor and a patient, an employee and a union, two people who would rather their relationship not be known.

A service can therefore be beyond reproach on content encryption and perfectly transparent about everything else. That is in fact the most common situation. We have detailed elsewhere how this same reasoning applies to other passive everyday signals, notably in our article on permanent phone location tracking and in our analysis of Leonardo’s SignalTrace system, which reconstructs journeys and relationships from nothing more than Bluetooth identifiers picked up in passing.

A good question to put to any vendor: what is left on your servers if a judge seizes them tomorrow morning?

The identifier required, a number, an address or nothing

This is the most concrete and most underestimated criterion. Three models coexist.

The phone number. In most countries it is tied to an identity document. It is unique, durable, and already present in hundreds of people’s address books. Requiring a number means tying every account to a legal identity and making the discovery of the social graph trivial: you just compare address books. The number is also the well-known weak point of authentication, as we showed in our article on SMS-based 2FA: a successful SIM swap does not just steal a code, it steals a messaging identity.

The email address or a random identifier. Better, because a disposable address costs a few seconds and a random identifier says nothing. It nevertheless remains a durable identifier on the server side, and therefore a hook for correlating sessions over time.

No identifier. This is the most recent and rarest model. There is no account at all, no directory, no permanent address. You exist as a set of cryptographic keys on your device, and people reach you through a single-use invitation link. Nothing to enter, nothing to leak, nothing to correlate.

Open source and independent audit, two ideas to stop confusing

These are two different things and it is time to stop presenting them together.

Open source means the code is readable. It is a necessary condition for trust, not a proof of security. Nobody reads the code, except by accident. Serious flaws have survived for years in widely watched free software projects.

Independent audit means a third party paid to look for flaws has looked, and has published what it found. That is infinitely stronger, and infinitely rarer, because it is expensive.

You then have to distinguish two kinds of audit. A cryptographic design review examines whether the protocol is well thought out on paper. An implementation audit examines whether the code actually does what the protocol claims. Both are useful, they do not prove the same thing, and a project can have the first without the second.

The Threema case illustrates the value of the exercise perfectly. In 2022, three researchers from ETH Zurich found seven attacks against its protocol, across three different threat models, and disclosed them to the vendor. Threema responded with a new protocol, Ibex, published in late November 2022. A closed, unaudited application would never have had that episode, which would not have meant it was any safer.

Jurisdiction and the CLOUD Act

Where a company is established determines which governments can compel it. It is a legal criterion, not a technical one, and it is decisive.

The CLOUD Act, passed in the United States in 2018, settles a question raised by the Microsoft Ireland case: can an American company refuse to hand over emails stored on an Irish server? The legislator’s answer is no. The text requires providers under American jurisdiction to disclose the data they control, regardless of where it is stored. A server in Frankfurt operated by an American company remains within reach of an American demand. The provider can object if the request conflicts with foreign law, but the objection is a procedure, not a shield.

The practical consequence is simple: hosting in Europe is not enough if the host, the parent company or the holding company falls under American law. The question to ask is not “where are your servers” but “who can legally compel you, and on what basis”.

Two qualifications have to be added. First, a protective jurisdiction is useless if the service nonetheless holds exploitable data: the best defence remains having nothing to hand over. Second, a hostile jurisdiction does not condemn a service that structurally knows nothing. Signal is American and has never been able to hand over anything but two timestamps.

Project sustainability, the criterion nobody looks at

A very well designed messenger that disappears in eighteen months leaves you with an unusable address book and, often, a lost history. This criterion never appears in comparisons. The year 2026 made it unavoidable.

In April 2026, the Session Technology Foundation publicly announced that it had raised only about 65,000 dollars in donations, that it needed roughly one million dollars a year to operate, and that its cash would not last beyond July. All staff were let go and development stopped. Session has more than one million monthly active users. In June, the foundation announced that the project had been saved by donations from thousands of users, most of them small amounts, and that it was restarting with a team of three developers led by software architect Jason Rhinelander.

Three weeks later, on 9 July 2026, the Briar project published a comparable message: after considering shutting down, it is moving to maintenance mode, meaning security and bug fixes only, with no development of new features, for lack of sustainable funding.

Two emblematic projects, two different economic models, the same year, the same dead end. The question to ask before adopting a messenger has therefore become: who pays, how much, and for how long? A foundation living on donations, a company selling licences, a subsidised university project and a volunteer community piece of software do not have the same life expectancy, and that has nothing to do with the quality of their cryptography.

Practicality, a security criterion in its own right

This last criterion is often treated with contempt by purists. That is a mistake.

A messenger your contacts refuse to install protects nobody, because the conversation will take place elsewhere, in the clear. A messenger whose notifications do not arrive pushes its users back to WhatsApp for urgent exchanges. A messenger that requires both people to be connected at the same instant is unsuited to ordinary correspondence across two time zones.

The real security of a system is the security of its real use, not that of its spec sheet. A slightly less pure model that your contacts actually use protects more than a perfect model you are alone in using.

Mainstream messengers

WhatsApp is the most used messenger in the world. It belongs to Meta, it is free, and its business model rests on the group’s advertising ecosystem and on business services.

What it really protects. The content of messages, with the Signal protocol, since 2016. This implementation is serious and that has to be said plainly: the content of your WhatsApp conversations is not readable by Meta. End-to-end encrypted backups exist and are worth turning on, because they are not on by default. The app is extremely reliable, available everywhere, and your contacts already have it.

What it does not protect. Everything else. On a simple legal demand, Meta discloses subscriber data: account name, creation date, last connection, IP address, email address. On a search warrant, the company provides the address book of the person targeted, and also the list of other WhatsApp users who have that person in their contacts. In other words, the social graph is deliverable in both directions. The metadata retained includes timestamps, sender and recipient identifiers, delivery statuses, group composition and its changes. According to an FBI document made public, WhatsApp is able to produce certain metadata for a targeted user every fifteen minutes as part of real-time surveillance. Finally, the phone number is mandatory, and Meta falls under the CLOUD Act.

Who it is for. For everyone, as an ordinary communication channel where you accept that the relationship graph is known to Meta and disclosable to a judicial authority.

Telegram is often filed among the secure messengers. That is a misunderstanding to clear up without aggression, because Telegram is excellent at what it actually does.

What it really protects. Nothing more than a classic online service, for everyday use. Ordinary conversations, called cloud chats, are encrypted between the client and the server, then stored encrypted on Telegram’s side, which holds the means to read them. End-to-end encryption is only available in secret chats, which are not on by default, are limited to one-to-one exchanges, remain tied to the original device and do not sync. What Telegram does excellently, on the other hand, is the massive group, the broadcast channel, large file sharing and multi-device presence. It is a formidable publishing network, and that is how it should be judged.

What it does not protect. The content of ordinary conversations against the vendor, the phone number, the IP address. The company’s position changed in September 2024, after the arrest of Pavel Durov in France: Telegram now discloses the numbers and IP addresses of reported users, in response to valid legal requests, whereas the previous commitment limited such disclosures to terrorism cases. The figures published for 2024 reflect the change in scale: roughly 900 requests fulfilled in the United States for 2,253 users, 14,641 in India for 23,535 users, 142 in the United Kingdom. The group is also registered in the British Virgin Islands and run from Dubai, a structure whose opacity is in itself a data point for analysis.

Who it is for. For public broadcasting, large communities, monitoring. Not for a conversation that must stay confidential from the vendor.

The de facto standard

Signal

Signal is the benchmark, and this article treats it as such. It is published by the Signal Foundation, an American non-profit funded by donations and by an initial endowment from Brian Acton.

What it really protects. The content, with the protocol it invented and which serves as the industry reference. But above all, and this is what sets it apart, the rest: private contact discovery, sealed sender, systematic minimisation of retained data. The proof is not declarative, it is judicial. Signal publishes its responses to legal demands on a dedicated page, and those responses all look alike: the organisation can provide only the account creation timestamp and the last connection date. In a case brought before the District of Columbia court, the authorities requested subscriber information for thirty-seven phone numbers. The answer was the same. It is the only public record of resistance to legal demands of that quality in this entire comparison, and it is worth more than any marketing promise.

What it does not protect. The phone number remains mandatory at sign-up in 2026. Usernames, introduced in 2024, mean you no longer have to give your number to your contacts, which is real progress, but they do not remove the requirement at account creation. Public work indicates that Signal is studying registration without a number, possibly backed by a one-off payment to limit abuse, but at the time of writing it is not available. Signal also falls under American law, and therefore the CLOUD Act: the protection does not come from the jurisdiction, it comes from the fact that there is nothing to hand over. Finally, the infrastructure is centralised and the ecosystem is closed to third-party clients, a point we return to later.

Who it is for. For just about everyone. It is the best ratio of protection to real-world adoption on the market, and it is the default recommendation when the phone number is not a problem in your threat model.

Molly

Molly is a hardened fork of Signal for Android. It changes neither the protocol, nor the network, nor the identifier model: it hardens the client.

What it really protects. What Signal does not protect on the device side. Molly encrypts the local database behind a passphrase, which locks the entire application, and wipes RAM with random data on lock, to resist forensic analysis after seizure. It also lets you route traffic through a SOCKS proxy or Tor. A Molly-FOSS variant removes Google’s proprietary components. All things the official client does not do.

What it does not protect. Everything on the server side. Molly uses Signal’s servers, therefore requires a phone number and inherits exactly the same metadata profile and the same jurisdiction. It exists only on Android. And it runs on Signal’s network with the foundation’s tolerance, not with its formal authorisation, which has been incident-free for years.

Who it is for. For a Signal user on Android whose threat model includes physical seizure of the phone: a journalist travelling, an activist, a lawyer crossing a border.

Messengers without a phone number

Session

Session made a radical bet: get rid of the number and the email. At sign-up, the app generates a random account identifier, and nothing else is asked for. The project is run by the Session Technology Foundation, a foundation under Swiss law.

What it really protects. Identity at sign-up, and the IP address. Messages transit through a decentralised network of onion-routing nodes, so that no server knows both the origin and the destination. The code of the Android, iOS and desktop clients was audited in a report published by the French firm Quarkslab, which raised seven issues on Android, seven on iOS and two on the desktop client, most of them since fixed. The app is available on every platform and looks like an ordinary messenger, which is no small thing in this category.

What it does not protect. Session removed forward secrecy in 2021, citing stability problems with its decentralised architecture. Concretely, the compromise of a long-term key exposes past messages. In December 2025 the foundation announced a V2 protocol reintroducing forward secrecy and adding a post-quantum key exchange based on ML-KEM, but that protocol was not finalised at the time of writing. And above all, the sustainability criterion weighs heavily here: the project came within a few weeks of shutting down in 2026 and now runs with three developers for more than a million users.

Who it is for. For anyone who wants to do without a phone number without changing their usage habits, and who accepts the current absence of forward secrecy.

Threema

Threema is a Swiss company that sells its application. It is the only paid player in this comparison, and that is precisely what makes its model legible.

What it really protects. Identity and jurisdiction. On installation, the app generates a random Threema ID. The phone number and email address are optional and serve only to let your contacts find you, which nothing forces you to enable. The servers belong to the company and sit in an ISO 27001 certified data centre in Zurich, under Swiss law, outside the CLOUD Act. The source code is published and reproducible builds are available on Android, which makes it possible to verify that the distributed app matches the code. Threema had its mobile apps audited by Cure53 in October 2020, then its desktop app in January 2024. The Ibex protocol, adopted in late 2022, was the subject of a formal security proof published by German researchers in 2023.

What it does not protect. The price, around six euros as a one-off purchase, is a real obstacle to adoption by the people close to you, and it is the main practical brake. The 2022 ETH Zurich episode is also a reminder that even a serious player can have a vulnerable protocol for years: seven attacks found, a protocol entirely rebuilt. Finally, the Threema ID remains a durable identifier on the server side, which is not the no-identifier-at-all model.

Who it is for. For a European company, a law firm, a public body, or an individual who would rather pay for a product than depend on donations, and who wants a clear Swiss jurisdiction.

Wire

Wire has changed a great deal in nature. Born as a consumer messenger, it repositioned itself towards organisations, businesses and the public sector.

What it really protects. The content, with the Proteus protocol and then with MLS, the IETF’s group messaging standard of which Wire was one of the first serious implementers. Sign-up is by email, which avoids the phone number. The audits are public: Kudelski Security and X41 D-Sec published a review of the protocol implementation in 2017, then application audits of the iOS, Android and web clients in 2018.

What it does not protect. Metadata, which Wire keeps in the clear on the server side, a point the vendor has never concealed and which has been regularly criticised. The legal structure is also complex: operations fall under Wire Swiss GmbH in Switzerland, the group’s holding company is established in Berlin and the vendor states that more than 90% of the capital is held by European institutional investors, but an American entity was created in Delaware in 2019. This complexity deserves to be understood before selecting Wire for sensitive use.

Who it is for. For an organisation that needs compliant encrypted collaboration, with commercial support and centralised administration, more than for an individual seeking anonymity.

Element and the Matrix protocol

Element is the main client for Matrix, an open, federated protocol. The model differs from every other one in this comparison: anyone can host their own server, and servers talk to each other the way email servers do.

What it really protects. Autonomy. An organisation can host its server, control its infrastructure, depend on no vendor and remain reachable from the rest of the network. It is the only model in this comparison that offers that combination, and it is the reason several European public administrations selected it. End-to-end encryption of messages is in place.

What it does not protect. Metadata, and that is structural. Your server’s administrator sees who talks to whom, when, and in which rooms. Room metadata, name, topic and other state events, is stored in the clear on the server. Element is working on encrypting these state events, but the feature was still experimental and confined to lab options in September 2025. Federation makes the problem worse: a room’s history is replicated to the participating servers, which retain it. The vendor also sells a gateway designed to filter federation in order to limit these leaks, which is a useful admission.

Who it is for. For an organisation that wants sovereignty over its infrastructure and whose adversary is not its own system administrator. Not for an individual seeking to conceal their relationships.

Messengers with no identifier at all

This is the most recent category. The principle is not to hide an identifier but not to create one.

SimpleX Chat

SimpleX Chat is the first messaging network with no user identifier, random ones included. It is a genuine conceptual advance and it should be presented as such.

What it really protects. The social graph, by design. There is no account, no directory, no permanent address. Each conversation rests on one-way queues hosted on different relays: what you send goes through a queue on one relay, replies come back through another queue on another relay, so that no relay sees both ends. The relays are blind, they know neither the sender nor the recipient. The project has published two independent audits carried out by Trail of Bits: a security assessment of the implementation in November 2022, then a review of the cryptographic design of the protocols in October 2024, including a formal verification of the queue negotiation protocol and concluding with three medium-severity issues and one low-severity issue, all difficult to exploit. The protocol adds a post-quantum layer to the double ratchet. The relays are self-hostable, clients exist on Android, iOS and desktop, and the vendor, SimpleX Chat Ltd, is a British company registered since October 2021.

What it does not protect. Two things deserve to be said. First, the default hosting: the relays operated by the project run at a single provider, Linode, a subsidiary of the American company Akamai, in its European data centres in London, Frankfurt and Stockholm. A user who does not enable Tor and does not change relays therefore depends on infrastructure operated by an American company, which puts the CLOUD Act back in the picture. The topic is publicly documented in the project’s repository. Second, the user experience remains demanding: establishing a connection requires exchanging a link or a QR code, notification reliability on iOS was long a weak point and scaling up large groups is still a work in progress. Funding, finally, now rests on an equity crowdfunding round launched in August 2026.

Who it is for. For anyone who wants the no-identifier model with the best level of external verification available today, and who accepts a more technical learning curve.

Arpokrat Messenger

Arpokrat Messenger is our product, and this profile follows the same grid as the others. It has to be said bluntly up front: Arpokrat Messenger is a fork of SimpleX. The architecture described above, absence of identifiers, one-way queues, blind relays, is not ours, it is SimpleX’s. We do not claim to have improved it cryptographically, we credit it, exactly as our protocol page does explicitly. It is the same position we hold for ArpokratOS with respect to GrapheneOS.

What it really protects. What SimpleX protects, plus a series of operational and product choices. The relays we operate are spread across five jurisdictions chosen for their law, Switzerland, Iceland, Panama, Malaysia and Mauritius, none American, and the infrastructure rests on no American hyperscaler, neither Amazon Web Services, nor Google Cloud, nor Microsoft Azure, nor Cloudflare. Pending messages live only in RAM, swap is disabled, a power cut wipes everything, and release manifests are signed on a Qubes OS machine isolated from the network. Tor turns on with a single button, without a third-party app, and stays off by default. Incognito mode assigns a different profile per contact, display name and relay included, which prevents linking a professional life and a private one. The relays are self-hostable by anyone, the software being open. The clients are published under the AGPLv3 licence. The self-custodial wallet handles Bitcoin, Ethereum, Monero, Polygon, Solana and Tron, with keys never leaving the device, and Zcash support is announced without being available to date. The built-in Swap is an aggregator that compares offers from independent providers, rating each from A to D according to the level of identity verification required, from A for no KYC to D for mandatory KYC, with funds moving directly between the user and the chosen provider. To our knowledge, no other messenger offers this rating. The vendor, finally, is an identifiable commercial entity, Arpokrat GmbH, domiciled in Zug, Switzerland, with a public postal address, a PGP-signed warrant canary renewed on a sixty-day validity window, and a commitment to answer support within 24 hours. The app is free, without advertising.

What it does not protect. And this is where we have to be precise, because it is the only way to be credible about the rest.

Arpokrat Messenger has to date no independent cryptographic audit published in its name. SimpleX has two. The underlying protocol is therefore audited, our implementation and our operations are not, and that is not the same thing, as explained earlier in this article.

Arpokrat has no public record of resistance to legal demands. Signal has one, verifiable, spread over years. A warrant canary is a serious commitment, it is not a judicial precedent.

The app today exists only on Android. The iOS, Linux, macOS and Windows versions are announced, not available. For anyone exchanging with iPhone users, that is an immediate obstacle and there is no workaround.

The network, finally, is young and small. The number of users does not make security, but it does make your correspondents available, and that is a legitimate criterion we ourselves defended above.

Who it is for. For anyone who wants a no-identifier architecture without giving up everyday usability, and who prefers an identifiable commercial entity to a community project whose funding can stop. The positioning we defend is not “the most private”, it is narrower and more honest: the most usable among no-identifier architectures, with an asynchronous model that peer-to-peer architectures do not offer, an ecosystem and commercial support.

Briar

Briar is probably the most uncompromising project on this list. There is no server at all: messages pass directly from one device to another through Tor, and failing a connection, by Wi-Fi or Bluetooth between nearby devices.

What it really protects. Everything that depends on infrastructure, since there is none. Nothing to seize, nothing to subpoena, no operator to compel. Offline mesh mode genuinely works during an internet cut, which makes Briar the reference tool for blackouts and demonstrations. The code was audited by Cure53 in March 2017, with twelve issues raised and fixed. The project is free software and its design is authoritative. Briar Mailbox, a separate app to install on a spare Android device left switched on, makes it possible to receive messages while the main phone is offline, which partly answers the main limitation of the peer-to-peer model.

What it does not protect. Comfort of use, and now the project’s trajectory. Battery consumption is high, background operation on Android is erratic, account backup and attachments are missing, and adding a contact is laborious. There is no iOS version. The desktop version remains in beta, the latest being 0.6.5-beta released on 20 February 2026. And above all, the announcement of 9 July 2026 places the project in maintenance mode: security and bug fixes, without feature development. The project specifies that rumours of a complete shutdown are out of date, but its ambition is clearly suspended.

Who it is for. For an internet blackout zone, a demonstration, a censorship context, or a small group that accepts the constraint in exchange for the total absence of infrastructure.

Cwtch

Cwtch is developed by the Open Privacy Research Society, a Canadian non-profit based in Vancouver. The project explicitly targets metadata-resistant group messaging.

What it really protects. Metadata, including in groups, which is the hard problem. Connections go through Tor v3 onion services, and the servers that relay group conversations are designed to be untrusted on principle: they must learn nothing. Version 1.13, released in September 2023, marked the end of the long alpha and beta phase, and the project has continued through to 1.15.

What it does not protect. Sustainability, once again. The organisation lives essentially on individual donations and has said so publicly on several occasions. There is no iOS version. The pace of development is that of a small team, and the user ecosystem is very limited. We have not found a published external audit equivalent to those of SimpleX or Briar.

Who it is for. For an activist or research group that needs metadata-resistant collective conversations and whose members are technically comfortable.

The convergence of 2026, the messenger becomes a wallet

Here is the most interesting observation of the year, and to our knowledge nobody has yet put it this way.

In 2026, three forks of three different protocols, developed by three unconnected teams, had the same intuition at the same moment: integrating a self-custodial wallet into an encrypted messenger. Radar is a fork of Signal with Bitcoin over Lightning. Zerion is derived from Briar with Bitcoin and Monero. Arpokrat Messenger is a fork of SimpleX with a multi-chain wallet and a swap aggregator.

Three opposite technical bases, one and the same conclusion. That is no coincidence, it is the sign that two needs that used to be handled separately are converging. Sending money and sending a message pose the same problem: an intermediary who knows both ends. The answer built for messages, content encryption and metadata minimisation, is exactly what cryptocurrency users are looking for. And messaging is the only place where you already know your recipient.

The three approaches are nevertheless very different, and the comparison is instructive.

Radar

Radar was launched on 7 July 2026 by the Cake Wallet team, under a separate entity, Radar Chat, Inc., led by its founder Vikrant Sharma. It is a fork of Signal, free, open source, available on iOS and Android. The wallet is self-custodial, with a twelve-word recovery phrase and encrypted backups. The payment layer deserves a clarification, because the sources do not say the same thing. Radar’s site describes a Bitcoin wallet backed by the Lightning network, assigns a Lightning address to each account, and mentions nothing else. Several articles published in July 2026 indicate, on the contrary, that the underlying machinery rests on Spark, a Bitcoin layer 2 network integrated via the Breez SDK, a transfer between two Radar users then settling Spark to Spark in under a second. The two versions are not mutually exclusive, since the Breez documentation describes an SDK that supports Spark and Lightning together, Lightning addresses and bolt11 invoices included. Absent public confirmation from the vendor itself, we go with what is verifiable on its own site: self-custodial Bitcoin payments reachable over the Lightning network.

The most striking choice lies elsewhere. Radar is not a separate network: you connect to it with your existing Signal account, and contacts, conversations, groups and username follow. That is Radar’s competitive advantage, and it is also its main open question.

This interoperability implies that Radar inherits Signal’s model in full: the phone number remains the identifier, the Signal PIN controls account recovery and therefore, by default, access to the wallet keys that Radar encrypts into the Signal account, and the infrastructure called upon is the Signal Foundation’s, under American jurisdiction.

The sustainability of that arrangement then has to be questioned, without stating it as a fact. Signal has historically refused to let third-party clients use its servers: in 2016, the LibreSignal project was abandoned after Moxie Marlinspike made it known that he did not want either Signal’s name or its servers used by a fork, and he also ruled out any future federation. The foundation retains the technical ability to block a third-party client by its signature. To date it has not done so, and Molly has used the network for years without incident, a precedent the Radar team explicitly invokes. Radar also pays a monthly contribution to the Signal Foundation and plans to increase it as it grows. Nothing therefore indicates that Radar will be blocked. But a product whose network access depends on the continued tolerance of a third party carries a structural risk that neither SimpleX nor Briar carries, and the user deserves to know it before placing funds there.

Zerion

Zerion is derived from Briar, built on the Bramble transport protocol, published under GPL v3, and the project states clearly that it is neither affiliated with nor endorsed by the Briar project. It exists only on Android.

Credit where it is due, because it does several things remarkably well. All traffic goes through Tor, without exception: your device builds a three-hop circuit, your correspondent’s builds another, and the two meet at a rendezvous relay, six hops in total and no IP address exposure. Every message is protected by a post-quantum key exchange based on ML-KEM-768. Version 3.0 added a Bluetooth offline mesh that relays individual and group messages through nearby phones, each relay carrying only ciphertext, as well as an optional I2P transport. A hardened mode refuses to start on a compromised device, under a debugger or with hooking frameworks. Since version 3.0.4, an encrypted vault can hold self-custodial Bitcoin and Monero wallets, whose keys are generated on the device, protected by their own password, with reproducible builds from frozen sources and published fingerprints.

The limitation is structural and the project does not hide it: its documentation states in black and white that a message is only delivered when both devices are online and connected to Tor, and that no server stores it in the meantime for long offline periods. In other words, there is no equivalent of Briar Mailbox. That is the decisive technical point, and it is what separates a peer-to-peer model from a store and forward model in which a blind relay keeps the encrypted message until the recipient comes to collect it. For ordinary correspondence between two people who are not connected at the same time, the difference is not theoretical, it decides usage.

A second question remains open, and we frame it as a question since we have found no public measurement: what is the real quality of peer-to-peer audio and video calls on a six-hop Tor architecture? The technical choices announced are serious, Opus, H.264, AES-256-GCM encryption and padded frames, and calls are off by default. But Tor is not designed for low latency, and in the absence of published measurements, neither the vendor nor we can claim that the experience is comparable to a classic call.

Finally, we have found no published independent audit for Zerion.

Compared, the three approaches sketch three clear trade-offs. Radar chooses immediate adoption at the price of dependence on a third party and of keeping the phone number. Zerion chooses maximum network resistance at the price of deliverability and of availability on iPhone. Arpokrat chooses the asynchronous model and jurisdictional spread at the price of a track record and an audit that do not yet exist. None of these three trade-offs is absurd, and none is free.

Summary table

Application	Identifier required	Jurisdiction and hosting	Server-side metadata	Published external audit	Offline delivery	Code
WhatsApp	Phone number	United States (Meta), CLOUD Act	Extensive, contact graph deliverable on warrant	No for the service	Yes	Closed client
Telegram	Phone number	British Virgin Islands, management in Dubai	Extensive, cloud chats readable by the vendor	No	Yes	Open client, closed server
Signal	Phone number	United States, CLOUD Act	Two timestamps, public judicial record	Protocol formally analysed	Yes	Open
Molly	Number (Signal account)	Signal servers, United States	Identical to Signal	Inherited from Signal	Yes	Open
Session	None, random identifier	Switzerland, decentralised node network	Minimal, no forward secrecy to date	Yes, Quarkslab	Yes	Open
Threema	None, Threema ID	Switzerland, servers in Zurich	Minimal	Yes, Cure53 and ETH Zurich	Yes	Open, paid
Wire	Email or number	Switzerland and Germany, American entity in Delaware	Retained in the clear	Yes, Kudelski and X41	Yes	Open
Element / Matrix	Depends on the server, often email	Your host’s	Visible to the server, room state in the clear	Audits published on the protocol	Yes	Open
SimpleX Chat	None, no identifier	United Kingdom, default relays at Linode and Akamai	No correlation possible by a single relay	Yes, two Trail of Bits audits	Yes	Open
Arpokrat Messenger	None, no identifier	Switzerland (Zug), relays in five non-American jurisdictions	Blind relays, RAM only	None to date	Yes	Open, AGPLv3
Briar	None, no identifier	None, no server	None, nothing to seize	Yes, Cure53 in 2017	Via Briar Mailbox	Open
Cwtch	None, no identifier	Canada for the association, servers untrusted by design	Group metadata resistance	Not identified	Partial	Open
Radar	Number (Signal account)	Signal servers, United States	Identical to Signal	Not identified	Yes	Open
Zerion	None, no identifier	None, no server	None, everything goes through Tor	Not identified	No, both devices must be online	Open, GPL v3

Which messenger for which profile

There is no winner, there are situations.

For family and close friends. Signal, without hesitation. It is the only choice that combines serious protection with a real chance that your contacts will install it. If the phone number bothers you, turn on a username so you do not have to share it. If your family absolutely refuses to move, at least turn on end-to-end encrypted backups on WhatsApp: it is not the same protection, but it is real progress and it is free.

For a journalist with sources. The problem is not the content, it is the link. A no-identifier architecture is the only coherent answer here: SimpleX Chat or Arpokrat Messenger, with Tor enabled and a different profile per source. If your source already uses Signal and refuses to install anything else, use Signal rather than nothing, with a dedicated number that does not identify you, and Molly on Android to protect the device itself in case of seizure.

For an executive or legal counsel. The dominant criterion is jurisdiction, not anonymity. Threema for a firm or a small structure, with clear invoicing and Swiss servers. Self-hosted Element for an organisation that has a technical team and wants sovereignty over its infrastructure, bearing in mind that the server administrator sees the metadata. Wire for an organisation that wants a commercial collaboration product, after examining its shareholding structure.

For an internet blackout or censorship zone. Briar, because Bluetooth and Wi-Fi mesh mode works with no infrastructure at all, and Zerion for the same reasons with a more recent offline mesh. These are the only two real answers when the network itself is the adversary. Plan for Briar Mailbox if your correspondence has to survive extended offline periods.

For anyone handling crypto daily. This is the only profile where the convergence of 2026 changes anything. Radar if your usage is Bitcoin and your network is already on Signal, accepting the dependence on Signal’s infrastructure and the phone number. Zerion if you want Bitcoin and Monero with maximum network resistance, and your correspondents are on Android and often online. Arpokrat Messenger if you want several chains, asynchronous availability and the ability to compare swap providers by their KYC requirements.

For anyone who wants the maximum with no usability compromise. This category does not exist, and that is the honest conclusion of this comparison. The theoretical maximum is Briar or Zerion, and it is paid for in deliverability, in battery and in the absence of iPhone. The most favourable compromise today, if your correspondents are on Android, is a no-identifier architecture in store and forward mode, SimpleX Chat or Arpokrat Messenger, with Tor enabled. If you have to include iPhone users, SimpleX Chat is today the only one in this family to cover both platforms. Arpokrat Messenger, available on Android, is under development for iOS and for desktop platforms, with no availability date announced.

What we chose at Arpokrat and why

This section is not a sales pitch, it is an explanation of trade-offs, including the ones we did not make.

We started from SimpleX rather than writing a protocol. The reason is simple: a secure messaging protocol only has value once it has been inspected, and a new protocol has by definition no inspection behind it. SimpleX has a public specification, public code and two Trail of Bits audits. Inventing our own cryptography would have let us make a better marketing page and a worse messenger.

We chose the store and forward model rather than peer-to-peer. That is an explicit trade-off against the theoretical maximum. A blind relay that keeps an encrypted message until it is collected is one more piece of infrastructure, and therefore one more surface. In exchange, a message leaves when you write it and arrives when your correspondent connects, which is the condition for normal correspondence. The practicality criterion, defended at the start of this article, is not a stylistic clause: we applied it to ourselves.

We spread the relays across five jurisdictions outside the United States and excluded American hyperscalers, not out of posturing but because the CLOUD Act works by compelling an American provider over the data it controls. A blind relay that keeps nothing on disk has little to hand over; a blind relay that no American order can reach has even less. The two measures add up, neither replaces the other.

We integrated a wallet and a swap aggregator because the same person who refuses to let an intermediary know their contacts generally refuses to let an intermediary know their transactions. The A to D rating of swap providers by their identity verification requirements comes from the same logic: we do not decide on the user’s behalf what level of privacy they want to pay for, we give them the information to arbitrate.

What we have not yet done, finally, deserves to be said in the same section. We have no independent audit published in our name. We have no history of published legal demands, only a warrant canary. We are not yet on iOS. These three gaps are real, they are documented in our profile above, and none of them is closed by a press release.

Conclusion

The right question is not “which is the best messenger”. It has no answer, because it is badly framed. The right question is: who are you protecting yourself against?

Against an advertiser who wants to profile your interests, just about every app in this comparison will do. Against a violent partner who has access to your phone, the question is local locking and memory wiping, and Molly answers better than Threema. Against a legal demand in your country, the question is jurisdiction and what the service holds. Against an adversary trying to establish that you spoke to someone, the only answer is an architecture that does not create that information. And against an adversary able to cut the network, the only answer is not to depend on it.

No app answers all these threats at once, and those that claim to deserve your suspicion first. What 2026 demonstrated is that encryption has become the easy part. What remains hard is metadata, jurisdiction, and a project’s ability to still exist in two years. Session came within a few weeks of disappearing, Briar scaled back its ambitions, and those two events say more about the real state of the sector than any comparison of cryptographic primitives.

So choose according to your adversary, not according to a ranking. And keep in mind that the best tool in the world is worth nothing if the conversation ends up elsewhere because the person you are talking to would not install it.

Sources

The Time Bomb: Harvest Now, Decrypt Later and the Zero-Knowledge Imperative

Tue, 26 May 2026 00:00:00 +0000

The dependence of European governments on American cloud infrastructure poses more than just an immediate interception problem. The great revelation, the most devastating threat for decades to come, is what intelligence specialists call the HNDL: “Harvest Now, Decrypt Later” strategy.

This is not a frontal intrusion, but a silent theft. Intelligence agencies and state adversaries are intercepting and storing immense amounts of encrypted data today, simply because the cost of storage has become negligible.

They wait patiently for the moment when technological leaps and the unpredictable evolution of computing power will render current cryptographic keys obsolete. What constitutes a protected state secret in 2026 could become an open book in fifteen or twenty years.

Retroactive Liability and Temporal Risk

The HNDL model introduces a novel concept: delayed legal harm. Traditionally, a breach of secrecy is a static event. With the massive collection of data for future decryption, confidentiality becomes a time-dependent variable.

To quantify this risk, the HNDL scientific model defines that confidentiality inevitably fails when the required lifespan of the secret exceeds the adversary’s decryption horizon. Sectors of critical exposure are currently in a state of latent vulnerability.

If a state or an organization does not guarantee the absolute sovereignty of its hardware infrastructure, it is practically signing a waiver of long-term confidentiality for its citizens and institutions.

Today’s interception is tomorrow’s compromise. Turning cloud dependence into a national security debt is a gamble impossible to repay.

The Arpokrat Antithesis: Legal Impossibility by Code

Faced with this vulnerability, the industry is responding by creating radical digital sovereignty ecosystems. The Arpokrat model emerges as the perfect antithesis to centralized messaging: this architecture operates on a decentralized network, protected by the very strict Federal Act on Data Protection (FADP) in Switzerland.

The core logic is one of absolute Privacy by Design. By removing the need to provide a phone number, the user becomes a simple cryptographic key, devoid of physical identity.

Legally, this drastically changes the rules of the game. If the architecture is fundamentally Zero-Knowledge and non-custodial, the company faces a technical impossibility to comply with foreign warrants.

This is not civil disobedience against extraterritorial laws, but an unstoppable mathematical and legal safeguard: what you do not hold cannot be disclosed.

Beyond Encryption: Devaluing the Target Data

The true response, natively integrated into the Arpokrat messaging app, is not to bet on eternal mathematics, but to devalue the data itself.

Without central metadata, without phone numbers, and without IP logs to link a message to a physical individual, the encrypted content loses its strategic value because it becomes unattributable.

However, software alone can do nothing if the hardware betrays it upstream.

Ultimately, security in the 21st century requires the independence of the machine itself. Deploying a sovereign de-Googled OS has become an absolute survival requirement for anyone handling state secrets.

The Illusion of Sovereignty: The Olvid Case and the CLOUD Act Trap

Thu, 21 May 2026 00:00:00 +0000

The announcement sounded like a true “cry of independence” in the corridors of Paris: the Prime Minister ordered the government to abandon WhatsApp and Signal in favor of Olvid, a messaging app presented as “native.” The stated goal was clear: protect state secrets from the long reach of foreign intelligence agencies.

However, a bitter irony quickly emerged: Olvid’s core — its server infrastructure — beats within Amazon Web Services (AWS), an American giant.

For the general public, this seems like a simple technical hosting issue. But for architects of sovereign cybersecurity and those tracking data geopolitics, it is a primary political vulnerability.

Extraterritoriality and Conflict of Sovereignties

By relying on Amazon’s infrastructure, Olvid automatically enters the orbit of the US CLOUD Act.

The legal analysis of this case reveals a scenario of jurisdictional insecurity that simply adopting a national “app” does not resolve. The tipping point lies in the concept of “control” versus “localization.”

The CLOUD Act radically changed the legal paradigm by stipulating that the physical location of the server does not matter. The service provider’s (here, AWS) obligation to cooperate stems solely from its jurisdictional tie to the US. Thus, Washington can demand data from companies under its jurisdiction, even when that data is physically stored on European soil.

Legally, this creates a frontal conflict with the General Data Protection Regulation (GDPR). The Court of Justice of the European Union (through the famous Schrems I and II rulings) has already established that US surveillance laws do not offer a level of protection equivalent to Europe’s, as they are not limited to what is “strictly necessary.”

Digital sovereignty is not an attribute of software, but a property of the integrity of the chain of custody.

The Spectre of FISA and the False Promise of Encryption

Worse still, this dependence on American infrastructure places this data under the shadow of the Foreign Intelligence Surveillance Act (FISA), which authorizes electronic surveillance for “foreign intelligence” purposes targeting individuals located outside the US.

Faced with these threats, Olvid asserts that its end-to-end encryption constitutes a sufficient shield. From a privacy engineering perspective, this defense is dangerously partial.

The recent rejection of backdoors by the French National Assembly shows legislative resistance to vulnerability by design. Yet, even if the content of a message is encrypted, AWS’s centralized infrastructure exposes metadata. Knowing who is talking to whom, when, how often, and from where is often much more valuable to foreign intelligence than the message content itself.

Encryption protects the text, but the centralized server betrays the network of contacts.

The Real Danger Is Yet to Come

As long as European infrastructure relies on entities subject to extraterritorial statutes, the legal security of our communications will remain purely temporary and illusory.

National security in the 21st century requires much more than good legislative intentions or superficial software shields: it demands total infrastructure and hardware independence. Because while intercepting this metadata and encrypted packets seems harmless today, it actually feeds the most devastating threat of the next decade: the strategy of “Harvest now, decrypt later”.

A state secret intercepted today is nothing but a mathematical time bomb.

(Read the rest of our analysis in Part 2: The Time Bomb and the Zero-Knowledge Imperative)