One check closes the machine-in-the-middle door: your safety number, compared with your contact's over a channel the network cannot touch. Once per contact, and any key substitution between you becomes visible instead of silent. This guide tells you exactly what the number is, why the transparency log cannot replace the check, and how the check runs.
Know what the safety number is
Your safety number is a short fingerprint computed with HKDF-SHA-512 over your session root and both peers' ML-DSA-87 identity public keys, sorted so both devices derive the same bytes. At the in-person connect ceremony — before a session exists — the same fingerprint is computed over the two identity keys alone. The identity keys are the keys that sign every handshake between you. If your device and your contact's derive the same number, you hold each other's real keys. If an attacker sits between you and substituted their own keys, the two numbers differ. The mathematics leaves no third outcome.
Understand why the log is not enough
QERYX logs every identity binding in the Key Transparency System — an append-only Merkle log whose signed tree heads make silent key substitution detectable by auditors and by your own device. The log shrinks the attack to a narrow, expensive window. It cannot shrink the window to zero: transparency detects equivocation after the fact, and detection is not prevention. The out-of-band comparison is the one step that needs your hands, and it is the step that makes the guarantee yours instead of ours.
See how the check runs
- Once QERYX arrives, the check runs once per contact, between your device and theirs.
-
The number is compared over a channel the network between you cannot
rewrite — one of:
- In person: the devices compare for you.
- On a voice or video call: the number is read aloud, both directions. You are also hearing a voice you know.
- Over another channel you already trust — one you have independently verified.
- Numbers match — the contact is verified, and the verified state persists.
- Numbers differ — stop. Do not send anything sensitive. Re-check on a different channel, and if the mismatch holds, treat the session as intercepted and re-verify after a fresh key exchange.
Act when keys change
A key-change notice will usually mean your contact reinstalled or moved to a new device. It can also mean interception. The residual risk named in the threat model is precisely the user who taps past this prompt: verification after a key change is the entire defense. Run the check again (§3) before you continue the conversation — especially before anything you would not publish.
References
- Identity and Key Transparency — the log this check completes.
- The QERYX Threat Model §12.2.2 — active machine-in-the-middle at handshake, mitigation and residual risk.
- NIST FIPS 204 — ML-DSA, the identity-signature primitive behind the number.