Zoom rolled their own encryption scheme, transmit keys through servers in China
The serverside key handling stuff is bad, but generally known (Zoom has features whose natural implementation require them to keep keys serverside).<p>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".<p>You can see penguins through an ECB-encrypted bitmap because discrete blocks of the bitmap image repeat, and thus have the same ciphertext, and these correspondences carry obvious meaning in a bitmap. The same is not automatically true of video or audio data with normal codecs. Aaron Toponce points out that sensor noise will likely scramble ECB ciphertexts, for instance.<p>Colm MacCárthaigh makes an even more important point, which is that it's already very trick to reliably encrypt voice tracks, because common encoding and transmission techniques make them susceptible to traffic analysis. So, for instance, you can quickly find papers about exploiting silence suppression to make predictions about speech in an encrypted audio channel. The point here being, cryptanalytic attacks on ECB are unlikely to be anyone's first recourse.<p>Obviously, the 128 bit AES key thing doesn't really have any practical impact.<p>Designers should religiously avoid ECB mode, but the real danger of ECB is in interactive settings, where we as attackers get to <i>induce</i> plaintext patterns, and use chosen boundaries to isolate targeted ciphertext. Bulk video and audio transmission isn't that kind of interactive setting. You still don't want to read people saying that ECB is OK; it's bad.<p>Essentially: it seems like Zoom's cryptography is bad, but not in a way that really matters compared to brochure-level badness of non-end-to-end-encryption.