Ya surgieron un par de preguntas comparando Hash y MAC, pero busqué y no encontré respuesta a mi pregunta.
Por lo general, enviamos "Encrypt (M, k) || MAC (M, K)" para que el receptor pueda verificar la integridad y la autenticación del mensaje.
Pero parece que "Encrypt (M, k) || Hash (M)" funciona igual. ¿Es este esquema de autenticación de mensajes vulnerable?
Tenga en cuenta que incluso los cifrados y MAC ingenuos (es decir, Encrypt(M, k) || MAC(M, K) ) tienen una vulnerabilidad. Si el atacante conoce una cantidad de texto sin formato posible que el mensaje podría contener, entonces pueden averiguar el contenido de un mensaje comparándolo con el hash de MAC del texto sin formato conocido. El Encrypt-and-Hash también sufre la misma vulnerabilidad, y es mucho más fácil, ya que el atacante puede generar sus propios hash calculando el hash de textos similares en lugar de tener que interceptar mensajes pasados con contenido idéntico.
Por ejemplo, si sabes que Alice siempre le envía un mensaje a Bob cada una de las tres a las tres posibles opciones de café: "El café de hoy es Cappuccino / Black / Moccacino", entonces si el hash del mensaje coincide con uno de ellos, lo harías Conozca la elección de café de Alice.
Con MAC, deberá coincidir con un texto sin formato conocido anterior o un "oráculo" (que puede generar mensajes cifrados con el texto sin formato elegido). Esto se denomina ataque de texto sin formato elegido .
La mejor práctica actualmente aceptada es cifrar y luego MAC (es decir, Encrypt(M, k) || MAC(Encrypt(M, k), K) ).
Entonces, la pregunta es: ¿por qué no reemplazar esto con Encrypt-then-hash: Encrypt(M, k) || Hash(Encrypt(M, k)) es obvio? Dado que cualquiera puede calcular el hash de la parte cifrada, este hash no proporciona autenticación.
Bonificación: Otra posible construcción es MAC-then-Encrypt (es decir, Encrypt(MAC(M, K), k) ), esto es vulnerable a los ataques que modificaron el texto cifrado, lo que probablemente producirá basura en el servidor y será rechazado debido a un hash incorrecto, pero puede Aún así proporcionar información útil para el atacante. Uno de estos ataques es el ataque oracle de relleno . Hash-then-Encrypt es vulnerable al mismo ataque.
Sugiero leer sobre los temas de cifrado autenticado o cifrado autenticado con datos asociados.
Al igual que agregó la etiqueta authentication a su pregunta, esa es realmente la respuesta. El MAC implica una información que debe ser conocida solo por las partes que se comunican: la clave. Cuando se combinan con el cifrado (como en sus preguntas), los MAC se utilizan con el cifrado simétrico, por lo tanto, la clave será la misma y solo la conocerán las dos partes que se comunican.
Al contrario de un hash simple (que proporciona integridad ), un MAC también proporciona autenticación .
(En el cifrado asimétrico, las firmas digitales proporcionan estas características).
Esto no es extremadamente importante cuando se realiza el cifrado, ya que un atacante necesitaría el mensaje descifrado para generar el hash de todos modos. La parte autenticación del MAC es mucho más importante en la comunicación no cifrada.
Demonios, asumiendo que K es la clave de un cifrado de bloque y M el texto en claro entonces:
Encrypt(M, K) || MAC(M, K) Encrypt(M, K) || Hash(M || K) Son equivalentes en el significado de alto nivel. Dado que un hash criptográfico que recibe una clave secreta como entrada es una forma válida de generar un MAC.
Lea otras preguntas en las etiquetas authentication hash cryptography