I would like to compress data before encrypting and storing it in a MySQL DB to reduce especially bandwith requirements (compression reduces bandwith by 70-80%). At present, all is handled by a server-based script. In the future, the DB may also 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.
Am I understanding the issue correctly?
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)?