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

31–40 of 151 posts

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

#31

Post by diablo1 »

drivingmenuts wrote: post #13
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.

> out of sight and mind of the user

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.

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

#32

Post by kodablah »

I have a naive question as I'm toying w/ a similar WebRTC project myself. Since all browsers support h264/opus, can I just reasonably ask each client to send 720p to my WebRTC peer which is really a server before I relay it? Then, can't we just use naive e2e encryption with any extra encoding/decoding? Meaning, in my TransformStream, can I just window.subtle.encrypt on the way out and window.subtle.decrypt on the way in? Is it due to the fact that the insertable streams have to remain in their video format? Pardon my ignorance. This naive approach does assume everyone can at least handle the download speeds of the group's video and the upload speed of their own.

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

#33

Post by shadowgovt »

diablo1 wrote: post #31
drivingmenuts wrote: post #13

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

> out of sight and mind of the user 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).

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

#34

Post by Arathorn »

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

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

#36

Post by Arathorn »

pal_9000 wrote: post #26

Jitsi 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?

The challenging bits are:

* How do you handle non-encrypted participants (e.g. people dialling in from the PSTN?)

* Up until this week, you haven't been able to intercept WebRTC streams for doing E2EE if running in-browser. (Zoom however doesn't use WebRTC, so they don't have this excuse).

* Do you have a safe place to store the keys, and manage user identity?

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

#37

Post by georgyo »

pal_9000 wrote: post #26

Jitsi 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 either the server stores your private key, or you have many keys which is much harder to verify.

E2EE is much easier on phones, which is why Signal is so good. The identity is your phone number, and you can only have one key associate with your number. That key never leaves your device. Conceptually easy.

Video conferencing has none of those advantages, and I don't know how you would make it conceptually easy for users without reducing the security.

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

#38

Post by saghul »

shawnz wrote: post #12

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

We’ve kept the entire packet header unencrypted so the effect is more visible. The final implementation will just leave the minimum required bytes (1 or 2) of the header unencrypted.

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

#39

Post by chvid »

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…

This hits the nail on its head.

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.

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

#40

Post by cdolan »

Vinnl wrote: post #11

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

I gave my impressions on 8x8 in a different comment below. It got really long and touched upon some things outside the scope of your question so I made it its own top level comment.
Post reply on HN