[desilentio]

Isn't the whole point of end-to-end encryption -- not to have to trust any third party -- undermined by secret source? If one does not trust Zoom not to snoop on content passing unencrypted through their servers, why should one trust them to provide true end-to-end encryption? And, if one does trust them to provide true end-to-end encryption, why might one not as well trust them not to snoop on unencrypted content?

[lacker]

The point of end-to-end encryption is to prevent a government from being able to access your communications afterwards. Zoom or any other private company is much more able to implement a standard technical solution like end-to-end encryption than to resist legal subpoenas for information they have but would prefer to not have.

[desilentio]

Are you saying that Zoom is recording conversations?

[Spooky23]

Zoom offers a service to record meetings in the cloud, as almost all providers do. So they can intercept, and can probably be compelled to do so by court order.

E2E is something nerds complain about.

[scubbo]

I'll be the first to admit that I am very far from a crypto expert, but - does this implication necessary follow? Couldn't they just be recording and persisting the (encrypted) stream, and then making it available to "someone who has the key"?

[Spooky23]

That might work for a 2 party call. But I was on a call this afternoon with 70 participants — which of the 70 recordings do you want to keep?

It’s a hard problem, which gets much easier and delivers a better UX if you can trust the service provider. Also consider why you trust 70 meeting participants more than Zoom/Microsoft/Google/Verizon?

[superice]

It's not that hard. Instead of generating 70 end-to-end encrypted recordings of your meeting, you just generate 70 end-to-end encrypted packets with a shared symmetric key inside that allow you to decrypt the meeting encrypted with that shared key. You only need one version of the recording because there is only one symmetric key, but you transmit that to each client using their public/private keypair.

[scubbo]

> consider why you trust 70 meeting participants more than Zoom/Microsoft/Google/Verizon?

For the very simple reason that "the people that I choose to communicate with are people that I have chosen to communicate with", whereas the communication medium chosen is "the least-bad available". I am able to take whatever other measures I wish via other channels to verify and built-trust-in the participants, but I cannot do so with the communication medium owner.

[mrstubbs]

The Zoom backend serves as a router for (possibly hundreds) individual encrypted streams of audio and video during a meeting. In order to support a cloud-save feature, they must first decrypt those streams in order to re-encode them into a unified multimedia file. Even if they were to store encrypted versions of all of these individual audio/video streams, how would they ultimately present that back to the user on request? There is no practical or easy way to do this.

[Thorrez]

> Even if they were to store encrypted versions of all of these individual audio/video streams, how would they ultimately present that back to the user on request? There is no practical or easy way to do this.

You would play it similar to how you attend a Zoom meeting. They could probably reuse most of the client code for this feature. But yes, I agree this is likely not the user experience that most users want.

[petertodd]

I think he's saying that Zoom can record conversations. Not that they actually are.

[lacker]

Well, yes, definitely. It isn’t a peer-to-peer architecture, so at some point Zoom is storing files that correspond to your video calls. At some point I’m sure they’re deleted but someone with a subpoena can access them before they are. End-to-end encryption means there is never any window when a government could mandate access.

[desilentio]

I would have thought they were never stored on disk (by Zoom anyway, maybe by the NSA and the Chinese). Wouldn't that require a huge amount of space?

[monocasa]

Where do you think the training data for the background replacement algorithms came from?

[sonicggg]

They are not opening their source code, as far as I know, so who is auditing this supposed end-to-end encryption?

[oscargrouch]

Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data?

The middle-man shares a temporary key where his end-point can decrypt the message at any time, generating a new key to deliver the message to its original destiny.

I mean, i've always understood e2e encryption with centralized points of distributions as whatsapp, having the understanding that they, and they only, could still claim e2e while at the same time being able to decrypt the messages themselves.

So i never trust the claim of full secrecy unless i know its e2e over a real p2p channel without a middle-man working as a broker between the parties (where the broken can generate and distribute the keys)

Its looks like snake oil to me. Of course far from the eyes of north korea, who is barely a treat to anyone, but with all we know about things like PRISM, probably being available to all the north-american agencies.

[nulbyte]

> Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data?

No; this is specifically what end-to-end encryption is designed to prevent. In E2E, the data is encrypted at one end and it is not decrypted until it reaches the other end, because no one in the middle has the decryption key.

[oscargrouch]

The middle-man in this case is a trusted one, the owner of the centralized infrastructure, not like in MITM.

Isnt possible that one peer encrypt, pass it to the central server who have the other key, the central server than encrypts again and share it with the real end making it believe the key he is using actually is the same one generated in the first part of the process?

Its like the OR from tor but with 3 parties instead.

How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?

[Thorrez]

> How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?

From the article:

> Participants will also see the meeting leader’s security code that they can use to verify the secure connection. The host can read this code out loud, and all participants can check that their clients display the same code.

Obviously the vast majority of people won't do this, so the vast majority of people won't be fully protected against active MITMs. But the potential of meeting participants doing this will discourage attackers in many cases.

[zertrin]

Yeah in E2EE key distribution is always the tricky part.

For "good" UX, usually it is based on trust that the peer keys are exchanged with help of the centralised service as middle man but that it does not alter the keys.

For good security, each party should ideally check public key fingerprints with each other party via another mean of communication to ensure that there was no man in the middle. But that's poor UX and might be unpractical for large meetings of participants that do not know each other.

[hunter2_]

I agree. But I suppose it does have a slight benefit that if you trust the individuals at Zoom who implemented the encryption, now you no longer need to also trust the individuals at Zoom who have access to network traffic and/or server-side code but not client application code.

This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.

[rsa25519]

Didn't Zoom hire Keybase to do their encryption?

> This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.

Well, before we had to trust simply that people with networking access were non-malicious. Now, we can simply trust that at least one of [crypto, network] people are non-malicious. That seems like an improvement to me.

[kelnos]

For me, hiring the Keybase team did not increase my trust in Zoom; it sadly lowered my opinion of the Keybase team (which had already taken a hit due to their integration of cryptocurrency into the Keybase platform).