7 ms·

how can you have end-to-end encryption with server side processing in conference calls with 50 participants?

by 0x006A 7y ago

ekimekim 7y ago
You abandon the server-side processing part and have all 50 participants share a single key. The server then acts as a dumb broadcast network. It's definitely not easy, which is probably a big reason no-one in this space is doing it.
- _-___________-_ 7y ago
  You lose a lot of features, too. No calling in from a normal telephone if your Internet connection sucks. Everyone has to share the same stream, so no tailoring res/bitrate/etc to individual participants.
Phlogistique 7y ago
Though it is probably not practical today, there exists a research field for this kind of problems. The keyword is "homomorphic encryption".
michaelt 7y ago
1. Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. 2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second, with unencrypted markers showing where they can be sliced and joined. If you can upload a 1080p stream, chances are you've got the bandwidth to send a 360p stream too! 3. Each client tells the server which other call participants they'd like to see, and the server sends them the appropriate encrypted streams, switching between low and high bandwidth as appropriate.
- sarakayakomzin 7y ago
  a few problems: >Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? How do you plan on doing that without any substantial lag? >2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second you have managed to double your egress for almost no value.
  - XelNika 7y ago
    > you have managed to double your egress Only compared to the current, unencrypted version. For E2E encryption, the alternative, as I see it, is pushing out an encrypted video stream per recipient. He has reduced his egress from O(n) to O(1).
  - michaelt 7y ago
    > how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? By doing whatever Signal and Whatsapp do to support 50-person encrypted group chats. > you have managed to double your egress Not at all. Firstly, the whole point of having two streams is to accommodate viewers with different bandwidth requirements, so the second stream will be a fraction the size of the first. If I'm already uploading HD video at 5 Mbps, and I start also sending an SD stream at 1 Mbps, my egress has risen by only 20%. Secondly, the h264 spec provides for 'Scalable Video Coding' [1] where a high quality stream can have a lower quality 'subset bitstream' allowing a high-quality video to be converted to low quality by selectively dropping packets. So your egress might not rise by even 20%! Although this h264 feature is less widely used, potentially raising engineering costs. [1] https://en.wikipedia.org/wiki/Scalable_Video_Coding https://en.wikipedia.org/wiki/Scalable_Video_Coding
  - marcosdumay 7y ago
    > how are you doing this exactly? A master node negotiates a symmetric key that lasts for the duration of the call. The master is either selected by the server or in round of Paxos, and since everybody has the same key, if he leaves it just needs a new round of negotiation.
tonyztan 7y ago
My problem with this is Zoom's misleading claims. If Zoom can't implement end-to-end encryption, it shouldn't claim that it does.
- imglorp 7y ago
  I think they would claim the terminology is ambiguous. If the connection is encrypted between all clients and the central server, a business person might say that's end-to-end, ie all traffic in flight. The real test is peer-to-peer or not.
  - viraptor 7y ago
    That's not how E2E is defined... anywhere. Also you don't have to be P2P to support E2E.
  - prophesi 7y ago
    I'm afraid of other services catching on to this "semantic loophole". Would changing the terminology to perhaps client-to-client encryption solve this?
  - smileysteve 7y ago
    > If the connection is encrypted between all clients and the central server, a business person might say that's end-to-end, I think that's the problem being described. That is not end-to-end encrypted. It is, however, encrypted. Zoom simply needs to drop the "end-to-end" part.
ComodoHacker 7y ago
You can't, without having every client process all the video and mix all audio. In other words, with current consumer hardware and internet coverage, you can't.

how can you have end-to-end encryption with server side processing in conference calls with 50 participants?

by 0x006A 7y ago

how can you have end-to-end encryption with server side processing in conference calls with 50 participants?

You abandon the server-side processing part and have all 50 participants share a single key. The server then acts as a dumb broadcast network. It's definitely not easy, which is probably a big reason no-one in this space is doing it.

_-___________-_ 7y ago
You lose a lot of features, too. No calling in from a normal telephone if your Internet connection sucks. Everyone has to share the same stream, so no tailoring res/bitrate/etc to individual participants.

Phlogistique 7y ago

Though it is probably not practical today, there exists a research field for this kind of problems. The keyword is "homomorphic encryption".

michaelt 7y ago

1. Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. 2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second, with unencrypted markers showing where they can be sliced and joined. If you can upload a 1080p stream, chances are you've got the bandwidth to send a 360p stream too! 3. Each client tells the server which other call participants they'd like to see, and the server sends them the appropriate encrypted streams, switching between low and high bandwidth as appropriate.

sarakayakomzin 7y ago
a few problems: >Clients negotiate end-to-end encryption session key between themselves the same way as a chat app would. how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? How do you plan on doing that without any substantial lag? >2. Each client sends the server two (or more) encrypted video streams, varying in bandwidth and keyframes per second you have managed to double your egress for almost no value.
- XelNika 7y ago
  > you have managed to double your egress Only compared to the current, unencrypted version. For E2E encryption, the alternative, as I see it, is pushing out an encrypted video stream per recipient. He has reduced his egress from O(n) to O(1).
- michaelt 7y ago
  > how are you doing this exactly? a 50 way diffie-hellman that renegotiates every time a user leaves or joins? By doing whatever Signal and Whatsapp do to support 50-person encrypted group chats. > you have managed to double your egress Not at all. Firstly, the whole point of having two streams is to accommodate viewers with different bandwidth requirements, so the second stream will be a fraction the size of the first. If I'm already uploading HD video at 5 Mbps, and I start also sending an SD stream at 1 Mbps, my egress has risen by only 20%. Secondly, the h264 spec provides for 'Scalable Video Coding' [1] where a high quality stream can have a lower quality 'subset bitstream' allowing a high-quality video to be converted to low quality by selectively dropping packets. So your egress might not rise by even 20%! Although this h264 feature is less widely used, potentially raising engineering costs. [1] https://en.wikipedia.org/wiki/Scalable_Video_Coding https://en.wikipedia.org/wiki/Scalable_Video_Coding
- marcosdumay 7y ago
  > how are you doing this exactly? A master node negotiates a symmetric key that lasts for the duration of the call. The master is either selected by the server or in round of Paxos, and since everybody has the same key, if he leaves it just needs a new round of negotiation.

tonyztan 7y ago

My problem with this is Zoom's misleading claims. If Zoom can't implement end-to-end encryption, it shouldn't claim that it does.

imglorp 7y ago
I think they would claim the terminology is ambiguous. If the connection is encrypted between all clients and the central server, a business person might say that's end-to-end, ie all traffic in flight. The real test is peer-to-peer or not.
- viraptor 7y ago
  That's not how E2E is defined... anywhere. Also you don't have to be P2P to support E2E.
- prophesi 7y ago
  I'm afraid of other services catching on to this "semantic loophole". Would changing the terminology to perhaps client-to-client encryption solve this?
- smileysteve 7y ago
  > If the connection is encrypted between all clients and the central server, a business person might say that's end-to-end, I think that's the problem being described. That is not end-to-end encrypted. It is, however, encrypted. Zoom simply needs to drop the "end-to-end" part.

ComodoHacker 7y ago

You can't, without having every client process all the video and mix all audio. In other words, with current consumer hardware and internet coverage, you can't.