Security risks of symmetric encryption with compression for database data

Question

I would like to compress data before encrypting and storing it in a MySQL database to reduce especially bandwith requirements. In the future, the DB may be accessible via a web interface.

Various comments on the insecurity of compression plaintext prior to encryption, related to security breaches such as CRIME or BREACH, make me unsure of how to do this. Also, some argue that compression prior to encryption is actually good security practice. I realize that attacks such as CRIME or BREACH are specific scenarios, but I am concerned that my application might be too close (or eventually come too close) to a similar scenario where compression may pose a security risk (DB contents can be stolen, server compromised etc). I am also not enough of an expert to fully understand all the aspects, details and nuances of CRIME or BREACH.

After reading this discussion on the topic, with the recommendation to pad the plaintext with a random nonce before compression, I wonder if the following implementation (in PHP) will safely do the job:

    $plaintext = gzcompress ($plaintext . openssl_random_pseudo_bytes (64));
    $cipher_text = openssl_encrypt ($plaintext, 'aes-256-cbc', $key, 0, $iv);

Data integrity is ensured through an HMAC signing / verification procedure on the cipher text and key.

Is this a safe implementation?

Would there be any benefit in the nonce being of random length, and then adding the length information to the end of the padding in order to remove the padding after decryption? Or should the length of the nonce be in relation to the length of the plaintext (which would typically be at least 512 bytes)?

NOTE: as far as I can tell, my specific application and proposed solution do not seem answered by the possible duplicate suggested in the comments.

Answer 1

CRIME and BREACH depend on the attacker to control part of the data and then see how the length of the encrypted data changes. In the case of a web application the attacker can often control part of the data but has no knowledge how much space the data need after compression and encryption.

DB contents can be stolen

To make these compression based attacks work the attacker has to be able to control the input to the database and then steal the database again and again after each change in the attacker controlled input. If the attacker is capable of stealing the database again and again then you might have other serious problems (like the attacker having direct access to the encryption key) and encryption will probably not help you anyways.

server compromised etc

The server has to be compromised in a way that the attacker can control parts of input to the database and is able to read the encrypted input or at least determine it's size. This is a very specific scenario and in most cases the attacker will probably be deeper in the system and has access to the encryption keys anyway. Or that attacker is not that deep in the system and has no access to the encrypted data or the size of the encrypted data.

...I also do wonder whether my proposed solution will in fact protect the encrypted data against attacks related to compression

No it will not. Since you are adding a fixed number of random bytes at the beginning you will in effect just add a string which in most cases cannot be further compressed. And thus you just add a fixed length to the compressed content which does not make this kind of attacks any harder. A better way would be to add a random amount of data but this will also only slow down the attack.

For a more detailed discussion see Can BREACH be thwarted by simply adding a sort of "salt" into the page being compressed?.