Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proof of concept: end-to-end encryption in Jitsi Meet

jitsi.org

Post reply on HN
Print view View original

111–120 of 151 posts

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#111

Post by CiPHPerCoder »

tptacek wrote: post #107
CiPHPerCoder wrote: post #104

Earlier quoted context omitted.

It's only weird if you put Signal's specific design decisions from 2013 on a pedestal and declare it perfect and incapable of being improved. (N.b. I don't expect my specific suggestions to be adopted. However, I view complaining without offering solutions to be poor form, so I offered some alongside my complaints.) Of course, any deviation from Signal's design can and should be vetted by the same experts that vetted…

In addition to my previous comments, I also have a thing about reflexively suggesting that people eliminate CBC from their designs. Depending on circumstances, CBC can be a safer choice than CTR (and CTR-derived modes like the AEAD stream ciphers); different failure modes.

You're entitled to your thing. Granted, CBC mode has a better misuse story than CTR, but an extended-nonce ChaPoly AEAD is likely to be safer in most of Signal's installed userbase (n.b. the same userbase Matrix and Jitsi would be targeting in a lot of cases), given the ARM SIMD (AES-NI equivalent) situation.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#112

Post by Vinnl »

hiq wrote: post #71
Vinnl wrote: post #67

Earlier quoted context omitted.

Sure, but that's a different problem than the one about UX for E2E encryption, no?

The post you answered to said: > 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 sti…

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.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#113

Post by Vinnl »

shadowgovt wrote: post #93
Vinnl wrote: post #53

Earlier quoted context omitted.

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.

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.

Ah, I see now! Definitely agree; if it hampers UX, users will switch.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#114

Post by sigwinch28 »

barbs wrote: post #110
sigwinch28 wrote: post #97

Earlier quoted context omitted.

I'm not sure if you are aware of the difference, but you can use Chromium instead of Chrome. I am mainly a Firefox user on NixOS, but for running Chrom{e,ium} I find that Firejail [0] is a good option. For example, to run chromium in "store" mode and point it to the demo jitsi instance: firejail --profile=chromium chromium --app="https://meet.jit.si" In reality, I combine this with `nix-shell` and set it as a shell a…

Or you can download the Electron app here https://github.com/jitsi/jitsi-meet-electron

Didn't realise they had one! Might be more convenient than my shell aliases :)

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#115

Post by danShumway »

hiq wrote: post #62
Vinnl wrote: post #14

Earlier 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…

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 a…

Isn't that an orthogonal concern?

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.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#116

Post by garmaine »

sigwinch28 wrote: post #97
garmaine wrote: post #76

Earlier quoted context omitted.

Really, really sad. I’m not going to run Chrome for this one application.

I'm not sure if you are aware of the difference, but you can use Chromium instead of Chrome. I am mainly a Firefox user on NixOS, but for running Chrom{e,ium} I find that Firejail [0] is a good option. For example, to run chromium in "store" mode and point it to the demo jitsi instance: firejail --profile=chromium chromium --app="https://meet.jit.si" In reality, I combine this with `nix-shell` and set it as a shell a…

I’m not going to run a different browser for one application.

I don’t even install anything derived from Chrome in my computer, and I’m not going to change that policy.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#117

Post by fladd »

Arathorn wrote: post #34
shadowgovt wrote: post #9

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…

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…

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)!

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#118

Post by Arathorn »

fladd wrote: post #117
Arathorn wrote: post #34

Earlier 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…

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...

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#119

Post by sigwinch28 »

garmaine wrote: post #116
sigwinch28 wrote: post #97

Earlier quoted context omitted.

I'm not sure if you are aware of the difference, but you can use Chromium instead of Chrome. I am mainly a Firefox user on NixOS, but for running Chrom{e,ium} I find that Firejail [0] is a good option. For example, to run chromium in "store" mode and point it to the demo jitsi instance: firejail --profile=chromium chromium --app="https://meet.jit.si" In reality, I combine this with `nix-shell` and set it as a shell a…

I’m not going to run a different browser for one application. I don’t even install anything derived from Chrome in my computer, and I’m not going to change that policy.

Fair enough.

Please be aware that aside from E2E demoed here, there is allegedly a Firefox-specific bug regarding WebRTC which degrades performance for all participants in a call: https://community.jitsi.org/t/software-unusable-on-firefox-w...

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#120

Post by crazygringo »

I'm actually really curious as to whether verifiable E2EE is possible in normal business videoconferencing -- if someone here can enlighten me I'd really appreciate it.

It seems clear that there has to be a single key, rather than separate keys for each pair of participants, since in a large meeting we need all video streams running through a server and everyone receiving the same streams, for manageable upload bandwidth. Also, many participants often cannot peer directly due to NAT etc.

But therefore... as long as you're trusting the server with key distribution/management in the first place... don't you necessarily have to simply trust that the server isn't peeking? That by necessity, since anyone else can join the call and get the decryption key from any of the peers... that the server can too, whether by MITM attack, a "fake participant" that joins for a millisecond but doesn't appear in UX, etc.?

That unless you actually have the capability of auditing the server and the code it's running, E2EE doesn't actually give you any concrete guarantees whatsoever? You've just got to trust? Which at the end of the day, is no different from trusting them not to peek at transport encryption?

Of course you can run your own Jitsi server. But if you've already got control over your servers then you might as well just be using transport encryption anyways, since you trust yourself -- right?

(Obviously if you come up with your own keys and send them to participants via a separate channel of communication then it's fine -- but obviously that's not something regular users are ever going to do.)

Would love to know if I'm misunderstanding something here -- if the newfound significance of E2EE in videoconferencing is just due to Zoom falsely advertising it, or if it's actually a realistic goal.

Post reply on HN