311–316 of 316 posts
Why can't people bother to construct a minimally secure encryption system given that there are so many good documents and code examples out there? I don't mean anything with ratcheting, forward secrecy, replay protection, nonce reuse resistance, or any other bells and whistles, just basic competent symmetric encryption without gaping holes or ridiculous bizarre design choices? It's not hard! (1) Generate 12 bytes of…
AES-GCM was not designed to be used with random nonces - otherwise the nonce space would need to be larger than 96 bits. It was only designed to be safe with a unique counter nonce. That does not always become a problem, but it will in Zoom's case.
Zoom is encrypting a video stream, which means you cannot use AES-GCM wholesale, but have to use it to encrypt chunks of data.
The problem is that 12 bytes (96 bits) of nonce is just not enough, and after encrypting a certain amount of data with the same key, the chance of repeating the nonce becomes rather high. And if you have a long video conference call with many participants using the same key, you'll sooner or later generate enough data that the nonce will be repeated. Once the nonce is repeated, GCM loses its security guarantees.
It's hard for me to estimate how bad it would be, since I'm not familiar enough with the plaintext data characteristics, but in this case it could even be worse than using ECB.
AES-GCM is a cryptographic primitive that is meant for sequential whole-message encryption. The moment you're using it for streaming you are rolling your own crypto. Even if you've used a cipher that supports larger nonces like XChaCha20-Poly1305, you can still not be sure that you're absolutely free from mistakes if you also want authentication, for instance.
Zoom was negligent for just going ahead with AES-ECB, but finding a solution for this problem is not that simple. When you need to stream encrypted data, encrypting it directly with a safe AEAD construction is not always going to make you safe. That's why it's generally safer to use TLS, even considering how historically problematic TLS is. Of course Zoom could not use TLS for streaming video, since this would preclude them from using UDP and allowing for packet loss. I've never encrypted TLS traffic and I'm not familiar enough with other protocols like dTLS and [Noise](https://noiseprotocol.org/) to know if they will be useful in this case, so I won't be making any claims to how easy this is.
Earlier quoted context omitted.
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 t…
I find that the opposite is true. Most comments are emotional, and I have to search for controversial comments to find anything objective/worth reading. Like Reddit, this site is biased to the political left (USA). I wish we could just avoid all politics in tech.
when you're the USA, the world looks biased to the political left ...
Earlier quoted context omitted.
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…
The students log in via email and from home, they both count as personal identifiers. Now, China knows who is attending which lesson. And how much activity each individual shows. And also, what happens on the side like environment sounds, environment at the camera (e.g., how generous the student's apartment is). Also, the client can analyze the mouse cursor movement, see what other apps are running and how (on native…
We still do not have any evidence that the PRC has access to unencrypted Zoom server logs and frankly I assume we would have the same (or worse) issues I had with my tests from Iran that either SIP/WebRTC doesn't work or appears to be intercepted. So, at least for me and my users, Zoom is the most accessible and "least worst" solution.
Earlier quoted context omitted.
The students log in via email and from home, they both count as personal identifiers. Now, China knows who is attending which lesson. And how much activity each individual shows. And also, what happens on the side like environment sounds, environment at the camera (e.g., how generous the student's apartment is). Also, the client can analyze the mouse cursor movement, see what other apps are running and how (on native…
Just as an FYI 2 weeks later... We decided on not enforcing Zoom accounts for our students for various reasons. So the PRC might have IP address access to a SIP/Zoom server but this is not something we, as a small university, can solve. Even without Zoom the PRC could trace access to our bigbluebutton server or a jitsi videobridge and I don't presume that using Webex or Vidyo or what have you would solve this issue (…
And indeed, an intelligence could possibly hack your bigbluebutton server. This involves, however, a targeted attack instead. I think this is a different scenario, though.