Ce guide vous explique comment récupérer l’accès à votre propre portefeuille de prévente. Chaque entrée ci-dessous décrit comment un mot de passe saisi correctement peut avoir été modifié par un logiciel entre le clavier et la fonction de dérivation de clé. Aucune de ces modifications n’affaiblit ni ne compromet la cryptographie sous-jacente, qui reste solide — la récupération ne fonctionne que si vous reproduisez sans erreur le mot de passe que vous avez réellement utilisé.

Comment la prévente crypte votre mot de passe

D’après l’implémentation de référence canonique de pyethsaletool, la chaîne est courte : votre mot de passe est étendu à l’aide de PBKDF2-HMAC-SHA256 pendant 2 000 itérations (tronquées à 16 octets) pour générer une clé ; cette clé déchiffre l’encseed à l’aide de l’algorithme AES ; le résultat est haché pour obtenir une clé privée et son adresse est comparée à l’ethaddr figurant dans le fichier. Seul un mot de passe correct donne une adresse correspondante. Il s’agit du mode 16300 de hashcat.

Trois idées reçues qu’il convient de dissiper, car les pages consacrées à la récupération les reprennent : la prévente n’ utilise pas scrypt (il s’agit du keystore V3 plus récent, mode 15700) ; le nombre d’itérations est délibérément faible (2 000), ce qui rend les recherches de mots de passe candidats gérables ; et le mot de passe n’est pas salé avec une valeur aléatoire — c’est le mot de passe lui-même qui se sale. C’est ce dernier détail qui explique pourquoi une infime modification de l’entrée produit un résultat complètement différent.

La cause profonde : création vs. décryptage

Erreurs d’encodage et de normalisation

• La normalisation Unicode (NFC vs NFD) — la cause principale. Un même caractère peut correspondre à un point de code unique (NFC : é = U+00E9) ou à une lettre associée à un signe combinatoire (NFD : e + U+0301). Sous macOS, les applications reçoivent du texte au format NFD dans de nombreux contextes ; Linux et Windows utilisent le format NFC. Si le texte a été créé dans un format et retapé dans l’autre, cela ne fonctionne pas. Tester les quatre formats (NFC, NFD, NFKC, NFKD) permet de résoudre une grande partie des cas.
• Différences entre les formats UTF-8, Latin-1 et UTF-16 au niveau des octets. Le traitement d’un tréma par le navigateur a pu générer des octets de poids faible au format Latin-1 ou des unités UTF-16 brutes, et non le format UTF-8 auquel s’attend un outil moderne.
• Double encodage / caractères corrompus (par exemple, « ä » transformé en « ä ») résultant d’un processus de création puis de stockage mal décodé.
• Translittération. Un utilisateur a saisi un caractère national d’une certaine manière, mais s’en souvient différemment : en allemand, ä ↔ ae, ß ↔ ss; en suédois, å ↔ aa; en norvégien, ø ↔ o/oe; en espagnol, ñ ↔ n, etc.
• Substitution d’homoglyphes. Lorsqu’une configuration cyrillique ou grecque est active, un caractère qui apparaît comme un caractère latin à l’écran ( le « а » cyrillique pour le « a ») correspond en réalité à un point de code totalement différent.

Particularités de la saisie sous macOS

• Guillemets et tirets « intelligents ». macOS remplace automatiquement les guillemets droits ‘ » par des guillemets courbes ‘’ », et les tirets – par –—. Le mot de passe semble identique, mais les octets diffèrent.
• « Accent bloqué » sur une touche morte. Sous macOS, une touche morte représentant un accent aigu, un tréma ou un accent grave, lorsqu’elle est suivie d’une lettre non de base, produit le signe diacritique seul suivi de la lettre — le mot « café », par exemple, peut avoir été enregistré sous la forme « caf´e ».
• Menu des accents accessible par pression prolongée et ergonomie de la touche Verrouillage majuscules. Le sélecteur d’accents et une touche Verrouillage majuscules restée activée (absence de voyant lumineux visible sur certains Mac) génèrent des variantes de majuscules et d’accents que l’utilisateur n’a jamais souhaitées.

Disposition du clavier et paramètres régionaux

• Remappage complet de la disposition du clavier — le mécanisme le plus évident mis en évidence par l’enquête menée par la Fondation. Si la langue de saisie du système d’exploitation n’était pas l’anglais au moment de la saisie ou du transfert, le système remappait les touches, de sorte que les caractères qui apparaissaient dans le champ n’étaient pas ceux indiqués sur les touches.
• Inversion des touches « y » et « z » sur le clavier QWERTZ et autres permutations de disposition entre la saisie initiale et la ressaisie.
• Le problème de suppression des caractères non ASCII dans la console Geth. Si un portefeuille de prévente était ensuite importé dans Geth, la console supprimait silencieusement les caractères dont le point de code était supérieur à 127 dans certaines configurations régionales — un mot de passe comportant des caractères spéciaux pouvait ainsi être tronqué ou vidé de son contenu. (Il s’agit d’un bug lié à un chemin d’accès spécifique, et non d’un bug lié aux navigateurs de 2014.)

Erreurs de saisie, de matériel et de fichiers

• Le « geste d’agitation » lié à la phase d’entropie. La prévente collectait des données d’entropie initiales à partir des mouvements de la souris, et le champ de mot de passe n’était pas toujours désactivé pendant cette étape : une frappe accidentelle en agitant la souris pouvait ajouter un caractère que l’utilisateur n’avait jamais prévu et dont il ne se souviendrait pas. Ce problème est spécifique à l’expérience utilisateur (UX) de la prévente.
• Espaces et sauts de ligne issus du collage (un espace en début ou en fin de ligne, ou un \n/\r\n détecté lors du collage dans le champ).
• Des touches qui collent ou qui rebondissent, provoquant l’affichage involontaire d’un caractère en double.
• Troncature après validation / mot de passe vide — champ modifié après avoir passé avec succès la validation du formulaire.
• Différences liées au rechiffrement. L’importation du portefeuille dans MyEtherWallet, Mist ou Geth entraîne son rechiffrement à l’aide de nouveaux paramètres de chiffrement : il est possible qu’une copie s’ouvre tandis qu’une autre échoue, et une réimportation corrompue peut rendre le portefeuille définitivement inaccessible. Conservez et testez chaque copie.
• Téléchargement interrompu / intégrité du fichier. Un téléchargement interrompu sur une connexion lente peut entraîner un fichier encseed incomplet ; dans ce cas, aucun mot de passe ne permettra jamais de le déchiffrer. Vérifiez le fichier avant de consacrer le moindre effort à son décryptage.

Ce que cela signifie pour la reprise

Le résultat concret est encourageant : si vous vous souvenez de votre mot de passe, la récupération d’un portefeuille de prévente revient essentiellement à énumérer ces transformations d’une chaîne de caractères connue — et non à deviner des millions de mots de passe. Voici une approche judicieuse :

• Retrouvez tous les exemplaires du fichier JSON — le service de prévente vous l’a envoyé par e-mail ; vérifiez vos anciens e-mails, vos disques durs, vos sauvegardes sur le cloud et vos anciens ordinateurs. Les copies rechiffrées présentent des différences, donc plus vous en trouverez, plus vous aurez de chances de réussir.
• Vérifiez chaque fichier (format JSON valide, longueur d’encseed raisonnable) avant d’y consacrer du temps.
• Vérifiez dans votre gestionnaire de mots de passe s’il existe une entrée datant de 2014 faisant référence à la vente participative d’Ethereum — ainsi que l’historique des mots de passe, car la valeur enregistrée a pu être modifiée par la suite.
• Testez votre meilleur candidat avec les variantes d’encodage et de particularités de saisie mentionnées ci-dessus, en fonction du système d’exploitation et du clavier que vous utilisiez à ce moment-là.

Si le fichier lui-même a disparu, personne ne pourra vous aider — mais si vous l’avez toujours en votre possession, vos chances de récupération sont bien meilleures que ne le pensent la plupart des utilisateurs. C’est notre métier ; consultez notre guide de récupération des jetons achetés lors de la prévente d’Ethereum.

Sources

Ce catalogue s’appuie sur des sources primaires plutôt que sur des opinions : l’implémentation de référence canonique ethereum/pyethsaletool et l’interface de prévente (ethereum/www) ; l’enquête menée par la Fondation Ethereum elle-même sur les « mots de passe erronés » (le fil de discussion Mist n° 3513 et les rapports associés) ; les problèmes de go-ethereum concernant l’encodage et la gestion des entrées en ligne de commande ; l’implémentation du mode 16300 de hashcat; et l’outil ethereum2john de John the Ripper. Les comportements mentionnés ci-dessus sont documentés dans ces sources ainsi que dans les témoignages des participants qui se sont retrouvés bloqués.

Foire aux questions