Qu'est-ce que la clé privée et le fichier de stockage de clés MyEtherWallet ?

Fondamentaux de la clé privée

1. Une clé privée MyEtherWallet est un entier aléatoire de 256 bits représenté sous la forme d'une chaîne hexadécimale de 64 caractères.

2. Cette valeur constitue la seule preuve cryptographique de propriété des actifs Ethereum détenus à l’adresse correspondante.

3. La clé privée permet directement la signature des transactions sans nécessiter aucune autorité centralisée ou validation tierce.

4. La perte ou l'exposition de cette clé entraîne une perte irréversible du contrôle sur les fonds et les jetons associés.

5. Il est mathématiquement impossible de dériver la clé privée de l'adresse publique ou de toute activité en chaîne.

Structure et objectif du fichier de clés

1. Un fichier Keystore est un conteneur chiffré au format JSON qui stocke une version obscurcie de la clé privée.

2. Il contient des métadonnées telles que l'algorithme de chiffrement utilisé (PBKDF2 ou Scrypt), le sel, le nombre d'itérations et le texte chiffré.

3. Le nom du fichier suit le modèle d'horodatage UTC : UTC--aaaa-mm-jjThh-mm-ss.zzzzzz--address .

4. Sa conception impose une double exigence : la possession du fichier et la connaissance du mot de passe de décryptage.

5. Contrairement aux clés privées brutes, les fichiers Keystore sont intentionnellement résistants aux attaques par force brute en raison de fonctions de dérivation de clé à forte intensité de calcul.

Processus de génération dans MyEtherWallet

1. EtherWallet invoque ethUtil.crypto.randomBytes(32) pour produire une entropie cryptographiquement sécurisée pour la clé privée initiale.

2. La méthode statique Wallet.generate gère à la fois les modes standard et ICAP-direct, avec des boucles conditionnelles pour les contraintes d'adresse.

3. La dérivation de clé publique utilise l'arithmétique de courbe elliptique secp256k1 via ethUtil.privateToPublic() .

4. La génération d'adresse applique le hachage Keccak-256 à la clé publique non compressée et la tronque aux 20 derniers octets.

5. Le chiffrement final au format V3 Keystore utilise soit PBKDF2-HMAC-SHA256, soit Scrypt, en fonction des paramètres sélectionnés par l'utilisateur.

Implications en matière de sécurité des choix de stockage

1. Le stockage uniquement du fichier Keystore sans le mot de passe le rend cryptographiquement inerte et fonctionnellement inutile.

2. Conserver la clé privée brute en texte brut augmente le risque d'exposition en cas de compromission de l'appareil ou de partage accidentel.

3. Les exportations de portefeuilles papier intègrent la clé privée au format QR code, exigeant une discipline de sécurité physique équivalente à la gestion des espèces.

4. Les intégrations de portefeuilles matériels contournent entièrement le stockage local en déléguant les opérations de signature à des éléments sécurisés isolés.

5. Samsung Blockchain Keystore exploite l'interface utilisateur de confiance basée sur TEE pour empêcher la capture d'écran ou l'enregistrement au clavier lors de la saisie mnémonique.

Foire aux questions

Q1 : Un fichier Keystore peut-il être déchiffré sans le mot de passe d'origine ? Les tentatives de force brute sont confrontées à des difficultés exponentielles en raison du nombre élevé d'itérations dans PBKDF2 ou des paramètres gourmands en mémoire dans Scrypt ; aucune méthode de récupération pratique n'existe en cas d'oubli du mot de passe.

Q2 : Est-il sécuritaire d’ouvrir un fichier Keystore dans un éditeur de texte ? Oui, mais uniquement dans un environnement isolé : son contenu est un texte chiffré en base64 et ne révèle aucune clé privée utilisable sans un déchiffrement réussi.

Q3 : Pourquoi MyEtherWallet génère-t-il des adresses différentes lors de l'utilisation du même mot de passe d'une session à l'autre ? Chaque création de portefeuille déclenche une nouvelle génération d'entropie ; les mots de passe servent uniquement de clés de déchiffrement, et non d'entrées de départ déterministes.

Q4 : Que se passe-t-il si je renomme un fichier Keystore ? Renommer n'affecte pas la fonctionnalité : l'adresse est intégrée dans la charge utile JSON et n'est pas dérivée du nom de fichier.