Zoom rolled their own encryption scheme, transmit keys through servers in China • Hacker News Board

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

#51

Post by colanderman » Fri, Apr 03, 2020, 8:21 PM UTC

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…

No comment on the original claim, but that example is encryption applied to an uncompressed image. (Adjacent identical pixels are not typically represented individually when compressed, and thus encryption could not cause the banding patterns seen in those regions of the image if it were compressed prior to encryption.)

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

#52

Post by rzimmerman » Fri, Apr 03, 2020, 8:22 PM UTC

miked85 wrote: post #42

rzimmerman wrote: post #36

Earlier quoted context omitted.

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.

If the encryption scheme is poor, why would the data being compressed or not matter?

AES-ECB isn't necessarily insecure, it's just very easy to misuse (and I agree what the article described is a misuse). I think the argument is that if there are patterns in the input data, the same patterns will show up in the AES-ECB encrypted data, just with different values. Compressed data should be high entropy and hard to predict, so there really shouldn't be structure or patterns to the input data. There's no guarantee that any given compression algorithm provides sufficient randomness, though.

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

#53

Post by stouset » Fri, Apr 03, 2020, 8:25 PM UTC

miked85 wrote: post #42

rzimmerman wrote: post #36

Earlier quoted context omitted.

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.

If the encryption scheme is poor, why would the data being compressed or not matter?

Compression already makes a compressed file roughly indistinguishable from random noise (module access to the decompressor). So the patterns have been removed.

That doesn’t make this good, but it means that one specific example isn’t immediately applicable.

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

#54

Post by rzimmerman » Fri, Apr 03, 2020, 8:26 PM UTC

api wrote: post #41

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? 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? It's not hard! (1) Generate 12 bytes of…

The only thing I can think if is that maybe the protocol Zoom is using precludes prepending the nonce due to the packet format. But surely there's some way to do this with packet counters and user IDs. It's possible this was an intermediate step but I'm really stretching for excuses here.

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

#55

Post by staticassertion » Fri, Apr 03, 2020, 8:27 PM UTC

miked85 wrote: post #42

rzimmerman wrote: post #36

Earlier quoted context omitted.

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.

If the encryption scheme is poor, why would the data being compressed or not matter?

It's harder to extract patterns from high entropy data. I don't think anyone's saying that this is even an OK thing to rely on, at all, just that the nature of the data means that this specific weakness is likely more difficult to take advantage of.

If zoom were transmitting text this would be relatively more serious.

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

#56

Post by jonmartinwest » Fri, Apr 03, 2020, 8:28 PM UTC

remarkEon wrote: post #6

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

Maybe, it makes the "Ministry of State Security of the People's Republic of China" job easier? It would allow them to easily access lots of data.

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

#57

Post by matthewaveryusa » Fri, Apr 03, 2020, 8:28 PM UTC

jasonv wrote: post #3

gen3 wrote: post #2

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.

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

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

#58

Post by [deleted] » Fri, Apr 03, 2020, 8:33 PM UTC

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.

[deleted]

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

#59

Post by snazz » Fri, Apr 03, 2020, 8:34 PM UTC

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

It's been a somewhat noticeable hit, but they're still doing great overall: https://www.google.com/search?q=zm+stock

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

#60

Post by kardos » Fri, Apr 03, 2020, 8:37 PM UTC

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.

Zoom does screen sharing, right? Surely it's not transmitted uncompressed, but it is stationary for a long time and perhaps only small parts changing when they do (eg, switching slides). Is there an ECB-based weakness here?