¿Cuál es el mejor método de compresión personalizado para usar cuando tengo SSL?

9

Supongamos que tengo una aplicación que realiza el cifrado mediante SSL y siempre que no pueda controlar qué paquete de cifrado se está negociando, y suponiendo que tengo alguna compresión personalizada sobre los datos antes de que tenga lugar el cifrado. ¿Cuál sería el mejor modo de compresión a utilizar? Si continúo y uso DEFLATE / GZIP am paranoid, podría exponerme a un ataque en el que un atacante pueda exponer datos encriptados utilizando los ataques de texto sin formato elegidos. (algo similar al ataque de CRIME)

    
pregunta Cookies 01.08.2013 - 17:33
fuente

1 respuesta

24

El cifrado oculta datos pero pierde tamaño de datos . Esa es una propiedad común de todos los sistemas de encriptación: los datos encriptados tienen (más o menos) el mismo tamaño que los datos claros.

La compresión altera el tamaño de datos pero lo hace encontrando "redundancias" (en un sentido vago) en los datos. Por lo tanto, la tasa de éxito de la compresión depende del contenido de datos . Por lo tanto, la compresión hace que tamaño de datos dependa del contenido de datos .

Tome los dos juntos, y esto lo llevará a una conclusión inevitable pero sombría: la compresión filtra información sobre el contenido de los datos, incluso a través del cifrado. La única conclusión general es que no deberás comprimir nada .

El CRIME attack simplemente funciona con esa idea, en una configuración específica de la Web donde el atacante elige una parte de los datos comprimidos y trata de obtener otros datos confidenciales que también forman parte del flujo comprimido. Este es un ataque de texto simple elegido y hace que el ataque sea realmente eficiente. Sin embargo, en general, una fuga es una fuga: incluso en escenarios de ataques puramente pasivos, la compresión hará que su conexión sea "menos segura".

El principio no es específico de Deflate ; cambiarlo a un algoritmo personalizado no lo salvaría. Desinflar no es "especialmente débil" o "especialmente fuerte" a ese respecto.

Todo lo anterior se aplica a todos los algoritmos de compresión sin pérdida . No para los algoritmos de compresión con pérdida que logran un ancho de banda de datos fijo. Por ejemplo, si comprime música en un MP3 a exactamente 128 kbits / s (sin velocidad variable), el tamaño de los datos resultantes no dependerá del contenido de la música, solo de la duración de la música original. Pero, por supuesto, los algoritmos de compresión con pérdida son aplicables solo a los datos donde se puede tolerar la pérdida; p.ej. Sonido, no XML.

(Lo que pasa con "lossy" es que no se puede garantizar una tasa de compresión fija sin tener alguna pérdida de datos potencial, debido a la pigeonhole principio , a menos que su "compresión" sea en realidad una falta de compresión, con los datos de entrada totalmente sin cambios.)

    
respondido por el Tom Leek 01.08.2013 - 17:51
fuente

Lea otras preguntas en las etiquetas