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

61–70 of 151 posts

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

#61

Post by waterhouse »

est31 wrote: post #45
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?

Actually, WebRTC was designed from the start to be end to end encrypted as well as peer to peer. Even designed in a way that you can't turn off encryption even if you wanted. This choice was done during the early design period of WebRTC which coincided with the Snowden revelations. However, over time people who built WebRTC systems (like jitsi or zoom) realized that end to end encryption makes multi-party chats hard.…

> end to end encryption makes multi-party chats hard. The basic issue is that you don't want to burden end points with sending the video streams to all users. ... The mandatory end to end encryption was circumvented by connecting to a central server.

Dumb question: Can't you choose one video encryption key K, use ten thousand individual secure connections (with different keys) to share K with all the other users, then encrypt your video with K and let central servers mirror it all they like? (Could even have other clients do some mirroring, bittorrent-style.) Regarding downsampling: if the client has only enough CPU and bandwidth to put out one stream, then, yeah, that doesn't work very well, but otherwise you could put out multiple streams (all encrypted with K) of different quality.

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

#62

Post by hiq »

Vinnl wrote: post #14
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-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 and they steal your passphrase by serving some new JS code).

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

#63

Post by snarf21 »

shadowgovt wrote: post #33
diablo1 wrote: post #31

Earlier quoted context omitted.

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

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.

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

#64

Post by sigwinch28 »

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

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

#65

Post by capableweb »

manishsharan wrote: post #35

Love Jitsi but dont try to run this on AWS EC2 -- the network charges quickly add up. I had set Jitsi videobridge for my kid's friends and their friends -- the network charges quickly added up before I shut it down.

Try a host that doesn't charge for bandwidth. Dedicated servers at Hetzner and/or OVH doesn't charge this imaginary fee so you can sleep well and just pay a static sum each month.

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

#66

Post by hiq »

CiPHPerCoder wrote: post #21
Arathorn wrote: post #18

Earlier quoted context omitted.

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

I appreciate the context. It's probably wise to abandon Signal interop. My reasoning here is: Moxie isn't ever going to acquiesce on the points he's stubborn about, and Olm/Megolm could otherwise be a great cryptographic design with or without his approval. > What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ? Confusion between ciphertext on line 85 and ou…

> I appreciate the context. It's probably wise to abandon Signal interop.

> Olm/Megolm could otherwise be a great cryptographic design with or without his approval.

Could you (or Arathorn) expand on why Olm should deviate from the Signal protocol, instead of trying to reproduce it as closely as possible? Which requirements are different?

I understand that the Signal protocol is the state of the art in terms of E2EE for 1:1 conversations (and small groups). I understand how Matrix wants to address big groups and thus need Megolm. Where does this leave Olm?

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

#67

Post by Vinnl »

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…

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

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

#68

Post by lucb1e »

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…

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.

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

#69

Post by Igelau »

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 hard part about e2e is that it only gets you anything if none of the parties involved are being surveilled after decryption. This is easily within the capabilities of any adversary worth worrying about.

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

#70

Post by lucb1e »

sergiotapia wrote: post #19
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.

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?
Post reply on HN