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

201–210 of 316 posts

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

#201

Post by [deleted] »

tlear wrote: post #190
_snsh wrote: post #63

Earlier quoted context omitted.

This is a great article, but as an educational provider it fails to answer one question: Why should I care? The only concerning thing for me is, why would they lie about using AES-256 when none of my users (and I assume most of their users) would care in any way about AES-256 vs. AES-128 in ECB mode. Why would they lie? Even after this, having my users conducting university lessons over something that might be decryp…

Lets say these lessons are a politics seminar discussing whatever PRC finds objectionable, then family of the student back in the old country get their social credit score deducted. Or even better use those recording in the future as compromat as needed.

[deleted]

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

#202

Post by Igelau »

restingrobot wrote: post #75
dpeck wrote: post #70

Earlier quoted context omitted.

the difference is a copy and paste from an older StackOverflow post.

Using code without understanding its implications would fall in the gross incompetence category.

Awfully big talk on a Friday!

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

#203

Post by whoopdedo »

kardos wrote: post #60
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.

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?

Those unchanged pixels won't be transmitted. Only the changed part of the screen needs to be sent to the client. For example, RFB[RFC 6143] would send a 16-byte header with the size and position of a rectangular area of the screen followed by the pixels in that rectangle. Or multiple rectangles can be sent in one update message. But if you consider the case of text being typed, there will be a single rectangle per keystroke(s).

Now I wonder if a sequence of these rectangles, all the same size and in roughly the same area of the screen, would lend to some sort of statistical analysis. At the very least the timestamps of the updates would tell you how fast the operator is typing.

[RFC 6143] https://tools.ietf.org/html/rfc6143

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

#204

Post by kevin_thibedeau »

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

There are lots of embedded processors with hardware support for AES-128 only. I have to fight to keep AES-256 out of the ciphersuite list because of the performance regression. The rest of the world will probably force the issue eventually but the saving grace is that 3DES is still considered secure.

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

#205

Post by sdenton4 »

tptacek wrote: post #162
ghostpepper wrote: post #143

Earlier quoted context omitted.

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?

I don't know audio well enough to answer this, but you can play with it directly; it took about 7 minutes for me to throw a trivial Go program together to AAC-encode a WAV of half a minute of speech; the only repeated 16-byte blocks I got were a couple runs of zeroes. The trick with ECB is that you're relying on 128-bit blocks of plaintext repeating with perfect alignment, and, to do anything useful with it, those re…

For audio, you don't want to send a wav file over the line, as it's incredibly wasteful. Once it's reasonably encoded, you necessarily end up with a lower entropy steam... So should still have some version of "solid blocks of color", especially for silence. (Exact details depend on the codec, though.)

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

#206

Post by johncolanduoni »

kop316 wrote: post #196
johncolanduoni wrote: post #170

Earlier quoted context omitted.

I think you may want to look closer at Shannon’s source coding theorem; The Shannon entropy of the output of a compression algorithm will be higher than the entropy of the source as identifiable patterns are eliminated. Otherwise the theorem would trivially contradict itself.

Shannon's source coding theorn says that the entropy in a compressed information is at most the entropy of the uncompressed information. If you add entropy to a compressed algorithm, you are by definition adding noise to the SNR of a signal.

We’re not talking about a noisy channel here, so I’m not sure where you’re getting the SNR from. I think we’re talking about entropy of different distributions here so let’s cut to a concrete example relevant to your original claim (that compression doesn’t help reduce the impact of repeated blocks in ECB by reducing the rate of repeated blocks).

Suppose we have some string of bytes. When we split it into aligned 16-byte blocks (let’s assume it divides evenly for simplicity), we find that the distribution of these blocks are not evenly distributed. For example, 1% of blocks turn out to be the same, which given the number of symbols in this code is massively out of proportion.

We apply a Huffman code using the 16-byte blocks present in the message as the alphabet and their observed statistics for this particular message (if that aspect bothers you, you can assume we pretend the dictionary to the message). Huffman codes are optimal for per-symbol encoding.

Suppose we re-evaluate the distribution of 16-byte blocks in the compressed data; will this distribution have higher entropy (meaning there will be fewer duplicate blocks to exploit ECB with) or not?

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

#207

Post by johncolanduoni »

kop316 wrote: post #197
johncolanduoni wrote: post #194

Earlier quoted context omitted.

No, their argument is that if you have a higher entropy per byte, there will be more variation in the aligned 16-byte chunks that are relevant for attacking AES-128-ECB. This reduces the probability of the attacker being able to find equal blocks.

And my argument is if I know the video encoding and compression sequence, I wouldn't depend on AES-ECB. I know the patterns that show up. If I am encrypting something, I only want to depend on the strength of the encryption. I don't want to hope that something else ensures that an adversary cannot figure out my ciohertext. That is a very bad idea.

Sure, and nobody was arguing they should have used ECB or that they shouldn’t change it. Only that the ability to exploit this given compressed data is lower than the uncompressed penguin image example.

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

#208

Post by Igelau »

kart23 wrote: post #199
Igelau wrote: post #198

Earlier quoted context omitted.

I don't know how much free time they have over there, but snooping in on courses that a relative outside the country is taking and storing all of them... I mean, if you want to peg someone's social credit score, just stakeout their house and wait for them to spit outside or something. Hell, just make something up and dare them to come argue. Why go to all that effort?

Doesnt go exactly like that. More like: CCTV captures someone going to an area where known rebels or political activists live. (Look up videos on chinas face recognition, its insane.) Police decide to look through the person's zoom meeting transcripts, making a search on certain keywords. They find evidence of rebellious activities, and order further surveillance on the individual or arrest them.

In a surveillance state of the scope you've described, triangulating the zoom transcripts of an international relative's course work back to someone you spotted on CCTV is still hardly worth the extra trouble. At that level of erosion of civil liberties, they can already send the jackboots to break down the door when they make the CCTV match. Don't find anything? You plant something or coerce them into ratting on someone else. Why would you go mining terabytes of data that's mostly boring meetings and calls from grandma?

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

#209

Post by 3xblah »

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.

"We take security seriously and we are proud to exceed industry standards when it comes to your organizations communications."

https://zoom.us/security

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

#210

Post by sseagull »

WalterBright wrote: post #106
WalterBright wrote: post #79

Earlier quoted context omitted.

Much cheaper than trying to put out the fires caused by not using them. Experience costs more because it pays off.

There's a reason airlines don't put a freshly minted, cheap pilot in command of a 747.

I know market cap isn't everything, but just thought I would look it up.

Zoom (ZM) has a market cap of $40.77B (with a forward PE of 327.31...). Delta (DAL) has a market cap of $18.19B, with a forward PE of 3.91.

Like I said, market cap isn't everything, but I find that astonishing.

Post reply on HN