Par exemple si je chiffre un volume (avec LUKS) rempli avec /dev/zero au préalable (dans lequel il n'y a qu'un fichier texte contenant 4 caractères), c'est l'intégralité du disque qui est chiffré (et pas uniquement le fichier texte).
1) Lorsque tu lances ta commande de création du volume chiffré ("cryptsetup luksFormat ...."), tu notes qu'il ne faut que quelques secondes pour que le programme te rende la main. Cela veut dire que "cryptsetup" n'a écrit que quelques octets sur le disque, à savoir les informations de chiffrement. La grande majorité du disque, elle, n'a pas été touchée, donc ton disque est toujours plein de de zéro.
2) Après avoir monté ton volume chiffré, et avant sa première utilisation, tu vas devoir le formater (en ext4 par exemple, mais tu peux aussi mettre du FAT32, NTFS, brtfs, etc ...). Dans le cas de l'ext4, cela donnerait "mkfs.ext4 /dev/mapper/xxxxx". La commande en question va alors écrire quelques blocs de donnés sur le disque (ce que l'on appelle des "inodes"), que luks va bien entendu chiffrer.
3) Si on analysé le disque après cela, que voit t'on ? Beaucoup de zero, et éparpillé à des endroits bien précis, des blocs de données chiffrés, mais dont la taille et le nombre peuvent d'identifier que ce sont des blocs d'inodes, et donc, que le volume chiffré est formaté en ext4.
4) Si tu connais des éléments de signatures précis du système de fichiers (la structure des blocs d'inode est quelque chose de donnu), alors tu peux comparer ces signatures aux données chiffrés. Cela peut t'aider à déchiffré le volume complet.
5) Conclusion: remplir le disque dur de données aléatoires permet de rendre plus difficile l'identification des blocs connus du volume chiffré.
# L'intégralité du disque n'est pas chiffré
Posté par Olivier (site web personnel) . En réponse au message Remplir un volume de données aléatoires avant de le chiffrer ?. Évalué à 7.
1) Lorsque tu lances ta commande de création du volume chiffré ("cryptsetup luksFormat ...."), tu notes qu'il ne faut que quelques secondes pour que le programme te rende la main. Cela veut dire que "cryptsetup" n'a écrit que quelques octets sur le disque, à savoir les informations de chiffrement. La grande majorité du disque, elle, n'a pas été touchée, donc ton disque est toujours plein de de zéro.
2) Après avoir monté ton volume chiffré, et avant sa première utilisation, tu vas devoir le formater (en ext4 par exemple, mais tu peux aussi mettre du FAT32, NTFS, brtfs, etc ...). Dans le cas de l'ext4, cela donnerait "mkfs.ext4 /dev/mapper/xxxxx". La commande en question va alors écrire quelques blocs de donnés sur le disque (ce que l'on appelle des "inodes"), que luks va bien entendu chiffrer.
3) Si on analysé le disque après cela, que voit t'on ? Beaucoup de zero, et éparpillé à des endroits bien précis, des blocs de données chiffrés, mais dont la taille et le nombre peuvent d'identifier que ce sont des blocs d'inodes, et donc, que le volume chiffré est formaté en ext4.
4) Si tu connais des éléments de signatures précis du système de fichiers (la structure des blocs d'inode est quelque chose de donnu), alors tu peux comparer ces signatures aux données chiffrés. Cela peut t'aider à déchiffré le volume complet.
5) Conclusion: remplir le disque dur de données aléatoires permet de rendre plus difficile l'identification des blocs connus du volume chiffré.