Matthew Green's article on this is has a thread here: <a href="https://news.ycombinator.com/item?id=22771193" rel="nofollow">https://news.ycombinator.com/item?id=22771193</a><p>The Intercept article on it has a thread here: <a href="https://news.ycombinator.com/item?id=22767807" rel="nofollow">https://news.ycombinator.com/item?id=22767807</a><p>It's probably too much of a stretch to merge all these, because many comments are about specifics of those posts, and the ones that aren't are kind of generic and so maybe not worth merging anyway (<a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20generic%20discussion&sort=byDate&type=comment" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...</a>).
The serverside key handling stuff is bad, but generally known (Zoom has features whose natural implementation require them to keep keys serverside).<p>People are dunking on Zoom for rolling their own crypto and coming up with AES-128-ECB. This is also bad, but people should be aware that it's a lot more complicated than "you can see penguins through it".<p>You can see penguins through an ECB-encrypted bitmap because discrete blocks of the bitmap image repeat, and thus have the same ciphertext, and these correspondences carry obvious meaning in a bitmap. The same is not automatically true of video or audio data with normal codecs. Aaron Toponce points out that sensor noise will likely scramble ECB ciphertexts, for instance.<p>Colm MacCárthaigh makes an even more important point, which is that it's already very trick to reliably encrypt voice tracks, because common encoding and transmission techniques make them susceptible to traffic analysis. So, for instance, you can quickly find papers about exploiting silence suppression to make predictions about speech in an encrypted audio channel. The point here being, cryptanalytic attacks on ECB are unlikely to be anyone's first recourse.<p>Obviously, the 128 bit AES key thing doesn't really have any practical impact.<p>Designers should religiously avoid ECB mode, but the real danger of ECB is in interactive settings, where we as attackers get to <i>induce</i> plaintext patterns, and use chosen boundaries to isolate targeted ciphertext. Bulk video and audio transmission isn't that kind of interactive setting. You still don't want to read people saying that ECB is OK; it's bad.<p>Essentially: it seems like Zoom's cryptography is bad, but not in a way that really matters compared to brochure-level badness of non-end-to-end-encryption.
This is honestly the best “Zoom is bad” summery I’ve seen so far. While I certainly believe some of the Zoom hate is blown out of proportion, this article does a good job explaining to someone who isn't a security expert what the issues are. I've been getting questions about the company from family and friends, and will be forwarding this to them. Well done.
Using AES in ECB mode is clearly a bad choice, but honestly it's not that horrible for high entropy data like compressed audio/video. I'm sure someone could prove me wrong one day, but it seems hard to extract any useful patterns out of compressed audio/video. It does check the box of "uses encryption" for regulatory reasons (while missing the intent). It's pretty egregious considering how easy this is to get right.<p>The 128-bit key is not inherently wrong if they were rotating these out during the stream. That being said, there's no reason not to do it right and use a mode like GCM with a longer key - most hardware supports acceleration for AES-256 these days. It can actually be slower to use a 128-bit key on 64-bit systems.<p>While I respect the decision not to disclose the waiting room vulnerability, it's pretty obvious what's going on given the context. They probably shouldn't have mentioned where the vulnerability is.<p>I'm honestly surprised anyone with technical knowledge thought that Zoom was actually doing end-to-end encryption given how the software works. All of the video transcoding/downconversion is clearly happening on the server. Your client is not sending multiple compressed streams for varying connection bandwidths. That's the main reason a lot of people like Zoom - it actually works well with dozens or hundreds of participants.
"Zoom, a Silicon Valley-based company, appears to own three companies in China through which at least 700 employees are paid to develop Zoom’s software. This arrangement is ostensibly an effort at labor arbitrage: Zoom can avoid paying US wages while selling to US customers, thus increasing their profit margin. However, this arrangement may make Zoom responsive to pressure from Chinese authorities."<p>I'm not here to defend zoom but any and all companies that can do this have and are doing the very same thing to minimize costs. It's not great but it's the expected way of managing a software company in 2020. It would be hard to do business otherwise.<p>Whether it's good or bad that's a question that will need to be reexamined given the current situation.
Given Zoom is blocked in China, what reason is there for the main key server to be there?<p>Even ignoring the appearances, for latency and the fault tolerance reasons, China is the last place you'd want to put it a critical server for an app used in the West.
I really don't think this counts as rolling your own crypto. They just used a weak implementation of existing methods.<p>No more rolling your own crypto than if I were to use DES.
> Zoom’s most recent SEC filing shows that the company (through its Chinese affiliates) employs at least 700 employees in China that work in “research and development.”<p>Wow. What could all of these people possibly be doing? It can't be development and QA; what's going on over there?
>However, this arrangement may make Zoom responsive to pressure from Chinese authorities.<p>Zoom doesn't even have to be responsive to pressure, just a developer has to be. And they live there so yah they'll be understandably responsive.
Seriously, all people who are surprised about this type of news should really understand that most "successful" (as in, popular) tech/.com/SV "startups" these days are like this.<p>If you "waste" time on the real important stuff such as a good design, user security, or the like, you will lose over to a competitor who didn't and therefore was able to spend more time on marketing.<p>If you waste your time on user privacy you will be totally crushed by that competitor whose definition of "privacy" was "how much can I pester this user until he gives me access to his address book so I can spam his friends?".<p>I don't think this is good. I think this is very sad. But it is what it is.<p>I still remember the Whatsapp founders coming into the jabber mailing lists with "please let me configure my server"-type questions, for god's sake.
Why can't people bother to construct a minimally secure encryption system given that there are so many good documents and code examples out there?<p>I don't mean anything with ratcheting, forward secrecy, replay protection, nonce reuse resistance, or any other bells and whistles, just basic competent symmetric encryption without gaping holes or ridiculous bizarre design choices?<p>It's not hard!<p>(1) Generate 12 bytes of random nonce using a good secure random source, prepend to message.<p>(2) Use nonce to initialize AES-GCM.<p>(3) Run it through AES-GCM, append tag.<p>(4) Done.<p>That's not hard and it's secure enough for common use cases.
always wondered why zoom.us url not zoom.com which they both own.<p>it's basically to give the perception it's US company and assumed trustworthy.
Could we fix the title of this post please? There is a GULF of difference between 'transmit keys through servers in China' and the actual text from the article, " We suspect that keys may be distributed through these servers."<p>Implication is fine, but it should not be declarative without proof.
If I were to design a video conference platform my focus would be usability, video quality, speed.<p>Because those are the things that matters to end-users; if it gives up some security because there is a server somewhere that decrypts, converts and reencrypt the traffic then that is a trade-off but so be it if the goal is to create a popular widely used platform.
Zoom deserves a lot of animosity for its <i>privacy</i> issues like sharing data with Facebook.<p>On the other hand I am mystified by all the security hype. Yes I might be able to guess a Zoom meeting ID, just as if I might guess your phone number and prank call you. In a Zoom meeting <i>you can see who is connected</i>. In the old days of conference calls do you remember asking “who’s on the line?”. What are you talking about that requires encryption?<p>If so there are tools for that - signal, etc.
Just out of curiousity I decided to check for a particular representation on the Zoom website. There must be some "magic" in these words because so many tech companies use them.<p>"<i>We take security seriously</i> and we are proud to exceed industry standards when it comes to your organizations communications."<p><a href="https://zoom.us/security" rel="nofollow">https://zoom.us/security</a>
Just a pet-peeve here: I am well aware if the CCP and how they run things in China as well as their hostilities against the west. But sending traffic or anything to or through China in itself is not a security risk. If the data goes through the US and you are european, whatever protocol weakness exists should also worry you because of possible network and server-side adversaries in the US.<p>"China" is a threat not a vulnerability is all I meant, and using it for hype-training seems dishonest.<p>I've had meetings with people in different companies using webex,goto meeting,skype , zoom,teams and hangouts. I found hangouts to be the most worrysome with regards to privacy (not security). A lot of the issues that keep popping up about zoom this week might also apply to the others (looking at you webex!).<p>Zoom became popular because you can see everyone's video all at once. They had a betterr product. Vulnerabilities don't make a product bad, how you handle them does! If anything, I would like someone to show me how the free security audit zoom received by the hype crowd this week does not make it a superior alternative (provided they continue patching it).
The Intercept article about this has a thread here: <a href="https://news.ycombinator.com/item?id=22767807" rel="nofollow">https://news.ycombinator.com/item?id=22767807</a>
On Ubuntu would installing Zoom via Snap be preferable than as a normal package when it comes to security / sandboxing, should the case be that they turn evil?
Is there any validity to the claim from earlier in the week (comments here on HN) that they Have engineers based out of China and it’s essentially tied to the CCP?
Zoom has betrayed us all! Congress must require zoom to explain why they are sending encryption keys to China when all participants are USA citizens. Zoom is betraying USA citizens and their customers. We must pressure USA zoom execs to explain exactly why they are doing this.
Zoom just works great ... just focus on making a better product (aggh Google Hangouts) than hyping up the hysteria by adding China to the mix.<p>It is rather suspicious to see all the articles of late.