Yes, if the keys are held in servers that they have access to then they would be able to decrypt the traffic and see what is happening. The whole point of e2e encryption is that only the 2 parties have the keys, Zoom are abusing this term and making people believe they are doing e2e

What makes you think they're abusing the term? Did you read their whitepaper?

https://github.com/zoom/zoom-e2e-whitepaper

The whitepaper is fine, it's the comments from Alex Stemos that make me think they are abusing the term.

https://twitter.com/alexstamos/status/1268061792527241216

He did not say they can't monitor calls.

https://twitter.com/alexstamos/status/1268061795572314113

If they can enter the meeting, either they have to get confirmation from the host who would send the keys to the person entering the meeting or they already have the keys and can enter the meeting and decrypt the stream.

Is this before or after their new E2EE plans?

They apparently 'define it differently' to every other company, organization, and infosec professional. This sort of thing used to be called lying, but it's essentially an 'alternative fact' now:

https://www.theverge.com/2020/3/31/21201234/zoom-end-to-end-...

Zoom, however, denies that it’s misleading users. The company told The Intercept, “When we use the phrase ‘End to End’ in our other literature, it is in reference to the connection being encrypted from Zoom end point to Zoom end point,” and that “content is not decrypted as it transfers across the Zoom cloud.”

Whether the paper is any different is sort of irrelevant if they're starting off from a place of bad faith. One time after another this company has 'accidents' like this, while removing CCP distinguished nonpersons from the platform. A sense of skepticism is certainly justified.

If implemented correctly, the server doesn’t get the key. Look up Diffie–Hellman key exchange for more information on how this is possible. This can be verified by auditing the client so you don’t need to trust Zoom.

> The Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack.[1]

Whoever controls key distribution can control the encryption channel; without a way to verify public keys, all bets are always off. You're right that auditing the client is one (if not the only?) way to do this.

[1]: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...

This is true, but they are going to help law enforcement with calls that have bad content in them, the only way this can happen is if they have the ability to decrypt the streams or enter calls silently and get the keys.

Edit: Sorry for coming across a little brash, I'm quite a strong advocate of real encryption and this kind dilution of terms makes my blood boil because terms are being diluted and people have trust in something that betrays them.

What do you mean by auditing the client... Like audit the source code or something that we could do independent of the source code? (serious question)

You can audit the client either through source code or through very painful binary analysis.

It would, and apparently they do, don't want to spread rumors though, so take this with a grain of salt: https://news.ycombinator.com/item?id=23553453

Yes