Hacker News Reader

Comment by jadbox | Hacker News Reader

Can you explain a bit about "Matrix's E2EE key management stuff" and how it "letting individual users transparently self-manage their keys"? Is there docs on it?

View on HN

Each end device you use to connect to your Matrix account creates own keys per default, but you can also import/export keys if you want to. Then other parties can enable or disable trust for each key. For browser based clients like riot, I think each session creates another key.

Docs (the first link is most relevant to your question):

https://github.com/matrix-org/matrix-doc/blob/master/specifi...

https://matrix.org/docs/guides/end-to-end-encryption-impleme...

https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/ol...

https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...

I really like the work matrix did. But the UI for having just an e2e encrypted chat with someone you can't physically authenticate keys with on a simple not so important chat is so annoying and confusing. As I understand it they're redesigning it. But as it stands for a normal end user the UI is broken if you ask me.

Personally I liked the flow of knowing a shared secret to a private channel back when people were doing blowfish in IRC was way better than this exponential key exchange thing.

Sure it's not as secure, but at least it's somehow humanly feasible.

Yeah, I wasn't talking about the crappy old UX that you & the grand-parent are referring to, but the redesign which is on the horizon in the coming days (https://news.ycombinator.com/item?id=22856867) :)

So E2EE key management has been a (very) long time coming in Matrix. Firstly: E2EE is pretty useless if you don't verify the identity of keys, as you could be just talking to a MITM (e.g. a malicious server admin could add a 'ghost' device onto your account in order to sniff the messages people are sending you).

Originally (in 2016) we let users verify the devices they're talking to by checking their Curve25519 public keys out of band - e.g. "s5jZ K5a/ 4iAN If7K L0PL XNNG h/4G 901H +dB6 YMB9 1H4". This is obviously completely unusable, and precisely the sort of terrible UX which made the great-grand-parent say "individual users don't want to be arsed to self-manage their encryption keys; You can't solve the UX on that".

Then, we improved things a bit (in Feb 2019) by adding the ability to verify devices by comparing a list of 7 emojis out of band - you calculate a shared secret via ECDH between the devices. This is specced in https://github.com/matrix-org/matrix-doc/issues/1267 and analysed in https://www.uhoreg.ca/blog/20190514-1146. This solved the problem of comparing ugly public keys and made verification actually fun (imagine people yelling 7 emoji at each other across a room, or over VoIP etc, to verify identity), but meant you still had to verify each new device manually, which gets very tedious very quickly.

We have finally fixed this over the last N months, which is what I was talking referring to in the previous post.

Firstly, when you sign into a new device, as part of login you have to verify that device's identity with an existing one (or enter a recovery code/passphrase) - a bit like 2FA. Then, every user who has verified you in the past will automatically trust this new device - you have effectively vouched for its veracity yourself. We call this cross-signing, and it's specced at https://github.com/matrix-org/matrix-doc/pull/1756.

Secondarily, we've added QR-code scan based verification (https://github.com/matrix-org/matrix-doc/pull/1544) - so the actual login process here ends up feeling similar to WhatsApp Web: the user just scans a QR code on their new device, and hey presto: all other users who have ever verified your identity in the past will magically trust your new device.

We're hoping that between QR/emoji-based verification and cross-signing we've ended up with a UX which will let non-technical users transparently manage their keys without really realising it (as it will boil down to "scan this code to log in" and "scan this code to check you're not being intercepted").

The expectation is to turn this on by default in Riot and launch it this Thursday (fingers crossed). And in future, Jitsi could use the same identity/key-management model to ensure that you're actually talking to the people you think you're talking to in their shiny new E2EE conferences.

How do you do key rotation?

From a user perspective, you'd either log out of a device and log back in (thus getting a new device key), or you can hit a big reset button on your cross-signing state if you want to blow away your master key and start over (which isn't so much rotation as revocation, but should be adequate).

https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro... has the details from the implementor's perspective.

EDIT: in theory you could also rotate all keys from a client by creating a new master signing key and then re-publishing all your existing cross-signing signatures with the new keys. This sounds like quite a good way to grandfather in untrustworthy attestations though; it might be safer to start over. The current implementation doesn't support this.

,, E2EE is pretty useless if you don't verify the identity of keys, as you could be just talking to a MITM (e.g. a malicious server admin could add a 'ghost' device onto your account in order to sniff the messages people are sending you).''

This is just not true. The amount of passive listening is so much more than the amount of MITM, as most middle men don't want people to know that they are listening. It's just too easy to catch them if they do it on a massive scale, as long as just 0.1% of users verify the E2E keys. This way the remaining 99.9% gets a part of the security benefit as well.

I think there's a misunderstanding here - I was sloppily conflating together MITM (a malicious server admin who has created a false device eclipsing a real one, who forwards traffic onto the real one, having reencrypted it) and a "ghost device" (a malicious party who has added a new device to your account which is sniffing your messages).

My point was that to mitigate both attacks, it's vital to verify key identity out of band. I agree MITM is much less likely than passive listening via a ghost device: we haven't seen MITM in the field, but we have seen attackers try to add ghost devices to spy on accounts (by acquiring a login password, adding a new device, and hoping the victim doesn't notice they've sprouted a new E2E device and that nobody verifies devices).

Perhaps it would be more illuminating to say that E2EE is mostly pointless if you don't verify keys. Then all you have to do is encrypt on the network links to get the same level of security for a lot of these things that claim E2EE as they have the power to do trivial MITM.

The point is that instead of requiring end users to verify public keys, it's better UX to give them the ability if they want, but not require. I remember an email standard that sent public keys inside the emails, and the replies are encrypted with that public key.

Sure, MITM is possible, but it's easy to detect, at the same time the UX is easy to scale to billions of people.

That's autocrypt. It is awesome and should be default on all email clients. As part of the autocrypt standard MITM is not detectable as that would just provide users with information they could do nothing about. Autocrypt is fine just as long as the users are made to understand that the privacy protection is a lot less than the protection they would get from a PGP key they actually got from someone directly. No UX in the world can overcome that incontrovertible fact.

Thanks for writing this up - it's really interesting reading and following the Matrix project and this comment was really easy to understand/gives a lot of context.

Reply on news.ycombinator.com