[gfodor]

So which of the two is it? A shared secret key among all clients, or individual keys per client. If its the latter, which would be smart, this line is a lie:

"...and do not decrypt it at any point before it reaches the receiving clients"

[detaro]

It doesn't make sense to encrypt the traffic differently for the individual users, since you would need to send multiple copies of the stream if the server can't do it (which is also a big downside of all the P2P solutions). It's not smart design for large-scale video chat.

A shared key or different keys per sender (which I don't think adds anything, but I might be missing something) both do not require the server to decrypt/reencrypt, and thus fairly sure that's what they are doing if this is anywhere close to accurate.

[gfodor]

WebRTC SFUs encrypt traffic differently to the individual users. Each outgoing packet needs to be encrypted with the receiver's negotiated keys, is my understanding. If it was a shared key, then presumably that key could be negotiated among the peers using public key exchange, unbeknownst to the server, and then all traffic be e2e encrypted, which it isn't. I have minimal understanding of what protocols Zoom uses out of the box, but if they don't support e2e encryption, it seems to me they need the keys on the servers for a reason, and the only legit reason would be to trans-crypt the packets.

[detaro]

It's a lot easier to implement central key management than a fully e2e system, especially if they do need the key for many meetings anyway on some of their systems.