¿Cómo puedo auditar qué tipo de cifrado del Modo Bloqueo se está usando cuando no hay un código fuente disponible?

La prueba para el modo ECB / CBC / OFB / CTR es bastante sencilla. También es sencillo ver si el modo tiene cifrado autenticado como EAX / GCM (aunque no es sencillo ver qué modo de AE).

• ECB: tiene un archivo con muchos bloques similares en el texto plano. ¿Ves bloques idénticos en el texto cifrado? (Sí, esto es similar a la respuesta de Dan, la última parte de la respuesta de Adnan, pero se incluye para completar).
• CBC: Encripta un archivo y luego invierte un poco en la IV (típicamente en el primer bloque del texto cifrado); Digamos que volteaste el quinto bit del primer bloque. ¿Ves un bit volteado idéntico en el primer bloque del texto sin formato después de descifrarlo? De manera similar, voltear un bit aleatorio más adelante en el archivo, diga el octavo bit en el décimo bloque del texto cifrado. Cuando descifras, ¿ves el décimo bloque como una tontería y luego el octavo bit del undécimo bloque se invierte? Nuevamente, consulte el modos de operación para el descifrado de CBC y la razón debe ser clara.
• OFB / CTR: prueba si tienes un cifrado de flujo. Sin tocar el IV / Random Nonce (normalmente el primer bloque), si modifica un poco más adelante en el texto cifrado, ¿ve el mismo bit invertido en el texto plano descifrado? Si es así tienes un cifrado de flujo; una diferencia importante con respecto a CBC es que en este caso no hay bloque de galimatías. Estoy de acuerdo con el comentario de CodesInChaos de que hay poca diferencia de seguridad entre OFB / CTR. Si tiene la clave de cifrado ¹ llámela K, podría diferenciar entre OFB / CTR. Por ejemplo, sea c[1] , c[2] el primer y segundo bloque de texto cifrado y p[1] , p[2] sea el primer bloque de texto simple. Calcule D(K, c[1] XOR p[1]) y D(K, c[2] XOR p[2]) , donde D(K, c) es el descifrado del bloque c con la clave K . Si son números consecutivos, tienes el modo CTR. Si D(K, c[2] XOR p[2]) = c[1] XOR p[1] tiene modo OFB.
• EAX / GCM: ambos son encriptación autenticada: contienen un código de autenticación de mensaje (MAC) y el archivo no se descifra (incluso a gibberish) si el archivo se modifica, ya que el MAC no será válido con una probabilidad abrumadora.

Por supuesto, mucho de esto asume cosas como que conoces el tamaño del bloque, pero eso debería ser fácil de entender. Por ejemplo, cifrar un mensaje muy pequeño (1 byte). Luego, asumiendo que no hay MAC involucrado, es probable que cree un mensaje de dos bloques (IV + un bloque de texto cifrado rellenado, aunque CTR / OFB no lo haga); luego encriptar un mensaje más largo. De prueba y error, debería poder averiguar el tamaño del bloque y el tamaño IV.

EDITAR: Definitivamente estoy de acuerdo con el excelente punto que mencionó Thomas Pornin. Este tipo de ingeniería inversa podría ayudar a descubrir el cifrado de bloque, pero en realidad no prueba la seguridad. Hay muchas puertas traseras que podrían haberse colocado de forma encubierta que no se pueden detectar sin una ingeniería inversa dolorosa, al pasar por el ensamblaje. Por ejemplo, podría creer que tiene un cifrado de bloque de cifrado autenticado que solo se puede descifrar con su clave secreta construida a partir de su frase de contraseña. Pero en realidad, el archivo está cifrado con una clave aleatoria, que a su vez está cifrada al principio del archivo con su frase de contraseña, y luego una vez con su clave de puerta trasera. Por lo tanto, podrían descifrar cualquier archivo que uses. O tal vez el esquema hace este mismo esquema, por ejemplo, al comienzo del archivo, almacenar la clave por archivo para descifrarla usando su clave secreta, pero solo hay alrededor de mil millones o más de claves (que ellos conocen todas). O tal vez esté encriptado solo con su clave, pero la función de derivación de claves solo usa los primeros ~ 30 bits del hash de su frase de contraseña como su clave. Por lo tanto, podría ser muy rápidamente forzado con un billón de intentos. Del mismo modo, no tiene que ser una puerta trasera deliberada; simplemente podría ser un defecto de implementación sutil e impropio que permita ataacks de canal lateral.

¹ Esto no se asumió para otras partes: hay muchas maneras que puede conocer para ingresar una frase de contraseña al sistema de descifrado, pero no conocer la función de derivación de claves (o la función de cifrado) Utilizado internamente para generar la clave.

@dr jimbob da las respuestas correctas en cuanto a la detección de los modos de cifrado de bloque. Me gustaría complementar eso con otra visión de la pregunta; a saber: si no puede saber qué algoritmo se usa con qué modo de operación y qué formato, solo con la documentación del producto, entonces el producto no debe usarse . En términos generales, la seguridad no puede ser probada; por lo tanto, tenemos que recurrir a la mejor opción, que es tratar de asegurarnos de que el producto se diseñó e implementó con el debido cuidado y siguiendo las mejores prácticas y los estándares establecidos. Esto exige una amplia documentación y transparencia. Una gran parte de las "mejores prácticas" es documentar lo que haces . Si el producto utiliza cifrado para sus datos pero no dice cómo lo hace, entonces ya sabe que es sub-estándar para la parte de documentación. Por lo tanto, es más seguro asumir que el producto es descuidado y no usarlo.

Otro punto no relacionado es que tratar de determinar cómo funcionan las cosas dentro de un producto dado constituye ingeniería inversa y eso podría ser ilegal, dependiendo del país en el que viva y / o trabaje. Si es ilegal, debe abstenerse de ello e insistir en la documentación adecuada. Si es legal, entonces un poco de descompilación o desensamblaje a menudo ofrecerá una vista más precisa de lo que hace el producto, incluido el tipo de algoritmo y el modo de cifrado. Este enfoque complementa las pruebas sugeridas por @dr jimbob.

El ECB, al menos, es fácil de detectar siempre que pueda solicitar la versión encriptada de los textos seleccionados.

Simplemente compare el cifrado de 0000000000000000000000... y 1000000000000000000000... , asegurándose de que sus textos sean lo suficientemente largos como para abarcar algunos bloques.

Si el BCE está en uso, los textos cifrados diferirán solo en el primer bloque ; los bloques posteriores serán idénticos. Esto se debe a que el BCE encripta cada bloque de forma aislada. Si se está utilizando algún otro modo (de propagación), los dos textos cifrados, con alta probabilidad, diferirán en todos los bloques. Esto se debe a que la diferencia en el primer bloque se incorpora en los bloques subsiguientes.

Tenga en cuenta que no necesita conocer la clave de cifrado para lograr esto.

Ya que estás tratando de encontrar el modo de encadenamiento, supongo que ya conoces el algoritmo de cifrado y la clave de cifrado.

La solución más fácil en la que puedo pensar es definir un texto simple y luego dárselo a su caja negra de encriptación y obtener el texto cifrado. Luego, escriba un script que descifre independientemente el texto cifrado utilizando todo el número finito de modos de encadenamiento disponibles y luego compare el resultado con su texto simple. Cualquiera que produzca una coincidencia, BINGO!

Otra forma es definir un texto simple, cifrarlo con todos los modos de encadenamiento disponibles y luego comparar el texto cifrado con la salida de la caja negra de cifrado para el mismo texto simple.

La auditoría de ECB es un poco más divertida. Defina su texto simple para tener bloques idénticos (bloques de 16 bytes para AES) y observe la salida para bloques de texto cifrado de 16 bytes idénticos. Este método no requiere el conocimiento de la clave.