Zoom Rolling Out End-to-End Encryption Offering
blog.zoom.us
blog.zoom.us
It does sound very intriguing to me at least.
AES-GCM refers to a specific set of trade-offs. How do those trade-offs differ with the changes that Zoom has made?
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.
I do not trust Zoom to get this right
Details: https://github.com/zoom/zoom-e2e-whitepaper/blob/master/zoom...
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.
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.
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?
I still use telegram because I deem it better than whatsapp, but the security sucks nonetheless.
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.
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.
[1] https://www.forbes.com/sites/thomasbrewster/2020/04/03/warni...
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.
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.
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?
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.
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.
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.
> 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.
E2E is something nerds complain about.
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.
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?
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.
There were many discussions about it when the "Zoom acquires Keybase" story was on the front page of HN, and the overwhelming sentiment was "yes."
I only use private teams for friends and colleagues but I use the encrypted cloud storage and have lots of git repos.
I wasn’t even aware of public teams but between HN, Twitter, and Discord I don’t need more distraction.
I’d even gladly pay a monthly subscription if it would guarantee the continued existence.
For example, say they have the capability to add a law enforcement key to the list of keys being used to encrypt the channel to allow eavesdropping. I wouldn't call that a backdoor.
> A "backdoor" in computing is a method of bypassing the normal method of authentication. Backdoors are usually inserted into a program or algorithm before it is distributed widely. They are often hidden in part of the design of the program or algorithm. In cryptography specifically, a backdoor would allow an intruder to access the encrypted information without having the correct credentials. The backdoor would either a) allow the intruder to guess the access key based on the context of the message or b) allow the intruder to present a skeleton key that will always grant him access.
Probably the most famous backdoor is the Dual_EC_DRBG which I believe had a weakness in the random number generator that leaked its internal state.
It's not an add-on feature. The ramifications are a completely different way of shuttling the data between endpoints.
> Do I have access to all the features of a regular Zoom meeting?
> Not right now. Enabling this version of Zoom’s E2EE in your meetings disables certain features, including join before host, cloud recording, streaming, live transcription, Breakout Rooms, polling, 1:1 private chat, and meeting reactions.
Some of those features they can bring back, some they might not be able to.
Considering their growth throughout, why would they waste their time implementing it fully and correctly?
A videoconference has to be able to adjust audio and video quality in real time between participants. E2E is a technical barrier to that because the streams are encrypted and harder to work with, it is possible to have E2E but it's hard work and it's resource intensive and it affects reliability.
With E2EE, by definition, the server becomes a dumb relay, and all control moves into the clients. Depending on how E2EE is implemented, you then lose the ability to do some or all of these optimizations.
There are potential workarounds, but each comes with further tradeoffs in turn, in performance, privacy & complexity. That's not to say that it's completely impossible to optimize given E2EE, as you can move many optimizations to each client, or try to have clients expose just enough data for servers to optimize traffic without being able to read the contents (e.g. by splitting the audio & video streams so the server can manage them independently, or having each client upload separate high & low res video of their own video stream). It definitely makes many optimizations dramatically harder though, creates some serious engineering problems, and in practice rules out some optimizations completely.
If it's E2E, the server can't transcode the stream. Realistic options are the sender sending multiple quality streams and the server picking the right one for each receiver, or sending to the server at the quality of the least capable receiver.
There's a concept of bitrate peeling, which would be great for this --- send the highest quality to the server, and the server sends a truncated stream to receivers with poor bandwidth etc. The transport stream would have to be designed so that the truncation points are known to the server, and that the receiver can verify integrity at any chosen truncation point. There's the real problem that this isn't a productionized concept; AFAIK, it's only an expiremental feature in Vorbis, and in that case, quality at a given bitrate is inferior when truncating to that bitrate vs directly encoding at that bitrate.
Client sends a video stream to zoom. Zoom reencodes the video on the fly in different formats and forward to the 10 participants separately.
Participants have different devices and network connectivity, that's how the dirty real world is, so zoom has to do that. It's development work and it's compute intensive but it's a hard requirement to have "good" videoconferencing.
Imagine the same thing with E2E. Client sends a video steam to zoom. Zoom can't do shit with it because it's encrypted, it can't be decoded it can't be reencoded.
If they were to get caught a second time not actually doing E2E, the fallout would be considerably worse than the first time. Especially since the first time they explained it away as an accidental misuse of the term rather than actually trying to pull a fast one--when I do tend to believe.
Either way, I saw no ill effects for them for being caught on either occasion. Zoom is now effectively defacto and I have heard almost nobody refusing to participate in Zoom's services because of their reputation - bar technical forums such as these.
Why would they continue to claim their solution was E2E encrypted after already admitting it's not?
Zoom doesn't care about security. They care about marketing. And customers aren't willing to hold them to task for their BS.
I work for a US defense contractor who uses their infernal software - specifically for export restricted communication no less! Apparently it's very easy to get FedRAMP authorization[0].
Zoom has no reason to care about security because their customers clearly don't care. E2E encryption is just another marketing bullet for their website. There wont be another backlash because everyone who cares already abandoned the platform.
[0] https://marketplace.fedramp.gov/#!/product/zoom-for-governme...
It allows to tick a feature for users, and effectively make harder to spy a conversation if you don't have the key, but that doesn't protect you more if your adversaries are Zoom partners.
So ahead of things like iMessage. About the same as stuff like Whatsapp. Behind things like Signal, Telegram, PGP and the like.
BTW, in practice few people get any benefit out of forward secrecy when used for E2EE messaging as they tend to keep their old messages. Forward secrecy protects against the disclosure of the private key used in such systems. If the attacker can get at your private key then they pretty much for sure get your saved messages.
I talked about this in a series of PGP advocacy articles I recently did:
There are different applications with different solutions.
Honest question, I haven't checked recently.
Pfahahahahahaha.
More seriously, my understanding is that Zoom uses automatic updates, so it can never be secure even in the unlikely event the code that's on your machine this week actually does correctly implement end-to-end encryption. Also, if you're trusting Zoom's servers to give you the encryption keys you have a MitM attack waiting to happen.
"True" E2E encryption doesn't really exist nowadays, at least in the context of being spied on by governments.
Edit: Direct sources don't really exist for obvious reasons. Google it, and there's plenty of articles to help you read between the lines. If you think the govt isn't capable or interested in this, you're being naive.
Edit: Cool, so no sources then. Now it's a mighty big unverified claim based on what the governments might be capable and willing to do.
/s, obviously.
I assume there will be analysis done in the near future by third parties, but even that analysis is not sufficient to protect against a future change or a one-off, court-mandated targeted "switch" to join a un-announced participant to a meeting. The client can be designed to be 'dumb' in this regard.
I also can't trust that the meat I buy in the supermarket actually has in it what it says on the packaging technically speaking unless I slaughter a pig myself. Obviously this isn't a reasonable standard to treat anything by.
When a company goes out of their way to actually sell you E2E encryption and the company actually is fairly known and thus liable I can at the very least assume, for practical purposes that they're not lying to me until proven otherwise because they're risking their entire reputation and probably a very costly legal battle.
Do-it-yourself encryption isn't really realistic because it's not going to be used by ~99% of people.
A market cap of $129 billion (with a B) with annual revenues of 600 million? I feel like this is a crazy gone bad joke, how in the world do they expect to justify that kind of valuation?
Can someone please explain what is their current business plan, and what is their future one? They don't have ad space to generate revenue, they don't have a viable subscription based model, they are not a real B2B product, and they are not going to keep adding users forever. This was once in a lifetime situation where a majority of people were using it, and they still weren't able to capitalize on them in a way of monetizing them.
I feel like they hit their peak without reaping the milestones and achievements along the way (except getting out like a bandit from the stock market).
Am I taking crazy pills or?
For zoom though, I think that they will continue to find ways to extract more revenue per users. I think what will increase in the future is more and more economy will be digital economy, and people will be more willing to pay for and do commerce in a virtual platform. And companies will find ever more commerce opportunities with digital technologies. So I think they will continue to increase their revenue.
Sounds like they got a sudden spike in interest, realized that their customers were angry, admitted the error, bought keybase, and provided what their customers asked them for.
There's an ashtonishing lack of ethics in our industry. A marketing error here, a software bug there [1], a misleading opt-out here [2], a preinstalled malware there [3][4][5], a little violation of privacy of here [6][7], a little lack of respect there [8][9]... It's all happening all at once. We shouldn't be lapping it up.
[1] https://news.ycombinator.com/item?id=24514433
[2] https://news.ycombinator.com/item?id=22531087
[3] https://news.ycombinator.com/item?id=9072424
[4] https://news.ycombinator.com/item?id=17145204
[5] https://news.ycombinator.com/item?id=3298205
[6] https://news.ycombinator.com/item?id=19031055
[7] https://news.ycombinator.com/item?id=23929044
"Always make sure your malicious act can be adequately explained by stupidity if you get caught"
I don't actually care whether the board at Symantec were deliberately turning a blind eye to forbidden practices and then get caught or they were too incompetent to exercise effective oversight and had no idea there was a problem, we can't trust them in either case.
So, no. This perfectly above-board version is not what happened.
I missed that one, thanks for the heads up (found sources @ [1]). Between that and Keybase going into cryptcurrency, that means I uninstalled Keybase and quit using it.
E2E in the sense that security nerds bang their chests about isn't what customers want. Boards of directors of public companies, some attorneys, and some others need it. Almost nobody else does. It means that you don't have cloud recording, can't use POTS phones to connect to the meetings, etc. People with those needs have security controls beyond the software, so they probably need something like Webex, or should be using directly connected room systems. Someone who needs E2E for real reasons aren't doing it from home, for example, as you need to take other measures to protect that meeting content.
That's like saying only car mechanics care about kind of oil that goes into your car. Yeah I mean nerds care because nerds know the difference. This is not something where nerds caring about e2e is at odds with what everyone benefits from. Better security benefits everyone without taking away from the experience.
There's absolutely _nothing_ preventing recording while having end-to-end encryption. It just means the recording happens at one of the ends and can be uploaded. Hell, you could even go as far as storing the encrypted streams, and then decrypt on the device during playback. The keybase people especially have experience with messages that are encrypted so that only a handful of recipients can decrypt it.
The POTS line, I'm less sure about. But I'm still a little iffy about it, since everything is VoIP now. But that may not matter.
If you look at 100 Webex customers, who have access to a high quality E2E capability, you’ll find 3-5 (outside the military) who have ever used it.
You cannot do service-side POTS integration unless you integrate with an on premises PBX and restrict external calls.
I’ve been on teams designing high security collaboration environments. E2E is a need for specific use cases only — the user endpoint is usually a bigger risk. Nobody with that need is considering Zoom!
The others are rolling it out.
Zoom is being used for schools with kids younger than my 7 year old. And probably telehealth too. These should all be e2e encrypted.
Enterprises should be demanding e2e. Especially given the Chinese governments aggressive corporate espionage, I’m shocked that more companies aren’t nervous about having potentially sensitive meetings on Zoom. I know one of my clients expressly forbids their employees from joining Zoom meetings.
Zoom acquires Keybase: https://news.ycombinator.com/item?id=23102430
There are secondary benefits, the acquisition did bring some probably-helpful talent around encryption/infosec, but as you said the rollout seems really fast vs acquisition time for a product that size.
> Zoom’s end-to-end encryption (E2EE) offering will be available as a technical preview, which means we’re proactively soliciting feedback from users for the first 30 days.
It is a commendable step forward, but I wonder what their concerns are about this feature with such a careful rollout schedule. The difference seems only about who generates/manages the key, so unless they were decrypting the packets in transit, they should not be concerned about this.
Existing solutions are out there for folks with high security needs (that are in some cases darn hard to use with bigger non tech groups).
Your POTS phone call to a bridge is not e2e to all the other recipients. The phone system doesn't have support for E2E in many cases. And zoom still has people using phones to connect.
Additionally, they have in the past done mixing and other things on the server for very large broadcast type events. Ie, instead of doing 10 streams to 4,000 people (40,000 streams) you do 10 streams, mix, then one stream to 4,000 people.
However since they claim that it is only the key acquisition that is changing it seems likely that it will work.
While they may have shut down activist accounts in China before that is more likely because they want to maintain their unblocked status in China for business reasons.
It is also possible that Zoom must cooperate with Chinese authorities in providing local user information to maintain their unblocked status, that is true about all Microsoft and Apple products as well and true about several other countries besides China as well. Your information shouldn't be touching servers in China unless you are communicating to or from China.
That said, personally, I don't fully trust anyone's end-to-end claims unless the client is open source OR protocol is open for third-party clients.
What does it matter where they are based if their operations in the US are beholden to Chinese government coercion?
B. By not being based in China, they can publicly say something about IF it it happens to be the case otherwise, and also have the choice to exit China if they wish. If they were based in China they may be forced to keep quiet.
(That said, there is also US government coercion, so it's about which evil you think is worse, I guess. I'd honestly rather they were based in Sweden or some other place.)
[Significant Country X] intelligence activities are typically not limited to people who are physically in [Significant Country X].
It's the same issue with WhatsApp. I hear rumors that law enforcement can access WhatsApp messages so i guess there must be a backdoor like this.
So, it disables all the parts of video conferencing that make it a somewhat suitable stand-in for in-person meetings?