Once QERYX arrives, you will verify each contact once with Request Entanglement: you send the request, each of you confirms it with one tap on your own phone, and the Herald guides you both. After that first confirm everything runs on its own; if a device or key ever changes, the same request returns. This guide says what the confirm pins, why the transparency log keeps watching in the background, and what a returned request means.
Know what Request Entanglement is
Request Entanglement is the one step you take to verify a contact. When both phones confirm, each pins the other's ML-DSA-87 identity public key — the key that signs every handshake between you — through a check derived with HKDF-SHA-512 over both identity keys, sorted so both devices compute the same bytes. The code the confirm pins lives only inside the cryptography, and the two devices check it for you.
Understand why the log keeps watching
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, which checks it in the background. 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 confirm on each phone is the one step that needs your hands.
See how the confirm runs
- Once QERYX arrives, you will send each contact a Request Entanglement, once.
- Your contact will confirm it on their phone, and you on yours: one tap each. The Herald will guide you both.
- Both phones will pin each other's keys, and the contact is verified. Everything after that first confirm will run on its own.
Act when a device or key changes
If your contact moves to a new phone, reinstalls, or their key changes for any other reason, the same entangle request returns and asks them to confirm again. A returned request will usually mean a new device. It can also mean interception: the residual risk named in the threat model is precisely a returned request confirmed without knowing why it returned. Confirm it when you know why it came back — 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 confirm.