Implement E2E key verification process

[richvdh]

We should implement some sort of process to help people do device verification instead of encouraging them to blindly stab at "verify"

[richvdh]

For example, Alice wants to verify Bob’s device:

• Alice opens the verification dialog for Bob’s device (from the device info or a message from Bob)
• Bob finds Alice’s user (in a room member list?) and opens a “verify yourself to this user” dialog; this shows him a phrase such as “correct horse battery staple”
• Bob reads out the phrase to Alice over the phone or sth
• Alice types it into the verification dialog

Future alternatives might involve scanning a QR code or using an NFC bump.

It’s possible to design a process which establishes verification in both directions (so Bob will also know about Alice’s device), but it’s Complicated.

[richvdh]

(See also #2622: the current UX encourages people to stab at 'Verify' to make the ugly triangles go away)

[Cadair]

Alice types it into the verification dialog

Would you need to type it in? Could it not be displayed on both screens like with Signal?

[pingiun]

The implementations in Whatsapp and signal are pretty good UX, except that they use a hexidecimal string for vocal verification. Something like this would be better, keybase uses this and I feel it's very easy to use.

[ara4n]

enough of the rest of e2e is now in place that this should be p1

[frabcus]

This is fantastic! I've a lot to say about this, and I'm not sure if this is the right ticket or it should have a design doc or be split up. Key things that come to mind:

1. Encryption needs to be on by default, or people won't use it. So that should be definite goal. Hope it is!
2. Verification with an out-of-band method is not socially understood as needed yet. This means that basically nobody will do it, unless they have a specific privacy need. I think (compulsory but easy) verification via email and/or phone number is a good intermediate method.
3. Then even if verified by (relatively insecure, but way better than unencrypted) phone/email, the user interface can make clear you're not fully secure, but not in too negative a way (after all, that's as secure as WhatsApp or Signal!)
4. And lead you into out of band confirming that as described in this issue - by reading something out over a voice call. Ideally this would be four or five words in a common language, rather than long codes. And if codes, definitely don't have both caps and lowercase.
5. In person verification by QR code is really fun and easy too, if led through it nicely by the user interface.

Phew!

[rschulman]

We ought to be keeping eyes on other ways of transferring keys as well, such as keybase or the new key transparency project from Google. If there are existing methods of key verification, we could either use them or learn from them.

[rschulman]

One other option to consider is whether we can create a more user friendly challenge/response system. If the verifying person can ask the person to be verified a question (obviously over an encrypted channel) that only they would know the answer to and that person can respond with a signed response, that level of security is probably good enough for most threat models.

[uhoreg]

Some of my recent thoughts regarding this:

1. QR codes are cool and will make things really easy for people with the right equipment, but we need a baseline verification method for people who can't scan QR codes, and this baseline needs to be as easy as possible. My suggestion would be to leave this issue for tracking improvements to the baseline verification, and create separate issues for QR codes/NFC/keybase/etc.
2. For the baseline, I think we're stuck with "read something out, and have the other person verify what you read", which is basically what we currently have with the base-64-encoded key, but using something easier to read than [a-zA-Z0-9+/]. Currently, we have 43 base-64 digits, so I take it to mean that we have 256 bits to verify.
   1. The "something" that is read out must be able to work with assistive technologies (e.g. screen readers)
   2. There was a suggestion somewhere of using emoji. However, there aren't that many emoji that would be suitable for use (e.g. easily recognizable, easy to distinguish from other emoji, non-controversial, etc.) In fact, I went through the category lists from emojipedia, and I could only pick out less than 100 emoji that I would want to use for this purpose. If we managed to come up with a list of 128 emoji that could be used, then the verification process would involve comparing 37 emoji, which is quite a bit.
   3. I think that the best option is to use a word list. The EFF has published two word lists: a long list (7776 words) and a short list (1296 words). Although the word lists are intended for passphrases, it should be fairly usable for key verification, and can be pared down if some words should be excluded (e.g. if there may be confusion between two words -- although they've already dropped homophones). They seem to have already put a lot of thought into the word lists. If we take 4096 words from the long list (to make math easier), then verifying the full 256 bits would involve comparing 22 words. If we take 1024 words from the short list, then verifying 256 bits would involve comparing 26 words.
      • Alternative word lists are the PGP word list (2*256 words, so verifying 256 bits would involve comparing 32 words), and the list given in RFC1760/RFC2289 (2048 words, so verifying 256 bits would involve comparing 24 words, but some of the words in that list sound similar such as "sung" and "sunk", so may need to be pruned down)
   4. For people who don't speak English, we can provided word lists in different languages (a first cut would be to just translate the English word list, though some words may need to be replaced if there are homophones in the translated language). If two people are trying to communicate, I think it should be safe to assume that they share a common language. This language may not be a user's preferred language (the language that their Riot UI is set to), so the UI should allow switching between languages within the key verification screens. For example, if I was trying to verify keys with someone who spoke French but not English, I would want to be able to use the French word list even though my Riot UI would be set to use English.
   5. We may want to support different paranoia levels for those who don't want to have to verify all 256 bits. For example, something along the lines of "For extremely paranoid, compare these 26 words (256 bits). For moderately paranoid, compare these 16 words (160 bits). For "I just don't want my kids reading my messages", compare these 13 words (128 bits)". (As a point of comparison, PGP fingerprints are 160 bits long)

[end wall of text]