Quelle solution de chiffrement (libre/open-source) avec une communauté toujours active conviendrait le mieux pour ce cas de figure? Cryptsetup, LUKS, Veracrypt, dm-crypt, autre ?
LUKS, sans hésiter. Comme dit plus haut, cryptsetup et dm-crypt désignent grosso modo la même chose.
Le point à prendre en compte est que pour démarrer un système GNU/Linux, on lance un noyau Linux, pour lequel on a chargé en mémoire un système de fichier racine initial, qu'on appelle l'initrd. Dans cet initrd, il y a un programme init, et tout ce qu'il faut comme pilotes, outils et bibliothèques pour pouvoir accéder au périphérique sur lequel se trouve le vrai système de fichiers racine, et monter ce dernier.
Toi, tu veux chiffrer ce système de fichiers. Il faut donc une prise en charge de ce chiffrement dans l'initrd. Et ça, je pense que ça ne laisse qu'un seul candidat, LUKS, qui est certainement intégré à l'initrd prévu par ta distribution (en installant au besoin un paquet spécifique), et probablement le seul qui soit ainsi intégré.
Comment ne pas commettre d'erreur avec les pièges que je sens venir: Le bios EFI ; le MBR ; Grub ; Windows ; bitlocker ; le chiffrement éventuel du /boot ; autre ? A quoi faut-il particulièrement faire attention?
Pour l'EFI, aucun problème, il n'a rien à voir avec le système de fichiers chiffré qui servira de / ou de /home sous GNU/Linux. Tout ce qu'il faut, c'est que la partition système EFI, sur laquelle se trouve ton chargeur de démarrage, soit lisible par l'EFI, donc pas chiffrée.
Pour GRUB, là c'est plus particulier. Il a apparemment une prise en charge de LUKS, mais je ne sais pas ce qu'elle vaut. Généralement, dans ce genre de cas, il me semble qu'on met en place un /boot non chiffré. C'est là que GRUB ira chercher le noyau et l'initrd à lancer. Il n'y a pas de problème à ne pas chiffrer ce système de fichiers, puisqu'il ne contient que des informations publiques, à savoir un noyau Linux et un initrd assemblé selon les règles d'une distribution GNU/Linux connue.
Windows n'est en aucun cas concerné par le chiffrement d'un système de fichier utilisé exclusivement par un système GNU/Linux. Pareil pour Bitlocker.
# Mon avis
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au message Deux systèmes de chiffrement cote à cote pour un système dual boot. Évalué à 3.
LUKS, sans hésiter. Comme dit plus haut, cryptsetup et dm-crypt désignent grosso modo la même chose.
Le point à prendre en compte est que pour démarrer un système GNU/Linux, on lance un noyau Linux, pour lequel on a chargé en mémoire un système de fichier racine initial, qu'on appelle l'initrd. Dans cet initrd, il y a un programme init, et tout ce qu'il faut comme pilotes, outils et bibliothèques pour pouvoir accéder au périphérique sur lequel se trouve le vrai système de fichiers racine, et monter ce dernier.
Toi, tu veux chiffrer ce système de fichiers. Il faut donc une prise en charge de ce chiffrement dans l'initrd. Et ça, je pense que ça ne laisse qu'un seul candidat, LUKS, qui est certainement intégré à l'initrd prévu par ta distribution (en installant au besoin un paquet spécifique), et probablement le seul qui soit ainsi intégré.
Pour l'EFI, aucun problème, il n'a rien à voir avec le système de fichiers chiffré qui servira de / ou de /home sous GNU/Linux. Tout ce qu'il faut, c'est que la partition système EFI, sur laquelle se trouve ton chargeur de démarrage, soit lisible par l'EFI, donc pas chiffrée.
Pour GRUB, là c'est plus particulier. Il a apparemment une prise en charge de LUKS, mais je ne sais pas ce qu'elle vaut. Généralement, dans ce genre de cas, il me semble qu'on met en place un /boot non chiffré. C'est là que GRUB ira chercher le noyau et l'initrd à lancer. Il n'y a pas de problème à ne pas chiffrer ce système de fichiers, puisqu'il ne contient que des informations publiques, à savoir un noyau Linux et un initrd assemblé selon les règles d'une distribution GNU/Linux connue.
Windows n'est en aucun cas concerné par le chiffrement d'un système de fichier utilisé exclusivement par un système GNU/Linux. Pareil pour Bitlocker.