4 ms·

Encrypted data attempts to look like random binary data, generally. Random binary data doesn't compress very well, sometimes even negatively.

unnouinceput 5y ago
OP said the other way around. We all know encrypted data does not compress well, but why would you need to disable compression when encrypting? Compressed data should actually be a smaller dataset hence encrypting it should be even faster.
- teddyh 5y ago
  In general, if the size is then visible after encryption, you can tell that the data, whatever is was, compressed well. This is information leakage, and can, IIUC, be exploited to surprising degrees.
  - unnouinceput 5y ago
    This doesn't make any sense. Here you have a disk. It's compressed or not, doesn't matter, the size stays the same. Then you use BitLocker on it. Again, compressed or not, after BitLocker encrypts it, the size is still the same. Your point?
    - teddyh 5y ago
      Like I said, “if the size is visible after encryption”. I don’t know if this is a huge issue with block device encryption in general, but then again, OpenZFS isn’t really only a block-device-level driver, is it? I would not be surprised to hear that OpenZFS somehow encrypts on some higher level than the whole block device.
    - rcxdude 5y ago
      Compress then encrypt opens up one important vulnerability: if an attacker can control a part of what you're encrypting (which they perhaps can on an average laptop drive, think a cookie in a webbrowser), and they can observe the size of the message after it has been compressed and encrypted, then with repeated attempts they can guess part of your secret and wait until the compression algorithm succeeds in matching part of their data with your secret. TBH, with whole-disk encryption I would not worry too much about this attack (the threat model is almost always theft where repeated observations of the cryptext after being modified by someone with the key are not practical), but it was core to a lot of vulnerabilities that basically forced TLS-level compression to be almost universally disabled.
aborsy 5y ago
True, but you could compress then encrypt. There have been what’s called “compression oracle” attacks on SSL with compress then encrypt scheme, see CRIME https://en.m.wikipedia.org/wiki/Oracle_attack https://en.m.wikipedia.org/wiki/Oracle_attack An attacker could inject known plaintext to an unknown source and observe the size of the ciphertext. If the size doesn’t change much, it means the chosen plaintext is correlated with the source. Several variants exist. Compression is often not recommended in VPNs.

unnouinceput 5y ago

OP said the other way around. We all know encrypted data does not compress well, but why would you need to disable compression when encrypting? Compressed data should actually be a smaller dataset hence encrypting it should be even faster.

teddyh 5y ago
In general, if the size is then visible after encryption, you can tell that the data, whatever is was, compressed well. This is information leakage, and can, IIUC, be exploited to surprising degrees.
- unnouinceput 5y ago
  This doesn't make any sense. Here you have a disk. It's compressed or not, doesn't matter, the size stays the same. Then you use BitLocker on it. Again, compressed or not, after BitLocker encrypts it, the size is still the same. Your point?
  - teddyh 5y ago
    Like I said, “if the size is visible after encryption”. I don’t know if this is a huge issue with block device encryption in general, but then again, OpenZFS isn’t really only a block-device-level driver, is it? I would not be surprised to hear that OpenZFS somehow encrypts on some higher level than the whole block device.
  - rcxdude 5y ago
    Compress then encrypt opens up one important vulnerability: if an attacker can control a part of what you're encrypting (which they perhaps can on an average laptop drive, think a cookie in a webbrowser), and they can observe the size of the message after it has been compressed and encrypted, then with repeated attempts they can guess part of your secret and wait until the compression algorithm succeeds in matching part of their data with your secret. TBH, with whole-disk encryption I would not worry too much about this attack (the threat model is almost always theft where repeated observations of the cryptext after being modified by someone with the key are not practical), but it was core to a lot of vulnerabilities that basically forced TLS-level compression to be almost universally disabled.

aborsy 5y ago

True, but you could compress then encrypt. There have been what’s called “compression oracle” attacks on SSL with compress then encrypt scheme, see CRIME https://en.m.wikipedia.org/wiki/Oracle_attack https://en.m.wikipedia.org/wiki/Oracle_attack An attacker could inject known plaintext to an unknown source and observe the size of the ciphertext. If the size doesn’t change much, it means the chosen plaintext is correlated with the source. Several variants exist. Compression is often not recommended in VPNs.