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

31–40 of 316 posts

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

#31

Post by rongenre »

phendrenad2 wrote: post #28
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.…

Is compressed audio/video actually high-entropy (in the time domain) though?

Compressed anything is high entropy

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

#32

Post by Skunkleton »

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.

Search for images encrypted with aes-CBC. This is pretty much the definition of rolling your own crypto.

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

#33

Post by rzimmerman »

phendrenad2 wrote: post #28
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.…

Is compressed audio/video actually high-entropy (in the time domain) though?

I'm actually not sure - that's a good point. The whole point of compressing audio for video conferencing is to preserve human speech, so things that produce radically different waveforms but "sound the same" to us might show up as patterns. I guess it's better to avoid the question entirely and use an appropriate stream cipher!

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

#34

Post by dmitrygr »

songshuu wrote: post #9

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." Implication is fine, but it should not be declarative without proof.

The article is quite direct: key directly sent to client in USA directly from a server in china. what is unclear?

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

#35

Post by kaesar14 »

derision wrote: post #24
Leary wrote: post #21

Earlier quoted context omitted.

"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?

Google is many orders of magnitudes larger than Zoom. Zoom has one product, Google has thousands of products, many more complex than Zoom.

Yeah, 28x the engineers for research at Google makes sense -- I'd say the work Google is doing is at least 28x more expansive, complex, etc. 700 engineers is quite a lot for a company of this size!

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

#36

Post by rzimmerman »

kop316 wrote: post #30
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.…

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

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

#38

Post by jldugger »

rongenre wrote: post #31
phendrenad2 wrote: post #28

Earlier quoted context omitted.

Is compressed audio/video actually high-entropy (in the time domain) though?

Compressed anything is high entropy

Depends on the compression. Lossy compression discards a lot of noise vs the signal we care about and would in a sense reduce entropy.

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

#39

Post by rzimmerman »

remarkEon wrote: post #6

Is there any reasonable explanation for why this scheme was designed in this manner?

It's possible some protocol issues prohibit the use of other stream cipher modes like AES-GCM. I can't think of any but maybe:

* Dropped packets/out of order packets. You should be able to include the IV/counter with the packet but maybe the protocol prohibits that.

* Avoiding reusing counters between participants - seems like you could just use the participant ID as part of the counter and avoid this

* Concerns about partial packet loss - shouldn't happen with UDP and GCM would handle this just as well

I'm trying but I can't think of a good reason to do it this way.

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

#40

Post by songshuu »

dmitrygr wrote: post #34
songshuu wrote: post #9

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." Implication is fine, but it should not be declarative without proof.

The article is quite direct: key directly sent to client in USA directly from a server in china. what is unclear?

Have read the whole article myself, I did not see that explicitly stated. Could you provide the quote?
Post reply on HN