No identity substitution

In an end-to-end secure messaging app, a contact’s identity is carried by their key: substituting their key amounts to substituting yourself for them. A user’s long-term cryptographic key pair is the foundation on which the secure communication channel with them is built. These keys are required for end-to-end encryption, and they are what end-to-end authentication seeks to authenticate.

If this long-term key pair changes, all the security of future exchanges with that user now rests on the new pair. A manual verification carried out on the old key is then worth nothing. A key change therefore amounts to a complete reset of the security of your exchanges with a user: a communication that was secure at one point may no longer be after a key change. This is not a trivial operation.

Let us be clear that we are talking here about a change to a completely independent key. A key change is acceptable, on the other hand, if the new key is signed by the old one, which could be justified when the application changes cryptographic primitives (encryption or signature algorithm), for instance to move to a post-quantum cryptosystem. In that case, if the first key was correctly authenticated, the new one can be considered authenticated as well.

Signal and WhatsApp let a user change their key, typically when changing phones. This new key is random and completely independent of the one that existed on the previous device. The user’s correspondents are informed by an alert indicating that the key has changed, but this alert is purely informational: the new key is accepted by default, without any new verification, even though the security of the channel has been completely called into question.

The problem with phone-number identification

More worrying still, to change a user’s key on these messaging apps, all it takes is proving to the service’s directory that you own the associated phone number. That proof relies on a six-digit code sent by SMS: intercepting that SMS is therefore enough to change a user’s key and, in effect, to take control of their account.

Who can intercept that SMS? Any actor along its delivery chain. In the case of Signal, that includes:

• Signal itself;
• the SMS provider sending messages on Signal’s behalf;
• the phone carrier of the number’s owner;
• abroad, the local carrier the phone is connected to (what is known as roaming);
• any actor able to set up a rogue cell tower near the user’s phone.

The legitimate operator of each of these links, like any adversary who managed to compromise them, is in a position to take control of a Signal or WhatsApp account. In practice, the adversary can then receive the messages addressed to the victim and send messages in their name, impersonating them with all of their contacts.

Two events show that the risk of relying on such a delivery chain is very real:

• In the summer of 2022, a phishing attack against Twilio^archived, which at the time delivered Signal’s verification SMS, exposed the phone number or verification code of about 1,900 Signal accounts, and at least one account was actually re-registered on a device controlled by the attacker.
• In late 2024, CISA and the FBI^archived revealed^archived that the Salt Typhoon group, attributed to a Chinese state actor, had compromised several major US carriers, with access to the content of the SMS messages traveling unencrypted on their networks; FBI officials themselves recommended^archived moving away from SMS in favor of encrypted messaging apps. In response, many voices recommended using Signal. That advice is debatable since, as we have just seen, the security of an account rests on the confidentiality of a code received by SMS… that is, on exactly what Salt Typhoon had just compromised.

Detection that comes too late to protect

It is sometimes objected that the victim will eventually notice the compromise, for instance when they find themselves logged out of Signal or WhatsApp. In some cases, this after-the-fact realization is not acceptable. Consider a concrete example: a journalist travels to a hostile country. There, while roaming, her phone goes through a local carrier, which happens to be the adversary. The adversary can perform the steps one usually performs when changing phones and reinstalling Signal or WhatsApp: it enters the victim’s number, intercepts the verification SMS and takes over her account. It now receives the messages meant for the victim and can write in her name. The victim cannot even regain control, because recovering the account requires a new SMS, which that same carrier will not deliver to her.

A secure messaging app must protect its users from a hostile network. Those that use the phone number as an identifier, and can therefore only “authenticate” their users by SMS, are vulnerable to a malicious phone network.

Additional protections, but a structural problem

Signal offers a PIN mechanism whose role deserves clarification. By default, this PIN is only required to restore the user’s settings and contacts: it is not needed to recover the account itself. An attacker who has intercepted the verification SMS can therefore simply skip this step and take over the account.

Signal additionally offers an option called Registration Lock, which makes entering the PIN mandatory when re-registering. When enabled by the user, this option limits the reach of the SMS-interception attack. Its protection is, however, limited in time: after seven days, Registration Lock is disabled and the account becomes recoverable again on presentation of the verification SMS alone.

This limitation stems from a design constraint: Signal must be able to let a new user take over a phone number that has been reassigned by the carrier after a period of inactivity. A permanent Registration Lock would make that recovery impossible.

WhatsApp offers comparable protections, with the same limits. Its two-step verification adds a six-digit PIN, required in addition to the SMS code when registering on a new device. Like Signal’s PIN, it is optional and disabled by default. Moreover, it does not lock the account: the account remains recoverable on the basis of the SMS code alone. If the user has linked an email address, it merely offers a shortcut for resetting the PIN, and authority then shifts to another external identifier, the email address, which can likewise be intercepted or compromised. Without an accessible email address, seven days after the last connection, recovery by SMS alone reopens. This escape hatch is not an oversight; it stems from the same design constraint as described above: it must always be possible to let a new holder use a reassigned number.

These mechanisms make things harder for an opportunistic adversary, but they do not remove the underlying problem: authority over the account ultimately remains tied to possession of the phone number and to the cooperation of the actors delivering SMS messages.

A limit intrinsic to the choice of identifier

This dependency is not specific to Signal or WhatsApp: it follows directly from the choice of identifying users by their phone number. As soon as an account is tied to a phone number, the messaging operator has no means of its own to distinguish the account’s legitimate owner from a new user who has legitimately obtained that number after the carrier reassigned it. The only proof of identity it can demand is possession of the number, and the only way to verify it remotely remains sending a code by SMS, which involves the chain of actors described above. No additional mechanism can escape this dependency: as long as identity rests on a phone number, authority over the account remains contingent on the cooperation of whoever controls that number. No messaging app built on this model can therefore do structurally better, short of abandoning the phone number as an identifier.

Recent developments: Key Transparency

The problem of a silent key change orchestrated by a compromised operator has seen significant developments in recent years. WhatsApp was one of the first mainstream players to deploy a so-called Key Transparency mechanism, named Auditable Key Directory (AKD)^archived, based on cryptographically auditable data structures. Apple then deployed a comparable system for iMessage under the name iMessage Contact Key Verification^archived, with notable improvements, in particular the verification of consistency proofs directly on the user’s device, and a “gossip” mechanism that lets different clients compare, among themselves, the keys they see for the same user. Signal has taken the same path: a key transparency log^archived maintained by Signal records the associations between identifiers (phone number, account identifier, username) and public keys, along with a reference implementation of a third-party auditor^archived; automatic key verification^archived based on this log has been in place in its apps since August 2026.

These systems make it possible to detect that a centralized directory is presenting different keys to different recipients (a so-called “split view” attack) or that a key has been added without the user’s knowledge. They mitigate the risk of trusting a centralized directory by making its operations verifiable and auditable.

A word of caution, however: security conceptually still rests on a third party, the directory service and the associated transparency service. It also assumes an ecosystem of auditors, a gossip mechanism that works, and a user who pays attention to inconsistency alerts when they occur.

As for the ecosystem of auditors, there is, at the time of writing (September 2026), no public registry of auditors comparable to the lists of recognized logs that browsers maintain for Certificate Transparency. WhatsApp’s log is verified by a single third-party auditor, Cloudflare^archived, which has been countersigning its consistency since 2024 and publishes its status^archived. Signal’s is audited by Cloudflare^archived and by Trail of Bits^archived. The scope of this verification also deserves clarification: the auditor attests that the log is consistent and that its past is never rewritten, not that a key belongs to its legitimate owner; and a single auditor shifts trust more than it removes it, since an operator and its auditor could, together, present divergent views without detection. This is probably why Apple offers in parallel a manual verification mechanism using short codes (the SAS protocol of Serge Vaudenay, a professor of cryptography at EPFL), intended for users who want end-to-end authentication. This is the same protocol Olvid uses to let its users get in touch remotely.

Above all, note that Key Transparency does not address the central problem of this criterion. A re-registration obtained by intercepting an SMS produces a key change that is perfectly “legitimate” in the eyes of the log, which will record it just as it would record an ordinary phone change. Key Transparency targets the directory that lies selectively, not the takeover of the identifier: as long as identity remains a phone number, it makes substitution visible, it does not make it impossible.

A structural solution: removing the key–identifier association

One aspect of Apple’s implementation deserves to be highlighted: manual verification applies not to the key of a specific device but to an account key that signs all of the user’s current and future devices. The account key is itself generated on the device and synchronized through the end-to-end encrypted iCloud Keychain. This approach avoids one of the main problems of manual verification, namely that it has to be redone every time the device changes.

This improvement does not, however, address the underlying question. As long as a user’s identity is carried by a non-cryptographic identifier (phone number, email address, account identifier) that must then be associated with a public cryptographic key, that association remains the system’s Achilles’ heel. While Key Transparency makes the association verifiable and auditable, it does not remove the association itself. Apple’s account key is tied to an Apple ID, itself associated with an email address and, in most configurations, a phone number: each of them a point through which a sufficiently determined adversary can attempt to hijack authority over the account, regardless of the cryptographic robustness of the edifice built on top.

The only way to remove this point of attack is to stop basing the user’s identity on an identifier external to the cryptography. Several paths can lead there, and two solutions illustrate this philosophy by different means.

Olvid gives the user a persistent cryptographic identity: their long-term key pair is their identity, shared with their contacts. The user, in short, is their key. There is no centralized directory associating an identifier with a key, and therefore no association that could be hijacked. The direct consequence is that a key change is not a seamless maintenance operation but constitutes, by construction, a change of identity: the user who holds the new key is simply no longer the same user as the one who held the previous one.

SimpleX Chat reaches the same diagnosis and answers it with an even more radical approach: not assigning any global identifier to the user, not even a persistent public key. Each conversation relies on per-queue identifiers specific to the bilateral relationship, distinct from one conversation to the next. Two contacts of the same SimpleX user thus cannot, by analyzing network metadata, determine that they are talking to the same person. Where Olvid answers “the user is their key,” SimpleX answers “there is no user, only relationships.” Both approaches escape the centralized-directory problem, by different means. That said, lacking a stable identity, a SimpleX user cannot rely on their existing contacts to authenticate new ones: there is nothing a third party could vouch for. Yet that is how a “web of trust” is woven: on PGP, by signing another user’s public key; on Olvid, by introducing two of your contacts to each other. SimpleX also has an introduction mechanism, the one by which a group’s host connects its members with one another. But it carries no guarantee: without a stable identity, there is nothing the introducer could have authenticated beforehand and could vouch for; the introduction is only worth as much as the links it passes through, which are themselves never authenticated, by construction. It is therefore impossible to build a web of trust, since that requires stable identities.

On Threema, the approach is different again: the identifier is not the phone number but a string of 8 random characters (the “Threema ID”), with which a public key is associated once and for all. The phone number is optional and only serves to let your contacts find you. No mechanism allows changing the key of an existing ID. If you lose your private key (for instance if you lose your phone), you must create a new ID, in other words a new identity. Where Olvid and SimpleX remove the association between an identifier and a key, Threema merely freezes it. That is enough to rule out silent key changes, but not to solve authentication: the initial link between a Threema ID and its key is still distributed by Threema’s central directory, which you take at its word on first contact. This is why Threema does meet the “No identity substitution” criterion but not the End-to-end authentication criterion.

In September 2026, Signal also introduced a new paid feature called “Signal Login^archived,” which makes it possible to create an account without providing a phone number. A cryptographic identifier then replaces the number. Key substitution remains possible, but requires knowledge of that identifier, which makes most of the attacks described here considerably harder.

The design choices of Olvid, SimpleX Chat, Threema and Signal Login nevertheless come with a constraint: the responsibility for preserving one’s identity, whether a long-term key or the local database holding all of one’s relationships, falls entirely on the user, and its permanent loss means the loss of the account. Olvid addresses this constraint with a system of recovery codes to be kept offline, which allow the cryptographic identity to be restored on a new device; SimpleX, with local mechanisms for exporting and importing the database. This is a deliberate design trade-off, in favor of structurally stronger security, at the price of greater demands on the user.

Applying this criterion

✅Good if a user’s long-term key can never be replaced by an independent key; in particular, no external mechanism (SMS code, email) makes it possible to re-associate their identifier with a new key. A change signed by the old key remains acceptable.