Pairing Without an Account: How Peering Decides Who to Trust
Most remote desktop tools ask you to sign up so that a company can decide whether two devices belong together. Peering skips the company and asks you instead, with six digits.
Every device is its own identity
The first time Peering runs on a Mac or an iPhone it generates a P-256 key pair and keeps the private half in that device's Keychain. That key is the device's identity for good. There is no username, no password and no server that holds a copy. Each time the app starts it signs a fresh self-signed certificate over that key, and other devices pin the key and not the certificate.
This matters because a self-signed certificate proves nothing by itself. It says "this key made this certificate", not "this is the Mac in your living room". Something has to connect a key to a physical device, and that something is you.
The six digits
When a phone meets a Mac for the first time, both screens show a six digit code. You confirm they match. If they do, each device stores the other's key. If they do not, someone is sitting between the two and you decline.
The code is not random and it is not a password. It is a short hash of the entire handshake: both device IDs, fresh one-time keys from each side, one-time random numbers from each side, and the Mac's identity key. Specifically, it is the first four bytes of a SHA-256 over those fields, reduced to six decimal digits. If an attacker relays the connection, the Mac and the phone each see a different transcript and therefore a different number.
Why commit first
A six digit code has only a million values, so a clever attacker could try to grind through one-time keys until both sides happen to show the same number. The protocol closes that door with a commit and reveal step:
- Each side sends a hash of its one-time key and its random number first.
- Only after both hashes are in does either side reveal the real values.
- Each side checks the reveal against the hash it was given earlier.
Because an attacker has to commit before seeing anything, they cannot tune their values to match. What is left is a blind guess, with a one in a million chance of a matching code per attempt, and a failed attempt shows up as a mismatch that you can see.
The QR shortcut
If you scan the Mac's QR code, there is nothing to compare by eye. The QR contains a 16 byte secret that only someone looking at the Mac's screen could have. The phone uses it to compute a proof (an HMAC over the handshake), and the Mac accepts it as evidence that the person pairing is physically in front of the Mac. Without that proof, the Mac asks its own user to approve.
After pairing, trust is a key comparison
Every later connection is a TLS 1.3 session in which both sides present their key. The phone takes the Mac's key from the certificate it actually received, never from anything the Mac says in a message, and compares it to the stored one in constant time. A different key means no connection. Nothing is asked of you after the first time.
If a Mac claims "I already know you" but your phone holds no stored key for it, the phone refuses. The claim proves nothing, since a stranger could say it just as easily.
The practical walkthrough is in the pairing guide. For what happens to the connection once it exists, see what the relay can see.
Questions
Does Peering need an account or an email address?
No. Each device creates its own key and stores it in its own Keychain. Pairing is a six digit code you compare on both screens.
What does the six digit pairing code protect against?
Someone sitting between your iPhone and your Mac. The code is derived from the whole handshake, so a man in the middle produces different codes on the two screens and you can see the mismatch.