Thread by @matthew_d_green

Zoom has published some details about their encryption practices. The claims are actually pretty good, though there are a few open questions. blog.zoom.us/wordpress/2020…

The summary is that Zoom claims to do full e2e between Zoom clients, and the exceptions occur only when you allow telephony bridging or cloud recording, etc. That sounds pretty great.

However...

It also seems fairly clear from the way Zoom describes things that the company *does* have control of the encryption keys. So this may be a situation where Zoom can *choose* not to decrypt — less a situation where they *can’t*.

As a friend just said to me: “I have a cheesecake in my fridge I’m choosing not to eat; that doesn’t mean I can’t eat it if I want to.” So this may be an analogous situation. With boring caveats.

So the simple technical caveats:

1. If users don’t have the explicit capability to control whether Zoom’s servers (bridges) get access, then it’s not really e2e.

2. If users can’t tell whether a Zoom server has access, then that’s not really e2e either.

There are also different levels of centralized key management. Apple, for example, uses a centralized server to distribute public encryption keys. This means Apple never has anyone’s secret keys. But they can hypothetically conduct active attacks by substituting public keys.

A different version of centralized key management might actually have clients’ secret keys or session keys. I have no idea from this blog post which one Zoom is using.

Hopefully they’ll clear things up in the future. //

One last comment: nobody is trying to beat up Zoom. I’m sure they’re doing the best they can in a tough situation.

It’s not their fault they became a critical piece of software everyone needs to depend on. But that’s where they are, and they will hopefully rise to the occasion.