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

71–80 of 151 posts

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

#71

Post by hiq »

Vinnl wrote: post #67
hiq wrote: post #62

Earlier quoted context omitted.

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?

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 stick to the current model where you already trust Jitsi. Firefox Send solves the UX problem because it doesn't completely address the encryption key handling problem.

To be fair, I still think Firefox Send is slightly better than traditional file hosting, just not significantly.

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

#72

Post by lucb1e »

Arathorn wrote: post #24
CiPHPerCoder wrote: post #21

Earlier quoted context omitted.

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…

> Moxie isn't ever going to acquiesce on the points he's stubborn about Yup, indeed. https://signal.org/blog/the-ecosystem-is-moving/ was written after I mailed him to ask if they'd consider interop. ( https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom was our overdue response)

His eponymous talk on 36C3 was similarly disappointing, mostly defending stubborn choices. Glad I didn't decide to spend the time watching it in person and got to see another talk by watching this one back instead.

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

#73

Post by tptacek »

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…

If it's HMAC'd, there's no sidestepping of padding oracles needed. Error side channels are a consequence of chosen ciphertext attacks, not of padding. Switching to CTR would not "go a long way" towards shoring up the security of their protocol.

I do not understand your "confused deputy" attack. Can you outline it in more detail?

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

#75

Post by shadowgovt »

lucb1e wrote: post #70
sergiotapia wrote: post #19

Earlier quoted context omitted.

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?

Removing? Hardly. I'm just saying that as a feature, it's not on the critical path to mass-adoption without solving the key-tracking UX.

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

#76

Post by garmaine »

christefano wrote: post #74

Sad to see this is dependent on an extension to WebRTC that’s (currently) Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this will be supported by any other browsers.

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

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

#77

Post by garmaine »

tptacek wrote: post #73
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…

If it's HMAC'd, there's no sidestepping of padding oracles needed. Error side channels are a consequence of chosen ciphertext attacks, not of padding. Switching to CTR would not "go a long way" towards shoring up the security of their protocol. I do not understand your "confused deputy" attack. Can you outline it in more detail?

Is it really HMAC’d? 8 bytes isn’t cryptographic protection. It may be secure, but the standard arguments don’t apply.

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

#78

Post by GordonS »

crznp wrote: post #60
georgyo wrote: post #37

Earlier quoted context omitted.

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…

You could still make the phone a primary device and allow it to perform the key agreement and pass control off with a QR code, but that is complicated and leaves open the question of who is allowed in this conference. So perhaps you just give up on persistent identity: just have an unencrypted waiting room, the organizer and their delegates can approve people in the waiting room to enter the encrypted conference.

Do you mean kind of like how authentication is sometimes handled on input/UI constrained devices (e.g. TVs), where a message could be played to callers, asking them to enter a one-time code at a particular website?

On the face of it, this could work quite well for most people.

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

#79

Post by josh2600 »

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…

How do you do key rotation?

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

#80

Post by garmaine »

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…

Not a dumb question at all. That’s exactly how this would be sensibly designed. Does WebRTC’s built in E2EE encryption not do this?
Post reply on HN