Element-web: Ability to perform manual e2e key comparison

[vit9696]

Background

Current version of Riot supports "legacy" mechanism to compare e2e encryption keys. This mechanism behaves requires you to compare public key fingerprints in text form for each device and to press accept if they match. This method is marked as deprecated and is apparently hidden or unavailable in the future versions of Riot.

This type of verification is the only type that suits my needs, and no available alternatives I am aware of provide a suitable replacement mechanism. Just to make it clear, some of these alternatives are currently broken, but even if they are fixed, it will not solve my problem as they have technical implementation issues, while this report covers a design problem.

What do I demand from the verification process?

• The verification step should contain unambiguous 7-bit ASCII text suitable for sending through any communication method e.g. mailing with GPG encryption from a terminal. Emojis and other pictures or unicode symbols simply do not work for obvious reasons, I cannot even recognise some of them, putting aside typing.

• The verification step should not demand other users to verify each other at the same time. It is simple, but there are at least three subproblems with this:

  • Different timezones and the amount of time needed for key verification.
    Keys can be sent with GPG or printed on physical paper. It is unlikely that I could verify the contact key at the same time he sends it to me, as I frequently communicate with "offline" messages in the first place.
  • Amount of devices to verify.
    When my contact and I have multiple devices, accepting each new key requires time, including the time to reach the device (e.g. it could be at home). The need to verify devices simultaneously is time consuming, even if it is one device (thx to cross-signing). In case I am online, this requires my time immediately, and I may be busy. While I am fine to have the keys in my mail, I may not be fine to look for all the devices and spend half an hour verifying emojis.
  • Ability to share public keys.
    For group/work contacts I can send or receive public keys of another person from an already trusted account. This way A can have keys of B and C, which he can then send to D, who trusts A. He will also send D keys to B and C, effectively avoiding any direct verification.

Proposed resolution

Make sure that legacy verification continues to work and rename it to "Manual fingerprint verification" or something similar.

This is personal, but having the approach is critical for my workflow, and I will have to abandon Riot if it disappears. Current legacy mechanism lets me verify the new contact with 4-5 devices very quickly, usually in less than a minute on each device. All the emoji variants require days, so I simply cannot go this way.

[t3chguy]

Current legacy mechanism lets me verify the new contact with 4-5 devices very quickly, usually in less than a minute on each device.

With cross-signing you could just verify them and they verify their own devices though (so their number of devices does not affect how many verifications you have to perform), a manual cross-signing verification could be interesting, though it would be one way and would need to be performed by both parties.

[vit9696]

Like I said, cross-signing indeed reduces the amount of verifications to 1, though I guess it was not clear from this line:

The need to verify devices simultaneously is time consuming, even if it is one device (thx to cross-signing).

It obviously is a requirement to verify keys on both sides no matter how you do that. However, doing this at different times is crucial for a suitable mechanism. Since designing manual cross-signing may take some time, I request legacy verification to be restored as is.

This way we can protect from receiving an update, which will suddenly break the ability to verify the devices the normal way. For people like me such an update (if it happens) will be a critical regression.

[t3chguy]

It obviously is a requirement to verify keys on both sides no matter how you do that.

QR code verification only needs to be done one-way, a nonce is used to do in-band verification in the other direction

[vit9696]

Right, technically it is still two ways, just only one user action is needed. In either case this nuance is not what I need, as a nonce will have a short time limit for security purposes, and here it is what we try to avoid.

[jryans]

Thanks for raising this use case! We'll be making several changes before shipping cross-signing to ensure this is covered:

• Session verification confusing and not working with cross-signing
• If I haven’t set up SSSS, I should enter the bootstrap UX when clicking [Start Verification]
• I should be able to opt out of cross-signing/SSSS altogether
• Send legacy verification request when clicking [Start verification] if other user doesn't have xsigning keys
• Bring back legacy verification by comparing public device keys

I'll also track this issue as part of the cross-signing work as a kind of meta-issue that we can close when all of the above are done.

[lbeltrame]

Another use case for this is for "legacy" sessions. I have about 30, as I started using Synapse and Riot with E2EE since many months ago, which at time required frequent login/logout cycles as E2EE wasn't as robust as today. I can't "verify" those sessions, because they do not exist anymore, so interactive verification can't be used.

[t3chguy]

I can't "verify" those sessions, because they do not exist anymore, so interactive verification can't be used.

Then you should be deleting those devices sessions from your Settings > Security so that others don't have to verify them and for generally keeping your account clean.

[bwindels]

All the linked issues are closed, so closing this as well.