¿El cifrado simétrico proporciona integridad de los datos?

El cifrado simétrico no proporciona integridad. La cantidad de control que un atacante puede tener sobre los datos cifrados depende del tipo de cifrado; y algunos detalles específicos de algunos modos de encriptación pueden dificultar un poco la vida del atacante si desea realizar modificaciones quirúrgicas. Con CBC, el atacante puede voltear cualquier bit que desee, siempre que no le importe transformar una docena de otros bytes en basura aleatoria.

Hay modos de cifrado recientes que combinan el cifrado simétrico y la integridad comprobada (con un MAC ). Estos modos garantizan tanto la confidencialidad como la integridad. AES-CBC es no uno de ellos. Si desea un modo de cifrado con integridad, le recomiendo EAX .

Actualización: con respecto a su experimento: CBC es un modo en el que la longitud de los datos de origen debe ser un múltiplo de la longitud del bloque de cifrado del bloque (16 bytes, para AES). Dado que un mensaje de entrada arbitrario puede tener cualquier longitud, se agrega relleno : algunos bytes, con contenidos específicos que pueden eliminarse de forma inequívoca al descifrarlos. En su caso, OpenSSL se queja de que, al descifrarlo, no encuentra una estructura de relleno adecuada. Sin embargo, si el atacante no altera los últimos 32 bytes de los datos encriptados, el relleno no se dañará, por lo que las alteraciones de todos los últimos 32 bytes permanecerán sin ser detectadas. E incluso para los últimos 32 bytes, hay formas de evadir la detección con una probabilidad no tan pequeña.

El cifrado CBC no proporciona integridad de datos. He aquí por qué:

Corregir alguna clave k (desconocida para el atacante). Sean E (k, -) y D (k, -) las funciones de cifrado y descifrado de algunos cifrados de bloque. Sea p un bloque simple de texto plano. Voy a denotar XOR por +. Después de arreglar algunos IV, ciframos de la siguiente manera:

c = E (k, p + IV).

Luego, enviamos IV y c sobre el cable. Para descifrarlo, computamos

p = D (k, c) + IV.

(Tenga en cuenta que esto es equivalente a la declaración D (k, c) = IV + p.)

Ahora, suponga que un atacante conoce un solo par de texto simple / texto cifrado. Vamos a denotarlos como p y (IV, c), como arriba. Ahora, supongamos que al atacante le gustaría crear un texto cifrado que descifre a algún otro bloque de texto simple que elija, digamos p '. Afirmo que (IV + p + p ', c) se desencripta a p'. ¿Por qué?

Bueno, simplemente seguimos el procedimiento de descifrado anterior, reemplazando IV con IV + p + p '. Tenemos

D (k, c) + (IV + p + p ') = (IV + p) + (IV + p + p') = p '.

Sorprendentemente, el modo ECB no es vulnerable a este problema (aunque tampoco apoyo su uso).

El cifrado AES-CBC no proporciona integridad. Dependiendo de cómo se implementa y usa, puede ocurrir que se detecten algunas modificaciones accidentales en el texto cifrado, pero no se defiende contra la manipulación malintencionada del texto cifrado.

El cifrado sin autenticación es uno de los errores más comunes en el uso de la criptografía . Ha generado serias vulnerabilidades en muchos sistemas, incluyendo ASP.NET, encriptación XML, Amazon EC2, JavaServer Faces, Ruby on Rails, OWASP ESAPI, IPSEC y WEP. Vea el enlace anterior para más información.

La solución: debe usar un esquema de cifrado autenticado (no AES-CBC), como EAX, o debe usar un código de autenticación de mensaje, como CMAC, en el modo de cifrar y autenticar.

Si va a implementar la criptografía usted mismo, lo invito a leer la pregunta aquí titulada Lecciones aprendidas y conceptos erróneos con respecto al cifrado y criptología para ayudarlo a evitar algunos de los errores más comunes. El uso del cifrado sin autenticación es uno de ellos.

Los cifrados simétricos por sí solos no proporcionan integridad porque no detectan modificaciones maliciosas o accidentales en el texto cifrado; el descifrado generará algo más que el texto sin formato original y, a menos que esto resulte en una violación del protocolo para la carga útil descifrada, entonces tiene un problema de integridad.

La solución es incluir texto simple dentro de paquetes que incluya datos que puedan usarse para validar la integridad del paquete, generalmente una suma de comprobación basada en hash ( editar: con clave HMAC). Esto es lo que se hace, por ejemplo. para la seguridad de la capa de transporte.

Aquí hay un ejemplo de un esquema de protección de texto sin formato utilizado en un byte seguro de Versile Platform protocolo de transporte (descargo de responsabilidad: estoy involucrado en el desarrollo de VP).

Editar: me di cuenta de que la encapsulación de mensajes es una exageración para su escenario, que involucra un archivo completo, por lo que es mejor que solo agregue un MAC con clave en el texto cifrado completo. Para formatos de paquetes protegidos, como D.W. señala que los detalles son importantes, y la "suma de comprobación" debe realizarse como un MAC con clave.

Si incluye el texto simple, entonces diría que sí, utilizando una clave simétrica para cifrar algo, donde el receptor puede descifrarlo y compararlo con el texto simple, proporciona integridad de los datos.