Me gustaría comprimir los datos antes de cifrarlos y almacenarlos en una base de datos MySQL para reducir especialmente los requisitos de ancho de banda. En el futuro, la base de datos puede ser accesible a través de una interfaz web.
Varios comentarios sobre la inseguridad de la compresión de texto sin formato antes del cifrado, relacionados con infracciones de seguridad como CRIME o BREACH, hacen que no esté seguro de cómo hacerlo. Además, algunos argumentan que la compresión antes del cifrado es en realidad una buena práctica de seguridad. Me doy cuenta de que los ataques como CRIME o BREACH son escenarios específicos, pero me preocupa que mi aplicación esté demasiado cerca (o eventualmente se acerque demasiado) a un escenario similar donde la compresión pueda representar un riesgo de seguridad (el contenido de la base de datos puede ser robado, comprometido etc). Tampoco soy lo suficientemente experto como para comprender completamente todos los aspectos, detalles y matices de CRIME o BREACH.
Después de leer esta discusión sobre el tema, con la recomendación de rellenar el texto plano con un nonce aleatorio antes de la compresión, me pregunto si la siguiente implementación (en PHP) hará el trabajo de manera segura:
$plaintext = gzcompress ($plaintext . openssl_random_pseudo_bytes (64));
$cipher_text = openssl_encrypt ($plaintext, 'aes-256-cbc', $key, 0, $iv);
La integridad de los datos se garantiza mediante un procedimiento de firma / verificación HMAC en el texto y la clave del cifrado.
¿Es esta una implementación segura?
¿Habría algún beneficio en el hecho de que el nonce sea de longitud aleatoria, y luego agregar la información de longitud al final del relleno para eliminar el relleno después del descifrado? ¿O debería ser la longitud del nonce en relación con la longitud del texto sin formato (que normalmente sería de al menos 512 bytes)?
NOTA: por lo que puedo decir, mi aplicación específica y la solución propuesta no parecen ser respondidas por el posible duplicado sugerido en los comentarios.