How do you know that key is theirs?

Begin with the sentence the specification uses about itself. Signal’s X3DH document, which defines how two parties who have never met arrive at a shared secret, says: “If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with.” That is not a footnote. It is the edge of what the mathematics is for. To open a conversation, Alice asks the server for a prekey bundle — Bob’s identity key, his signed prekey, the signature over it, optionally a one-time prekey. The server hands it over. Everything after that moment is impeccable. Everything before it rests on the server having handed over the right key.

Trust on first use

The model nearly every messenger uses is called trust on first use. The first time you talk to someone you accept whatever key the directory offers, because you have nothing to compare it against; from then on the app remembers, and can notice if it changes. TOFU is a good bargain: it costs the user nothing and converts a permanent exposure into a single moment of one. Its weakness is in its name: if the substitution happens at first contact, there is no earlier key for the new one to disagree with, and nothing, anywhere, will ever object.

The classical remedy is the safety number. Signal renamed it from “fingerprint” in November 2016 after research found that people associated the word with something intimate, and reshaped it at the same time: twelve groups of five digits, one number belonging to the conversation rather than one per participant, so that “when Alice and Bob set out with the objective of verifying that their communication is private, they are provided with a single piece of information.” X3DH names the same practice as the fix: the parties “may compare their identity public keys … through some authenticated channel. For example, they may compare public key fingerprints manually, or by scanning a QR code.”

It works, and almost nobody does it, because it needs a second channel or a shared room. But verification is not only a ritual without an afterlife. In June 2017 Signal set out what marking someone verified changes later on: for an unverified contact, an incoming message following a key change is shown immediately, together with a warning; for a verified one, “if a verified safety number changes, sending a new message to that contact always requires manual approval.” Verifying somebody once buys you an interruption at the moment it matters.

What Signal shipped in August

On 11 August 2026 Signal introduced Automatic Key Verification. It targets precisely the case safety numbers were always aimed at and rarely reached: in Signal’s framing, the scenario where “a key is swapped out without the key owner’s knowledge — for example, if a malicious party compromised Signal and associated a different key with your connection’s phone number.” Underneath it is key transparency: a Merkle-tree log that produces, as Trail of Bits describes it, “a globally consistent view of the set of public keys associated with each phone number.” Signal, Cloudflare and Trail of Bits each operate an independent auditor over that log, checking that the map “is globally consistent and well formed” and that it “does not hide any entries.”

The honest bound comes from the auditor rather than the vendor, and deserves quoting rather than paraphrasing: “A fully malicious server may therefore maintain a split view of the system for at most one week before client applications start to display warning messages.” One week is not zero. It is also an entirely different proposition from indefinitely, and quietly.

Where this still stops short

To verify a contact automatically you open their profile, tap View Safety Number, then tap Verify automatically; on success you get a green check and “Encryption verified.” That is a real improvement on finding a second channel and reading sixty digits aloud. It is also, still, a thing you have to decide to do. The strongest identity check ever shipped in a consumer messenger sits behind a screen most users will never open.

Detection that runs only when a worried user goes looking is a service for the worried. It is not a defence.

This is the same structural mistake as the linked-devices list, and it is worth naming because it recurs: the capability gets built, it is correct, it is documented — and then it waits. “The feature exists” answers an audit question. It does not protect anybody. The part of Signal’s design that protects people without being asked is the older and humbler one: the key-change notice that appears in the conversation on its own, and the send that will not proceed for a contact you had previously verified. Those fire whether or not the user suspected anything. That property is scarcer than it ought to be.

Where OSHI is, precisely

This week we audited our own. Android has a hasKeyChanged(); the detection is real and it was written correctly. Until 13 September 2026 it was called from exactly one place: when the user opened the safety-number screen. In other words it ran for people who had already concluded something was wrong. On iOS there was no detection at all. Both platforms now run the check on the message path, where it can actually catch something.

And then it stops, so here is the rest of it: nothing displays the alert yet. The detection exists; the banner does not. By the standard this article has been applying to everyone else, OSHI currently fails it. We would rather write that down than be found out.

There is no purely technical answer to the question in the headline. A key is a number a server gave you. What turns it into a person is either something you did once, in a room or on a phone call, or independent witnesses agreeing that nobody swapped it. Both are real. Neither is automatic. And the difference between a mechanism and a defence is whether it speaks first.