BlockPulseNews
ECDSA et EdDSA sont deux algorithmes de signature numérique fondés sur les courbes elliptiques. ECDSA, utilisé avec la courbe secp256k1 par Bitcoin et Ethereum, est le plus ancien ; EdDSA, souvent dans sa variante Ed25519, est plus simple et déterministe.
Thème : Portefeuilles et clés
Une signature numérique prouve qu'un message, par exemple une transaction, a été autorisé par le détenteur d'une clé privée. ECDSA (Elliptic Curve Digital Signature Algorithm) est un standard largement répandu qui peut s'utiliser avec différentes courbes : Bitcoin et Ethereum l'emploient avec secp256k1, tandis que la courbe P-256 est courante dans les cartes à puce et les passkeys. ECDSA nécessite un nombre secret, appelé nonce, à chaque signature. Si ce nonce est prévisible ou réutilisé, la clé privée peut être retrouvée à partir des signatures publiques. Beaucoup d'implémentations modernes le dérivent donc de façon déterministe, selon la méthode RFC 6979.
EdDSA (Edwards-curve Digital Signature Algorithm) a été conçu pour éviter ces écueils dès l'origine. Sa variante la plus connue, Ed25519, repose sur une courbe de type Edwards, et son nonce est toujours dérivé de la clé privée et du message, ce qui supprime la dépendance à un bon générateur aléatoire. L'algorithme est rapide et ses signatures ne sont pas malléables dans sa version standard. Solana, Cardano ou Stellar l'utilisent, tout comme les clés de validateurs des chaînes basées sur CometBFT. Bitcoin a de son côté ajouté les signatures de Schnorr avec Taproot, qui partagent plusieurs avantages d'EdDSA tout en restant sur secp256k1.
Imaginons deux portefeuilles. Le premier, sur Ethereum, signe chaque transaction avec ECDSA sur secp256k1 ; s'il utilisait un générateur aléatoire défaillant produisant deux fois le même nonce, sa clé privée serait exposée. Le second, sur Solana, signe avec Ed25519 : le nonce étant calculé à partir de la clé et du message, ce type de défaut ne peut pas se produire de la même façon.
Les deux schémas sont considérés comme sûrs lorsqu'ils sont correctement implémentés, mais les erreurs d'implémentation sont la principale source de failles : nonces faibles en ECDSA, ou règles de vérification incohérentes entre bibliothèques EdDSA. Ni l'un ni l'autre ne résisterait à un ordinateur quantique suffisamment puissant. Les clés ne sont pas interchangeables entre les deux schémas.
Bitcoin a été conçu avec ECDSA sur secp256k1, et Ethereum a repris ce choix pour ses comptes. Changer de schéma demanderait une évolution majeure du protocole et des portefeuilles. Bitcoin a toutefois ajouté les signatures de Schnorr avec Taproot.
Oui, une phrase BIP-39 peut générer des clés pour les deux schémas, selon des méthodes de dérivation différentes. C'est pourquoi un même portefeuille peut gérer des comptes Ethereum et Solana à partir d'une seule phrase.
Les derniers articles de BlockPulseNews sur ce sujet.