Comment un portefeuille crypto génère-t-il des clés privées et publiques ?

Processus de génération de clé

1. Un portefeuille cryptographique lance la génération de clé en produisant un nombre aléatoire cryptographiquement sécurisé dans un champ fini spécifique, généralement un entier de 256 bits pour Bitcoin et Ethereum.

2. Cet entier devient la clé privée, représentée sous la forme d'une chaîne hexadécimale de 64 caractères ou d'une phrase mnémonique de 12 ou 24 mots codée via les normes BIP-39.

3. La clé privée est ensuite introduite dans une fonction de multiplication de courbe elliptique, en particulier secp256k1 pour Bitcoin et Ethereum, pour dériver la clé publique correspondante.

4. La clé publique subit un hachage SHA-256 suivi d'un hachage RIPEMD-160 pour produire une sortie de 160 bits, qui constitue la base de l'adresse du portefeuille.

5. Un octet de version et une somme de contrôle sont ajoutés avant que le codage Base58Check ne transforme le résultat en format d'adresse final lisible par l'homme.

Fondation de cryptographie à courbe elliptique

1. La courbe secp256k1 définit la structure mathématique utilisée dans les principales blockchains : y² = x³ + 7 sur un champ premier modulo p = 2²⁵⁶ − 2³² − 977.

2. Les clés privées sont des multiplicateurs scalaires appliqués à un point générateur fixe G sur cette courbe.

3. Les clés publiques apparaissent sous la forme des coordonnées du point (x, y) résultant après multiplication scalaire : cette opération est efficace sur le plan informatique mais irréversible sans méthodes de force brute.

4. Le problème du logarithme discret garantit que la déduction de la clé privée à partir de la clé publique reste impossible avec les capacités informatiques actuelles.

5. Chaque clé privée valide correspond à exactement une clé publique, mais plusieurs clés privées ne peuvent pas produire des clés publiques identiques sous des chemins de dérivation standard.

Dérivation de l'adresse du portefeuille

1. Après avoir obtenu la clé publique non compressée (65 octets), les portefeuilles appliquent SHA-256 pour la compresser en un résumé de 32 octets.

2. Ce résumé passe par RIPEMD-160 pour générer un hachage de 20 octets, l'identifiant principal utilisé dans les transactions en chaîne.

3. Un préfixe spécifique au réseau (par exemple, 0x00 pour le réseau principal Bitcoin, 0x01 pour testnet) précède la sortie RIPEMD-160.

4. Une somme de contrôle double SHA256 calcule les quatre premiers octets, ajoutés au hachage préfixé.

5. La charge utile binaire complète subit le codage Base58Check pour produire des adresses P2PKH héritées telles que 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa .

Intégration de phrases mnémoniques

1. BIP-39 introduit la dérivation de clé déterministe à l'aide d'une phrase de départ de 12 ou 24 mots générée à partir de 128 à 256 bits d'entropie.

2. Les mots sont sélectionnés dans un dictionnaire fixe de 2048 mots ; chaque mot code 11 bits, permettant une reconstruction précise de l'entropie originale.

3. Une somme de contrôle étend l'entropie avant le mappage de mots, garantissant ainsi la résistance aux fautes de frappe lors de la saisie manuelle.

4. PBKDF2-HMAC-SHA512 avec 2048 itérations dérive une graine de 512 bits à partir de la phrase secrète mnémonique et facultative.

5. Cette graine sert d'entrée aux algorithmes de portefeuille déterministes hiérarchiques (HD) BIP-32, permettant la dérivation d'innombrables paires de clés à partir d'une seule racine.

Implications sur la sécurité de la génération de clés

1. Des sources d'entropie faibles, telles que des horloges système prévisibles ou des RNG OS à faible entropie, peuvent produire des clés privées statistiquement biaisées et vulnérables à la reconstruction.

2. La réutilisation de la même clé privée sur plusieurs chaînes ou contextes augmente la surface d’exposition sans avantage cryptographique.

3. Les portefeuilles matériels isolent la génération de clés à l'intérieur d'éléments sécurisés, empêchant ainsi les fuites lors des opérations de création ou de signature.

4. Les portefeuilles logiciels reposant uniquement sur des API Web Crypto basées sur un navigateur peuvent exposer la génération d'entropie à des attaques par canal secondaire s'ils sont mal mis en œuvre.

5. L' absence de véritable caractère aléatoire invalide toute la garantie cryptographique , rendant même les courbes mathématiquement solides inefficaces contre une récupération ciblée.

Foire aux questions

Q : Deux portefeuilles différents peuvent-ils générer la même clé privée ? Statistiquement possible mais pratiquement impossible : il existe 2²⁵⁶ valeurs uniques, ce qui rend la probabilité de collision inférieure à 1 sur 10⁷⁷.

Q : Pourquoi certains portefeuilles affichent-ils à la fois des clés publiques compressées et non compressées ? Les clés compressées réduisent de moitié les besoins de stockage en codant uniquement la coordonnée x plus le bit de parité ; les deux formes donnent des adresses identiques une fois hachées.

Q : Est-il sûr de générer des clés hors ligne à l'aide d'outils open source ? Oui : si l'environnement est isolé, les sources d'entropie sont vérifiées et aucune pile réseau n'est active pendant la génération.

Q : La modification de la phrase secrète dans un portefeuille BIP-39 modifie-t-elle les clés privées dérivées ? Oui, la phrase secrète agit comme un sel dans PBKDF2, produisant des graines entièrement distinctes et donc des hiérarchies de clés divergentes.