¿Qué tan difícil es modificar el texto cifrado AES de una manera significativa?

Si el texto sin formato acolchado se ajusta a un solo bloque, luego edítelo de manera significativa sin saber que la clave debería ser prácticamente imposible, en el sentido técnico de poder hacerlo (incluso solo una parte del tiempo) contaría como una ruptura a gran escala de AES.

En otras palabras, bloque único El cifrado AES se autentica automáticamente en el grado exacto en que el espacio de válido plaintexts es pequeño comparado al espacio de todos los bloques posibles (suponiendo que el destinatario verifique realmente que el bloque descifrado es válido). No importa si los colores de la placa válidos son en su mayoría similares o se ven muy diferentes; todo lo que cuenta es sólo cuántos de ellos hay. Esto se debe a que AES, como cualquier otro buen cifrado de bloques, se supone que se comporta como una permutación pseudoaleatoria del espacio de todos los bloques posibles.

Por supuesto, esto ignora la posibilidad de ataques de protocolo de nivel superior, como engañar al receptor para que acepte un bloqueo que ya estaba cifrado por separado (por ejemplo, para una ejecución diferente del protocolo).

Una vez que su texto sin formato es más largo que un bloque, el uso del BCE hace que sea trivialmente fácil de mezclar y combinar entre piezas de mensajes codificados por separado en los límites del bloque. Pero esta es una propiedad del BCE, no de AES en particular. Ninguna aplicación media seria debería usar el BCE para datos que no se conocen muy bien siempre para que quepan en un solo bloque.

En su ejemplo, parece que sería mucho más relevante para atacar la aplicación A directamente que para atacar la comunicación entre A y B. Por ejemplo, si la aplicación A se ejecuta en un dispositivo o cuenta que el usuario controla, el usuario probablemente podría modificar los datos antes de que la aplicación A los encripte, y / o inspeccione la aplicación (¿en ejecución?) para extraer la clave.

Alternativamente, parece que el protocolo que estás dibujando probablemente sería vulnerable a los ataques de repetición, sin molestarse en editar ningún mensaje. Esto significa que un ataque en el transporte TLS (como engañar al cliente para que confíe en una raíz de CA que usted controla) podría convertirse en un ataque en la parte de autenticación, es decir, el cifrado adicional de las credenciales puede dar mucho menos. seguridad que los diseñadores pretenden.

La modificación de los datos cifrados a veces es posible a través de un ataque de bitflip . Esto es más un ataque del modo de operación de cifrado por bloques y no realmente en el algoritmo de cifrado. En algunos modos de operación (pero no en ECB), el texto cifrado está XORed con texto simple del bloque siguiente o anterior. Esto significa que voltear un poco confunde un bloque completo y voltear un bit en otro bloque.

Para un ejemplo práctico, considere que nos sirven una cookie cifrada que contiene lo siguiente:

{"user": "johndoe", "nick": "john", "admin": 0}

Cuando se encripta utilizando el modo CBC, se divide en bloques de 16 bytes. Cada bloque está XORed con el bloque anterior (o el vector de inicialización) y se cifra. El mensaje consta de los siguientes bloques:

• {"user": "johndo
• e", "nick": "joh
• n", "admin": 0}

Ennuestroataquedebitflip,cambiamosunpocoeltextocifradodelbloque2.Estoharáqueelbloque2eneltextoplanodescifradoseconviertaenbasura,perotambiénunpocoenelbloque3.EstosucedeporqueelresultadodeldescifradoesXORedconeltextocifradodelbloqueanterior,queestábajonuestrocontrol:

ElresultadoesunacookiequecontieneJSONválido,conelindicadordeadministradorestablecidoen1:

{"user": "johndoaRbUTPasBIrmAnO5n", "admin": 1}