Hacker News Reader

Comment by smokey_circles | Hacker News Reader

I don't understand how the FTC arrived at the conclusion they're not E2E? Or have I missed something?

>Despite promising end-to-end encryption, the FTC said that "Zoom maintained the cryptographic keys that could allow Zoom to access the content of its customers' meetings, and secured its Zoom Meetings, in part, with a lower level of encryption than promised."

Not wonderful but that still, technically, is an E2E encryption scheme. Is it not? Or do they mean one end terminates in Zoom's servers and it's not E2E through the whole pipe, but rather two pipes stitched together?

Agreed it's not as secure as they marketed, but this seems to suggest if you want to offer E2E you need a specific kind of key storage to meet this new precedent. Good in practice, but maybe the FTC are not the right people to placing such a hurdle down?

I'm sure I've missed something though.

View on HN

I'm not sure what you mean by "you need a specific kind of key storage". You don't need any kind of key storage for e2e. You only need to facilitate the key exchange as a server, then push the opaque data both ways. If zoom (the company, not the software client) can get the encryption key, the call is not e2e encrypted.

>If zoom (the company, not the software client) can get the encryption key, the call is not e2e encrypted

Ah, thank you. That was the bit I was missing.

Silly question I know but I couldn't wrap my head around the wording

A lot of the servers are in China. So You have state actors involved.

Our company had stop using zoom for security reasons.

Most videoconferencing systems are not E2E-encrypted. They encrypt the link between each participant and the central server. This makes implementation simpler in a few ways.

A good E2E-encrypted system would involve Zoom never having the keys at all, so "key storage" would be irrelevant.

The issue here is merely that Zoom claimed to be E2E-encrypted when they were not. They could have simply said "encrypted" and there would be no issue.

Wouldn't E2E encryption of a call with 40 participants require each user to have 39 times the upload bandwidth, in order to send 39 video streams encrypted with different keys? And potentially several times the computational cost on the client, in order to downsample video according to the different available download bandwidth of every other participant?

Is there anyone doing group videoconferencing with E2E encryption, for more than a handful of participants?

Typically, the central server does not transcode. Participants simulcast a few bitrates, and the central server forwards to each other participant the sub-stream with the appropriate bitrate for the bandwidth capacity of that participant. This is compatible with E2E encryption, by individually encrypting each sub-stream. Participants can share a session key that is unknown to the central server.

FaceTime supports group calls and claims E2E encryption for them. WhatsApp does too, I believe? I'm not sure how many participants you can have.

>Wouldn't E2E encryption of a call with 40 participants require each user to have 39 times the upload bandwidth, in order to send 39 video streams encrypted with different keys?

I think you use public key cryptography to securely distribute an encryption key for that call. So the host sends 39 messages encrypted with different keys containing a shared key. Then everyone uses the shared key to encrypt/decrypt the call data.

The zoom definition of E2E is that the one end is one user and the other end is the zoom server.

At no point is there encryption directly from one user to anothre.

What kind of hurdle do you see? What you've described isn't e2e encryption, the FTC is absolutely correct.

The FTC not doing something unreasonable here, I would wager you are by implying they're placing undue hardship on a company that peddles bald-faced lies.

Reply on news.ycombinator.com