4 ms·
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, compres
by 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 agoLike 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 agoCompress 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.