[matthewdgreen]

Security codes ("safety numbers" on Signal) are supposed to provide you with a means to detect malicious MITM attacks. Since most users don't check their contacts' numbers out-of-band -- or even verify their own codes regularly -- it's kind of a probabilistic mechanism. In theory these checks should dissuade attacks on the system, but in practice does it?

This post illustrates one of the many reasons the solution is less effective than I would like it to be. Specifically, when the system spits out weird results (changing safety numbers, mismatched numbers) it tends to be hard to diagnose the problem in a way that lets you verify, let alone prove to third parties, that there really was an attack. Since changes and mismatches "just happen", people tend to take warnings less seriously than they would if there was a path to diagnosing the problem. Moreover, from a hypothetical attacker's perspective there isn't much disincentive when most users will just shrug at these problems. I'm not sure there's a perfect solution to this, but I think it would be interesting to make these systems more robust.

[ianopolous]

Yes, a system with so many false positives will be ignored by users. Warnings should only occur if a genuine problem is detected.

Ideally we'd all use an append-only merkle log ala certificate transparency to lookup public keys. This is much harder to MITM, and you can do lookups over onion routing to make it even harder. Of course, if your identifiers have PII (like phone numbers in Signal and Whatsapp) this is not going to fly, but that's the bed they made for themselves.

[gcr]

The system you propose is exactly the design of Keybase! In fact, KB even supports proofs of real-world identities that are themselves signed on the Merkle tree, automatically periodically checked by clients. (However, this still leads to tons of false positives...)

[ianopolous]

Yep keybase was great, apart from being closed source, centralized and not having a viable business model.

[kfreds]

Oh, a fellow fan of transparency logs!

I'd love to hear what you think about a log a few colleagues and I have designed. We've tried to get to the essence of transparency logging. It's a minimalistic design, and it doesn't require trusting the log operator.

www.sigsum.org

[chucky]

I feel like you are hinting at one solution already. Security features are worthless without education. WhatsApp should give a "step by step guide" on what to do when the safety number changes, and they should block users from continuing to use the app until they have verified that they have taken these steps.

This is by no means fool-proof, but it would at least work against the problem now where they are basically training users to ignore these dialogs.