Hacker News Reader

Comment by miked85 | Hacker News Reader

If the encryption scheme is poor, why would the data being compressed or not matter?

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.

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.

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.

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.

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.

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.

Literally nobody is making that argument or in any way suggesting that ECB is a great choice. Just that this one specific attack doesn’t apply.

Which specific attack?

The one discussed directly in the grandparents of this thread.

In your own words.

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.

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?

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.

"The use of ECB mode is not recommended because patterns present in the plaintext are preserved during encryption."

absolutely - I was asking why a poor encryption scheme would be considered acceptable just because the data is compressed.

Reply on news.ycombinator.com