Oh please. It's a demo. Moving on.
Proof of concept: end-to-end encryption in Jitsi Meet
51–60 of 151 posts
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#52I love the fact that it's open source, and well documented. I am currently hosting my own instance at https://jitsi.mastodo.ch/ and I plan to offer it as a free alternative to zoom, citrix, etc.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#53Earlier quoted context omitted.
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-readabl…
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 disagreed with "you can't solve the UX", but I definitely agree that it's a hard problem. Looking forward to seeing what they come up with.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#54Earlier quoted context omitted.
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…
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):
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...
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#55Jitsi is on a roll! By the way, Does anyone know the challenging part of e2e in video chats? Thinking out of intuition, it would be keys are exchanged during handshake and binary data is decoded on the clients? I'm just wondering how could Zoom miss it?
I cannot think how you could possibly do the key exchange securely and automatically, if you want to give a link to someone and have it "just work". If all you have is the URL, then the server sees the encryption key. Video conferencing also rarely has users register. So there isn't a way to validate users either. And even if they did register and users didn't care about the extra friction, multiple devices means eit…
I don't know much about the broader context, but to this part:
> If all you have is the URL, then the server sees the encryption key.
Not necessarily. It's possible to put the key after a "#" in the URL, which allows client-side code to use it without sending it to the server. This technique is used at ZeroBin, among other places. (Edit: This is actually done in the video in the OP as well.)
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#56Earlier quoted context omitted.
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.
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).
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#57Earlier quoted context omitted.
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): https://github.com/matrix-org/matrix-doc/blob/master/specifi... https://matrix.org/…
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.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#58Earlier quoted context omitted.
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…
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?
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.
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#59Earlier quoted context omitted.
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/…
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 doi…
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) :)
Re: Proof of concept: end-to-end encryption in Jitsi Meet
#60Jitsi is on a roll! By the way, Does anyone know the challenging part of e2e in video chats? Thinking out of intuition, it would be keys are exchanged during handshake and binary data is decoded on the clients? I'm just wondering how could Zoom miss it?
I cannot think how you could possibly do the key exchange securely and automatically, if you want to give a link to someone and have it "just work". If all you have is the URL, then the server sees the encryption key. Video conferencing also rarely has users register. So there isn't a way to validate users either. And even if they did register and users didn't care about the extra friction, multiple devices means eit…
You could still make the phone a primary device and allow it to perform the key agreement and pass control off with a QR code, but that is complicated and leaves open the question of who is allowed in this conference.
So perhaps you just give up on persistent identity: just have an unencrypted waiting room, the organizer and their delegates can approve people in the waiting room to enter the encrypted conference.