Hacker News Reader

Comment by aneutron | Hacker News Reader

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).

It does sound very intriguing to me at least.

View on HN

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.

Details: https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom...

If the key is available to Zoom, what's the point?

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

Alex Stamos promised that they have no way to do this. https://web.archive.org/web/20200702200900/https://twitter.c... But the tweet has since been deleted.

The same that prevents Whatsapp from doing the same: trust.

Last time I checked, the entire client codebase of Telegram was open source, and encryption happens on the client.

Of course, all the metadata are visible to Telegram servers, because they handle authorization and discovery. But not the communication content.

What am I missing?

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.

The point is that nobody can easily eavesdrop the meeting, e.g. by copying the network stream.

This of courses does not prevent Zoom from eavesdropping, should law enforcement or a three-letter agency demand that.

With E2EE, Zoom themselves cannot access meeting streams, much like any other third party, including police and NSA.

Just to be clear, in E2E it's not available to Zoom.

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?

[1] https://www.forbes.com/sites/thomasbrewster/2020/04/03/warni...

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.

Yes, but more likely they'd have someone be hired surreptitiously before forcing anything.

What was published not too long ago: https://github.com/zoom/zoom-e2e-whitepaper

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.

Huh, didn't know about this. Can you please give me your source on this ? Should be a fun read.

I'm also very curious about this. AES-GCM satisfies my threat model, "enhanced" does not.

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

>1. intentional backdoors

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.

I do not trust Zoom to get this right

They acquihired keybase a while ago: https://keybase.io/blog/keybase-joins-zoom

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.

Saying something "satisfies your threat model" is pretty foolhardy unless you can read Zoom's source code and implementation of this standard.

It sounds good though

I'm curious about your threat model, only because this doesn't concern me much. Why does this not satisfy yours, I'm afraid I'm a missing something.

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 believe parent infers that 'enhanced' means they modified crypto stack and broke prime directive: "Never roll your own crypto".

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.

Yeah symmetric ciphers are easy (TM), it's the pub key shit that really gets you.

Perhaps enhanced means backdoor-ed.

Reply on news.ycombinator.com