Re: Cryptsetup - impossible d'accéder à une machine Jessie chiffrée
Bonjour
J'ai créé 3 fichiers contenant la passphrase encodée en UTF-8, en ISO-8859-1 et en CP850 :
pp_utf8.txt
pp_iso-8859-1.txt
pp_cp850.txt
(avec la commande iconv)
J'ai vérifié l'encodage avec la commande
file -i <file>
Ok : utf-8, iso-8859-1 et us-ascii
Enfin, j'ai testé les fichiers de passphrase :
sudo cryptsetup luksOpen /dev/sdb5 /dev/mapper/dr1 --key-file <file>
où <file> est un nom de fichier (pp_...)
Pour les 3 fichiers, j'ai eu le même message "No key available with this passphrase."
J'ai vérifié la syntaxe de la commande :
Si mauvais nom de fichier => "failed to open key file"
--key-file pp_utf8.txt
--key-file="pp_utf8.txt"
sont equivalents (pas d'erreur
Idem avec le chemin complet ou non :
/home/user/pp_utf8.txt ou pp_utf8.txt
J'ai exploré l'hypothèse d'un très léger oubli sur deux mots de la passphrase (4 possibilités)
Le test avec les 3 séries de fichiers ont échoué.
Néanmoins, dans 2 des cas, il y a un caractère accentué français.
la commande file -i renvoie utf-8 et iso-8859-1 mais elle renvoie
Mais en cp850, elle renvoie unknown-8bit au lieu de us_ascii. Ainsi, je ne sais pas si le test de la passphrase en CP850 est valide.
En ce qui concerne le test du keyslot utilisé, la doc cryptsetup est formelle :
"On ne peut pas vérifier si un key slot est endommagé car auxun checksum n'est conservé"
Si on dispose de la passphrase exacte (dans le même encodage que celui utilisé lors de sa configuration...!), la doc de cryptsetup mentionne l'outil de test d'un keyslot (il vérifie si le niveau d'entropie est conforme à celui généré par cryptsetup ou s'il correspond à un keyslot endommagé)
La commande est la suivante :
chl_luks_keyslots etc.
Sur le LiveCD GParted 0.23.0, cette commande n'est pas disponible.
Il faut rapatrier et installer le code présent dans
/misc/keyslot_checker
https://gitlab.com/cryptsetup/cryptsetup/tree/master/misc/keyslot_checker
Voilà où j'en suis.
Tout ça a été fait quand j'ai pu avoir un calme total. J'ai soigneusement écrit, vérifié puis exécuté chaque commande.
Qu'en pensez-vous ?
Merci
Important : vu le caractère crucial de la sauvegarde du luks header, l'équipe Debian devrait impérativement informer du risque de perte définitive des informations en cas d'endommagement du luks header et du mode opératoire à suivre.
Idem pour l'équipe cryptsetup qui devrait informer l'équipe de chaque distribution d'informer la personne qui installe un système chiffré.
Savez-vous comment alerter l'équipe Debian pour qu'elle corrige ce problème (selon moi) ?
----- Original Message -----
From: Sébastien NOBILI <sebnewsletter@free.fr>
To: debian-user-french@lists.debian.org
Sent: Fri, 08 Sep 2017 13:29:02 +0200 (CEST)
Subject: Re: Cryptsetup - impossible d'accéder à une machine Jessie chiffrée
Le vendredi 08 septembre 2017 à 11:41, roger.tarani@free.fr a écrit :
> Bonjour
> Concrètement, comment faut-il procéder ?
Concrètement, je t’ai donné une liste de commandes le 07 septembre 2017 à 10:42
et Pascal t’a donné des idées de tests le 07 septembre 2017 à 20:37.
À toi de jouer.
> Et que je ne comprends pas ce qui a été changé dans le système pour que les caractères accentués (qui apparaissent correctement dans le terminal, juste avant que la passphrase soit exigée) puissent ne plus être reconnus par cryptsetup (ou les modules Debian qui invoquent cryptsetup?)
Le fait que les caractères accentués apparaissent correctement n’indique rien du
tout. Tu peux voir un « é » et pourtant l’ordinateur peut voir différentes
valeurs différentes pour ce même « é », c’est dépendant de l’encodage choisi.
Fais les manips, on verra ensuite où on va.
Sébastien
Reply to: