Cifrado de secuencia / bloque agregue un hash simple para garantizar la integridad

Por qué no garantiza que la integridad sea más fácil de ver en el caso de un cifrado de flujo como RC4, donde el cifrado es un XOR bit a bit de los datos con un flujo dependiente de la clave. Básicamente, el cifrado del mensaje m es: e = m XOR s _k , donde s_k es la salida RC4 (un largo flujo de bits pseudoaleatorios producidos desde la tecla k ). Supongamos que aplica el método "agregar hash y luego cifrar". Comienzas con el mensaje m y obtienes esto:

e = ( m || h ( m )) XOR s _k

Ahora viene un atacante, y es inteligente, y adivina el contenido de m (recuerde: el atacante busca la integridad, no la confidencialidad, por lo que asumimos que ya conoce el mensaje). Como una función hash no tiene clave, el atacante puede volver a calcular m || h ( m ). De eso obtiene:

s_k = ( m || h ( m )) XOR e

Ahora el atacante tiene la secuencia secreta dependiente de la clave s_k . Luego procede a cifrar su mensaje falso m ' mediante la computación:

e ' = ( m' || h ( m ')) XOR s _k

Esto funciona tan bien como m ' no es más largo que m (podría ser más corto). Tras el descifrado, el hash coincidirá, y la integridad se anula. Dato curioso: conozco un sistema para banca en línea con base en la web que usaba esta construcción para la integridad y se implementó ampliamente. Afortunadamente, se ha solucionado hace más de una década.

El problema es que el hashing no proporciona nada en términos de integridad en su escenario. Usted está confiando en el cifrado solo para afirmar la integridad. Si obtengo una retención del mensaje y lo descifro, podría alterar el mensaje, volver a calcular el hash, cifrarlo nuevamente y transmitirlo.

Si confía solo en el cifrado para proporcionar integridad, este proceso funciona, pero el hashing no tiene ningún punto.