21–30 of 316 posts
> 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.” Wow. What could all of these people possibly be doing? It can't be development and QA; what's going on over there?
There are 20,000 google engineers working in "research and development", what could all of these people possibly be doing?
Zoom deserves a lot of animosity for its privacy issues like sharing data with Facebook. 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 you can see who is connected . In the old days of conference calls do you remember asking “who’s on the line?”. What are you talking about that…
> 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.” Wow. What could all of these people possibly be doing? It can't be development and QA; what's going on over there?
"Wow. What could all of these people possibly be doing?" There are 20,000 google engineers working in "research and development", what could all of these people possibly be doing?
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.
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.
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’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.” Wow. What could all of these people possibly be doing? It can't be development and QA; what's going on over there?
You do realize development include software engineering, right? 700 people doing programming isn't even remotely surprising. Not to defend them against the recent security fiasco, but innuendos such as this that links "employees working in China" directly with "shady business" makes me at least uncomfortable.
With good management, a team of 50 should be able to provide what Zoom provides.
I really don't think this counts as rolling your own crypto. They just used a weak implementation of existing methods. No more rolling your own crypto than if I were to use DES.
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.…
Earlier quoted context omitted.
You do realize development include software engineering, right? 700 people doing programming isn't even remotely surprising. Not to defend them against the recent security fiasco, but innuendos such as this that links "employees working in China" directly with "shady business" makes me at least uncomfortable.
I didn't read it as suggesting it was "shady business". I read it as an insinuation that the company didn't know what it was doing from the top down, so they didn't hire smartly or manage well; they just threw numbers of people at the problem (and got predictably bad results). With good management, a team of 50 should be able to provide what Zoom provides.
Of course, with this read comes the age old question of "I can build Google/FB with 20 good men, what are they doing?"
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.…
...you're joking right? The Wikipedia example for why ECB is not recommended is literally an image:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
Edit: This applies to compression too. Please refer to Shannon's source coding theorem.