Descripción general. Su propuesta no es segura (consulte más abajo para análisis de criptoanálisis). Es por eso que no es una alternativa razonable al cifrado autenticado.
Un poco más de fondo. ¿Por qué necesitamos cifrado autenticado? Se debe a que el cifrado sin autenticación no es seguro . Muchos desarrolladores no lo saben, por lo que terminan con un uso inseguro de la criptografía.
Es posible utilizar manualmente tanto un algoritmo de cifrado como un algoritmo de autenticación. Por ejemplo, puede usar la construcción de encriptación y luego autenticación utilizando un esquema de encriptación seguro y una autenticación de mensaje segura ( Algoritmo MAC). Sin embargo, esto requiere un esfuerzo adicional por parte del desarrollador.
El cifrado autenticado se diseñó como una primitiva única que es fácil de usar para los desarrolladores y que proporciona toda la autenticación necesaria (para que no tenga que hacer algunas cosas adicionales para proporcionar seguridad). Por lo tanto, es útil para la seguridad. Algunos esquemas de cifrado autenticados también tienen el beneficio de un mejor rendimiento que el cifrado por separado y luego la autenticación, pero eso es una consideración secundaria.
Lea No use cifrado sin autenticación para obtener más detalles sobre este tema.
Criptoanálisis de su esquema. Usted propuso que adjuntáramos un hash del mensaje antes de cifrar: en otras palabras, C = Cifrar ( K , M || H (M) ), donde || representa la concatenación de cadenas de bits. Este esquema no es seguro contra los ataques de texto sin formato seleccionado, con muchos algoritmos de cifrado. Por ejemplo, mostraré un ataque contra su propuesta, si está utilizando el cifrado en modo CBC (aunque el ataque también se aplica a muchos otros modos de cifrado).
Tenga en cuenta que si un hombre en el medio trunca un texto cifrado que se generó con el modo CBC (en un límite de bloque), el destinatario no notará el truncamiento, y después del descifrado recibirá una versión truncada del mensaje. que el remitente estaba tratando de enviar. Así que, con ese fondo, aquí está el ataque. Deje que Alice sea el remitente, Bob el destinatario y asuma una configuración de texto sin formato elegido.
El atacante elige un mensaje M que desea que Alice envíe: pero Alice se niega a enviarlo (tal vez M dice "transferir $ 100 de mi cuenta y dárselo a El atacante ", o algo así. El atacante construye algún otro valor X de modo que Alice esté dispuesta a enviar M ' = M || H (M) || X (tal vez X dice "¡es broma! no te atrevas"). El atacante convence a Alice para que cifre y envíe M '. Esto significa que Alice va a transmitir el texto cifrado C ' = Encriptar ( K , M' || H (M ') ) = Encriptar ( K , M || H (M) || X || H (M ') ). El atacante juega al hombre en el medio, captura C ' y lo trunca mientras está en vuelo. Llamemos a C '' el texto cifrado truncado. Bob recibirá C '' , lo descifra y luego verifica el hash. Si el atacante eligió el punto de truncamiento correctamente, luego de descifrar, Bob obtiene M || H (M) , verifica el hash, ve que el hash es correcto y concluye que Alice debe haber enviado M .
En otras palabras, al final de este ataque, Bob concluye que Alice autorizó la transmisión del mensaje M , pero nunca lo hizo. (Ella autorizó la transmisión de algún otro mensaje, pero no M .)
Si esto es o no una vulnerabilidad grave de seguridad dependerá del contexto en el que se use, como el formato del mensaje M . Pero, empíricamente, en al menos algunas aplicaciones, este tipo de ataque podría representar un serio peligro para la aplicación. Por lo tanto, los criptógrafos consideran que este no es un buen esquema de propósito general.
Dado que hay buenos esquemas que han sido cuidadosamente examinados y comprobados como seguros para uso general, los criptógrafos recomendarían usar uno de esos esquemas de propósito general (como el cifrado autenticado, o la construcción de cifrar y luego autenticar), y en particular, no utilice el que mencionó.