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

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

Where are you getting this recommendation? Who recommended it - to Zoom? And when?

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

If you're prepared to be at least slightly interested in problems even if ECB only contributes rather than blowing them wide open, then maybe you should look at H.264 I-frames first.

An I-frame stands on its own. For example the WebP image format is essentially just one I-frame from VP8. If the scene is literally unchanged from one I-frame to the next, all the exact same image data must be re-encoded, and logically (if the codec is at all efficient) that means the same bytes.

[ If you just don't use I-frames then all loss becomes unrecoverable and people will stop saying your product "Just works". In products like a DVD or Netflix I-frames are needed to make it "seekable". This is obviously not a necessity in a video conference, but the ability to handle network glitches and to add/ remove participants seamlessly is a requirement ]

So with ECB for I-frames clearly we can tell if nothing changed. Maybe an artificially lit meeting room with nobody in it, a desk left unmanned. Or a screen share left showing an unchanging desktop. Is that a "useful" thing for eavesdroppers to learn? Do you think Zoom users would be surprised that eavesdroppers can tell their colleagues took a coffee break?

But because codecs like H.264 are oriented around square blocks I suspect we can do better. They're not deliberately trying to have these blocks encode to exactly 16 bytes and so mostly they won't, but of course one chance in 16 isn't nothing and we get to try every I-frame. Probably not to the point of getting a blocky outline of a moving person on a stream (which is sad because I'm pretty sure that, like the Penguin, would make the point viscerally) but enough to have some idea which parts of a scene (or a slide deck) are changing.

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 seems extra-uninteresting compared to things like 'plaintext can be recovered from encrypted realtime VBR-encoded audio'.

In that context 'I-frames might be both identical and magically align' seems even more contrived than the already more-famous-than-informative penguin.

> In that context 'I-frames might be both identical and magically align' seems even more contrived than the already more-famous-than-informative penguin.

Did you take a look at an actual H.264 video stream of something boring?

I downloaded a random example of an H.264 video of the generic movie lead-in you've seen a million times where giant numerals appear in descending sequence. The sequence repeats itself several times, allowing us to compare I-frames each time.

Let me quote from the first time a giant numeral two is displayed - briefly in hexadecimal:

> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7

That's not encrypted, but on the other hand I also don't understand what it means because I am not an H.264 decoder. So an ECB encoded block would be just as meaningful to me.

Of course, we'd only get the same exact ECB encoded block if the input was the same... a few seconds later another I-frame of the same giant numeral two and:

> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7

Ah. Well, maybe it's just a fluke? A few seconds later the same number is featured in the I-frame again and...

> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7

Maybe I got real stupid in my old age but I think what's going on here is exactly what I already told you to expect. Given the same input the H.264 I-frame encoded is identical or at least so very similar as to be full of the same 16-byte sequences. Actually it's mostly 9-byte sequences, it's just that it needs so very, very many of them to encode an I-frame that statistically producing a recurring 16-byte sequence was almost inevitable.

Let me be clear here: I don't understand H.264 well enough to align this naturally frame aligned, I just took the raw data and pretended it was already 128-bit aligned because that logically cannot be worse than what you'd get if you knew what you were doing. I would be astonished if somebody who actually knows what they're doing can't get much better results from this.

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.

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.

    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

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

I don't think it would make a huge difference but the numbers might be higher/more representative. Another way might be to just capture zoom traffic of someone's Quarterly Synergies presentation or whatnot.

Edit: also thought of a silly upper-bound test for Team Penguin - you get plaintext of every colliding block in the stream. How much penguin can you get out of that?