I'm curious about what they call "enhanced AES-GCM encryption". Because to me that smells like "roll your own crypto" kind of deal, where "moar perf" quickly ends up being "moar sidechannels" (whether willingly or not).
In both the "normal" case and in situations where end-to-end encryption is enabled, the audio and visual streams are individually encrypted with AES-GCM-256 using a key derived from a shared per-meeting key. The difference is that in the normal case, the per-meeting key is stable for the entire meeting and is available to Zoom (as is needed for POTS bridge, cloud recordings, etc...). When the meeting is E2EE, the key is generated by the host, distributed to the other attendees, and rotated as the meeting participants change.
Not sure why you're being downvoted, as I'm curious about that as well.
Your parent's description of the protocol makes it seem like the meeting host generates a key and sends it to Zoom so Zoom can send the key to the participants. I skimmed the whitepaper, though, and it seems what actually happens is the clients generate their own public/private keypairs, which allows the clients to negotiate session keys without exposing the keys to Zoom's server.
Of course since the client code is closed source, you just have to trust that it isn't sharing the session keys with Zoom or a third party. That's the same potential flaw as with something like WhatsApp's, Telegram's, or FB Messenger's E2EE mode: the app itself can intentionally break the security of the system, and you probably won't know it.
The default mode is not E2EE. The same key is used by all participants and is distributed by Zoom's servers. In this mode, all features are available, including the ones that require a cloud service (like 1-800 number support).
If a meeting is set to E2EE, then a bunch of features are turned off and the keys come from the host* and are sent to the other attendees enveloped with their public keys. Zoom's infrastructure never sees the keys, only the encrypted content packets that are relayed to all the participants.
Agreed with the parent. Even if the above is true, what's to prevent Zoom from creating a quiet/phantom "extra participant" and never having the client UI tell you about it.
I mean, the entire premise of their service is that you're routing your communications through their super-powered intermediate proxy services. You're using their clients end-to-end and their servers in the middle. They can do whatever they want with any of those
The new and shiny TelegramX client all of my friends are using is only available as closed source binary. Also their encryption is open, that's true, but they implemented their own algorithms with blackjack and hookers and noone is really sure how secure it really is iirc. Additionally, encrypted chats aren't even the default, single-end to single-end and not available on desktop.
I still use telegram because I deem it better than whatsapp, but the security sucks nonetheless.
Zoom's development team is based in China [1]. Could the government there force these devs to "enhance" this encryption with a backdoor or two for "state security" reasons?
Of course they could. Just like they can in Australia. We've already got plans for large tech companies to have "embedded" federal agents in their buildings.
AES-GCM has serious problems with nonce reuse when you have encrypted a lot of data. As I recall, solving that problem was part of the CESAR competition a couple years back.
Not sure how a closed code can satisfy a threat model depending on the encryption details. If you trust the company to implement AES-GCM in secrecy, why not also trust with the "enhanced" part?
If they say they're using regular AES-GCM from a library that's been decently vetted, the main things you have to worry about are
1. intentional backdoors
2. someone using the library improperly (like using the same IV for every encryption)
If they're rolling their own encryption library, you have to worry about
1. intentional backdoors
2. someone using the library improperly
3. the quality of their implementation of crypto primitives
Getting #2 right is definitely doable for a typical programmer who takes a little time to understand the basic dos and donts. IMO #3 is not doable for a typical programmer, and certainly isn't trivial even for people that are experts (at least for a relatively complicated pair of algorithms like AES and GCM). So even though #3 is just one more thing that can go wrong, it's way more likely to be a problem than #2
With all of the previously disclosed security fiascos of Zoom decisions, this would be my concern. Whether it was for debugging purposes later, it just makes something down the road easier, or it was done to satisfy an external request.
Yes, and that makes me sad every time I think about it. Keybase had such potential to change privacy/encryption but just couldn't make it work financially.
The word 'enhanced' in the context of cryptography just means 'modified', and modifications to security-critical algorithms are considered unsafe unless proven safe.
AES-GCM refers to a specific set of trade-offs. How do those trade-offs differ with the changes that Zoom has made?
I clearly read it as enhanced compared to the previous versions, which used to be AES-ECB until earlier this year.
Note how it mentions "How is this different from Zoom’s enhanced GCM encryption?", which means enhanced also applies to the normal Zoom meetings which are encrypted but not E2E, and supports this interpretation.
I think this is probably the intended meaning, but it’s best not to be too generous when it comes to questionable things people say about their security.
It does sound very intriguing to me at least.