[meowface]

I'd recommend reading the original Citizen Lab article as well, which discusses the flaws more specifically. This Intercept article is good, but seems to be aimed at more of a general, less-technical audience.

https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto...

At the very least, they are validating TLS certificates. (Which I know is the true bare minimum requirement of TLS, but "goto fail" and all...)

>We set up mitmproxy to intercept the TLS traffic and configured the Zoom Linux client to route its TLS traffic through mitmproxy. Fortunately, the Zoom client did appear to warn us that the fake TLS certificates generated by mitmproxy were untrusted.

[dang]

That article is now being discussed at https://news.ycombinator.com/item?id=22768494. Not sure whether to try to merge these threads.

[fulafel]

The CL article seems to be underplaying the vulnerability of ECB, with the "not recommended" description. Any cryptographer will tell you it's downright trivially broken, with textbook practical attacks taught to undergrads.

[cvwright]

Is ECB any worse than any other deterministic encryption?

Deterministic encryption can be ok if the data that you’re encrypting is already really random (high min-entropy). Compressed audio and video streams have a decent amount of entropy. Probably not enough to satisfy a cryptographer, but it’s probably enough to make it very difficult to learn much from 128-bit AES ECB blocks.

Note that everyone’s favorite ECB example with the picture of Tux the Linux penguin is not very realistic, because the plaintext is not compressed. If you ECB a JPEG or a PNG, you won’t see the same patterns.

I teach the attacks on ECB in my network security class. It’s bad, but AES is not the Caesar cipher. I’m not sure “trivially broken” is quite right.

That said, I am really curious what Zoom is actually doing here. Going to have to take a look today. My guess is that the real fail from using ECB mode is more likely to come from using it on audio/video metadata, or on other more structured parts of the protocol.

[doomrobo]

All this is technically true. As long as you believe that you will never ever under any circumstance send the same video chunk twice under the same key, you get all the security guarantees of a real CPA-secure (=> non-deterministic) symmetric cipher. But 1. I don't think this is a reasonable belief, and 2. even if it is, why chance it when you can use CTR mode and a random nonce, with practically zero overhead?

[cvwright]

> As long as you believe that you will never ever under any circumstance send the same video chunk twice under the same key

Yes, that is the question here, and it's a really fascinating one. How often do you send two identical 128-bit chunks in practice? How much does it depend on the quality of your webcam and your lighting? If the video is grainy and splotchy in the background, you're getting a lot of randomness in your data. How much does that help? Any at all? Or are you still totally screwed?

> even if it is, why chance it when you can use CTR mode and a random nonce, with practically zero overhead?

1000 times this. Crypto code should be like the safety components in a car or an airplane. You wouldn't buy a car with seatbelts or brakes that work 90% or even 95% of the time. In the same way, you shouldn't write network code that probably doesn't let an adversary figure out everything you're sending.

[prophesi]

> Is ECB any worse than any other deterministic encryption?

Yes, it's objectively worse than literally any other AES mode. You wouldn't need to depend on compression to protect your data.

[cvwright]

Note that I was asking specifically about deterministic modes. Those include SIV mode [1] but not the more common CBC, CTR, etc.

Any deterministic encryption relies on entropy of the plaintext for security [2]. This is not unique to ECB.

My objection was to the hyperbolic phrase "trivially broken." SIV mode is deterministic, but nobody who understands what it does would call it "trivially broken."

And I'm definitely not saying that anyone should use ECB. Just that in this case, the vulnerability may not live up to the hype.

By all means, go ahead bashing on Zoom. It's the cool thing to do these days, and clearly they've done enough to deserve most of it.

[1] https://web.cs.ucdavis.edu/~rogaway/papers/siv.pdf

[2] https://eprint.iacr.org/2006/186

[prophesi]

I'm personally more upset that they're advertising 256bit AES yet using 128bit AES. Sure, 128bit is still fine to use today, but it's still false advertising. They're already falsely claiming end-to-end encryption. It doesn't help that they're using the weakest mode of AES on top of all of this.

If Zoom had a security audit, the auditors would quickly suggest using either some sort of ECB-based algorithm that uses an SIV, or just AES-CTR. I'm guessing they went with ECB due to its parallelization of the encryption/decryption process, which totally makes sense, except that there are much more secure algorithms out there.

[cvwright]

Yeah you have to wonder: Did they just not know about counter mode? The implications of that are frightening.

[lawnchair_larry]

This is dangerously wrong. ECB is a non-starter no matter the entropy of the plaintext. Trivially broken is accurate. I hope you are not teaching students that it is ever ok.

[auiya]

An explanation w/ visuals for how/why ECB is a broken mode of operation for cryptography - https://www.crypteron.com/blog/practical-searchable-encrypti...

[prophesi]

The exact same explanation + visual are already in The Intercept's article (and CitizenLab's). The rest of it is flaunting Crypteron's searchable encryption.

[meowface]

If you scroll down, they go into more detail, with the classic Linux penguin example.