Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zoom rolled their own encryption scheme, transmit keys through servers in China

citizenlab.ca

Post reply on HN
Print view View original

141–150 of 316 posts

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#141

Post by _snsh »

gerdesj wrote: post #121
_snsh wrote: post #103

Earlier quoted context omitted.

As I alluded to in another post I am from Germany and certain people I work with actually went through the "... they came for me" phase. Your point does not stand on its own.

I (en_GB) lived in that weird place called West Germany for about 10 years on and off back in the 70s and 80s. We have many friends (Hi Wurms, int al) who also have family, friends and acquaintances that lived through those days directly, shall we say, and of course my own family members who did from another side and perspective. You may want to take another look at my username and make of that what you will. My poin…

I'm not going to play "guess what my username means" with you, sorry. I'm also not going to play "who knows more people that lived through the 3rd reich" with you.

Me administering a Zoom account for my fellow employees and my students does not erode anybodies right. For me it is a choice between a GDPR compliant vendor and a vendor that does not care about the GDPR. Personally I have had good experiences with the GDPR (Facebook finally having to delete my account even though I would not verify it with a personal ID and cell phone number after I went through the irish data protection authority) and Zoom claims to be GDPR compliant.

So, frankly I'm not sure what you are talking about. It seems like you are going for a slippery slope argument I don't agree with.

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#142

Post by ouid »

rzimmerman wrote: post #25

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

communications on the platform aren't encrypted at all. That's what the article says.

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#143

Post by ghostpepper »

tptacek wrote: post #129

The serverside key handling stuff is bad, but generally known (Zoom has features whose natural implementation require them to keep keys serverside). 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". You can see penguins through an ECB-encrypted bitmap because disc…

As a total novice to crypto stuff, is there any way that someone with access to unencrypted audio/video from the sensor could work out some sort of "baseline" and then factor it into their cryptanalysis of encrypted content produced from the characterized sensor?

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#144

Post by ouid »

NikolaeVarius wrote: post #11

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.

Well, except for the part of the article where it is made clear that they don't implement any sort of encryption at all.

Zoom is an interface for secretly sending a message to the Chinese government, and then hoping that they secretly relay that message to the person on the other end of your call.

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#145

Post by mbesto »

matthewaveryusa wrote: post #57
jasonv wrote: post #3

Earlier quoted context omitted.

I think of it as a warning to future companies who take these kind of liberties...

The warning being that it doesn't matter because it doesn't affect their share price right? So far I haven't seen any tangible damage to them when it comes to $$.

Share price aside...it's the most reliable video conferencing app while others are crumbling to infrastructure pressure (UberConf, GotoMeeting, etc). Their downloads are through the roof right now:

https://www.msn.com/en-us/news/technology/zoom-tops-weekly-d...

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#146

Post by philwelch »

_snsh wrote: post #96
basch wrote: post #65

Earlier quoted context omitted.

Because a company doing an RFP with a checklist of features is going to rank them against their competitors, and it would look bad in the spreadsheet.

I assume this is your answer to "why would they lie?". It does not answer the question to why should an educational provider care though. And assuming I'll consider switching to webex the response to encryption in webex is this: https://www.webex.com/content/dam/Webex/eopi/Americas/USA/en... Which 404's and basically represents my experience with Cisco: "We don't give a shit about you, you already payed us.". Frankly…

In the general case, it’s bad practice to do business with liars. That’s one reason why an educational institution would care.

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#147

Post by sudosysgen »

tptacek wrote: post #129

The serverside key handling stuff is bad, but generally known (Zoom has features whose natural implementation require them to keep keys serverside). 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". You can see penguins through an ECB-encrypted bitmap because disc…

Sensor noise does not translate nearly as well as one might think in compressed videos. And there are likely repeating data blocks big enough to analyze.

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#148

Post by stubish »

tptacek wrote: post #129

The serverside key handling stuff is bad, but generally known (Zoom has features whose natural implementation require them to keep keys serverside). 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". You can see penguins through an ECB-encrypted bitmap because disc…

Screen sharing a presentation is problematic; lots of discrete blocks of bitmap image being repeated.

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#149

Post by daffy »

nerdkid93 wrote: post #118
daffy wrote: post #116

Is it possible to use Zoom on Linux from an ordinary user without sudo rights?

Use or install? I can run Zoom post installation without sudo.

Use. The only way I'm willing to use it is from a dedicated user that has access to nothing else. I don't want it installed in the system.

Re: Zoom rolled their own encryption scheme, transmit keys through servers in China

#150

Post by sudosysgen »

rzimmerman wrote: post #36
kop316 wrote: post #30

Earlier quoted context omitted.

> 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. ...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_operat…

It's definitely a terrible choice for uncompressed images or video. I'm arguing it probably isn't that bad for highly compressed video. That being said, if you're encrypting any data stream you should use an appropriate stream cipher.

You're forgetting about the technical intricacies of compressed video. Compressed video is a mix of high and low entropy content, with a predictable time pattern to this. For example, one can easily use traffic analysis to find B-Frames, and run analysis on that. Bam, you get very low entropy due to the stationary nature of video conference.
Post reply on HN