4 ms·

The problem with Zoom isn't, that it doesn't have end-to-end encryption. If you consider the problem, it is extremely difficult to solve, as in contrast to a 1:

by _ph_ 7y ago

The problem with Zoom isn't, that it doesn't have end-to-end encryption. If you consider the problem, it is extremely difficult to solve, as in contrast to a 1:1 video call, the server somehow has to to multiplex the streams and thus at least some access to them. With a trustworthy provider, this isn't a big issue. A trustworthy provider will have a clear policy which ensures that only the multiplexer has access to the unencrypted data. After all, you are running a proprietary client from that provider, and each client of course has access to all unencrypted data. The problem is, that the actions of Zoom doesn't make them look like a trustworthy provider. They lied about the end-to-end encryption. What they should have done instead is to be transparent on how unencrypted data is used on their servers and what their protocols are to prevent unauthorized access to that data. Which is especially important in a business context, because the business users themselves have confidentiality agreements, they need to guarantee and using an external provider for confidential data required that provider passing the neccessary scrutiny. And of course, the huge pile of security issues coming up with their client, the web server, the mac installer, the script host, give any reason to believe that they either don't know what they are doing or completely reckless at least. And the term "reckless" doesn't fit in a conversation about security :).

diebeforei485 7y ago
FaceTime seems to do it well enough. It's limited to ~30 people per call though.
- _ph_ 7y ago
  The problem is the required bandwidth, if you send all streams to all participients. If you do that, you can do end-to-end encryption, but you have to send all streams at the maximum resolution you want to support. If the server handles the mixing, each client only needs to be send one full-resolution stream.
mdavidn 7y ago
No. "End-to-end encryption" does not protect metadata necessary to route the data over a network, just the contents of the communication. The clients could negotiate keys to protect the contents of a meeting end-to-end. In other words, Zoom servers could deduce who was speaking, when they spoke, and for how long, but not what they said. Your internet service provider can deduce the same about your HTTPS connections.
- deleted 7y ago
  [deleted]
- IshKebab 7y ago
  > The clients could negotiate keys to protect the contents of a meeting end-to-end. Not really because Zoom makes fairly extensive use of the decrypted video streams on their servers, e.g. to detect who is talking, pause video for people with slow connections, etc. You could maybe do it for meetings with a few people in, but good luck doing it for meetings with 100 people. Hell the cryptography of group end-to-end encryption hasn't really been worked out yet. WhatsApp doesn't do it and that's just for text. I'm pretty sure Signal doesn't either. There's really nothing bad with not having end-to-end encryption for group video conferencing apps. The shitty thing is that they pretended that they did.
  - dwaite 7y ago
    > Not really because Zoom makes fairly extensive use of the decrypted video streams on their servers, e.g. to detect who is talking, pause video for people with slow connections, etc. You could maybe do it for meetings with a few people in, but good luck doing it for meetings with 100 people. You encrypt audio and video streams separately. If your connection is slow you stop grabbing the video stream. Detecting who is talking is a local function because you are receiving audio packets from them. Encryption doesn't have to change the amount of data sent. > Hell the cryptography of group end-to-end encryption hasn't really been worked out yet. WhatsApp doesn't do it and that's just for text. I'm pretty sure Signal doesn't either. Two ways: 1. Your password does not need to be shared with Zoom for entry into the meeting room. That password and the meeting room number are converted into a symmetric encryption key, so everyone who is able to join the meeting successfully has the same group shared secret for both sending and receiving video and audio. 2. You have an invitation system where the host of the meeting approves people. This approval causes the symmetric key of the meeting to be shared with the person seeking approval, encrypted to their public key. People who can supply a proof of possession of the password or whose public keys were associated with the meeting get invited without requiring confirmation by the host, although the participants in the room becomes a log of who was able to view the meeting. These get harder if you want to say have a periodic key rotation while a meeting is going, for sure. They also get harder if you try to encrypt routing metadata or disguise that the traffic is audio/video in general. The real thing that kills E2E for a corporate product like Zoom are the phone dial-ins. Hardly a point for all that security if you have one person calling in having the now unencrypted voice traffic bounced all over the place. > There's really nothing bad with not having end-to-end encryption for group video conferencing apps. The shitty thing is that they pretended that they did. 100% agreed within Zoom's market because of integration of external services like dial-in/dial-out voice.
fulafel 7y ago
The server does not have to decrypt or process the video, it can just send the same encrypted video to other clients (or you can use p2p communication without a server involved). There may be advantages to processing video at the server, but it's definitely not a hard requirement.
- _ph_ 7y ago
  The problem is, that then you have to send all video streams to all client, that doesn't scale very well.
  - fulafel 7y ago
    The clients could control which video streams they want to subscribe to without the server decrypting them. If you want to support thumbnail/fullscreen versions of streams, the clients could just send along two streams or use a codec that supports this kind, like h.264 SVC.
    - _ph_ 7y ago
      Yes, with effective 2 streams per client, the client could tell the server to send max. 1 full resolution stream and any number of low res streams. If you want full encryption, they have to be send as separate streams from each client. Also, the encryption would need to be negotiated between each pair of participants separately, that is doable, but scales with the square of all participants. So yes, full end-to-end encryption is possible, but quite an effort. But as I wrote before, just having encrypted connections to the server should be fine, if the server provider is trustworthy.
      - fulafel 7y ago
        Now we've moved into the territory of what's easier to implement, that's a different discussion and involves also the lack of implementation complexity at the server end. There is no problem doing key exchanges between all the participants as long as the number of participants isn't too huge. Everyone just needs to kex with everyone else, so from the POV of a single participant the effort scales linearly with number of participants, even though the work collectively done by everyone is squared.
_6fmb 7y ago
Zoom is sufficiently end-to-end encrypted for me. https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-encryption-for-meetings-webinars/ https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-...
Seirdy 7y ago
Matrix/Riot, Jitsi, and Signal seem to have handled E2EE voice/video pretty well while being FOSS (the first of which is a free/open protocol as well as a client).

by _ph_ 7y ago

diebeforei485 7y ago

FaceTime seems to do it well enough. It's limited to ~30 people per call though.

_ph_ 7y ago
The problem is the required bandwidth, if you send all streams to all participients. If you do that, you can do end-to-end encryption, but you have to send all streams at the maximum resolution you want to support. If the server handles the mixing, each client only needs to be send one full-resolution stream.

mdavidn 7y ago

No. "End-to-end encryption" does not protect metadata necessary to route the data over a network, just the contents of the communication. The clients could negotiate keys to protect the contents of a meeting end-to-end. In other words, Zoom servers could deduce who was speaking, when they spoke, and for how long, but not what they said. Your internet service provider can deduce the same about your HTTPS connections.

deleted 7y ago
[deleted]
IshKebab 7y ago
> The clients could negotiate keys to protect the contents of a meeting end-to-end. Not really because Zoom makes fairly extensive use of the decrypted video streams on their servers, e.g. to detect who is talking, pause video for people with slow connections, etc. You could maybe do it for meetings with a few people in, but good luck doing it for meetings with 100 people. Hell the cryptography of group end-to-end encryption hasn't really been worked out yet. WhatsApp doesn't do it and that's just for text. I'm pretty sure Signal doesn't either. There's really nothing bad with not having end-to-end encryption for group video conferencing apps. The shitty thing is that they pretended that they did.
- dwaite 7y ago
  > Not really because Zoom makes fairly extensive use of the decrypted video streams on their servers, e.g. to detect who is talking, pause video for people with slow connections, etc. You could maybe do it for meetings with a few people in, but good luck doing it for meetings with 100 people. You encrypt audio and video streams separately. If your connection is slow you stop grabbing the video stream. Detecting who is talking is a local function because you are receiving audio packets from them. Encryption doesn't have to change the amount of data sent. > Hell the cryptography of group end-to-end encryption hasn't really been worked out yet. WhatsApp doesn't do it and that's just for text. I'm pretty sure Signal doesn't either. Two ways: 1. Your password does not need to be shared with Zoom for entry into the meeting room. That password and the meeting room number are converted into a symmetric encryption key, so everyone who is able to join the meeting successfully has the same group shared secret for both sending and receiving video and audio. 2. You have an invitation system where the host of the meeting approves people. This approval causes the symmetric key of the meeting to be shared with the person seeking approval, encrypted to their public key. People who can supply a proof of possession of the password or whose public keys were associated with the meeting get invited without requiring confirmation by the host, although the participants in the room becomes a log of who was able to view the meeting. These get harder if you want to say have a periodic key rotation while a meeting is going, for sure. They also get harder if you try to encrypt routing metadata or disguise that the traffic is audio/video in general. The real thing that kills E2E for a corporate product like Zoom are the phone dial-ins. Hardly a point for all that security if you have one person calling in having the now unencrypted voice traffic bounced all over the place. > There's really nothing bad with not having end-to-end encryption for group video conferencing apps. The shitty thing is that they pretended that they did. 100% agreed within Zoom's market because of integration of external services like dial-in/dial-out voice.

fulafel 7y ago

The server does not have to decrypt or process the video, it can just send the same encrypted video to other clients (or you can use p2p communication without a server involved). There may be advantages to processing video at the server, but it's definitely not a hard requirement.

_ph_ 7y ago
The problem is, that then you have to send all video streams to all client, that doesn't scale very well.
- fulafel 7y ago
  The clients could control which video streams they want to subscribe to without the server decrypting them. If you want to support thumbnail/fullscreen versions of streams, the clients could just send along two streams or use a codec that supports this kind, like h.264 SVC.
  - _ph_ 7y ago
    Yes, with effective 2 streams per client, the client could tell the server to send max. 1 full resolution stream and any number of low res streams. If you want full encryption, they have to be send as separate streams from each client. Also, the encryption would need to be negotiated between each pair of participants separately, that is doable, but scales with the square of all participants. So yes, full end-to-end encryption is possible, but quite an effort. But as I wrote before, just having encrypted connections to the server should be fine, if the server provider is trustworthy.
    - fulafel 7y ago
      Now we've moved into the territory of what's easier to implement, that's a different discussion and involves also the lack of implementation complexity at the server end. There is no problem doing key exchanges between all the participants as long as the number of participants isn't too huge. Everyone just needs to kex with everyone else, so from the POV of a single participant the effort scales linearly with number of participants, even though the work collectively done by everyone is squared.

_6fmb 7y ago

Zoom is sufficiently end-to-end encrypted for me. https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-encryption-for-meetings-webinars/ https://blog.zoom.us/wordpress/2020/04/01/facts-around-zoom-...

Seirdy 7y ago

Matrix/Riot, Jitsi, and Signal seem to have handled E2EE voice/video pretty well while being FOSS (the first of which is a free/open protocol as well as a client).