En la práctica, es casi tan resistente con el cifrado como sin él, siempre que haga una copia de seguridad de la clave maestra y los metadatos correctamente.
Además de los metadatos, la corrupción afectaría solo el bloque del bit dañado, en la mayoría de los casos, solo 16 bytes.
Para la mayoría de las situaciones de corrupción de datos, con la clave y las herramientas (como su contraseña y Veracrypt / LUKS), tiene el mismo acceso que un disco no encriptado, tal como lo hace normalmente con el uso diario de un disco encriptado. El cifrado solo agregaría un paso adicional (abrir una partición cifrada) de lo normal. Entonces, en este caso, se comporta igual que los datos no cifrados.
Con Veracrypt o Luks, debe almacenar la clave maestra en el disco, que está cifrada con su contraseña. Dañar este sector (es) causaría la pérdida permanente de datos. Esto se puede resolver fácilmente con la copia de seguridad de la clave maestra (algunos kilobytes de tamaño), algo fácil de hacer con ambos software, y es muy recomendable para todos.
Detalles sobre metadatos no
Tanto Veracrypt como Luks usan XTS hoy. En este modo, se calcula una clave para cada bloque. En una simplificación, para cifrar el bloque i, use una clave generada con las claves maestras y el número de bloque. Entonces, el cifrado de un bloque es independiente de otro. Si corrompe alguna información, se restringirá a ese bloque.
En XTS, rompe el bloque en subbloques (generalmente de 16 bytes) y crea una clave, y encripta ese subbloque con él. Eso significa que si cambiamos un poco, solo estos 16 bytes se verían afectados.
Como prueba, al cambiar un solo bit en un volumen Luks, cambia 16 bytes del archivo original a galimatías, pero los otros 496 aún permanecen sin cambios. En un archivo 7zip, utiliza un método de flujo, que todos los bytes están encadenados, por lo que un cambio de byte afectaría a todos los restantes, este no es el caso aquí.
Algunos consideran que esto es un problema, ya que puede saber con precisión de 16 bytes cuándo y dónde cambia un texto sin formato, comparando solo los datos cifrados.
Se puede encontrar más información interesante sobre esto en estos enlaces:
/crypto/6185/what-is-a-tweakable-block-cipher
/security/39306/how-secure-is-ubuntus-default-full-disk-encryption
https://en.wikipedia.org/wiki/Disk_encryption_theory
Detalles sobre la llave maestra
LUKS
LUKS tiene algunos sectores al comienzo de la partición (o disco) con metadatos, que almacenan métodos de encriptación, otros parámetros y 8 ranuras de teclas. Para cifrar y descifrar el disco, utiliza una clave maestra , un gran número aleatorio generado al crear un contenedor LUKS. Para almacenarlo, encripta la clave maestra con su contraseña, iterando una función hash criptográfica muchas veces sobre la contraseña y generando una clave específica para esa ranura. Puede tener 8 contraseñas diferentes para el mismo disco, cada una encriptando la clave maestra con una contraseña diferente en una ranura. Cuando cambia la contraseña, es tan simple como cifrar la clave maestra y no cambiar toda la partición.
Entonces, cuando estas ranuras y metadatos están dañados, no puede recuperar la clave maestra que realmente se usa para descifrar, perdiendo todos los datos en el disco. Esta es una manera fácil de destruir rápidamente todos sus datos. Pero si tiene una copia de seguridad del encabezado de volumen, es bastante fácil recuperarlo.
A continuación se muestra una copia de las preguntas frecuentes de LUKS sobre la copia de seguridad extraída de https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequencyAskedQuestions#6-backup-and-data-recovery
6.2 ¿Cómo hago una copia de seguridad de un encabezado LUKS?
Si bien puede copiar el número apropiado de bytes desde el inicio de la partición LUKS, la mejor manera es usar la opción de comando "luksHeaderBackup" de cryptsetup. Esto también protege contra errores cuando se han utilizado parámetros no estándar en la creación de particiones LUKS. Ejemplo:
cryptsetup luksHeaderBackup --header-backup-file <file> <device>
Para restaurar, use el comando inverso, es decir
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
Si no está seguro acerca de la restauración de un encabezado, primero haga una copia de seguridad del actual. También puede probar el archivo de encabezado sin restaurarlo utilizando la opción --header para un encabezado separado como este:
cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>
Si eso desbloquea tus llaves, eres bueno. No olvide cerrar el dispositivo nuevamente.
En algunas circunstancias (encabezado dañado), esto falla. Luego use los siguientes pasos:
Primero determine el tamaño de la clave maestra:
cryptsetup luksDump <device>
da una línea del formulario
MK bits: <bits>
con bits iguales a 256 para los valores predeterminados antiguos y 512 para los valores predeterminados nuevos. 256 bits equivale a un tamaño de encabezado total de 1'052'672 Bytes y 512 bits, uno de 2MiB. (Consulte también el Artículo 6.12) Si luksDump falla, asuma 2MiB, pero tenga en cuenta que si restaura eso, también puede restaurar el primer 1M más o menos del sistema de archivos. ¡No cambie el sistema de archivos si no pudo determinar el tamaño del encabezado! Con eso, restaurar una copia de seguridad de encabezado demasiado grande todavía es seguro.
En segundo lugar, volcar el encabezado al archivo. Hay muchas formas de hacerlo, prefiero las siguientes:
head -c 1052672 <device> > header_backup.dmp
o
head -c 2M <device> > header_backup.dmp
para un encabezado de 2MiB. Verifique el tamaño del archivo de volcado para asegurarse. Para restaurar dicha copia de seguridad, puede probar luksHeaderRestore o hacer una operación más básica
cat header_backup.dmp > <device>
Veracrypt
Veracrypt es similar a LUKS. No estoy acostumbrado con él como lo estaba con Truecrypt, pero la idea general se mantiene.
Veracrypt solo tiene una ranura para teclas, por lo que no puede tener más de una contraseña al mismo tiempo. Pero puede tener un volumen oculto: almacena los metadatos al final de la partición (o disco o archivo). El volumen oculto tiene una clave maestra diferente y utilizará el final de la partición como espacio superpuesto. La idea de que debe hacer una copia de seguridad es la misma. Esto se puede hacer con Tools -> Backup Volume Headery Tools -> Restore Volume Header. Con el cifrado del sistema, solía crear un disco de arranque con copia de seguridad de clave que recupera el cargador y las claves de Truecrypt si ocurre algún daño. Se realiza antes de cifrar cualquier cosa, y que yo sepa, Veracrypt continúa haciendo lo mismo.
Para obtener más detalles, consulte este enlace https://veracrypt.codeplex.com/wikipage?title=Program%20Menu
Consideraciones de seguridad sobre las claves de respaldo
Si tiene una contraseña filtrada, por ejemplo, y cambia la contraseña del volumen a una nueva, segura y segura, alguien con acceso a la copia de seguridad aún podría descifrar los archivos con la contraseña anterior. La copia de seguridad es básicamente la clave maestra cifrada con la contraseña (antigua). Entonces, al cambiar las contraseñas, también es necesario hacer una nueva copia de seguridad y destruir las más antiguas. Y destruir datos permanentemente puede ser muy complicado.
Para cada copia de seguridad que tenga con esa contraseña, es una forma posible de descifrar los datos con esa contraseña. Esto se puede usar en Veracrypt, por ejemplo, usando una "Contraseña universal" (como en una corporación), haciendo una copia de seguridad y cambiando por otra contraseña. Entonces el departamento de TI. podría recuperar el acceso a ese volumen incluso si alguien perdió la contraseña (piense como una contraseña maestra, pero no confunda con la clave maestra de antes).
Reflexiones finales (TL; DR)
La probabilidad de dañar el sector específico con la clave maestra es menos probable que una falla completa del disco. Entonces, si estos datos son importantes, debe tener una copia de seguridad de ellos en lugar de solo los encabezados de volumen (Clave maestra).
Y la corrupción de los datos se extendió poco (16 bytes), resultando aceptable para la mayoría de los usos.
Por lo tanto, un bloque defectuoso en el medio de la partición o disco afectaría solo a ese bloque. Y algunos errores de bits en un sector están restringidos a ese sector, y ni siquiera afectarán totalmente a un sector de 512 bytes.
Actualización (23/01/2017): agregue más información basada en los comentarios de OP.