¿Por qué no puede un hash criptográfico dentro de un criptograma servir como MAC? [duplicar]

Question

¿Por qué no puede un hash criptográfico dentro de un criptograma servir como MAC? [duplicar]

#1 de Thomas Pornin (1 votos)
#2 de Desthro (0 votos)
#3 de John Deters (0 votos)

5

Mi pregunta está estrechamente relacionada con ¿Por qué? ¿Necesita autenticación de mensajes además del cifrado?

Específicamente estoy interesado en la criptografía de clave simétrica. Entiendo que los atacantes pueden modificar los mensajes criptográficos y el descifrado resultante será un mensaje alterado, los MAC están diseñados para resolver esto. Yo leí que debería cree el criptograma y luego genere un MAC desde el criptograma y envíelos juntos.

Mi pregunta es ¿por qué no podría uno simplemente adjuntar el mensaje original sin cifrar con un hash criptográfico del mensaje original y luego cifrarlos juntos? Entonces el receptor podría descifrar ambos y verificar el hash. Si se modificara el criptograma, el hash interno ya no coincidirá y ¿no sería difícil alterar el mensaje y / o el hash interno de manera que permanezcan consistentes ya que ambos están cifrados?

hmac

pregunta satur9nine 03.10.2014 - 07:53

fuente

3 respuestas

Lea otras preguntas en las etiquetas hmac

¿Qué información se expone cuando envío un mensaje desde mi dispositivo móvil? Política de seguridad del contenido e inicio de sesión de Facebook

score 1 · Answer 1

Anexar el hash y luego cifrar todo el lote no es necesariamente seguro. En realidad, dependiendo del sistema de cifrado, puede ser muy débil. Por ejemplo, suponga que el cifrado se realiza con un cifrado de flujo como RC4: el cifrado se realiza mediante XORing con un flujo pseudoaleatorio dependiente de la clave. Así, el atacante ve esto:

E = ( m || h ( m )) XOR S ( K )

donde m es el mensaje, h es la función hash, y S ( K ) es la secuencia pseudoaleatoria generada a partir de la clave K . Si el atacante adivina el valor de m (del contexto), entonces puede volver a calcular h ( m ), y luego obtener:

S ( K ) = ( m || h ( m )) XOR E

Luego, el atacante elige su propio mensaje m ', con contenido arbitrario, y envía:

E ' = ( m' || h ( m ')) XOR S ( K )

y voilà! La integridad ha sido derrotada.

score 0 · Answer 2

Acabo de familiarizarme con el ataque Padding Oracle descrito en el artículo que vinculó, y creo que respondió a su propia pregunta. Si el ataque de Padding Oracle puede llevar a un descubrimiento completo del texto sin formato, cifrar el mensaje de mensaje no cifrado Y el hash aún requerirá relleno, y por lo tanto lo hará vulnerable al descubrimiento.

Para implementar ambos, probablemente querrá hacer un hash del mensaje original, agregarlos juntos, cifrarlo, y luego copiar el texto cifrado resultante y agregarlo a su combinación cifrada. Eso lograría lo que desea, pero parece ser mucho trabajo cuando la solución original parece perfectamente aceptable.

score 0 · Answer 3

Por un lado, es ineficiente. El receptor tendría que pasar por todo el trabajo de buscar la clave, descifrando el mensaje antes de saber si valía la pena descifrarlo.

Del mismo modo, agrega riesgo. Si el MAC no computa, el receptor ni siquiera recuperará las claves necesarias para descifrar el mensaje, y el receptor nunca tendrá su carga útil. Esto podría ser crítico si la carga útil fuera maliciosa.

Considere este escenario. Digamos que su aplicación es un servicio web que acepta nuevos dibujos de artistas de todo el mundo que trabajan para usted. Todos sus artistas han recibido claves de firma para su trabajo y utilizan su clave pública para cifrarlos y enviárselas. Y digamos que su servidor era vulnerable a los archivos WMF maliciosos.

Soy un atacante, por lo que creo un WMF malicioso, creo algunos bytes aleatorios para el MAC, cifro el archivo y lo subo a su servidor. Su servidor descifra el archivo WMF y lo guarda para calcular el MAC. Pero la herramienta de indexación de su servidor lee el WMF intermedio y ejecuta el malware contenido en la vista previa, por lo que puede ser hackeado de todos modos. * Tenga en cuenta que esto sucede aunque todavía no haya verificado el MAC.

Si marcó primero el MAC, no habría descifrado la carga útil y no se habría expuesto al malware en el archivo WMF.

* Sí, el indexador que se ve comprometido por los archivos WMF fue una verdadera vulnerabilidad en Windows. Es imprudente suponer que un sistema está perfectamente libre de todas las vulnerabilidades.