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

221–230 of 316 posts

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

#221

Post by tialaramex »

tptacek wrote: post #175
tialaramex wrote: post #167

Earlier quoted context omitted.

Encouraging companies to lie by just writing it off when they're caught is an under-appreciated problem. If I'm honest and I'm working on a video conferencing platform, a potential customer asks "Do you have End-to-end encryption?". I say honestly "No". The customer goes to Zoom because they lied and said they do. Any outcome where Zoom keeps even _some_ of the resulting customers and money rewards deceit and ensures…

I've read this comment a couple times and am not clear whether or where you see the potential for useful leaks through repeated aligned plaintext blocks to occur, either in VBR AAC or in H264 video. I am spitballing and would welcome specific feedback on this if you have it; if you're speculating, can you force your speculation to the form of a test case we can go implement? We don't have to use Zoom; a reasonable mo…

Informed speculation is all I have.

I will say in passing that it's weird to keep picking VBR AAC in your examples, the document says they used SILK, which would make sense because SILK was designed (by Skype many years ago) for this application. AAC is from a different era (it turns out we were trying to be too clever back then) and targets a different application.

This bothers me because even if ECB was good enough here, which we're both agreed it isn't, encrypted SILK VBR is anyway specifically known to be vulnerable to the same approach they demo'd in "Spot Me if You Can" and similar papers:

https://ieeexplore.ieee.org/document/4531143

Keep in mind that even without any cryptographic work, we know the exact length in bytes (just like in that paper) of every SILK frame on the wire.

As to the cryptography:

I think the first thing I'd do if I was trying to turn this into an attack would be to send gibberish to Zoom's intermediary servers and see if they care (thus function as a potential Oracle).

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

#222

Post by tialaramex »

kevin_thibedeau wrote: post #204
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.

> the saving grace is that 3DES is still considered secure.

Nobody who wants to do AES-256 rather than AES-128 thinks 3DES is "still secure". 3DES is perhaps 112 bits of useful keyspace but it has 64-bit blocks which was already bad news when DES was invented.

TLS 1.3 doesn't have a 3DES option at all. You can do AES 128 or AES 256 (or ChaCha20).

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

#223

Post by kevin_thibedeau »

tialaramex wrote: post #222
kevin_thibedeau wrote: post #204

Earlier quoted context omitted.

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.

> the saving grace is that 3DES is still considered secure. Nobody who wants to do AES-256 rather than AES-128 thinks 3DES is "still secure". 3DES is perhaps 112 bits of useful keyspace but it has 64-bit blocks which was already bad news when DES was invented. TLS 1.3 doesn't have a 3DES option at all. You can do AES 128 or AES 256 (or ChaCha20).

The USG still considers it secure and that will retard forward progress.

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

#224

Post by tptacek »

tialaramex wrote: post #221
tptacek wrote: post #175

Earlier quoted context omitted.

I've read this comment a couple times and am not clear whether or where you see the potential for useful leaks through repeated aligned plaintext blocks to occur, either in VBR AAC or in H264 video. I am spitballing and would welcome specific feedback on this if you have it; if you're speculating, can you force your speculation to the form of a test case we can go implement? We don't have to use Zoom; a reasonable mo…

Informed speculation is all I have. I will say in passing that it's weird to keep picking VBR AAC in your examples, the document says they used SILK, which would make sense because SILK was designed (by Skype many years ago) for this application. AAC is from a different era (it turns out we were trying to be too clever back then) and targets a different application. This bothers me because even if ECB was good enough…

Everything that isn't authenticated (like CTR mode, which is what was supposedly "recommended" here) admits the potential of an oracle attack, so what's interesting to me here is what's distinctively bad about ECB in this setting. And: I'm not saying ECB is OK in this setting. I'm saying "it's not PenguinVision simple" and "what makes it not OK is probably interesting".

You know more about the codec situation here than I do. So, you tell me! What should I be looking at?

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

#225

Post by tptacek »

tedunangst wrote: post #220
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…

Somebody should add an ECB encrypted JPEG to wikipedia.

It will look just like the CBC comparison example, but I assume that's the point you wanted to make.

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

#226

Post by tptacek »

sdenton4 wrote: post #205
tptacek wrote: post #162

Earlier quoted context omitted.

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

I'm not sending a WAV file (or modeling that); I'm AAC-encoding.

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

#227

Post by tptacek »

killjoywashere wrote: post #219
barrkel wrote: post #213

Earlier quoted context omitted.

Lossy compression reduces entropy, I'd expect fewer repeats and more of what looks like random data in any compression worth its salt. Thomas also mentioned AAC, not PCM. I agree on the silence, but it would come up as smaller packets, not repeated packets, IMO. And then we're back to timing analysis of speech.

> Lossy compression reduces entropy, I'd expect fewer repeats and more of what looks like random data in any compression worth its salt. Um, so, just to make sure I understand you, you're implying that lossy compression is not worth its salt? Because you will surely have more repeats in a lower entropy space.

You get essentially no repeats (collisions, more precisely) in the AAC streams I played with. Some block boundary headers; that's it.

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

#228

Post by killjoywashere »

Igelau wrote: post #208
kart23 wrote: post #199

Earlier quoted context omitted.

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

It's all take data collection and they mine it later. 10 years from now they go looking for video from you. And yes, if you don't think people have weird incentives and time on their hands, have a look at the shitshow of US Presidential politics.

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

#229

Post by tptacek »

cwojno wrote: post #212
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…

But it does. It means that they're too inept to know the difference. What else are they claiming that is wrong?

I'm interested in the engineering details, not the message board punditry. If you've got details to contribute --- especially if I'm wrong about something --- let's see 'em.
Post reply on HN