Live data from Hacker News

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

citizenlab.ca

281–290 of 316 posts

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

#281
post #267

Earlier quoted context omitted.

like the Penguin, would make the point viscerally Isn't an important part of the argument that the point the penguin 'makes viscerally' is actually an extremely narrow, relatively uninteresting one? It tells you something like 'certain types of synthetic images represented entirely uncompressed in the spatial domain are obviously super leaky when ECB-mode encrypted'. Which, you know, neat but nobody does that. It see…

Firstly I don't want to play vulnerability Olympics. Zoom does lots of things wrong, it should fix all of them, and its users are right to complain at each of them, I don't understand any value from trying to pick some of them as "less bad" based on tenuous claims about what you think might or might not be possible in other domains like video encoding. > In that context 'I-frames might be both identical and magically…

You don't have to understand H.264. All you have to do is take the histogram of consecutive 16 byte blocks from the stream. It's like a 5 minute coding project. Then we don't have to wonder if there are aligned 16 byte block collisions; we can actually look at them and get a sense of where they are and how frequent they are relative to the size of the data. Can you do that? Or, failing that, can you provide a `curl` command anyone else could use to download the data you're looking at, so we can do it for you?

I can H.264 a series of images with solid-colored blocks and not see repeats. But who knows if my codec test harness is representative? I very much doubt it is. I'm certain that there are cases where there are not just collisions, but useful collisions. Let's understand what they are.

This isn't "vulnerability Olympics". It's simply about understanding what we are discussing.

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

#282

Earlier quoted context omitted.

More generally, there is a culture of celebrating rule-breaking or even law breaking within the startup community. As long as you get away with it, and make money off it, then it's totally cool...

That’s also partially a reaction to so many rules and laws being utterly counterproductive and/or corrupt. Respect for rules and regulations depends on those rules and regulations having respectable motivations and effects in the first place.

It does lead to a general sense of degrading lawlessness throughout society. When powerful people start to have contempt for laws it can get really abusive.

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

#283

Earlier quoted context omitted.

Firstly I don't want to play vulnerability Olympics. Zoom does lots of things wrong, it should fix all of them, and its users are right to complain at each of them, I don't understand any value from trying to pick some of them as "less bad" based on tenuous claims about what you think might or might not be possible in other domains like video encoding. > In that context 'I-frames might be both identical and magically…

You don't have to understand H.264. All you have to do is take the histogram of consecutive 16 byte blocks from the stream. It's like a 5 minute coding project. Then we don't have to wonder if there are aligned 16 byte block collisions; we can actually look at them and get a sense of where they are and how frequent they are relative to the size of the data. Can you do that? Or, failing that, can you provide a `curl`…

You can see the phenomenon I described for yourself in:

http://demo.nimius.net/video_test/videos/test.mp4

This file contains audio, which in the Zoom pseudo-RTP is separate so you should strip that out with your preferred tool without changing the H.264 video though it won't change the results very much (it only re-assures us that the recurring data is in the video stream as I assumed) so if you don't have such tools don't worry too much.

It has the case we're interested in, because it's the simplest to understand: I-frames with identical content.

If you've put together a "codec test harness" that's what you want to simulate. Don't feed in penguins or "solid-coloured blocks" just feed in a still image, and watch as (unsurprisingly) it outputs the same I-frame each time it needs to do so, regular as clockwork. You're not simulating a Zoom stream of abstract art, but a shared desktop that's showing Pauline's Q3 revenue forecast for two whole minutes while her team discuss Tiger King or the desktop of a guy who left five minutes ago but didn't leave the meeting, or (more speculatively) an empty meeting room on camera.

This is the beginning. If we stop dismissing it as just "more complicated" than just a Penguin pixmap and bring in people who know more about video codecs we can explore how much more can be done. If every slide show has the company logo and the presenter's name on the first slide, does that correlate? Can we make a watermark that would survive being played back through one codec and then encoded by Zoom?

But there's a strong sense in which I don't care to do all that actual work. Some of these things might be possible and some not, but we're not building a cool demo for a convention we're just here to say that Zoom is terribly insecure and if people feel they must use it, treat it like a meeting held in the local coffee shop, assuming your local coffee shop is bugged by both the US and Chinese government.

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

#284

Earlier quoted context omitted.

You don't have to understand H.264. All you have to do is take the histogram of consecutive 16 byte blocks from the stream. It's like a 5 minute coding project. Then we don't have to wonder if there are aligned 16 byte block collisions; we can actually look at them and get a sense of where they are and how frequent they are relative to the size of the data. Can you do that? Or, failing that, can you provide a `curl`…

You can see the phenomenon I described for yourself in: http://demo.nimius.net/video_test/videos/test.mp4 This file contains audio, which in the Zoom pseudo-RTP is separate so you should strip that out with your preferred tool without changing the H.264 video though it won't change the results very much (it only re-assures us that the recurring data is in the video stream as I assumed) so if you don't have such tools…

This is useful. Thanks! Out of ~22,000 AES blocks, this has ~1000 colliding blocks:

    04608c1c211004608c1c00000007419b: 4 samples
    1004608c1c211004608c1c0000000741: 4 samples
    0963211004608c1c211004608c1c0000: 5 samples
    33c00963211004608c1c211004608c1c: 5 samples
    63211004608c1c211004608c1c000000: 5 samples
    f7df7df7df7df7df7df7df7df7df7df7: 5 samples
    0001000003ff0000000e000004000000: 6 samples
    211004608c1c211004608c1c00000007: 7 samples
    c00963211004608c1c211004608c1c00: 8 samples
    0001000003ff00000014000004000000: 9 samples
    0001000003ff0000000d000004000000: 25 samples
    75d75d75d75d75d75d75d75d75d75d75: 31 samples
    5d75d75d75d75d75d75d75d75d75d75d: 33 samples
    00000b0000000b0000000b0000000b00: 34 samples
    d75d75d75d75d75d75d75d75d75d75d7: 34 samples
    7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9: 39 samples
    f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9f: 40 samples
    9fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe: 42 samples
    cfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7f: 42 samples
    fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7: 42 samples
    e7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f: 43 samples
    f9fcfe7f3f9fcfe7f3f9fcfe7f3f9fcf: 43 samples
    fe7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3: 46 samples
    3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9fc: 47 samples
    aebaebaebaebaebaebaebaebaebaebae: 60 samples
    baebaebaebaebaebaebaebaebaebaeba: 63 samples
    00000000000000000000000000000000: 69 samples
    ebaebaebaebaebaebaebaebaebaebaeb: 73 samples
    00060000000600000006000000060000: 147 samples
The collisions occur in runs, so, for instance, there's a run of ~40 "fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7"'s towards the end of the file.

I-frame macroblocks in H.264 are DCT'd, like a JPEG; I have no intuition for what the repeats would signify, except that the encoding is deterministic and, I guess, within an I-frame, stateless? So identical samples will show up in the output?

(It might be easy to instrument an H.264 decoder to get an indication of what frame I'm in when I see a collision, which is I guess what I'll do next).

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

#285
post #141

Earlier quoted context omitted.

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

"Guess the username" (you didn't even try and it was pretty bloody obvious):

Gerdes (my family name) means the same as the word German. A ger is a spear - https://en.wikipedia.org/wiki/Migration_Period_spear. A ger-man is a spear bearing man and gerdes is an old form of that. You lot had a habit of trundling around with spears - hence the name in English.

Using Zoom is of course not an awful thing to do. Just be careful me old fruit. Please.

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

#286
post #141

Earlier quoted context omitted.

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

Nitpick: he's not talking about the Drittes Reich, he clearly must be talking about the experience people had in eastern German DDR / "German people's republic".

Kids! How on earth would a Brit end up in the DDR? OK we did:

My dad was a British soldier (so was mum but that's another story). We were posted to exotic places like "Reindahln" (MG) and Paderborn and Soltau etc. We went on a holiday to West Berlin in around 1980ish. We were allowed through Check Point Charlie to see the DDR for a short while. Funnily enough exactly the same arrangement as getting into Northern Cyprus. ie the Turkish bit.

Anyway, we saw the Brandenburg Gate from both sides, when it was mined all around but rather nicely flood lit. I have to say the east side looked a bit shag back then.

Our German friends always used to look forwards to reunification but the cost when it came used to cause a few remarks cough. For me a unified Germany is a good and beneficial thing, regardless of cost. I saw first hand what life was like in E Berlin in the early 80s.

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

#287

Earlier quoted context omitted.

You can see the phenomenon I described for yourself in: http://demo.nimius.net/video_test/videos/test.mp4 This file contains audio, which in the Zoom pseudo-RTP is separate so you should strip that out with your preferred tool without changing the H.264 video though it won't change the results very much (it only re-assures us that the recurring data is in the video stream as I assumed) so if you don't have such tools…

This is useful. Thanks! Out of ~22,000 AES blocks, this has ~1000 colliding blocks: 04608c1c211004608c1c00000007419b: 4 samples 1004608c1c211004608c1c0000000741: 4 samples 0963211004608c1c211004608c1c0000: 5 samples 33c00963211004608c1c211004608c1c: 5 samples 63211004608c1c211004608c1c000000: 5 samples f7df7df7df7df7df7df7df7df7df7df7: 5 samples 0001000003ff0000000e000004000000: 6 samples 211004608c1c211004608c1c0000…

I'm just noticing, by the way, that one of the repeats in this test pattern video is the same as the repeat you observed in the Star Wars opening crawl, so presumably that has nothing to do with content.

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

#288

Earlier quoted context omitted.

That’s also partially a reaction to so many rules and laws being utterly counterproductive and/or corrupt. Respect for rules and regulations depends on those rules and regulations having respectable motivations and effects in the first place.

It does lead to a general sense of degrading lawlessness throughout society. When powerful people start to have contempt for laws it can get really abusive.

Sure. But at this point everyone picks and chooses which laws they care about. I've observed a pretty heavy overlap between people who care a great deal about taxi regulations (most of which exist merely to artificially prop up rent-seeking owners of taxi medallions) and people who consider American immigration law so fundamentally unjust that it should simply not be enforced anymore. Faithfully Obeying All The Rules And Regulations isn't an especially popular ideology, and if you consistently advocate it, you'll end up very unpopular with everyone.

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

#289

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.

I agree - all security is assembled from lower level primitives and can be insecure despite using good building blocks. AES (even AES-128) is a fine choice, ECB mode is even okay in some contexts, but using that a stream cipher is not appropriate.

Definitely. Some other places (I think Telegram iirc) do actually create their own encryption algorithms without using existing ones. That’s what I thought rolling your own crypto scheme was. If the problem with Zoom is that they chose a poor mode for the algorithm, why doesn’t the headline say that? Creating your own encryption algorithm is way worse.

If rolling your own encryption scheme is just choosing what algorithm you use — every system does that. So it’s not headline worthy. :/ I get that zoom needs to make better choices, but the rhetoric around it has been pretty poor and unhelpful.

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

#290

Given Zoom is blocked in China, what reason is there for the main key server to be there? Even ignoring the appearances, for latency and the fault tolerance reasons, China is the last place you'd want to put it a critical server for an app used in the West.

Zoom is no longer blocked in China.
Post reply on HN