GuiGui's Show

Il y a quelques années, j'apprenais, via Aeris, que des paramètres relatifs au chiffrement d'une partition chiffrée Linux (LUKS) sont déterminés à la création, qu'en fonction du contexte (vieille bécane, par ex.), ils peuvent être insuffisants, et qu'ils ne sont pas magiquement à l'épreuve du temps.

Notamment, il y avait un nombre d'itérations (devenu time cost) sur le keyslot (qui n'a rien à voir avec le condensant la clé du volume, « digest » dans luksDump). Depuis la version 1.7.0 de crypsetup, le minimum d'itérations doit représenter 2 secondes. Avec la fonction de dérivation de clé Argon2, il y a également un coût mémoire (memory cost) et un coût CPU (parallel cost). Par défaut : mémoire = 128 Mo ; temps = 0,8 s / 2s ; et parallel cost = nombre de cœurs, plafonné à 4 (sources : 1 et point 10.5).

La section 4 du RFC 9106 présente les paramètres recommandés : « Key derivation for hard-drive encryption, which takes 3 seconds on a 2 GHz CPU using 2 cores -- Argon2id with 4 lanes and 6 GiB of RAM. ». Au point 10.5 de sa FAQ, cryptsetup expose pour quoi il y déroge, notamment sur la quantité de RAM.

Je suis déjà passé à Argon2 (donc au format d'entête LUKS v2) en 2023.

Histoire d'être prévenant et à l'épreuve du temps, j'ai décidé de faire en sorte que le nombre d'itérations occupe environ 5 secondes : cryptsetup luksConvertKey /dev/sdXY --pbkdf argon2id --hash sha512 --iter-time 5000 (le changement se fait à chaud, sans perte de données).

Sur mon ordi à la maison, cela a donné : time cost = 19 ; memory cost = 1 Go ; parallel cost = 4. Cela prend environ 5 secondes pour monter la partition chiffrée.

Pour un disque dur USB utilisé sur cet ordi, cela m'a donné time cost = 17, le reste identique. Sur un autre disque dur USB sur ce même ordi, time cost = 19 (et le reste identique). :D Même remarque concernant le temps pour monter ces conteneurs chiffrés.

Sur ce même ordi, j'ai créé une partition chiffrée sur un disque dur interne SATA branché à un convertisseur USB. Puis je l'ai monté (avec VirttIO) dans une machine virtuelle distante. Time cost = 7, memory = 1G, et je n'ai pas relevé le parallel cost. Mais, sur cette VM, contrairement à l'ordi qui a créé la partition chiffrée, je n'ai qu'un cœur CPU et 1 Go de RAM (à l'époque). --iter-time 5000 m'a fait passer à time cost = 12 et memory = 680 Mo. Je voulais le même coût temporel que sur mon ordi à la maison (19). Je l'ai obtenu avec --iter-time 8000, pour 695 Mo de RAM et 1 cœur CPU. Cela prend environ 8 secondes pour monter la partition.

Sur une autre VM distante, avec 2 cœurs et 2 Go de RAM, --iter-time 5000 a produit un time cost = 4 ; memory = 258 Mo ; parallel = 2. Trouvant cela insuffisant, j'ai obtenu time cost = 20 et memory = 662 Mo avec --iter-time 10000. Conséquence : environ 10 secondes pour monter la partition.

On constate donc que, pour une même durée de dérivation de clé, 5 secs, on a bien des paramètres différents en fonction de la vélocité de la machine : time cost (= itérations) = 17 ou 19 pour 1 Go RAM et 4 cœurs ; time cost = 12 pour 680 Mo de RAM et un cœur, et time cost = 4 pour 258 Mo de RAM et 2 cœurs.

Note : la partition système de mon ordi à la maison utilise sha1 pour le condensat de la clé de volume. Le point 3.4 de la FAQ officielle consigne que cela ne peut pas être changé sans perte de données, mais aussi que cela est sans grande incidence sur la sécurité.