element-hq / riot-android

A glossy Matrix collaboration client for Android
Apache License 2.0
1.4k stars 394 forks source link

Fix end-to-end encryption #2714

Open maqp opened 5 years ago

maqp commented 5 years ago

Fix the encoding to base10:

I ran some tests regarding fingerprint read time and discovered that interestingly, flawless use of NATO alphabet makes Riot's fingerprint verification ~0.5s faster as Signal's base10 fingerprint verification. However, very few people are familiar with such schemes, so verification over an authenticated channel is much slower in practice. Just spelling the letters took about 39 seconds, using a lookup-table to reduce errors slows verification down significantly.

Also, in practice it only took 23 seconds to read the Base10 fingerprint in Signal, that's half the time, and since numbers have represented things like prices, number of enemy troops, language has evolved to make numbers distinct from one another, so no lookup table is needed. They are also universal. E.g. AFAIK the Japanese language does not have capital letters so base64 requires communicating the values in foreign alphabet.


Combine the fingerprints:

Also, since Riot isn't combining fingerprints like Signal does, you're going to have to spend 40 seconds of your life listening to your friend playing the employee of a cold war numbers station, and that's assuming they only have one device, 40 seconds extra for every additional device.

It's highly unlikely the authenticated channel is also under MITM by e.g. an advanced AI pretending to be each party. 60 digits is good value: If each party reads 30 digits from the mess, that's still log2(10^30) = 100 bits of security per direction.

Considering the ease of this I think it's weird the ~same amount of time has been spent to add label "In future this process will be more sophisticated". The longer you wait, the more Matrix clients there will be who use Base64 and the harder it will be to reach consensus about switching to usable fingerprints.


Put the user's fingerprint next to contact's fingerprint:

Having to navigate from contact's fingerprints to system settings to view personal fingerprint is horrible: it takes approximately 12 seconds to do that. If you were the unfortunate one who had to do that first, returning from system settings back to fingerprint takes additional ~10 seconds.


End-to-end encryption has useless warnings and is unnecessarily disabled by default

Opportunistic end-to-end encryption is the best the application can do right now, and that best effort should definitely be the default behavior. Normal users get scared when they get warnings like "E2EE is in beta and it might be dangerous" or "E2EE can not be disabled once enabled". There are no situations where the users, knowing the E2EE is potentially flawed decide to not use E2EE because it's safer that way. Flawed E2EE isn't less secure than TLS because E2EE always transits through the TLS. Users who are currently self-censoring themselves because they know to wait until E2EE is out of beta, will also do that when E2EE is on by default, but when it gives a non-blocking warning about being in beta.

In a way, it's good that the non-E2EE messages are advertised as "unencrypted". That way users who desire end-to-end encryption don't place unnecessary trust on TLS and server. However, it might deter users who to less secure applications where there exists misdirection, e.g. Telegram's "Cloud encryption" that claims to protect messages on server. TLS and private server in trustworthy circles is much better against data mining threat model and even incrementally better against state adversaries threat model, than service with centralized servers and TLS.

ChargingBulle commented 5 years ago

Hi. Thanks for the input. As far as I see this these are four different things and maybe you should repost them as a separate issue for every thing. Together with an good issue title this makes existing ideas & tickets much easier to find

ChargingBulle commented 5 years ago

About the last one: IIRC encryption will become enabled by default once the e2e is stable. Also: the riot team is well-aware of the unnecessary popups regarding new e2e devices: IIRC e2e keys of same owner should sign each other. This concept was in some Roadmap. I am unable to locate said road map right now. The last issue (regarding security popup & encrypting by default) is very porbably a duplicate.