It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them.
As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could.
Still, very cool technical demo, even if the odds of it displacing something like Zoom are near nil.
If they hook into Matrix's E2EE key management stuff, then they'll benefit from the huge amount of work we've put into letting individual users transparently self-manage their keys - c.f. https://youtu.be/APVp-20ATLk?t=6355 for a demo from last Wednesday. This stuff is due to ship in Matrix/Riot in the coming week.
That said, agreed that it's a massive and (up to now?) unsolved problem for how to get mainstream users to manage their keys sensibly. Keybase could have gone there, but ended up being poweruser-only. It'll be interesting to see if we've solved it in Riot.
Off-the-Record (OTR) Messaging for Pidgin[1] provides this and hides the complexity from the user. Sadly, all of my Google Talk, AIM, QQ, and MSN contacts have moved to proprietary platforms like whatsapp, skype, and facebook.
I miss the days of 1 messaging platform for all my work and personal chatting. For a solid decade Gaim/Pidgin handled all of this for me.
hm, OTRv3 has some pretty major shortcomings - off the top of my head; it's only for 1:1 chat; both users need to be online at the same time to initiate a session; limited to non-elliptic-curve DH; socialist millionaire's protocol for in-band key exchange (but relies on a secret being preshared out-of-band); etc. It was great back in the day, but Double Ratchet (a la Signal & Olm) has replaced it - just as MLS may replace the Double Ratchet in time.
Shipping next week in Riot "stable" already? Does that mean that also device verification will be functional by then? That would be fantastic (and also pretty impressive, given that it is unfortunately still entirely non-functional in the develop branch right now)!
Yeah, the hope is to ship in stable later this week. Verification should be working in develop as right now, if cross-signing is enabled (although it had a few regressions last week) - if not, please file bugs...
It is not working a all. I cannot verify a single one of my devices. With cross-signing enabled. It used to work just fine, and then one day there was a Riot update that broke everything. The issue seems to be known to you, though. Please see also my comment on the already open issue at https://github.com/vector-im/riot-web/issues/12959#issuecomm...
On Satuday a friend and I running our own synapse homeservers used Riot develop to set up cross signing and validate each other. On Monday we invited more friends who were on matrix.org to join us and ran into no end of trouble. In the end it seems like they ended up with plain old device signing. Was this regression, or a lack of support in matrix.org's homeservers?
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?
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):
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.
,, 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.
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).
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.
I'm not sure if that's such an unsolvable problem. For example, Firefox Send [1] also provides E2E encryption, but that's practically transparent to the user. The key is added as a hash to the URL, which the browser never sends to the server. The user just has to copy the sharing URL (which they do anyway) do obtain and share the key.
Jitsi might have an additional challenge in that their URLs are often human-readable and user-picked, so not everybody might be used to copy-pasting the links, but then they have the advantage of encryption probably being optional. Or they might think of a whole other solution that provides good UX that doesn't require users to manage keys. (Which, again, might be optional anyway.)
In this case you still trust Mozilla and the JS code they serve to your browser every time you visit this URL (in contrast to e.g. mobile apps), so I don't think it solves much: you still trust a third-party.
Of course it's still better than the default, since your data sent at time t_A won't be compromised by an attacker compromising Mozilla's servers at time t_B with t_A < t_B (well, you try to retrieve your data and they steal your passphrase by serving some new JS code).
There's nothing technical to prevent Firefox Send from using a native client instead of a web page. The client could have the same trust model as everything else on your system, while still embedding the key into the final URL or link you share with other users.
It wouldn't even need to be complicated -- a wrapper around libsodium that pushed encrypted data to a couple of REST endpoints would do the job.
> As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could.
I understood that you meant that Firefox Send solves this problem and does not handle users' keys. My point was that the trust model is still the same, so you might as well just stick to the current model where you already trust Jitsi. Firefox Send solves the UX problem because it doesn't completely address the encryption key handling problem.
To be fair, I still think Firefox Send is slightly better than traditional file hosting, just not significantly.
Yeah I guess you're right, in the sense that it's still a web application. Still, I don't think the general approach is limited to that. For example, Jitsi also has an Electron app. I haven't tried that, but I presume that would work in a similar way to e.g. Zoom, i.e. you paste an invitation link in there. That could just include the key, without it being sent to the server, and without it being a significant extra hurdle to the user.
Note that I'm not saying that that's necessarily the best solution; just that I don't believe that
> You can't solve the UX on that
is true, i.e. that there's nothing particularly inherent to the problem that results in there being exactly 0 good solutions to it.
Yeah, it shouldn't be unsolvable; my key thought is that it's actually the hard part of the story now (encryption client-side is pretty well-understood) and is under-solved. Even still, having more options in the world is better than having fewer, so I'm excited about this demo.
I think my choice of words left me open to misinterpretation: the "you... and...." phrasing was meant as synonymous with "If you... then...", not as a categorical claim that I believe the UX is unsolvable.
I don't understand where this problem of distributing encryption keys comes from in the context of this tech demo. Zoom uses "passwords" and people are more than happy to distribute them by email / WhatsApp / shouting from the rooftops.
The important aspect is that the video conferencing provider and server do not know the key.
I also disagree with your opinion that "you can't solve the UX on that".
The tech demo here essentially gives the same UX as Zoom call + passwords, but with actual end-to-end encryption.
There is the notable caveat in this tech demo that client-side scripts can still read the key (we have to assume the javascript that can read the URL hash is friendly).
Really, though, this can be solved: provide a native(ish) app even if it's just an Electron wrapper of the existing static assets and javascript code, register a handler with the OS for `jitsi://`, and use links like `jitsi://server.name/room#e2ekey=foo`, so we only have to trust the code on our machine, not the server.
I think passing in a static key (password) via a url fragment is what their demo is doing already. However, I get the impression the intention is to verify the keys of who's actually in the room, rather than just trusting a static key which will inevitably leak. They're presumably also planning to re-key via a ratchet to avoid a single leaked key compromising the whole conference recording.
Yes, my comment w.r.t. the hash is that it's inherently a bad final implementation because it's visible to the server via malicious Javascript.
I really hope that it can be as simple as "share a password with someone"/"send an invite link to someone" because as the parent effectively said, this would be a complete UX nightmare.
I'm having trouble envisioning how you could possibly put together a solution where the encryption key wouldn't be visible to Javascript, malicious or otherwise. How would that work?
Assuming that the client is essentially a web app then yes, the javascript must be able to read the encryption key.
However, it's not a hard requirement that the server delivers the javascript to us: it could be hosted locally, e.g. a trusted Electron wrapper around a set of HTML/CSS/JS stored on my computer, for some definition of trusted.
This is how a lot of other e2e-encrypted messaging app can be used, e.g. Signal, WhatsApp, Riot.im: a "trusted" set of client code over which the untrusted server has no control.
Things like Matrix use jitsi for video chatting. There is already existing end to end for messages, but the jitsi component wasn't end to end. Now Matrix can use its existing E2E messaging channels to distribute keys for an E2E jitsi session. In fact, group chat keys are distributed via two party E2E chats handled transparently by the clients, so it wouldn't even be a novel concept.
In the end it is all about making something that people will use because it provides what they need in a broad sense covering security, usability, video quality and a lot of other things.
So what you're saying is that all end to end encryption is futile and we might as well get rid of it? Let's not build this in, even opportunistically, for nobody because very few people use it?
Because saying "individual users don't want to be arsed to self-manage their encryption keys" + that service providers could keep your keys but then you might as well not have e2ee in the first place + that the UX is "impossible" to solve, is exactly that.
I'm not saying precisely that (I don't think the UX is impossible to solve; merely hard), but you've just given the kind of argument a product manager would give on prioritizing feature sets for a commercial application: by the logic you've laid out, centralized key management provided by the service provider likely attracts more users and is the feature "we" should implement first.
... which is why we see a lot more people using Zoom than using something else, and we see few solutions available that offer any client-side e2e encryption support at all (and if they offer it, it's almost always in addition to their server-managed key options).
At its most basic, encryption should be a thing that just happens, out of sight and mind of the user. Yes, that leaves vulnerability, but people generally don’t want to have to deal with it. Most of us are more interested in getting work done, rather than fiddling with the tools.
Which can be sometimes dangerous as more and more crypto is designed to be set-and-forget. It leaves the windows open for bad actors to exploit such simplicity and introduce backdoors when no-one was looking. Vigilance in managing keys (and integrity of the cryptosystem) is still required.
You can require something people won't do all you want, and it doesn't get done.
Cryptographic theory breaks down at the UX layer. If you try to improve security by cycling passwords too frequently, users start writing them on sticky notes tacked to their monitors. If you require users to keep their private keys in their own possession, users lose their private keys, get angry when you can't reconstitute those keys for them, and go use a service that can offer that feature.
I think there's a reason the entire ecosystem has moved in the direction of trusted actors who could, in theory, exploit that trust to know everything they can about the signal passing through their trusted zone (with those who trust nobody still operating independently as a fringe minority).
Exactly. The challenge is the balance between security and convenience. The issue is that without full management of keys and building of source that has been signed and then investigated, you have to trust someone. I think this is the issue, if you decide to trust, then you trust. The harder question is who can you actually trust.
you mean, like having people to remember to bring their house keys when they leave so they can get back in? Yes, it's an extra step that has nothing to do with the task I want to complete, but the price I pay is totally fair for the security I get for it.
That's a really decent example, because if you forget your house keys, you aren't forever denied access to your house / your house doesn't collapse into a shower of noise, never to be reconstituted.
If it did, you can pretty much guarantee people would either stop using house keys completely and just leave the key in the lock all the time or would come up with schemes to make it impossible to lose the key (such as locking the key in a tiny box, and then that box is secured with a key that doesn't cause the box to burst into flames if the second key goes missing).
In non-digital life, we make the tradeoff of less-than-perfect security for convenience, backed by the law (i.e. any competent locksmith can break into your house, and the things that keep them from doing it are (a) a general societal understanding that cracking open someone's front door without consent is a really dick move, and (b) if you do it, you're trespassing and can go to jail).
You can use KDFs based on passwords, shared phrases, etc even if they are just a shared secret in a DH exchange. I made a thing a while back (https://myscreen.live/) that did a common-phrase that was in a URL fragment which gives pretty good entropy (granted it's only for encrypting signalling).
You're downvoted but I agree. I'm a software dev and can't be assed about this. Even 2FA is a pain because I switch devices pretty regularly throughout the day. Managing my keys, no I have better things to do. Imagine a normie doing this? No chance.
Even so, the person you're replying to is calling for removing end to end encryption. I'm fine if you don't want to use 2FA or end to end encryption, but can't we let people like myself have it?
As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being MITM on encryption? Especially since if you have their keys you already could.
Still, very cool technical demo, even if the odds of it displacing something like Zoom are near nil.