I do not give a shit
Zoom rolled their own encryption scheme, transmit keys through servers in China
271–280 of 316 posts
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#272Earlier quoted context omitted.
So, if we can not avoid politics it is ok to encourage some views while discouraging the opposite views? How can we know for sure we are right or even on the good side, whatever "good" means?
First we'd need to establish a general frame of reference, a perspective, which could be a human one. From that perspective, the lowest common denominator is that bad is what harms humanity, e.g. by disregarding human rights. Human rights then becomes the new frame of reference, meaning that something can't be good if it's not within that frame.
Power struggle then becomes what are rights, and who owes them to whom? Who gets what rights and how are they enforced is pretty much the core of political struggle.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#273The 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…
Thank you for clearly articulating why using AES-ECB here is not as bad as the penguin image everyone seems to know. It's still a bad choice - you really need to prove to yourself that your data stream isn't susceptible and it's honestly easier just to use an appropriate stream cipher mode. I absolutely agree that the real deserved flak is for saying "end-to-end encryption" when that's clearly not what's happening. H…
When you control the content of the stream, you control whether there are repeated blocks. If there are none, do any objections to ECB remain?
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#274Earlier quoted context omitted.
Thank you for clearly articulating why using AES-ECB here is not as bad as the penguin image everyone seems to know. It's still a bad choice - you really need to prove to yourself that your data stream isn't susceptible and it's honestly easier just to use an appropriate stream cipher mode. I absolutely agree that the real deserved flak is for saying "end-to-end encryption" when that's clearly not what's happening. H…
When you control the content of the stream, you control whether there are repeated blocks. If there are none, do any objections to ECB remain?
Yes: ECB is also somewhat malleable, and uniquely vulnerable to "cut-and-paste" attacks since nothing ties a run of ciphertext blocks to its position in the stream. But these arguably aren't especially relevant to Zoom's threat model.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#275Earlier quoted context omitted.
Screen sharing a presentation is problematic; lots of discrete blocks of bitmap image being repeated.
If Zoom supports stock background filters or modes, that would seem to be another massive source of repeating plaintext, depending on the implementation.
I mean, it won't be, for the same reason 'tedunangst points out above. But even if it was: the repeats you'd be referring to would be leaking... stock background filters and modes.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#276Earlier quoted context omitted.
> the saving grace is that 3DES is still considered secure. Nobody who wants to do AES-256 rather than AES-128 thinks 3DES is "still secure". 3DES is perhaps 112 bits of useful keyspace but it has 64-bit blocks which was already bad news when DES was invented. TLS 1.3 doesn't have a 3DES option at all. You can do AES 128 or AES 256 (or ChaCha20).
The USG still considers it secure and that will retard forward progress.
There is an abundance of secure, widely reviewed symmetric ciphers for every imaginable application profile.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#277Earlier quoted context omitted.
> CTR mode, which is what was supposedly "recommended" here 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-fram…
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 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.
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#278The 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…
> Aaron Toponce points out that sensor noise will likely scramble ECB ciphertexts, for instance.
1) "likely" != "guaranteed to"
2) If there's sensor noise when you're sharing your screen, then you're doing something horribly horribly wrong
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#279Earlier 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…
> and Zoom claims to be GDPR compliant.
That's the thing, though. Zoom also claimed to be end-to-end encrypting with AES-256. If they were willing to lie about that, what's not to say they're willing to lie about GDPR compliance?
Re: Zoom rolled their own encryption scheme, transmit keys through servers in China
#280> Zoom’s most recent SEC filing shows that the company (through its Chinese affiliates) employs at least 700 employees in China that work in “research and development.” Wow. What could all of these people possibly be doing? It can't be development and QA; what's going on over there?
Why can't 700 people do development and QA?
I think it was more a jab at Zoom being buggy and (in light of recent revelations) inadequately secure - that is, implying that those 700 employees are obviously not doing development or QA given the state of the product.