Me gustaría agregar el cifrado AES a un producto de software, pero estoy preocupado por el aumento del tamaño de los datos. Supongo que los datos aumentan de tamaño, y luego tendré que agregar un algoritmo de compresión para compensar.¿El cifrado AES (128 o 256) amplía los datos? Si es así, por cuánto?
AES no expande los datos. Además, la salida generalmente no será compresible; Si tiene la intención de comprimir sus datos, hágalo antes de cifrarlo.
Sin embargo, note que el cifrado AES se combina generalmente con padding, que se aumentar el tamaño de los datos (aunque sólo por unos pocos bytes).
Me tomé la libertad de agregar una nota sobre el relleno. – sleske
Además, tenga en cuenta que, además del relleno, la criptodata requiere un modo CipherBlock que requiere un IV ("valor de inicialización") y un algoritmo MAC seguro para protegerse contra modificaciones. Para AES y la mayoría de los modos de bloque, el IV tiene 16 bytes y el HMAC más común (Sha1) es otros 16 bytes. –
Estoy bastante seguro de que el cifrado AES no agrega nada a los datos que se cifran, ya que eso daría información sobre las variables de estado, y eso es una mala cosa cuando se trata de criptografía.
Si desea mezclar compresión y encriptación, hágalo en ese orden. La razón es que los datos encriptados (idealmente) se ven como datos totalmente aleatorios, y los algoritmos de compresión terminarán por agrandar los datos, debido a su incapacidad para comprimirlos y a la contabilidad que viene con cualquier formato de archivo comprimido.
Si es necesaria la compresión, hágalo antes de encriptar.
AES no expande los datos, excepto unos pocos bytes de relleno al final del último bloque.
Los datos resultantes no son comprimibles, en cualquier caso, porque son básicamente aleatorios, ningún algoritmo basado en diccionario puede comprimirlos de manera efectiva. Una mejor práctica es comprimir primero los datos y luego encriptarlos.
Tenga en cuenta que los pocos bytes de relleno se agregarán incluso si la entrada es un múltiplo par del tamaño del bloque de cifrado; es necesario que haya * algo * de relleno para que el código de desbloqueo pueda calcular la cantidad de relleno que hay. –
No. El único cambio será una pequeña cantidad de relleno para alinear los datos con el tamaño de un bloque
Sin embargo, si comprime la nota de contenido que usted debe hacer esto antes de encriptación. Los datos encriptados generalmente no se pueden distinguir de los datos aleatorios, lo que significa que no se comprimirán.
@freespace y otros: una de las cosas que recuerdo de mis clases de criptografía es que no debes comprimir tus datos antes del cifrado, porque algunos fragmentos repetibles de la secuencia comprimida (como encabezados de sección, por ejemplo) pueden hacer que sea más fácil crackear tu encriptación
Si su algoritmo es tan vulnerable a un conocido ataque de texto plano, probablemente esté jodido independientemente. Existen cunas predecibles en muchos formatos estructurados comúnmente transferidos. La mayoría de los sistemas modernos están diseñados para operar en modos que evitan que dichos ataques sean factibles. – Brian
¡Correcto! los datos comprimidos a menudo tendrán menos segmentos repetibles o adivinables que el texto real real. Supongamos que está encriptando un archivo de código Java. ¿Alguien adivinará que // aparece a menudo? Además: los proveedores de Zip comprimen antes de encriptar. – Cheeso
@ Cheese Suena como algo de lo que debería ocuparse una IV aleatoria. – FluorescentGreen5
Es común comprimir datos antes de encriptar. Comprimirlo después no funciona, porque los datos cifrados de AES parecen aleatorios (como para cualquier cifra buena, aparte de los encabezados y demás).
Sin embargo, la compresión puede presentar ataques de canal lateral en algunos contextos, por lo que debe analizar su propio uso. Dichos ataques han sido reportados recientemente contra VOIP encriptado: lo esencial es que diferentes sílabas crean variaciones características en la tasa de bits cuando se comprimen con VBR, debido a que algunos sonidos se comprimen mejor que otros. Algunas (o todas) las sílabas pueden por lo tanto ser recuperables con suficiente análisis, ya que los datos se transmiten a la velocidad en que se generan. La solución es usar una compresión CBR (menos eficiente) o usar un buffer para transmitir a velocidad constante independientemente de la velocidad de datos que sale del codificador (lo que aumenta la latencia).
AES convierte bloques de entrada de 16 bytes en bloques de salida de 16 bytes. La única expansión es redondear los datos hasta un número entero de bloques.
Dado que el punto de cifrado es agregar entropía, espero que la compresión tenga poco efecto. Sin embargo, puedes probarlo y ver qué pasa. –