Security benchmark of messaging applications

At a glance
• End-to-end encryption — ✅ Good
• End-to-end authentication — ✅ Good
• End-to-end security — ✅ Good
• No identity substitution — ✅ Good
• Open source client — ✅ Good
• End-to-end multi-device — ✅ Good
• Minimal personal data — ✅ Good
• No contact discovery and spam — ✅ Good
• Post-quantum encryption — ❌ Poor (planned for 2027)

Olvid starts from a constraint set at the design stage: no server may play any role in the security of exchanges. A user’s identity is neither a phone number nor an account listed in a directory, but a pair of cryptographic keys: the user is their key. By default, there is therefore no central directory associating an identifier with a key, and consequently no association an operator could hijack.

In an enterprise deployment, an organization can operate a directory for its own members: the trust anchor is then deliberately moved to a server that the organization chooses and controls — never to the messaging operator. Even with that directory, no key substitution is possible: on contacts’ devices, a new key never replaces the old one; it can only appear as a new contact. Olvid’s servers therefore route encrypted messages between identities that have authenticated each other. As a result, even a total compromise of its servers would not allow a single conversation to be intercepted. To compromise exchanges, an adversary has to go after the devices themselves, or after the software distribution channel (the mobile app stores, for instance), the only central point common to all messaging apps.

This choice has a consequence: the user is responsible for their own identity, and losing it is final unless they have enabled the secure backups^archived Olvid offers. There is no operator to ask for an account reset, precisely because no operator has authority over accounts. It is the same trade-off as with Threema and SimpleX: structurally stronger security, at the price of greater demands on the user.

These choices have been examined by independent experts: the trust-establishment protocol has been the subject of a security proof^archived by Michel Abdalla, a researcher at CNRS and ENS, Olvid’s cryptographic core has been formally analyzed in a paper^archived published at ACM CCS 2026, and the applications have been CSPN-certified by France’s ANSSI, in 2020 for iOS^archived and 2021 for Android^archived (reports in French). As for the business model, it is the same as Threema’s: Olvid makes its living from paid offerings to businesses and government agencies, not from exploiting data.

End-to-end encryption ✅ Good

All exchanges (messages, attachments, calls) are end-to-end encrypted, in every chat, one-to-one or group, and encryption cannot be turned off. Keys are renewed continuously, which provides the forward secrecy the criterion refers to.

End-to-end authentication ✅ Good

This is Olvid’s founding property, and no other solution in the benchmark meets it. No contact can be added without the link between that contact and their key having been established by one of the following means:

in person, by scanning each other’s QR code, where the face-to-face setting naturally guarantees that the exchange is authentic;
remotely, by exchanging two 4-digit codes (Vaudenay’s SAS protocol^archived) over a channel you know to be authentic — those 8 digits are enough to limit an attack’s probability of success to about one in a hundred million per attempt; every failure is visible, and trying again requires a new invitation and a new exchange of codes: an attacker cannot keep retrying without the users noticing, and they would give up after a few failures;
through a mutual contact, who introduces two of their already authenticated contacts to each other;
or by joining a group, whose members are connected with one another.

In all four cases, the chain of trust never rests on the operator, which relays the exchange without being a link in it. By default, there is no directory to query, and therefore no key to substitute.

These four paths have one thing in common: they bring gestures from the physical world into the digital one — exchanging a business card, introducing one person to another. This is where a distinction that often goes unmentioned comes into play. Authenticating a correspondent, as we have seen, means anchoring trust somewhere: either in a third party, or in yourself. Solutions that impose a directory ask the user to trust something: a server, an infrastructure, a transparency mechanism they cannot inspect. Olvid, for its part, asks them to trust someone: the person they meet, or the contact who introduces them. One may object that a mutual contact formally remains a third party, just like a server. But a user is far better at judging whom to trust than what to trust: deciding whether to trust a friend who introduces someone to you is an everyday social judgment that people have always made; assessing whether an operator’s directory and its SMS delivery chain can be relied upon is not. Olvid does not claim to eliminate third parties altogether, but to replace them with one whose reliability the user is genuinely in a position to assess.

Going through a mutual contact is, moreover, not always a mere convenience. It is sometimes the only way to get in touch with someone. When you know a person only through a friend, all you know about them is what that friend has told you: for you, this contact exists only because a mutual friend introduced them. That is the ordinary situation of an introduction in the physical world, and it is also its limit: the trust you place in a stranger who is introduced to you can never be stronger than the trust you place in the person introducing them. No technical mechanism can go beyond that bound, because it has nothing to do with technology. A digital solution cannot make a meeting safer than it is in the tangible world. What a messaging app can do, on the other hand, is avoid degrading that security — avoid replacing it with trust in a server. Olvid does exactly that, by carrying over the gesture of introduction and preserving, in the digital world, its structure of trust — with one inevitable detail: the introducer acts through their device, and the trust placed in them now extends to it. That trust, however, never shifts to a server.

End-to-end security ✅ Good

Both components of the composite criterion are present: systematic encryption and end-to-end authentication.

No identity substitution ✅ Good

Since the identity is the long-term key pair itself, there is no external identifier (number, email) that a recovery mechanism could re-associate with a new key. A key change is, by construction, a change of identity. The rule holds even with the optional enterprise directory: a new key never replaces the old one on contacts’ devices — it can only appear as a new contact, and the old one has to be deleted manually. Nobody can therefore substitute themselves for a user by having a new key registered in their place.

Open source client ✅ Good

The applications are published under an open source license (AGPLv3)^archived, the cryptographic documentation is public^archived, and the server code is open as well^archived, under the same license (which the criterion does not require, since the server plays no role in security).

Reproducible builds make it possible to verify that the distributed application matches the published code. As of September 2026, they are available for the Android application distributed on F-Droid^archived, but not yet for the Play Store version.

End-to-end multi-device ✅ Good

All of a user’s devices share the same cryptographic identity. A contact who has authenticated that identity thus trusts all of the devices, with no additional verification and without being asked to do anything when a device is added; internally, a secure channel is established between each pair of devices from the shared key. The server distributes the list of a user’s device identifiers, and could therefore try to add a device of its choosing to it; but such an injection has no effect: such a device would not hold the private part of the targeted user’s identity, without which it cannot establish a secure channel with any contact. It could therefore neither receive nor send a single message. Maliciously adding a device thus has no consequence for the confidentiality of exchanges. Maliciously removing a device from the list, for its part, would only deprive that device of messages: a matter of availability, not security, and one that affects every messaging app that uses a server (the server can simply stop delivering the messages entrusted to it).

As for legitimately adding a device, it meets the requirements the criterion sets. The procedure can only be started from the device that already holds the profile, by a deliberate action in the settings: nothing — no message, no link, no QR code — can trigger a device addition from the outside. The user must then enter two 8-digit codes, one on each device: the first lets the two devices find each other on the server, the second (SAS-type) authenticates the encrypted channel established between them — the server relaying the transfer can neither read it nor insert itself into it. Nothing in this process can be confirmed on autopilot.

Minimal personal data ✅ Good

Olvid can be used without providing any personal data at all — no name, no email address, no phone number, no access to the address book. The server knows only what it strictly needs to deliver messages, and sending is even “anonymous” from its point of view. Like any relay server, however, it can observe the social graph of its users; minimization guarantees that the nodes of that graph remain pseudonyms. On Android, a setting also lets you turn off Google’s push notifications in favor of a permanent connection to Olvid’s servers: the notification token then disappears, and with it the means for a third party to link your messaging identity to your real one. For an organization, this absence of collection means fewer processing operations to document under the GDPR.

No contact discovery and spam ✅ Good

By default, there is no directory or identifier that would allow a user to be found: you cannot “search for” someone on Olvid (the optional enterprise directory only opens that search to members of the same organization). Above all, a user never receives a single message from a third party without having explicitly accepted the connection beforehand — the only thing that can reach them from a stranger is the connection request itself.

A stranger can therefore only reach out to a user if they already hold that user’s identity, which can be neither searched for nor discovered and only circulates if the user (or one of their contacts) has passed it on. And that solicitation boils down to a connection request carrying nothing but a name: a short string chosen by the sender, displayed as plain text — the irreducible minimum, since the recipient has to be told who is inviting them. No message, no media, no call is processed by the application before acceptance: spam and phishing through unsolicited messages are ruled out, and the surface exposed to zero-click attacks — which require being able to deliver content that the application processes automatically — is reduced to parsing and displaying a name.

Post-quantum encryption ❌ Poor

Olvid does not yet include post-quantum encryption: its secure channels currently rely on classical key encapsulation mechanisms (KEMs), built on the Curve25519 and MDC curves. A hybrid post-quantum KEM based on ML-KEM is to be added in 2027. It will protect both the initial establishment of the channels and their periodic renewal (the “full ratchet”), and therefore group chats too, since they rely on these same channels between devices.