¿El cifrado AES de una pequeña cantidad de bloques sería menos seguro que cifrar un búfer acolchado grande y de tamaño fijo?

0

Mi aplicación cifra un archivo con AES, y los datos se leen, se cifran y se escriben con un búfer. Su tamaño se define con un valor BUF_SIZE, que es constante.

Intentaré explicar mi pregunta con un ejemplo.

Por ejemplo, el tamaño del archivo es de 1.73 GB y el búfer es de 16 KB. La aplicación calcula (fsize% BUF_SIZE) y descubre que permanecerán 14K de datos.

Por ahora, hace lo siguiente:

1) Lee estos 14 KB de datos al búfer

2) Rellena otros 2 KB con datos aleatorios

3) Encripta y escribe el búfer completo.

¡El problema es que después de tal cifrado, incluso un archivo de texto sin formato de 310 bytes se convierte en un monstruo de 16 KB!

La idea es cambiar el algoritmo para cifrar SOLAMENTE estos 14 KB y escribirlos en el archivo resultante.

Cuando estaba escribiendo ese algoritmo, por algún motivo consideré que la segunda forma era inaceptable; ahora no puedo recordar la razón.

¿Es seguro cifrar archivos como este?

Estoy más interesado en saber si hacerlo de una manera u otra como se describe anteriormente hace que los ataques de recuperación de clave completa sean más fáciles. Soy un estudiante que hace esto en mi tiempo libre, no un profesional.

EDIT 1 : mi aplicación cifra el encabezado con AES / GCM-128 y los demás datos, con el modo AES / CFB-256. Así que, según tengo entendido, no importa para CFB la cantidad de datos que quedan, ¿no?

EDIT 2 : Agregué este enfoque a mi aplicación. Gracias a todos los que ayudaron! (^_^)

    
pregunta Ilya 13.05.2015 - 15:32
fuente

2 respuestas

2

Según NIST, el algoritmo AES es capaz de usar claves criptográficas de 128, 192 y 256 bits para cifrar y descifrar datos en bloques de 128 bits (16 bytes). significa que cada bloque que va como entrada al algoritmo AES será de 16 bytes, por lo que si su BUF_SIZE es de 16 KB, cuando quiera ir al AES, nuevamente se dividirá en bloques de 16 bytes de tamaño, y Al final, si hay datos con menos de 16 bytes, se rellenarán (por ejemplo, si desea cifrar 35 bytes, (2 * 16) +3, los 3 bytes restantes se rellenarán con 13 bytes rellenados).

Sin embargo, su modo AES es importante, por ejemplo, si su modo es CFB, OFB o CRT , no requiere ningún relleno y puede ser paralelizado. Los modos CFB, OFB y CTR no requieren medidas especiales para manejar los mensajes cuyas longitudes no son múltiplos del tamaño del bloque, ya que los modos funcionan al XORAR el texto simple con la salida del cifrado del bloque. El último bloque parcial de texto plano está en XOR con los primeros bytes del último bloque de flujo de clave, produciendo un bloque de texto cifrado final que es del mismo tamaño que el bloque de texto plano parcial final. Esta característica de los cifrados de flujo los hace adecuados para aplicaciones que requieren que los datos cifrados de texto cifrado tengan el mismo tamaño que los datos originales de texto sin formato.

Pero algunos modos (a saber, ECB y CBC) requieren que el bloque final se rellene antes del cifrado.

también necesita un IV (Vector inicial) para producir distintos textos cifrados, incluso si el mismo texto simple se cifra varias veces.

entonces de acuerdo a tu ejemplo:

BUF_SIZE = 16 KB == > 16 * 1024 = 16384 bytes === > 16384 mod 16 = 0, significa que cada BUF_SIZE no necesita relleno. y sigue siendo uno (14KB) == > 14 * 1024 = 14,336 bytes == > 14,336 mod 16 = 0, por lo que también la división restante no necesita relleno y se dividirá en 896 bloques como entrada para el algoritmo AES, que crea el mismo tamaño de entrada que salida.

O, por ejemplo, para 310 bytes, no es necesario que lo coloque en 16KB, solo necesita crear 19 bloques con 16 bytes, y quedan 6 bytes y ese se rellena con 10 bytes. Juntos son 20 cuadras.

310 = (19 * 16) +6.

Por lo tanto, debe preocuparse por la fortaleza de la clave y el tamaño y la forma de protegerla, y también debe usar el AES estándar que no es suyo, porque si solo queda 1 byte se rellenará con suficientes bytes de relleno.

Por lo tanto, en esta situación no hay diferencia entre el cifrado de 1 byte o 1024000 bytes, los ataques son perpetuos, el tamaño de los datos no es importante.

    
respondido por el Ali 14.05.2015 - 07:49
fuente
0

AES es un cifrado de bloque , lo que significa que la operación central solo procesa un bloque (de exactamente 16 bytes con AES). Cuando quiera "cifrar un archivo", debe decidir cómo dividir y barajar sus datos y qué enviará realmente al motor AES; esto se denomina modo de operación .

Todos los modos de operación no son iguales. Además, algunos modos también ofrecen cierta verificación de integridad, mientras que otros no. En la mayoría de las situaciones en las que se necesita cifrado, también se necesita integridad también (porque la mayoría de los ataques pasivos también pueden convertirse en atacantes activos), por lo que usar un modo de cifrado que garantice la integridad es, en general, una buena idea . Utiliza GCM para el encabezado; Esto es bueno. No usas GCM para el resto del archivo; esto es menos bueno Debe utilizar GCM en todo.

Pensar en la integridad aclara las cosas. La integridad se trata de detectar alteraciones. Esto significa que, al descifrar, no puede usar los datos hasta que haya completado las verificaciones de integridad (hasta entonces, no sabe si son correctos o no). Por ejemplo, si utiliza un proceso de archivo completo de GCM, obtendrá una sobrecarga de espacio muy baja (para un archivo fuente de n bytes, la versión encriptada de GCM tendrá una longitud n +16 bytes, incluida la "etiqueta de autenticación" que encarna la verificación de integridad); sin embargo, esto significa que debe descifrar todo el archivo antes de comenzar a usarlo. Si tiene, digamos, un archivo de video de 2 GB, es posible que desee descifrarlo "sobre la marcha" (aunque solo sea para evitar tener que guardar el archivo descifrado en algún lugar, o mantenerlo completo en la RAM), es decir, utilizarlo antes de descifrado completado.

Para admitir el acceso "distribuido", debe cifrar y descifrar las cosas por bloques. Simplemente divida el archivo de entrada en bloques de k bytes para algún valor de k (no es necesario que todos los bloques tengan el mismo tamaño) y cifrándolos por separado (con GCM, cada cifrado rendimiento k +16 bytes). Para evitar que un atacante mezcle maliciosamente los bloques, deberías incluir algún tipo de secuencia. GCM es un cifrado autenticado con datos asociados , lo que significa que puede proteger con integridad tanto los datos que están encriptados y algunos datos adicionales. Un formato de cifrado de archivo seguro usaría el número de secuencia de bloque como "datos asociados".

Al utilizar CFB, no obtiene integridad, por lo que tiene las vulnerabilidades correspondientes. Además, el modo CTR es posiblemente mejor que CFB, y GCM usa el modo CTR internamente, por lo que definitivamente es preferible GCM. / p>     

respondido por el Tom Leek 14.05.2015 - 15:03
fuente

Lea otras preguntas en las etiquetas