¿Cuál es el beneficio de agregar la clave de cifrado de datos y luego almacenarla (cifrada) junto con los datos?

Le daré un ejemplo concreto de cuándo / por qué tiene sentido almacenar la clave (encriptada) junto con los datos (resulta que tengo la pestaña abierta al responder otra pregunta, ¿por qué no?):

Cifrado de disco completo de Android .

En pocas palabras: cuando enciendes Android Disk Encryption, genera una clave AES-128 que usa para cifrar la unidad (llamada clave maestra). Luego toma su patrón / PIN / contraseña y lo usa para derivar una segunda clave AES-128 que utiliza para cifrar y almacenar la clave maestra en el disco. ¿Sabes cómo lo primero que hace Android durante el arranque es pedir tu PIN / contraseña? Eso es porque lo necesita para descifrar la clave maestra para que pueda descifrar y montar el sistema de archivos principal. La razón para tener dos claves AES-128 es que si cambia su patrón / PIN / contraseña, solo tiene que volver a cifrar el archivo de la clave maestra, no todo el disco.

Otro buen caso de uso son los datos en tránsito, por ejemplo, S / MIME o PGP :

El cifrado de grandes cantidades de datos de texto / adjuntos con un cifrado asimétrico (como RSA) es muy lento, por lo que lo que hacemos es cifrar los datos masivos con AES mediante una clave aleatoria y IV, luego cifrarlos con la clave pública RSA del destinatario y adjunte la clave AES cifrada y la IV al masaje.

En referencia a tu punto 2. : la razón exacta de esta elección probablemente depende del caso de uso específico, pero una ventaja que viene a la mente es que puedes revelar la clave de una fila a alguien, por ejemplo, un auditor, sin comprometer ninguna otra fila en la tabla. También puede enviar los datos a alguien sin tener que hacer el trabajo de descifrarlos o volver a cifrarlos (un gran ahorro si los datos son grandes o si tiene requisitos de tiempo real).

La mayor diferencia, (no lo llamaré un beneficio) es que si usa una clave aleatoria diferente para cada dato, puede usar un IV estático y no tener que almacenar un IV con cada dato .

Esto no sin embargo, le brindará seguridad adicional sobre la opción 1, utilizando el mismo DEK y un IV aleatorio fuerte para cada pieza de datos.

El único beneficio potencial (y es un poco exagerado) es que si se accede a los datos de forma independiente, la exposición de una clave de cifrado de datos (pero no la KEK maestra) solo expone la única pieza de datos que está cifrada con Ese DEK, y ningún otro dato. Si este es un escenario de amenaza real para usted, entonces la opción 2 es definitivamente el camino a seguir. Si no, o si necesita acceder a muchos datos simultáneamente o en rápida sucesión, entonces la opción 1 tiene claros beneficios.

¿Has considerado un sistema de archivos encriptado? Funciona muy similar a tu segunda propuesta.

Los ejemplos son eCryptfs en Unix y los modos de NTFS en Windows. En segundo lugar, no hay formas posibles de romper AES que no sea un ataque de fuerza bruta; Serpent-256 cifrado es más lento, pero no se conoce una forma de violar más que unos pocos números.

En cuanto a por qué elegiría uno sobre dos, es por una cosa llamada el ataque de arranque en frío: si un pirata informático obtiene acceso a una computadora en hibernación con una unidad cifrada, puede tomar otra computadora con el mismo estándar de memoria, eliminar la memoria de la primera computadora después de enfriarla y colocarla en la segunda máquina y luego iniciarla antes de que se degrade. Por lo tanto, puede recuperar las claves de los archivos que estaba usando, por lo que si solo tiene una, es fácil descifrar el disco duro, mientras que el uso de un sistema de cifrado de archivos individual solo permitirá al pirata informático descifrar lo que estaba abierto y en ejecución.

En resumen, ambos funcionarán a menos que esté preocupado por los ataques de acceso físico.