Hacker News Reader

Comment by secalex | Hacker News Reader

In both the "normal" case and in situations where end-to-end encryption is enabled, the audio and visual streams are individually encrypted with AES-GCM-256 using a key derived from a shared per-meeting key. The difference is that in the normal case, the per-meeting key is stable for the entire meeting and is available to Zoom (as is needed for POTS bridge, cloud recordings, etc...). When the meeting is E2EE, the key is generated by the host, distributed to the other attendees, and rotated as the meeting participants change.

Details: https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom...

View on HN

If the key is available to Zoom, what's the point?

Not sure why you're being downvoted, as I'm curious about that as well.

Your parent's description of the protocol makes it seem like the meeting host generates a key and sends it to Zoom so Zoom can send the key to the participants. I skimmed the whitepaper, though, and it seems what actually happens is the clients generate their own public/private keypairs, which allows the clients to negotiate session keys without exposing the keys to Zoom's server.

Of course since the client code is closed source, you just have to trust that it isn't sharing the session keys with Zoom or a third party. That's the same potential flaw as with something like WhatsApp's, Telegram's, or FB Messenger's E2EE mode: the app itself can intentionally break the security of the system, and you probably won't know it.

The default mode is not E2EE. The same key is used by all participants and is distributed by Zoom's servers. In this mode, all features are available, including the ones that require a cloud service (like 1-800 number support).

If a meeting is set to E2EE, then a bunch of features are turned off and the keys come from the host* and are sent to the other attendees enveloped with their public keys. Zoom's infrastructure never sees the keys, only the encrypted content packets that are relayed to all the participants.

Agreed with the parent. Even if the above is true, what's to prevent Zoom from creating a quiet/phantom "extra participant" and never having the client UI tell you about it.

I mean, the entire premise of their service is that you're routing your communications through their super-powered intermediate proxy services. You're using their clients end-to-end and their servers in the middle. They can do whatever they want with any of those

Alex Stamos promised that they have no way to do this. https://web.archive.org/web/20200702200900/https://twitter.c... But the tweet has since been deleted.

The same that prevents Whatsapp from doing the same: trust.

Last time I checked, the entire client codebase of Telegram was open source, and encryption happens on the client.

Of course, all the metadata are visible to Telegram servers, because they handle authorization and discovery. But not the communication content.

What am I missing?

The new and shiny TelegramX client all of my friends are using is only available as closed source binary. Also their encryption is open, that's true, but they implemented their own algorithms with blackjack and hookers and noone is really sure how secure it really is iirc. Additionally, encrypted chats aren't even the default, single-end to single-end and not available on desktop.

I still use telegram because I deem it better than whatsapp, but the security sucks nonetheless.

The point is that nobody can easily eavesdrop the meeting, e.g. by copying the network stream.

This of courses does not prevent Zoom from eavesdropping, should law enforcement or a three-letter agency demand that.

With E2EE, Zoom themselves cannot access meeting streams, much like any other third party, including police and NSA.

Just to be clear, in E2E it's not available to Zoom.

Reply on news.ycombinator.com