En pratique, il est presque aussi résilient avec le cryptage que sans, tant que vous sauvegardez correctement la clé principale et les métadonnées .
En dehors des métadonnées, la corruption affecterait uniquement le bloc du bit corrompu, dans la plupart des cas, seulement 16 octets.
Pour la plupart des situations de corruption de données, avec la clé et les outils (comme votre mot de passe et Veracrypt / LUKS), vous avez le même accès qu'un disque non crypté, comme vous le faites normalement avec l'utilisation quotidienne d'un disque crypté. Le chiffrement ajouterait seulement une étape supplémentaire (ouvrir une partition chiffrée) que l'ordinaire. Donc, dans ce cas, il se comporte comme des données non chiffrées.
Avec Veracrypt ou Luks, vous devez stocker la clé principale sur le disque, qui est cryptée avec votre mot de passe. Endommager ce (s) secteur (s) entraînerait la perte permanente de données. Cela peut être facilement résolu avec la sauvegarde de la clé principale (quelques kilo-octets), quelque chose de facile à faire avec les deux logiciels, et il est fortement recommandé pour tout le monde.
Détails sur les non métadonnées
Veracrypt et Luks utilisent XTS aujourd'hui. Dans ce mode, il est calculé une clé pour chaque bloc. Dans une simplification, pour chiffrer le bloc, ivous utilisez une clé générée avec les clés principales et le numéro de bloc. Ainsi, le chiffrement d'un bloc est indépendant d'un autre. Si vous corrompez certaines informations, elles seront limitées à ce bloc.
Dans XTS, il casse le bloc en sous-blocs (de 16 octets en général) et crée une clé, et crypte ce sous-bloc avec lui. Cela signifie que si nous changeons un peu dessus, seuls ces 16 octets seraient affectés.
Comme test, en changeant un seul bit dans un volume Luks, il change 16 octets du fichier d'origine en charabia, mais les 496 autres restent inchangés. Dans un fichier 7zip, il utilise une méthode de flux, que tous les octets sont enchaînés, donc un changement d'octet affecterait tous les autres - ce n'est pas le cas ici.
Certains considèrent cela comme un problème, car vous pouvez savoir avec une précision de 16 octets quand et où vous modifiez un texte brut, en comparant uniquement les données chiffrées.
Des informations plus intéressantes à ce sujet peuvent être trouvées sur ces liens:
/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
Détails sur la clé principale
LUKS
LUKS a quelques secteurs au début de la partition (ou disque) avec des métadonnées, stockant des méthodes de cryptage, d'autres paramètres et 8 emplacements de clé. Pour crypter et décrypter le disque, il utilise une clé principale , un grand nombre aléatoire généré lors de la création d'un conteneur LUKS. Pour le stocker, il crypte la clé principale avec votre mot de passe, en itérant plusieurs fois une fonction de hachage cryptographique sur le mot de passe et en générant une clé spécifique pour cet emplacement. Vous pouvez avoir 8 mots de passe différents pour le même disque, chacun chiffrant la clé principale avec un mot de passe différent dans un emplacement. Lorsque vous changez le mot de passe, c'est aussi simple que de crypter la clé principale et de ne pas changer toute la partition.
Ainsi, lorsque ces emplacements et métadonnées sont corrompus, vous ne pouvez pas récupérer la clé principale réellement utilisée pour déchiffrer, perdant toutes les données sur le disque. Il s'agit d'un moyen simple de détruire rapidement toutes vos données. Mais si vous avez une sauvegarde de l'en-tête de volume, il est assez facile de la récupérer.
Vous trouverez ci-dessous une copie de la FAQ LUKS sur la sauvegarde extraite de https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery
6.2 Comment sauvegarder un en-tête LUKS?
Bien que vous puissiez simplement copier le nombre approprié d'octets à partir du début de la partition LUKS, la meilleure façon est d'utiliser l'option de commande "luksHeaderBackup" de cryptsetup. Cela protège également contre les erreurs lorsque des paramètres non standard ont été utilisés dans la création de la partition LUKS. Exemple:
cryptsetup luksHeaderBackup --header-backup-file <file> <device>
Pour restaurer, utilisez la commande inverse, c.-à-d.
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
Si vous n'êtes pas sûr d'un en-tête à restaurer, faites d'abord une sauvegarde de celui en cours! Vous pouvez également tester le fichier d'en-tête sans le restaurer en utilisant l'option --header pour un en-tête détaché comme celui-ci:
cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>
Si cela déverrouille votre lot de clés, vous êtes bon. N'oubliez pas de refermer l'appareil.
Dans certaines circonstances (en-tête endommagé), cela échoue. Suivez ensuite les étapes suivantes:
Déterminez d'abord la taille de la clé principale:
cryptsetup luksDump <device>
donne une ligne du formulaire
MK bits: <bits>
avec des bits égaux à 256 pour les anciens paramètres par défaut et 512 pour les nouveaux paramètres par défaut. 256 bits équivaut à une taille totale d'en-tête de 1'052'672 octets et 512 bits de 2 Mo. (Voir également le point 6.12) Si luksDump échoue, supposez 2 Mo, mais sachez que si vous restaurez cela, vous pouvez également restaurer le premier 1 Mo environ du système de fichiers. Ne changez pas le système de fichiers si vous n'avez pas pu déterminer la taille de l'en-tête! Avec cela, la restauration d'une sauvegarde d'en-tête trop volumineuse est toujours sûre.
Ensuite, videz l'en-tête dans un fichier. Il y a plusieurs façons de le faire, je préfère les suivantes:
head -c 1052672 <device> > header_backup.dmp
ou
head -c 2M <device> > header_backup.dmp
pour un en-tête de 2 Mo. Vérifiez la taille du fichier de vidage pour être sûr. Pour restaurer une telle sauvegarde, vous pouvez essayer luksHeaderRestore ou faire une opération plus basique
cat header_backup.dmp > <device>
Veracrypt
Veracrypt est similaire à LUKS. Je n'y suis pas habitué comme je l'étais avec Truecrypt, mais l'idée générale tient.
Veracrypt n'a qu'un seul emplacement de clé, vous ne pouvez donc pas avoir plus d'un mot de passe en même temps. Mais vous pouvez avoir un volume caché: il stocke les métadonnées à la fin de la partition (ou disque ou fichier). Le volume caché a une clé principale différente et utilisera la fin de la partition comme espace superposé. L'idée que vous devez sauvegarder est la même. Cela peut être fait avec Tools -> Backup Volume Headeret Tools -> Restore Volume Header. Avec le chiffrement du système, il créait un disque amorçable avec une sauvegarde de clé qui récupère le chargeur et les clés Truecrypt en cas de dommage. C'est fait avant de crypter quoi que ce soit, et pour autant que je sache, Veracrypt continue de faire de même.
Pour plus de détails, consultez ce lien https://veracrypt.codeplex.com/wikipage?title=Program%20Menu
Considérations de sécurité sur les clés de sauvegarde
Par exemple, si vous avez un mot de passe divulgué et que vous changez le mot de passe du volume en un nouveau, fort et sécurisé, une personne ayant accès à la sauvegarde pourra toujours décrypter les fichiers avec l'ancien mot de passe. La sauvegarde est essentiellement la clé principale chiffrée avec (l'ancien) mot de passe. Ainsi, lors du changement de mots de passe, il est également nécessaire de faire une nouvelle sauvegarde et de détruire les plus anciens. Et détruire des données de façon permanente peut être très difficile.
Pour chaque sauvegarde que vous avez avec ce mot de passe, est un moyen possible de décrypter les données avec ce mot de passe. Cela peut être utilisé dans Veracrypt par exemple, en utilisant un "mot de passe universel" (comme dans une entreprise), en le sauvegardant et en changeant pour un autre mot de passe. Donc, le département informatique. pourrait récupérer l'accès à ce volume même si quelqu'un a perdu le mot de passe (pensez comme un mot de passe principal, mais ne confondez pas avec la clé principale antérieure).
Réflexions finales (TL; DR)
La probabilité d'endommager le secteur spécifique avec la clé principale est moins probable que vous ayez une panne de disque complète. Donc, si ces données sont importantes, vous devriez en avoir une copie de sauvegarde à la place des en-têtes de volume (clé principale).
Et la corruption des données s'est peu répandue (16 octets), ce qui est acceptable pour la plupart des utilisations.
Ainsi, un mauvais bloc au milieu de la partition ou du disque n'affecterait que ce bloc. Et quelques erreurs de bits dans un secteur sont limitées à ce secteur, et n'affecteront même pas totalement un secteur de 512 octets.
Mise à jour (23/01/2017): ajoutez plus d'informations sur la base des commentaires OP.