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

81–90 of 151 posts

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

#81

Post by [deleted] »

georgyo wrote: post #37
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 eit…

[deleted]

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

#82

Post by xiphias2 »

Arathorn wrote: post #58
jadbox wrote: post #47

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

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

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

This is just not true. The amount of passive listening is so much more than the amount of MITM, as most middle men don't want people to know that they are listening. It's just too easy to catch them if they do it on a massive scale, as long as just 0.1% of users verify the E2E keys. This way the remaining 99.9% gets a part of the security benefit as well.

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

#83

Post by CodeMichael »

Igelau wrote: post #69
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.

e2e means you don't have to worry about transparent 3rd parties keeping secrets for you. It prevents casual abuses of your privacy and sets the bar for violating it (deserved or not)

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

#84

Post by Arathorn »

josh2600 wrote: post #79
Arathorn wrote: post #58

Earlier quoted context omitted.

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

How do you do key rotation?

From a user perspective, you'd either log out of a device and log back in (thus getting a new device key), or you can hit a big reset button on your cross-signing state if you want to blow away your master key and start over (which isn't so much rotation as revocation, but should be adequate).

https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro... has the details from the implementor's perspective.

See also https://github.com/uhoreg/matrix-doc/blob/cross-signing2/pro...

EDIT: in theory you could also rotate all keys from a client by creating a new master signing key and then re-publishing all your existing cross-signing signatures with the new keys. This sounds like quite a good way to grandfather in untrustworthy attestations though; it might be safer to start over. The current implementation doesn't support this.

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

#85

Post by Arathorn »

xiphias2 wrote: post #82
Arathorn wrote: post #58

Earlier quoted context omitted.

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

,, 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).'' This is just not true. The amount of passive listening is so much more than the amount of MITM, as most middle men don't want people to know that they are listening. It's just too…

I think there's a misunderstanding here - I was sloppily conflating together MITM (a malicious server admin who has created a false device eclipsing a real one, who forwards traffic onto the real one, having reencrypted it) and a "ghost device" (a malicious party who has added a new device to your account which is sniffing your messages).

My point was that to mitigate both attacks, it's vital to verify key identity out of band. I agree MITM is much less likely than passive listening via a ghost device: we haven't seen MITM in the field, but we have seen attackers try to add ghost devices to spy on accounts (by acquiring a login password, adding a new device, and hoping the victim doesn't notice they've sprouted a new E2E device and that nobody verifies devices).

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

#86

Post by slacka »

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…

Off-the-Record (OTR) Messaging for Pidgin[1] provides this and hides the complexity from the user. Sadly, all of my Google Talk, AIM, QQ, and MSN contacts have moved to proprietary platforms like whatsapp, skype, and facebook.

I miss the days of 1 messaging platform for all my work and personal chatting. For a solid decade Gaim/Pidgin handled all of this for me.

[1] https://otr.cypherpunks.ca/

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

#87

Post by exabrial »

As long as I can disable this, good. I need performance over E2EE, much like many others. We face far more threats from poor communication being distant than we do from an threat where someone gets past our VPN, Firewall, breaks TLS encryption, gets into our VPS and private server, and silently participates in our meetings.

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

#88

Post by gonehome »

Arathorn wrote: post #58
jadbox wrote: post #47

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

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

Thanks for writing this up - it's really interesting reading and following the Matrix project and this comment was really easy to understand/gives a lot of context.

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

#90

Post by traspler »

waterhouse wrote: post #61
est31 wrote: post #45

Earlier quoted context omitted.

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, the…

So from what I understood, the clients had no way of accessing an encoded WebRTC video frame before it was sent over the network. Only with the new Insertable Streams is this possible. So they kind of plan to do what you say, encrypt it "manually" on client and let the router mirror it. Sharing the key as you proposed still dictates that you can p2p connect to all participants. Sadly that's not possible in all NAT situations and you would still need a TURN server for the clients to meet, having a again a central point.
Post reply on HN