Hay varios factores que entran en juego. La primera es que el cifrado debe ocultar los patrones: si tiene un archivo que contiene el mismo contenido repetido varias veces, el cifrado debería ocultar este hecho. Si tiene un esquema de cifrado débil, eso filtra información sobre los patrones en el texto simple en sus textos cifrados, entonces la compresión puede ayudar a reducir la cantidad de información que se filtra. Al menos, esa es la teoría clásica. Cualquier esquema de encriptación que sea lo suficientemente bueno para ser usado en la actualidad debería ocuparse de todos los patrones, sin embargo, con compresión o sin compresión (consejo relacionado: nunca use el modo ECB directamente). Por lo tanto, el argumento clásico de la compresión antes del cifrado ya no es tan relevante (y la compresión después del cifrado no tiene sentido en casi todos los casos).

Otro argumento "clásico" es que las posibilidades de romper un cifrado aumentan con la cantidad de texto cifrado con el que tienes que trabajar. Entonces, si comprime sus mensajes antes de enviarlos, le da a un atacante menos material para trabajar. Nuevamente, para cualquier cifrado seguro bajo nociones modernas, no debería tener que preocuparse por esto. Debería actualizar sus algoritmos y tamaños de clave de vez en cuando de acuerdo con las recomendaciones más recientes, rotar las teclas, etc., pero el impacto de la compresión en esto será mínimo. Además, si encripta cada mensaje bajo una clave por mensaje y luego la transporta después de cifrarla con una clave de encriptación de claves, lo cual es una tarea bastante estándar (especialmente cuando se trata de criptografía de clave pública), controlando la cantidad de texto cifrado que se envía bajo una clave mucho mejor de lo que podrías al manipular la compresión.

El siguiente punto es que quizás desee que el cifrado oculte también la longitud de su texto cifrado hasta cierto punto. No es demasiado difícil obtener algunos "metadatos" sobre lo que alguien está haciendo en una conexión TLS observando las longitudes y las frecuencias de los paquetes. La compresión antes del cifrado puede ayudar a reducir la intensidad de la "señal" en algunos casos, pero si está preocupado por el análisis del tráfico, probablemente debería hacer otras cosas como rellenar a una longitud fija. Una vez más, la compresión puede hacer que la situación sea mala. un poco menos malo, pero no va a convertir una mala situación en una buena.

Finalmente, es posible que hayas escuchado que la compresión dentro del protocolo TLS se eliminará y prohibirá en v1.3, o al menos ese fue el caso la última vez que leí el borrador. Esto no tiene que ver con la compresión en general, sino porque la forma específica en que el cifrado, el relleno, los MAC y la compresión interactuaron en TLS 1.2 y los estándares anteriores tenían algunas vulnerabilidades (CRIMEN, BESTIA, etc.). Eso no significa que no pueda comprimir a un nivel más alto (de aplicación) o que la compresión debilite el cifrado en general, solo que no tiene lugar en el módulo de cifrado real, al menos no de la forma en que se realiza en TLS en el momento.

EDITAR

En respuesta a los comentarios que hacen más preguntas, aquí hay dos ejemplos de cómo la compresión puede ayudarlo o perjudicarlo.

Ejemplo 1 Estás solicitando un trabajo y aceptas enviar un mensaje cifrado a tu mejor amigo para decirte si lo obtuviste o no. Debido a que trabajas en TI, un simple "sí" o "no" no funcionará, tiene que ser un GIF animado, así que preparas dos archivos yes.gif y no.gif, y porque estás preocupado por que alguien esté mirando en el tamaño de archivo de su texto cifrado, ambos son exactamente de 64 KB. Pero el yes.gif está lleno de colores, ponis y arco iris, y cuando se comprime, 60KB de gran tamaño, el no.gif es una animación lenta / blanca en blanco y negro más recatada y se comprime a 4KB. Su programa de cifrado aplica automáticamente la compresión antes del cifrado. En este caso, la compresión arruina tu seguridad por completo.

Ejemplo 2 Se ha dado por vencido con los GIF animados y está de acuerdo en que la próxima vez que quiera reunirse con su amigo, le dará un correo electrónico cifrado simplemente diciendo "Vamos a encontrarnos el próximo [día de la semana]". Su programa de cifrado se encripta en bloques de 8 caracteres (64 bits). Si su mensaje es "Vamos a reunirnos el próximo lunes". encaja bien en 3 bloques, si es "Vamos a reunirnos el próximo miércoles". eso es 4 bloques. Falló otra vez. En este caso, "le comprimiría mentalmente" todos los días en sus primeras tres letras ("Reunámonos el próximo MIÉ") le habría salvado.

En resumen: la compresión no ayuda ni daña el cifrado de forma genérica; si normalmente tiene que lidiar con mensajes de longitudes similares pero con niveles variables de entropía / compresibilidad, entonces puede hacer más daño que beneficio.

El ataque CRIME funciona debido a un conjunto de circunstancias muy específicas que involucran la compresión como un ingrediente, pero no deberían ser aplicables al almacenamiento de archivos.

La compresión no es seguridad en absoluto. Es posible que esté confundiendo la compresión con ocultación de datos de esteganografía pero, sin embargo, ninguna de ellas proporciona verdadera seguridad, sino que simplemente oculta las cosas. Por supuesto, el cifrado protege sus datos.

De Wiki :

  

Los ataques de fuerza bruta pueden hacerse menos efectivos al ofuscar los datos que se van a codificar, algo que dificulta que un atacante reconozca cuándo ha descifrado el código. Una de las medidas de la fortaleza de un sistema de encriptación es el tiempo que teóricamente le tomaría a un atacante montar un ataque exitoso de fuerza bruta contra él.

Esto puede ser donde comienza la confusión. Podrías pensar que 'oh hey cuando uso Winzip y miro los datos hexadecimales todo se ve diferente, por lo tanto ha creado una pequeña capa de oscuridad, ¿verdad? ' ¡Incorrecto! A menos que esté utilizando un método de oscuridad único , todo lo que está haciendo está ralentizando el proceso de Comprobando el intento de fuerza bruta por una cantidad de tiempo increíblemente pequeña.

Esto se debe a que cada archivo tiene lo que se denomina firma de archivo (para que el sistema operativo pueda dar sentido a todo los datos), por lo que, a menos que cree su propia firma de archivo única u oculte sus datos dentro de otra firma, no se obtiene ninguna mejora con solo cambiar una firma por otra.

Varios ataques con nombres muy evocadores han demostrado que la compresión puede provocar vulnerabilidad al filtrar información sobre el texto sin formato:

• CRIMEN (Compresión de información de fuga hecha fácil)
• BREACH (Reconocimiento y Exfiltración del Navegador a través de la Compresión Adaptativa de Hipertexto)

Básicamente, si puede controlar alguna parte del texto sin formato, puede adivinar otras partes del texto sin formato si observa el tamaño del texto cifrado (porque la compresión será más efectiva cuando coincida con los patrones existentes en el texto sin formato).

Imagina que alguien está tratando de descifrar un archivo de forma forzada, y cuando se intenta una determinada contraseña, aparece un archivo de texto en inglés obvio.

O suponga que se intenta el mismo ejercicio, pero todos los bytes en el archivo de texto se desplazaron 79 lugares antes del cifrado.

El segundo enfoque es más fuerte, aunque la ofuscación (bytes de desplazamiento) NO es cifrado.

Lo mismo puede ser cierto para comprimir un archivo antes de cifrarlo.