LUKS (Linux Unified Key Setup) est le format de chiffrement de disque natif de Linux. Vous le pilotez avec la commande cryptsetup, présente sur toutes les distributions. Sans la phrase de passe, les données sont illisibles si le support est volé, revendu ou renvoyé en garantie — mais LUKS ne protège rien tant que la machine est allumée et le volume déverrouillé.
L’essentiel
Créer un volume chiffré :sudo cryptsetup luksFormat /dev/sdX
Chiffrer un disque déjà rempli sans l’effacer :sudo cryptsetup reencrypt --encrypt --reduce-device-size 32m /dev/sdX
Prérequis : droits root, sauvegarde préalable, 15 à 30 minutes.
Distributions couvertes : Debian, Ubuntu, Fedora/RHEL, Arch, openSUSE.
Testé le 31/08/2026 avec cryptsetup 2.7.0 et systemd 255 sur Ubuntu 24.04 LTS. Les procédures nécessitant le module noyaudm_mod, une puce TPM2 ou une clé FIDO2 n’ont pas pu être testées dans cet environnement : elles sont conformes à la documentation officielle citée en fin d’article, et signalées comme telles.
Ce que LUKS protège, et ce qu’il ne protège pas
LUKS chiffre au niveau du bloc. Le contenu du disque est illisible tant que le volume n’est pas ouvert avec la bonne phrase de passe. C’est efficace contre trois scénarios précis : le vol du matériel éteint, la revente ou la mise au rebut d’un disque, et le passage du support entre des mains tierces (réparation, garantie).
LUKS ne protège pas contre une intrusion à distance sur un système allumé, contre un logiciel malveillant exécuté avec vos droits, ni contre quelqu’un qui accède à votre session déverrouillée. Une fois le volume ouvert, les données sont en clair pour le système. Le chiffrement de disque est une couche parmi d’autres, pas un substitut à un pare-feu correctement configuré, ni à la détection des logiciels malveillants et des rootkits, ni à un accès distant durci.
Les paramètres par défaut, vérifiés directement sur cryptsetup 2.7.0 : format LUKS2, dérivation de clé Argon2id, chiffrement aes-xts-plain64. Le luksDump affiche une clé de 512 bits, ce qui trompe régulièrement : il s’agit d’AES-256 en mode XTS, qui utilise deux clés internes de 256 bits. La sortie de cryptsetup --help le dit explicitement : « Default keysize with XTS mode (two internal keys) will be doubled. »
Installer cryptsetup selon votre distribution
Le paquet est souvent déjà présent. Vérifiez avant d’installer :
cryptsetup --version
| Distribution | Commande |
|---|---|
| Debian, Ubuntu, Mint | sudo apt install cryptsetup |
| Fedora, RHEL, Rocky, AlmaLinux | sudo dnf install cryptsetup |
| Arch, Manjaro | sudo pacman -S cryptsetup |
| openSUSE | sudo zypper install cryptsetup |
Le paquet porte le même nom sur les quatre familles.
Cas 1 : chiffrer un support vide ou dont les données sont sauvegardées
C’est la procédure standard, la plus rapide et la plus sûre.
Identifier le bon périphérique
lsblk -f
Repérez le support par sa taille et par sa colonne MOUNTPOINTS vide. N’utilisez jamais le nom seul : /dev/sdb peut désigner un disque différent au prochain démarrage. Pour une clé USB, comparez la sortie de lsblk avant et après le branchement.
Avertissement : l’étape suivante efface le support
cryptsetup luksFormat écrase l’en-tête et rend illisible tout le contenu existant. La seule confirmation demandée est un YES en majuscules. Relisez le nom du périphérique avant de valider.
Créer le volume chiffré
sudo cryptsetup luksFormat /dev/sdX
Vérifiez ensuite ce qui a réellement été écrit :
sudo cryptsetup luksDump /dev/sdX
Sortie réelle obtenue pour cet article (extrait) :
LUKS header information
Version: 2
Keyslots:
0: luks2
Key: 512 bits
Cipher: aes-xts-plain64
PBKDF: argon2id
Ouvrir et formater
mkfs.ext4 efface le contenu du volume déchiffré, au même titre que luksFormat. Vérifiez le nom de la cible avant de l’exécuter.
sudo cryptsetup open /dev/sdX coffre
sudo mkfs.ext4 /dev/mapper/coffre
coffre est un nom arbitraire : c’est le nom du périphérique déchiffré, disponible sous /dev/mapper/ tant que le volume reste ouvert. ext4 convient pour un usage entre machines Linux, ce qui est le seul cas où un volume LUKS s’ouvre sans outil tiers.
Monter et vérifier
sudo mkdir -p /mnt/coffre
sudo mount /dev/mapper/coffre /mnt/coffre
sudo cryptsetup status coffre
lsblk -f /dev/sdX
lsblk doit afficher crypto_LUKS sur la partition, et le système de fichiers choisi sur le volume en dessous. Fermez et rouvrez pour confirmer que la phrase de passe est bien redemandée :
sudo umount /mnt/coffre
sudo cryptsetup close coffre
Cas 2 : chiffrer un disque déjà rempli, sans effacer les données
C’est la question la plus posée sur ce sujet, et la réponse la plus souvent fausse dans les tutoriels francophones : oui, c’est possible, avec l’action reencrypt.
Deux voies existent, et le choix se fait sur une seule question : avez-vous de la place libre en fin de périphérique ?
Voie 1, en-tête sur le disque. L’en-tête LUKS occupe 16 Mio en tête du périphérique. Pour les libérer, les données sont décalées vers la fin, ce qui exige de l’espace libre là-bas.
sudo cryptsetup reencrypt --encrypt --type luks2 --reduce-device-size 32m /dev/sdX
Attention à ce que fait réellement cette option : cryptsetup ne redimensionne pas votre système de fichiers, il tronque le périphérique. La page de manuel est catégorique : « This is a destructive operation and cannot be reverted. Use with extreme care – accidentally overwritten filesystems are usually unrecoverable. » Réduire le système de fichiers avant l’opération est un prérequis, pas une option : les 32 derniers Mio doivent être vides de données.
Voie 2, en-tête détaché. Si le disque est plein jusqu’au dernier secteur, l’en-tête part dans un fichier séparé et rien n’est tronqué :
sudo cryptsetup reencrypt --encrypt --type luks2 --header /secours/coffre-header.img /dev/sdX
Le prix à payer est lourd et permanent : sans ce fichier d’en-tête, les données sont définitivement illisibles. Il devient aussi critique que la phrase de passe.
Deux avertissements valables dans les deux cas, cités de la page de manuel officielle :
- « ALWAYS BE SURE YOU HAVE RELIABLE BACKUP BEFORE USING THIS ACTION ON LUKS DEVICE. »
- Pendant toute la durée de l’opération, une partie du disque reste en clair : aucune confidentialité n’est garantie tant qu’elle n’est pas terminée.
En cas de coupure, la distinction entre les deux formats compte. Sur LUKS2, une interruption brutale (plantage, coupure de courant) est prévue : la récupération se déclenche automatiquement au prochain open, ou manuellement avec cryptsetup repair. C’est LUKS1 qui est explicitement signalé comme « not resistant to hardware or kernel failures during reencryption ». Une opération interrompue se reprend, elle ne se relance pas de zéro :
sudo cryptsetup reencrypt --resume-only /dev/sdX
Retirer le chiffrement d’un volume LUKS2
L’opération inverse existe, et n’oblige donc pas à sauvegarder puis reformater :
sudo cryptsetup reencrypt --decrypt --header /secours/export-header.img /dev/sdX
Deux pièges que la syntaxe ne laisse pas deviner. L’option --header est obligatoire ici, et le fichier qu’elle désigne ne doit pas exister : cryptsetup y exporte l’en-tête pour libérer la tête du disque. Ne réutilisez donc pas le fichier produit par luksHeaderBackup : l’opération échouerait. Second piège documenté : ce fichier ne doit jamais se trouver sur un système de fichiers porté par le disque en cours de déchiffrement, sous peine d’interblocage.
Les procédures reencrypt n’ont pas pu être testées dans l’environnement de rédaction de cet article : elles s’appuient sur le module noyau device-mapper, absent du bac à sable utilisé. Leur syntaxe et leurs avertissements proviennent directement de la page de manuel cryptsetup-reencrypt(8).
Gérer les clés : ajouter, changer, supprimer
Un volume LUKS2 accepte plusieurs phrases de passe, dans des emplacements appelés keyslots. Chacune ouvre le volume indépendamment des autres.
sudo cryptsetup luksAddKey /dev/sdX # ajouter une phrase de passe
sudo cryptsetup luksChangeKey /dev/sdX # remplacer une phrase de passe existante
sudo cryptsetup luksKillSlot /dev/sdX 1 # supprimer le keyslot numéro 1
sudo cryptsetup luksDump /dev/sdX # lister les keyslots occupés
Testé pour cet article : luksAddKey crée bien un second keyslot indépendant, avec le même PBKDF Argon2id que le premier. Vérifiez toujours qu’une nouvelle clé fonctionne avant de supprimer l’ancienne : luksKillSlot ne demande pas de confirmation croisée.
Déverrouiller avec un fichier de clé plutôt qu’une phrase de passe
Pour un disque secondaire qui doit s’ouvrir sans intervention au démarrage, un fichier de clé évite la saisie manuelle. Il faut alors protéger ce fichier comme un mot de passe, sur un support lui-même chiffré :
sudo mkdir -p /etc/luks-keys
sudo chmod 700 /etc/luks-keys
sudo dd if=/dev/urandom of=/etc/luks-keys/coffre.key bs=512 count=8
sudo chmod 400 /etc/luks-keys/coffre.key
sudo cryptsetup luksAddKey /dev/sdX /etc/luks-keys/coffre.key
La ligne /etc/crypttab correspondante place le fichier en troisième champ, à la place de none :
coffre UUID=<uuid-du-luks> /etc/luks-keys/coffre.key luks
Le fichier est lu intégralement comme phrase de passe, y compris un éventuel saut de ligne final : c’est pourquoi on le génère avec dd if=/dev/urandom et jamais avec un echo. Stocker ce fichier sur un disque système non chiffré annule l’intérêt du chiffrement du disque de données : n’utilisez le fichier de clé que si le système, lui, est déjà chiffré.
Sauvegarder et restaurer l’en-tête LUKS
L’en-tête contient les clés chiffrées. S’il est corrompu, la bonne phrase de passe n’ouvre plus rien. C’est le mode de perte de données le plus fréquent après l’oubli du mot de passe, et il est entièrement évitable.
sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file /secours/header-coffre.img
Testé pour cet article : la commande produit un fichier de 16 Mio, en lecture seule pour root. Conservez-le hors du disque qu’il protège — un script de sauvegarde automatisé avec rsync et crontab est un bon endroit pour l’inclure, à condition que sa destination soit elle-même protégée.
La restauration s’écrit :
sudo cryptsetup luksHeaderRestore /dev/sdX --header-backup-file /secours/header-coffre.img
Le point que la plupart des tutoriels omettent tient en une phrase de la page de manuel : « Header and keyslots will be replaced, only the passphrases from the backup will work afterward. » La restauration remet l’en-tête dans son état exact au jour de la sauvegarde, dans les deux sens. Une clé compromise que vous aviez supprimée depuis redevient valide. Et surtout, une phrase de passe ajoutée ou modifiée après la sauvegarde cesse de fonctionner : si vous avez changé de phrase de passe entre-temps et restaurez, vous vous retrouvez dehors avec la seule que vous connaissez.
La règle qui en découle : refaites la sauvegarde de l’en-tête après chaque luksAddKey, luksChangeKey ou luksKillSlot.
Déverrouillage automatique : TPM2, clé FIDO2, clé de secours
systemd-cryptenroll permet d’associer d’autres facteurs qu’une phrase de passe à un volume LUKS2. Les trois options utiles, toutes présentes dans systemd 255 vérifié sur le système de rédaction :
| Objectif | Commande |
|---|---|
| Déverrouiller via la puce TPM2 de la machine | sudo systemd-cryptenroll /dev/sdX --tpm2-device=auto |
| Déverrouiller avec une clé de sécurité type YubiKey | sudo systemd-cryptenroll /dev/sdX --fido2-device=auto |
| Générer une clé de secours à conserver hors ligne | sudo systemd-cryptenroll /dev/sdX --recovery-key |
Le support TPM2, FIDO2 et clé de secours est disponible depuis systemd 248 selon la page de manuel officielle. L’enrôlement seul ne suffit pas : il faut aussi ajouter l’option correspondante sur la ligne du volume dans /etc/crypttab.
coffre UUID=<uuid-du-luks> none tpm2-device=auto
La suite dépend du volume concerné, et c’est le point où la plupart des tutoriels induisent en erreur :
- Volume secondaire (un disque de données) : la ligne
crypttabsuffit. C’estsystemd-cryptsetupqui la traite après le démarrage, l’initramfs n’intervient pas. - Partition racine : l’initramfs doit savoir déverrouiller le volume. Sur Fedora et RHEL,
sudo dracut -favec le module systemd le permet. Sur Ubuntu 24.04 avec l’initramfs par défaut, non : le paquetcryptsetup-initramfslivré ne contient aucune référence àtpm2-device— vérifié sur le paquet2:2.7.0-1ubuntu4.2du système de rédaction. Unupdate-initramfs -un’y changera rien ; il faut un initrd basé sur systemd.
Avec le TPM2, le volume s’ouvre tant que l’état mesuré de la machine ne change pas. Une modification du firmware ou du chargeur de démarrage bloque le déverrouillage automatique et impose la phrase de passe : c’est le comportement recherché en cas d’altération du matériel. Ces trois commandes n’ont pas pu être testées ici, faute de puce TPM2, de clé FIDO2 et du module device-mapper dans le bac à sable.
Chiffrer la partition swap
Chiffrer le disque de données sans chiffrer le swap laisse fuir sur ce dernier des fragments de mémoire, dont potentiellement des clés. La méthode documentée dans le manuel crypttab utilise une clé aléatoire régénérée à chaque démarrage.
Avertissement : la ligne ci-dessous reformate à chaque démarrage la partition qu’elle désigne. Le manuel le dit sans détour : « Using the swap option will destroy the contents of the named partition during every boot, so make sure the underlying block device is specified correctly. » Une erreur de lettre détruit une partition de données à chaque boot, en silence. C’est aussi la raison pour laquelle il faut ici un identifiant stable et non /dev/sdaX : un UUID de système de fichiers ne convient pas non plus, puisque mkswap en régénère un à chaque démarrage. Utilisez PARTUUID=, que sudo blkid vous donne.
Dans /etc/crypttab :
swap PARTUUID=<partuuid-de-la-partition> /dev/urandom swap
Une précision qui évite une confusion légitime : /dev/urandom est accepté ici parce que l’option swap crée un volume dm-crypt simple, sans en-tête LUKS. Le manuel est explicite sur le fait que LUKS, lui, exige une clé persistante et n’accepte pas de clé aléatoire.
Puis dans /etc/fstab, sans quoi la partition swap est formatée mais jamais activée :
/dev/mapper/swap none swap sw 0 0
Conséquence directe du reformatage à chaque démarrage : l’hibernation devient impossible, l’image mémoire écrite avant l’extinction n’étant plus déchiffrable au redémarrage suivant.
LUKS et LVM : dans quel ordre
Deux ordres sont possibles, et ils ne rendent pas le même service.
| Architecture | Ce que ça permet | Contrainte |
|---|---|---|
| LVM sur LUKS (chiffrer d’abord, LVM dedans) | Une seule phrase de passe au démarrage ; redimensionner un volume se fait par un simple lvresize à l’intérieur du conteneur déjà ouvert |
Tout le conteneur doit être déverrouillé pour accéder à n’importe quel volume |
| LUKS sur LVM (LVM d’abord, chiffrer chaque volume) | Cloisonnement réel : chaque volume a sa clé, et on peut n’en déverrouiller qu’un | Une phrase de passe ou un fichier de clé par volume, et un cryptsetup resize supplémentaire à chaque redimensionnement |
Pour un poste de travail ou un serveur simple, LVM sur LUKS reste le schéma le plus courant : une seule saisie au démarrage, et la gestion de l’espace se fait entièrement au niveau LVM.
Redimensionner un volume chiffré
cryptsetup resize agit sur le volume déchiffré actif, pas sur la partition sous-jacente. L’ordre compte : agrandir la partition, puis le conteneur LUKS, puis le système de fichiers ; réduire dans l’ordre inverse.
sudo cryptsetup resize coffre
Sans --size, la commande aligne le volume sur le périphérique sous-jacent — donc l’agrandit ou le réduit selon le cas, ce n’est pas une commande à sens unique. Sur un volume LUKS2 dont la clé n’est pas dans le trousseau du noyau, resize réclame la phrase de passe : à prévoir si vous l’appelez depuis un script.
TRIM sur SSD : le compromis à connaître
Par défaut, les requêtes TRIM ne sont pas transmises à travers un volume LUKS. Les activer avec --allow-discards améliore la durée de vie et les performances d’un SSD, mais révèle à un observateur du disque quels blocs sont utilisés et lesquels sont vides. Sur un poste personnel, le compromis est généralement acceptable ; sur un support qui doit résister à une analyse, il ne l’est pas. Le choix vous appartient, il n’a pas de réponse unique.
Que faire si vous avez oublié la phrase de passe
Sans phrase de passe de secours, sans fichier de clé et sans sauvegarde de l’en-tête, les données ne sont pas récupérables. Aucun outil de récupération classique (testdisk, photorec) ne contourne Argon2id, et aucun prestataire non plus. Toute promesse contraire est commerciale, pas technique.
Une seule fenêtre existe : si la machine est encore allumée et le volume encore déverrouillé, avant tout redémarrage. Dans ce cas, la clé maître se trouve en mémoire vive et peut être extraite via un dump mémoire (avml) puis une recherche de clés AES (findaes), technique documentée par la communauté CHATONS. Elle échoue après extinction, et sur un noyau en mode lockdown. Ce n’est pas une méthode de récupération, c’est un sauvetage d’urgence.
La vraie réponse est préventive : ajoutez une seconde phrase de passe ou une clé de secours systemd-cryptenroll --recovery-key le jour où vous créez le volume, et sauvegardez l’en-tête.
Chiffrement et obligations professionnelles
Si vous transportez des données de clients sur un ordinateur portable, le guide pratique de la CNIL sur la sécurité des données personnelles recommande le chiffrement des « postes nomades et supports de stockage amovibles » (ordinateur portable, clé USB, disque dur externe), dans sa fiche 6 consacrée à l’informatique mobile. Ce n’est pas une obligation légale universelle : le RGPD impose une approche par les risques, dans laquelle le chiffrement est une mesure attendue pour du matériel mobile exposé au vol, pas une exigence uniforme pour un poste fixe.
Erreurs courantes au démarrage
cryptsetup: waiting for encrypted source device ... puis un démarrage qui échoue. Le système attend un périphérique que l’initramfs ne trouve pas. Comparez l’UUID inscrit dans /etc/crypttab avec celui que renvoie réellement sudo blkid — un UUID obsolète après un changement de disque ou un reformatage est la piste à écarter en premier — puis régénérez l’initramfs.
cryptsetup: ERROR: ...: maximum number of tries exceeded. Le déverrouillage a échoué le nombre de fois autorisé. Au-delà de la faute de frappe, la piste à écarter est la disposition du clavier dans l’initramfs, qui n’est pas toujours celle de votre session : le cas frappe surtout les installations serveur ou minimales, et les machines dont la disposition n’a été changée que dans l’environnement graphique sans mettre à jour /etc/default/keyboard. Deux commandes tranchent : cat /etc/default/keyboard et lsinitramfs /boot/initrd.img-$(uname -r) | grep -i keymap.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?. Le module noyau nécessaire n’est pas chargé. Normal dans un conteneur, anormal sur un système standard : sudo modprobe dm_mod.
Device or resource busy à la fermeture. Un processus utilise encore le volume. Identifiez-le avec lsof /mnt/coffre avant de forcer quoi que ce soit.
Dans tous les cas, journalctl -b | grep -i crypt donne l’erreur réelle plutôt qu’une supposition.
Tableau récapitulatif
| Besoin | Commande |
|---|---|
| Créer un volume chiffré | cryptsetup luksFormat /dev/sdX |
| Chiffrer sans effacer les données (32 Mio libres en fin de volume) | cryptsetup reencrypt --encrypt --reduce-device-size 32m /dev/sdX |
| Chiffrer sans effacer, disque plein (en-tête détaché) | cryptsetup reencrypt --encrypt --header nouveau.img /dev/sdX |
| Retirer le chiffrement (fichier d’export inexistant) | cryptsetup reencrypt --decrypt --header export.img /dev/sdX |
| Ouvrir / fermer | cryptsetup open /dev/sdX nom / cryptsetup close nom |
| Ajouter une phrase de passe | cryptsetup luksAddKey /dev/sdX |
| Supprimer un keyslot | cryptsetup luksKillSlot /dev/sdX 1 |
| Sauvegarder l’en-tête | cryptsetup luksHeaderBackup /dev/sdX --header-backup-file f.img |
| Restaurer l’en-tête | cryptsetup luksHeaderRestore /dev/sdX --header-backup-file f.img |
| Clé de secours | systemd-cryptenroll /dev/sdX --recovery-key |
| Vérifier l’état | cryptsetup status nom / cryptsetup luksDump /dev/sdX |
Ce qu’il ne faut pas faire
Ne stockez pas le fichier de clé d’un disque de données sur un système non chiffré. Ne supprimez pas un keyslot avant d’avoir testé son remplaçant. Ne lancez pas un reencrypt sans sauvegarde, quelle que soit la confiance dans votre matériel. Ne conservez pas la sauvegarde d’en-tête sur le disque qu’elle protège. Et ne comptez pas sur le chiffrement de disque pour protéger une machine allumée : ce n’est pas ce qu’il fait.
FAQ
Peut-on chiffrer un disque déjà rempli sans perdre les données ?
Oui, avec cryptsetup reencrypt --encrypt --reduce-device-size 32m. L’opération exige que les 32 derniers Mio du périphérique soient libres, et une sauvegarde préalable reste indispensable selon la documentation officielle.
Que se passe-t-il si j’oublie ma phrase de passe LUKS ?
Sans clé de secours ni sauvegarde d’en-tête, les données sont définitivement perdues. La seule exception concerne une machine encore allumée et déverrouillée, via une extraction de la clé maître en mémoire.
Peut-on chiffrer un Ubuntu déjà installé, après coup ?
Pour une partition de données ou un disque secondaire, oui, avec les procédures de cet article. Pour la partition racine, la voie fiable reste la réinstallation avec l’option de chiffrement de l’installateur : aucune des distributions couvertes ici ne documente une conversion en place de la racine comme procédure standard.
Quelle est la différence entre chiffrer et crypter ?
« Chiffrer » désigne l’opération réalisée avec une clé. L’Académie française est plus nuancée qu’on ne le dit souvent sur « crypter » : le verbe n’est selon elle « pas vraiment une hérésie », mais « l’usage et la norme veulent que l’on utilise chiffrer, cryptographier, coder ou encoder ». « Décrypter » reste en revanche parfaitement correct, avec un sens précis : casser un chiffrement sans posséder la clé.
LUKS ou VeraCrypt ?
LUKS est natif à Linux, intégré au noyau via dm-crypt, et gère le disque système. VeraCrypt est multiplateforme et propose en plus des conteneurs sous forme de fichiers, ce que LUKS ne fait pas nativement.
Le chiffrement ralentit-il le disque ?
AES-XTS s’appuie sur l’accélération matérielle AES-NI présente sur les processeurs récents. Mesurez sur votre machine plutôt que de vous fier à une estimation générale : cryptsetup benchmark.
Faut-il chiffrer aussi le swap ?
Oui dès que le système ou les données sont chiffrés, sinon des fragments de mémoire restent lisibles en clair sur le swap. La méthode par clé aléatoire coûte l’hibernation.
Une clé USB chiffrée avec LUKS s’ouvre-t-elle sur une autre machine ?
Sur toute machine Linux disposant de cryptsetup, oui. LUKS n’étant pas géré nativement par les autres systèmes d’exploitation, réservez le chiffrement LUKS aux supports qui circulent entre postes Linux.
Conclusion
La partie de LUKS qui demande une décision n’est pas le chiffrement lui-même — trois commandes suffisent — mais ce que vous mettez en place le jour de la création du volume : une seconde phrase de passe ou une clé de secours, et une sauvegarde de l’en-tête stockée ailleurs. Sans ces deux éléments, un oubli ou un secteur défectueux dans les 16 premiers Mio du disque suffit à rendre les données définitivement inaccessibles, et aucune commande ne rattrape ça.
Deuxième décision : si le disque appartient à une machine accessible à distance, le chiffrement ne couvre rien pendant qu’elle tourne — c’est la configuration de SSH qui protège cette surface-là, et les deux se complètent au lieu de se remplacer.
Sources officielles
- cryptsetup-reencrypt(8) — Arch manual pages — chiffrement et déchiffrement en place
- cryptsetup(8) — Arch manual pages — actions, keyfile, luksHeaderRestore
- crypttab(5) — Arch manual pages — syntaxe crypttab et swap chiffré
- systemd-cryptenroll(1) — man7.org — TPM2, FIDO2, clé de secours
- cryptsetup 2.1.0 Release Notes — kernel.org — LUKS2 par défaut
- cryptsetup 2.4.0 Release Notes — kernel.org — Argon2id par défaut
- Guide pratique de la sécurité des données personnelles — CNIL — fiche 6, informatique mobile
- Récupération d’une master key LUKS2 — forum CHATONS
