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

11–20 of 151 posts

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

#11

Post by Vinnl »

Jitsi has been doing great recently, and it's pretty amazing how many of my now-at-home-friends now reach for Jitsi by default (as opposed to Zoom, which used to be the case) after having been introduced to it just recently. I've never managed to "convert" so many people to something so easily :)

However, I'm wondering if anyone on here has become, or works somewhere that has become, a customer of 8x8 [1], the company behind it [2]? They supposedly support Jitsi primarily to 1) get contributions that also make their product better and 2) to advertise their product. I'm somewhat worried about whether 2 is working, and hence whether Jitsi will continue to receive their support.

(I'm not affiliated or anything btw, just a happy Jitsi user.)

[1] https://www.8x8.com/

[2] https://jitsi.org/user-faq/#heading8

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

#13

Post by drivingmenuts »

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…

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.

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

#14

Post by Vinnl »

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…

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

[1] https://send.firefox.com/

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

#15

Post by jcims »

Tech support question haha. I run Jitsi Meet (the service at meet.jit.si) on an iPad that I bought last year.

After about an hour the audio completely fails. No audio in. No audio out. I can't really tell if it's something with the app or if it's my terrible little dsl router/nat box dropping the audio stream. I don't have this problem on the desktop or laptop clients, just the iPad, so I'm guessing it's the app...but it could be that it works differently on the network.

Anyone see similar?

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

#16

Post by philcrump »

shawnz wrote: post #12

I see a lot of blocky patterns in the encrypted video streams... isn't that indicative of encryption weaknesses?

I think, I haven't looked at their implementation; they'll be an artifact of piping the encrypted/mis-decrypted stream into a video decoder. A lot of video coding techniques use variable-size blocks to describe changes to areas of the image, so it's reasonable that piping pseudo-random data into the decoder would produce some noticeable block shapes.

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

#18

Post by Arathorn »

CiPHPerCoder wrote: post #10

Ah, I they see they're using libolm, as is the Matrix project! I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below). Libolm is encrypting with AES-CBC [1]. In addition to side-stepping e…

Thanks for the feedback. So the reason for these choices of primitives when we wrote libolm was to keep close to libsignalprotocol (or libaxolotl as it was then), to try to keep the door open to interop with Signal at some level.

The primitives can be changed though once there's enough evidence to do so, and Matrix supports pluggable E2EE algorithms as per https://matrix.org/docs/spec/client_server/r0.6.0#messaging-... - so I'm not convinced this is a "massive legacy support and backwards compatibility trap" that we've set for ourselves.

What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ?

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

#19

Post by sergiotapia »

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…

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.

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

#20

Post by walterbell »

Arathorn wrote: post #18
CiPHPerCoder wrote: post #10

Ah, I they see they're using libolm, as is the Matrix project! I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below). Libolm is encrypting with AES-CBC [1]. In addition to side-stepping e…

Thanks for the feedback. So the reason for these choices of primitives when we wrote libolm was to keep close to libsignalprotocol (or libaxolotl as it was then), to try to keep the door open to interop with Signal at some level. The primitives can be changed though once there's enough evidence to do so, and Matrix supports pluggable E2EE algorithms as per https://matrix.org/docs/spec/client_server/r0.6.0#messaging-.…

Are you planning to support IETF MLS, https://datatracker.ietf.org/wg/mls/about/?
Post reply on HN