6 ms·

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'

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.
- stouset 7y ago
  Compression already makes a compressed file roughly indistinguishable from random noise (module access to the decompressor). So the patterns have been removed. That doesn’t make this good, but it means that one specific example isn’t immediately applicable.
  - monocasa 7y ago
    There's more in the stream than just compressed data. There'll be metadata info that you can make reasonable guesses about. ECB mode lets you take that information and apply it to other blocks in the ciphertext.
    - _jal 7y ago
      This thread is an excellent illustration of why you don't want your encryption implemented by merely good coders. You need people who know what they are doing.
      - stouset 7y ago
        I’m literally one of those people who “knows what they’re doing”. This is the problem with discussing ECB on an online forum. There’s no space to have a nuanced discussion without people cargo culting “ECB bad” over every comment. Yes, ECB is almost always the wrong choice. Yes, there are other ways it’s going to fail in this use case. Yes, compression before encryption itself often enables other attacks. No, I should not have to prefix a comment about ECB with this type of disclaimer when I’m making (what should be) an uncontroversial statement that the tux attack doesn’t directly apply to compressed image data. Ironically, when designing a protocol for my company, one of the reasons we didn’t use ECB when it would have been entirely justified (each chunk of data was precisely one block in size and keys were only ever used once) was because of potential backlash from people who only know “ECB bad” and nothing more.
    - stouset 7y ago
      I’m not arguing that. I’m saying that for compressed data, underlying patterns in data aren’t trivially exposed by ECB. Ergo, the “tux” attack on bitmap image files doesn’t really apply here. I meant nothing more and nothing less than that.
      - monocasa 7y ago
        And I'm saying that they aren't just sending compressed data, nor would hardly any practical communication application, which makes the "well maybe they have enough entropy that it doesn't matter?" argument moot.
- staticassertion 7y ago
  It's harder to extract patterns from high entropy data. I don't think anyone's saying that this is even an OK thing to rely on, at all, just that the nature of the data means that this specific weakness is likely more difficult to take advantage of. If zoom were transmitting text this would be relatively more serious.
  - anaphor 7y ago
    What about the chat system? I doubt they're intentionally compressing the text there in order to increase the entropy. I guess they could be using gzip or whatever, but we'd need to look at how the protocol works in more detail. Or do they use a different system for the chat protocol altogether?
deleted 7y ago
[deleted]
kardos 7y ago
Zoom does screen sharing, right? Surely it's not transmitted uncompressed, but it is stationary for a long time and perhaps only small parts changing when they do (eg, switching slides). Is there an ECB-based weakness here?
- whoopdedo 7y ago
  Those unchanged pixels won't be transmitted. Only the changed part of the screen needs to be sent to the client. For example, RFB[RFC 6143] would send a 16-byte header with the size and position of a rectangular area of the screen followed by the pixels in that rectangle. Or multiple rectangles can be sent in one update message. But if you consider the case of text being typed, there will be a single rectangle per keystroke(s). Now I wonder if a sequence of these rectangles, all the same size and in roughly the same area of the screen, would lend to some sort of statistical analysis. At the very least the timestamps of the updates would tell you how fast the operator is typing. [RFC 6143] https://tools.ietf.org/html/rfc6143 https://tools.ietf.org/html/rfc6143
kop316 7y ago
Compression does not introdoce entropy to a stream. Please refer to Shannon's source coding theorm. If anything, it reduces entropy.
- hackinthebochs 7y ago
  But it does increase the entropy per byte, thus making patterns harder to spot.
  - kop316 7y ago
    ....so your argument us to hope an adversary only sees part of your video and not all of it?
    - johncolanduoni 7y ago
      No, their argument is that if you have a higher entropy per byte, there will be more variation in the aligned 16-byte chunks that are relevant for attacking AES-128-ECB. This reduces the probability of the attacker being able to find equal blocks.
      - kop316 7y ago
        And my argument is if I know the video encoding and compression sequence, I wouldn't depend on AES-ECB. I know the patterns that show up. If I am encrypting something, I only want to depend on the strength of the encryption. I don't want to hope that something else ensures that an adversary cannot figure out my ciohertext. That is a very bad idea.
        johncolanduoni 7y ago
        Sure, and nobody was arguing they should have used ECB or that they shouldn’t change it. Only that the ability to exploit this given compressed data is lower than the uncompressed penguin image example.
sudosysgen 7y ago
You're forgetting about the technical intricacies of compressed video. Compressed video is a mix of high and low entropy content, with a predictable time pattern to this. For example, one can easily use traffic analysis to find B-Frames, and run analysis on that. Bam, you get very low entropy due to the stationary nature of video conference.
- pja 7y ago
  Yeah, the B-frames were my thought too, but ordinary sensor noise would hopefully make the individual frames different enough. If you’re doing green-screen background switching, or transmitting a static image then it’s definitely going to be a problem. But given all the other security issues that seem to hover around Zoom like a cloud of angry bees, this is probably all moot - if you really want to crack a video stream then there are probably easier ways.

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.
stouset 7y ago
Compression already makes a compressed file roughly indistinguishable from random noise (module access to the decompressor). So the patterns have been removed. That doesn’t make this good, but it means that one specific example isn’t immediately applicable.
- monocasa 7y ago
  There's more in the stream than just compressed data. There'll be metadata info that you can make reasonable guesses about. ECB mode lets you take that information and apply it to other blocks in the ciphertext.
  - _jal 7y ago
    This thread is an excellent illustration of why you don't want your encryption implemented by merely good coders. You need people who know what they are doing.
    - stouset 7y ago
      I’m literally one of those people who “knows what they’re doing”. This is the problem with discussing ECB on an online forum. There’s no space to have a nuanced discussion without people cargo culting “ECB bad” over every comment. Yes, ECB is almost always the wrong choice. Yes, there are other ways it’s going to fail in this use case. Yes, compression before encryption itself often enables other attacks. No, I should not have to prefix a comment about ECB with this type of disclaimer when I’m making (what should be) an uncontroversial statement that the tux attack doesn’t directly apply to compressed image data. Ironically, when designing a protocol for my company, one of the reasons we didn’t use ECB when it would have been entirely justified (each chunk of data was precisely one block in size and keys were only ever used once) was because of potential backlash from people who only know “ECB bad” and nothing more.
  - stouset 7y ago
    I’m not arguing that. I’m saying that for compressed data, underlying patterns in data aren’t trivially exposed by ECB. Ergo, the “tux” attack on bitmap image files doesn’t really apply here. I meant nothing more and nothing less than that.
    - monocasa 7y ago
      And I'm saying that they aren't just sending compressed data, nor would hardly any practical communication application, which makes the "well maybe they have enough entropy that it doesn't matter?" argument moot.
staticassertion 7y ago
It's harder to extract patterns from high entropy data. I don't think anyone's saying that this is even an OK thing to rely on, at all, just that the nature of the data means that this specific weakness is likely more difficult to take advantage of. If zoom were transmitting text this would be relatively more serious.
- anaphor 7y ago
  What about the chat system? I doubt they're intentionally compressing the text there in order to increase the entropy. I guess they could be using gzip or whatever, but we'd need to look at how the protocol works in more detail. Or do they use a different system for the chat protocol altogether?

deleted 7y ago

[deleted]

kardos 7y ago

Zoom does screen sharing, right? Surely it's not transmitted uncompressed, but it is stationary for a long time and perhaps only small parts changing when they do (eg, switching slides). Is there an ECB-based weakness here?

whoopdedo 7y ago
Those unchanged pixels won't be transmitted. Only the changed part of the screen needs to be sent to the client. For example, RFB[RFC 6143] would send a 16-byte header with the size and position of a rectangular area of the screen followed by the pixels in that rectangle. Or multiple rectangles can be sent in one update message. But if you consider the case of text being typed, there will be a single rectangle per keystroke(s). Now I wonder if a sequence of these rectangles, all the same size and in roughly the same area of the screen, would lend to some sort of statistical analysis. At the very least the timestamps of the updates would tell you how fast the operator is typing. [RFC 6143] https://tools.ietf.org/html/rfc6143 https://tools.ietf.org/html/rfc6143

kop316 7y ago

Compression does not introdoce entropy to a stream. Please refer to Shannon's source coding theorm. If anything, it reduces entropy.

hackinthebochs 7y ago
But it does increase the entropy per byte, thus making patterns harder to spot.
- kop316 7y ago
  ....so your argument us to hope an adversary only sees part of your video and not all of it?
  - johncolanduoni 7y ago
    No, their argument is that if you have a higher entropy per byte, there will be more variation in the aligned 16-byte chunks that are relevant for attacking AES-128-ECB. This reduces the probability of the attacker being able to find equal blocks.
    - kop316 7y ago
      And my argument is if I know the video encoding and compression sequence, I wouldn't depend on AES-ECB. I know the patterns that show up. If I am encrypting something, I only want to depend on the strength of the encryption. I don't want to hope that something else ensures that an adversary cannot figure out my ciohertext. That is a very bad idea.
      - johncolanduoni 7y ago
        Sure, and nobody was arguing they should have used ECB or that they shouldn’t change it. Only that the ability to exploit this given compressed data is lower than the uncompressed penguin image example.

sudosysgen 7y ago

You're forgetting about the technical intricacies of compressed video. Compressed video is a mix of high and low entropy content, with a predictable time pattern to this. For example, one can easily use traffic analysis to find B-Frames, and run analysis on that. Bam, you get very low entropy due to the stationary nature of video conference.

pja 7y ago
Yeah, the B-frames were my thought too, but ordinary sensor noise would hopefully make the individual frames different enough. If you’re doing green-screen background switching, or transmitting a static image then it’s definitely going to be a problem. But given all the other security issues that seem to hover around Zoom like a cloud of angry bees, this is probably all moot - if you really want to crack a video stream then there are probably easier ways.