And this is why you don't use unproven apps that come out of nowhere simply because they are "popular."
Zoom rolled their own encryption scheme, transmit keys through servers in China
161–170 of 316 posts
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#162The 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…
As a total novice to crypto stuff, is there any way that someone with access to unencrypted audio/video from the sensor could work out some sort of "baseline" and then factor it into their cryptanalysis of encrypted content produced from the characterized sensor?
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 repeats leaking useful information. In a bitmap image of a penguin, those repeats are easy: they're blocks of pixels of uniform color, and all ECB is doing is permuting their colors. That's less intuitively true of audio (where I'm not really seeing repeats at all, but, again, you should just play with it).
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#163The 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…
Sensor noise does not translate nearly as well as one might think in compressed videos. And there are likely repeating data blocks big enough to analyze.
I mean: go generate the test case that shows this. You don't even have to encrypt to prove it out; you can safely assume ECB will reveal any aligned 16-byte repeats, so all you need to do is take a histogram of all the consecutive 16-byte blocks in your encoded output.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#164Earlier quoted context omitted.
Compressed anything is high entropy
Untrue. Many performance trade-offs have to be made and the entropy has to vary drastically with time. See for example B-Frames vs I-frames in compressed video. Couple that with the very low entropy video conference data and bam.
Two words: sensor noise.
Even uncompressed video will be hard to see that "penguin image effect" in, because the pixels that make up each block will be constantly changing in a random way, and unlike that synthetically generated image, it's highly unlikely for a block to be the exact same as any other one in any given frame.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#165This is honestly the best “Zoom is bad” summery I’ve seen so far. While I certainly believe some of the Zoom hate is blown out of proportion, this article does a good job explaining to someone who isn't a security expert what the issues are. I've been getting questions about the company from family and friends, and will be forwarding this to them. Well done.
This is a great article, but as an educational provider it fails to answer one question: Why should I care? The only concerning thing for me is, why would they lie about using AES-256 when none of my users (and I assume most of their users) would care in any way about AES-256 vs. AES-128 in ECB mode. Why would they lie? Even after this, having my users conducting university lessons over something that might be decryp…
[flagged]
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#166The 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…
Screen sharing a presentation is problematic; lots of discrete blocks of bitmap image being repeated.
[deleted]
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#167The 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…
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 you'll get worse products in future because a worse product was given a leg up by lying. That's where we are today.
Silence detection (and a bunch of related problems) should be solved by using Constant Bitrate (CBR) encoding. The analysis linked says SILK was used, which was conceived as primarily a Variable (VBR) encoding but it doesn't go into enough depth to be sure whether VBR is in play here, though it's hard to give Zoom benefit of the doubt.
On the video side you can play sensor noise off against video codec optimisations. If you're sure the bottom 1-2 bits on a video conference camera feed is noise, the people writing the optimised live video encoder probably agree and aren't sending those bits anyway (you can synthesise noise perfectly well without sending it), so it's a wash.
And also though I agree it's not where you'd start do not rule out attackers controlling the plaintext - the "virtual pub" I attended a few hours ago with friends had a third party video playing, and sometimes people share their slide decks by video in corporate or government environments. It's definitely more practical to sneak deliberately watermarked video into someone's Zoom conference than to, as we worried about for disk encryption, get them to stash megabytes or gigabytes of carefully watermarked files on a drive.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#168Earlier quoted context omitted.
Hi dang, Thanks in advance for all your moderation efforts that make HN the site we all love to use on a regular basis. I'm curious if you've ever considered writing a blog post about some of the things you've learned from your years of moderation? You spend so much time on HN, you must have seen lots of patterns and have lots of insights on...well, everything that gets posted on HN to everybody that posts on HN. I'd…
While you wait for his response: https://www.newyorker.com/news/letter-from-silicon-valley/th...
At first, the site attracted about sixteen hundred daily visitors, and Graham moderated and maintained it himself. Today, around five million people read Hacker News each month, and it’s grown more difficult to moderate. The technical discussions remain varied and can be insightful. But social, cultural, and political conversations, which, despite the guidelines, have proliferated, tend to devolve. A recent comment thread about a Times article, “YouTube to Remove Thousands of Videos Pushing Extreme Views,” yielded a response likening journalism and propaganda; a muddled juxtaposition of pornography and Holocaust denial; a vague side conversation about the average I.Q. of Hacker News commenters; and confused analogies between white supremacists and Black Lives Matter activists. In April, when a story about Katie Bouman, an M.I.T. researcher who helped develop a technology that captured the first photo of a black hole, rose to the front page, users combed through her code on GitHub in an effort to undermine the weight of her contributions.
The site’s now characteristic tone of performative erudition—hyperrational, dispassionate, contrarian, authoritative—often masks a deeper recklessness. Ill-advised citations proliferate; thought experiments abound; humane arguments are dismissed as emotional or irrational. Logic, applied narrowly, is used to justify broad moral positions. The most admired arguments are made with data, but the origins, veracity, and malleability of those data tend to be ancillary concerns. The message-board intellectualism that might once have impressed V.C. observers like Graham has developed into an intellectual style all its own. Hacker News readers who visit the site to learn how engineers and entrepreneurs talk, and what they talk about, can find themselves immersed in conversations that resemble the output of duelling Markov bots trained on libertarian economics blogs, “The Tim Ferriss Show,” and the work of Yuval Noah Harari.
Not sure whether to agree or disagree.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#169Earlier quoted context omitted.
No comment on the original claim, but that example is encryption applied to an uncompressed image. (Adjacent identical pixels are not typically represented individually when compressed, and thus encryption could not cause the banding patterns seen in those regions of the image if it were compressed prior to encryption.)
The point is that any pattern in the plaintxt data shows up in encrypted data if you use AES-ECB. Compression does not introdoce entropy to a stream. So assuming that saying the stream is compressed and calling it good is a very bad idea. Please refer to Shannon's source coding theorem. If anything, compression reduces the entropy in the information.
> The point is that any pattern in the plaintxt data shows up in encrypted data if you use AES-ECB.
No, that's false. ECB reveals repeating plaintext blocks. "F0123456789ABCDEF0123456789ABCDEF" contains a repeating block-length sequence, but would encrypt to three distinct blocks under ECB, because the sequence is not aligned to a block boundary.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#170Earlier quoted context omitted.
No comment on the original claim, but that example is encryption applied to an uncompressed image. (Adjacent identical pixels are not typically represented individually when compressed, and thus encryption could not cause the banding patterns seen in those regions of the image if it were compressed prior to encryption.)
The point is that any pattern in the plaintxt data shows up in encrypted data if you use AES-ECB. Compression does not introdoce entropy to a stream. So assuming that saying the stream is compressed and calling it good is a very bad idea. Please refer to Shannon's source coding theorem. If anything, compression reduces the entropy in the information.
I think you may want to look closer at Shannon’s source coding theorem; The Shannon entropy of the output of a compression algorithm will be higher than the entropy of the source as identifiable patterns are eliminated. Otherwise the theorem would trivially contradict itself.