18 ms·

Using AES in ECB mode is clearly a bad choice, but honestly it's not that horrible for high entropy data like compressed audio/video. I'm sure someone could pro

Using AES in ECB mode is clearly a bad choice, but honestly it's not that horrible for high entropy data like compressed audio/video. I'm sure someone could prove me wrong one day, but it seems hard to extract any useful patterns out of compressed audio/video. It does check the box of "uses encryption" for regulatory reasons (while missing the intent). It's pretty egregious considering how easy this is to get right. The 128-bit key is not inherently wrong if they were rotating these out during the stream. That being said, there's no reason not to do it right and use a mode like GCM with a longer key - most hardware supports acceleration for AES-256 these days. It can actually be slower to use a 128-bit key on 64-bit systems. While I respect the decision not to disclose the waiting room vulnerability, it's pretty obvious what's going on given the context. They probably shouldn't have mentioned where the vulnerability is. I'm honestly surprised anyone with technical knowledge thought that Zoom was actually doing end-to-end encryption given how the software works. All of the video transcoding/downconversion is clearly happening on the server. Your client is not sending multiple compressed streams for varying connection bandwidths. That's the main reason a lot of people like Zoom - it actually works well with dozens or hundreds of participants.

phendrenad2 7y ago
Is compressed audio/video actually high-entropy (in the time domain) though?
- rongenre 7y ago
  Compressed anything is high entropy
  - jldugger 7y ago
    Depends on the compression. Lossy compression discards a lot of noise vs the signal we care about and would in a sense reduce entropy.
  - sudosysgen 7y ago
    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.
    - userbinator 7y ago
      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.
      - deleted 7y ago
        [deleted]
      - sudosysgen 7y ago
        You greatly overestimate both the image quality of crappy videoconferencing streamed video, the amount of pixel-wise sensor noise after noise reduction (pretty low actually), while underestimating the ingenuity of crypt-analysts and the power of having a lot of data. Like seriously, the only way the shitty 1mm or less sensors on webcams are able to deliver HD video is through an abject amount of noise reudction, sharpening and filtering. All of which greatly reduce entropy. Hint: You don't need to know the plaintext exactly. you just need to be able to build a reasonably precise probability distribution.
- rzimmerman 7y ago
  I'm actually not sure - that's a good point. The whole point of compressing audio for video conferencing is to preserve human speech, so things that produce radically different waveforms but "sound the same" to us might show up as patterns. I guess it's better to avoid the question entirely and use an appropriate stream cipher!
kop316 7y ago
> Using AES in ECB mode is clearly a bad choice, but honestly it's not that horrible for high entropy data like compressed audio/video. I'm sure someone could prove me wrong one day, but it seems hard to extract any useful patterns out of compressed audio/video. ...you're joking right? The Wikipedia example for why ECB is not recommended is literally an image: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation Edit: This applies to compression too. Please refer to Shannon's source coding theorem.
- rzimmerman 7y ago
  It's definitely a terrible choice for uncompressed images or video. I'm arguing it probably isn't that bad for highly compressed video. That being said, if you're encrypting any data stream you should use an appropriate stream cipher.
  - miked85 7y ago
    If the encryption scheme is poor, why would the data being compressed or not matter?
    - fennecfoxen 7y ago
      "The use of ECB mode is not recommended because patterns present in the plaintext are preserved during encryption."
      - miked85 7y ago
        absolutely - I was asking why a poor encryption scheme would be considered acceptable just because the data is compressed.
    - rzimmerman 7y ago
      AES-ECB isn't necessarily insecure, it's just very easy to misuse (and I agree what the article described is a misuse). I think the argument is that if there are patterns in the input data, the same patterns will show up in the AES-ECB encrypted data, just with different values. Compressed data should be high entropy and hard to predict, so there really shouldn't be structure or patterns to the input data. There's no guarantee that any given compression algorithm provides sufficient randomness, though.
deleted 7y ago
[deleted]
ouid 7y ago
communications on the platform aren't encrypted at all. That's what the article says.
tialaramex 7y ago
Is it just me to whom it seems obvious why they've gone with ECB? Zoom's design has a single key for everybody and for everything [ in the context of a particular video conference call ] . It's simpler and, to a layman, it sounds secure. [ We arguably contribute to this if we say e.g. "the key" implying it's just one thing when we mean something like a master secret in TLS used to derive lots of actual keys ]. Once you've committed to a single key ECB behaves exactly how you'd want. You've got some audio, or video, ready to send? Just encrypt it with the key. Receive some encrypted data? Just decrypt it. What happens if you have some network trouble briefly? Nothing, everybody decrypts whatever does arrive and maybe a few frames are missing. All of the other modes don't work at all if you try to use them this way. They all expect you to have thought about the problem and track a bunch more state and then maintain that state despite an unreliable network and other issues. Unless there is somebody in the room who says we can't do ECB because it's fundamentally not a secure choice, ECB is what you're going to get from this design decision. And I've been in rooms like that as the only voice, or at least as the only person who spoke up. I've been in rooms where I was part of a chorus too, but as organisations get bigger and "security is everyone's problem" becomes a phrase people learn but don't act on, it gets lonelier. Also, I actually can't even work out what a "correct" key rotation strategy could be for ECB with a variable number of parties all encrypting stuff at once. As a result it seems unlikely that Zoom did figure out such a strategy and then correctly implemented it. Instead it seems safe to assume there is no key rotation, everything sent by every participant for the life of the stream is encrypted with the same key, even though that's a terrible idea.
- betterunix2 7y ago
  That whole argument would make sense if there was not a standardized solution to the problem: https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Pro... I would like to hear the explanation for why they did not use SRTP, though I suspect the answer is, "We had no idea it existed."
kevin_thibedeau 7y ago
There are lots of embedded processors with hardware support for AES-128 only. I have to fight to keep AES-256 out of the ciphersuite list because of the performance regression. The rest of the world will probably force the issue eventually but the saving grace is that 3DES is still considered secure.
- tialaramex 7y ago
  > 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).
  - kevin_thibedeau 7y ago
    The USG still considers it secure and that will retard forward progress.
    - blattimwind 7y ago
      There is an abundance of secure, widely reviewed symmetric ciphers for every imaginable application profile.

phendrenad2 7y ago

Is compressed audio/video actually high-entropy (in the time domain) though?

rongenre 7y ago
Compressed anything is high entropy
- jldugger 7y ago
  Depends on the compression. Lossy compression discards a lot of noise vs the signal we care about and would in a sense reduce entropy.
- sudosysgen 7y ago
  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.
  - userbinator 7y ago
    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.
    - deleted 7y ago
      [deleted]
    - sudosysgen 7y ago
      You greatly overestimate both the image quality of crappy videoconferencing streamed video, the amount of pixel-wise sensor noise after noise reduction (pretty low actually), while underestimating the ingenuity of crypt-analysts and the power of having a lot of data. Like seriously, the only way the shitty 1mm or less sensors on webcams are able to deliver HD video is through an abject amount of noise reudction, sharpening and filtering. All of which greatly reduce entropy. Hint: You don't need to know the plaintext exactly. you just need to be able to build a reasonably precise probability distribution.
rzimmerman 7y ago
I'm actually not sure - that's a good point. The whole point of compressing audio for video conferencing is to preserve human speech, so things that produce radically different waveforms but "sound the same" to us might show up as patterns. I guess it's better to avoid the question entirely and use an appropriate stream cipher!

kop316 7y ago

> Using AES in ECB mode is clearly a bad choice, but honestly it's not that horrible for high entropy data like compressed audio/video. I'm sure someone could prove me wrong one day, but it seems hard to extract any useful patterns out of compressed audio/video. ...you're joking right? The Wikipedia example for why ECB is not recommended is literally an image: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation Edit: This applies to compression too. Please refer to Shannon's source coding theorem.

rzimmerman 7y ago
It's definitely a terrible choice for uncompressed images or video. I'm arguing it probably isn't that bad for highly compressed video. That being said, if you're encrypting any data stream you should use an appropriate stream cipher.
- miked85 7y ago
  If the encryption scheme is poor, why would the data being compressed or not matter?
  - fennecfoxen 7y ago
    "The use of ECB mode is not recommended because patterns present in the plaintext are preserved during encryption."
    - miked85 7y ago
      absolutely - I was asking why a poor encryption scheme would be considered acceptable just because the data is compressed.
  - rzimmerman 7y ago
    AES-ECB isn't necessarily insecure, it's just very easy to misuse (and I agree what the article described is a misuse). I think the argument is that if there are patterns in the input data, the same patterns will show up in the AES-ECB encrypted data, just with different values. Compressed data should be high entropy and hard to predict, so there really shouldn't be structure or patterns to the input data. There's no guarantee that any given compression algorithm provides sufficient randomness, though.

deleted 7y ago

[deleted]

ouid 7y ago

communications on the platform aren't encrypted at all. That's what the article says.

tialaramex 7y ago

Is it just me to whom it seems obvious why they've gone with ECB? Zoom's design has a single key for everybody and for everything [ in the context of a particular video conference call ] . It's simpler and, to a layman, it sounds secure. [ We arguably contribute to this if we say e.g. "the key" implying it's just one thing when we mean something like a master secret in TLS used to derive lots of actual keys ]. Once you've committed to a single key ECB behaves exactly how you'd want. You've got some audio, or video, ready to send? Just encrypt it with the key. Receive some encrypted data? Just decrypt it. What happens if you have some network trouble briefly? Nothing, everybody decrypts whatever does arrive and maybe a few frames are missing. All of the other modes don't work at all if you try to use them this way. They all expect you to have thought about the problem and track a bunch more state and then maintain that state despite an unreliable network and other issues. Unless there is somebody in the room who says we can't do ECB because it's fundamentally not a secure choice, ECB is what you're going to get from this design decision. And I've been in rooms like that as the only voice, or at least as the only person who spoke up. I've been in rooms where I was part of a chorus too, but as organisations get bigger and "security is everyone's problem" becomes a phrase people learn but don't act on, it gets lonelier. Also, I actually can't even work out what a "correct" key rotation strategy could be for ECB with a variable number of parties all encrypting stuff at once. As a result it seems unlikely that Zoom did figure out such a strategy and then correctly implemented it. Instead it seems safe to assume there is no key rotation, everything sent by every participant for the life of the stream is encrypted with the same key, even though that's a terrible idea.

betterunix2 7y ago
That whole argument would make sense if there was not a standardized solution to the problem: https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Pro... I would like to hear the explanation for why they did not use SRTP, though I suspect the answer is, "We had no idea it existed."

kevin_thibedeau 7y ago

There are lots of embedded processors with hardware support for AES-128 only. I have to fight to keep AES-256 out of the ciphersuite list because of the performance regression. The rest of the world will probably force the issue eventually but the saving grace is that 3DES is still considered secure.

tialaramex 7y ago
> 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).
- kevin_thibedeau 7y ago
  The USG still considers it secure and that will retard forward progress.
  - blattimwind 7y ago
    There is an abundance of secure, widely reviewed symmetric ciphers for every imaginable application profile.