Signatures numériques : ECDSA et Schnorr

Curiosité

1. Comment une signature prouve-t-elle le contrôle d’un nombre secret sans le révéler ?
2. Pourquoi la PlayStation 3 de Sony et plusieurs portefeuilles bitcoin sur Android ont-ils perdu leurs clés à cause de nonces réutilisés ou prévisibles ?
3. Qu’est-ce qui rend les signatures Schnorr plus petites, plus rapides et capables d’agrégation par rapport à ECDSA ?

Explorer

1. Une signature numérique prouve la possession d’une clé privée sans la divulguer. Dans Bitcoin, dépenser une sortie de transaction exige de signer le hash de la transaction avec la clé privée correspondant à la clé publique figurant dans le script de verrouillage de cette sortie. N’importe qui peut vérifier la signature à l’aide de la clé publique et du hash du message. Ce mécanisme garantit que seul le détenteur de la clé peut autoriser des transferts, tout en préservant la confidentialité.
2. ECDSA, normalisé dans ANSI X9.62 (1999), est le principal schéma de signature de Bitcoin depuis 2009. Il génère une paire de valeurs (r, s) à partir du hash du message et d’un nonce secret k. La valeur r est la coordonnée x du point k·G ; la valeur s vaut k⁻¹(hash + x·r) mod n, où x est la clé privée. Comme chaque signature exige un nouveau k aléatoire, réutiliser ou divulguer k permet à un attaquant de calculer directement la clé privée.
3. La clé de signature de la PlayStation 3 de Sony a été compromise en 2010 lorsque fail0verflow a démontré que Sony réutilisait le même nonce pour toutes les signatures. Bitcoin a connu des vols similaires en août 2013 en raison d’une faille SecureRandom d’Android, qui produisait des nonces prévisibles. Le RFC 6979 (2013) a résolu ce problème en dérivant k de manière déterministe à partir de la clé privée et du hash du message, éliminant ainsi le recours à des sources aléatoires externes.
4. Les signatures ECDSA sont malléables : pour un r donné, il existe deux valeurs s valides (s et n−s). Un tiers pourrait substituer la signature équivalente, modifiant ainsi l’identifiant de la transaction sans l’invalider. Les règles de politique de Bitcoin exigent une normalisation « low-S », qui restreint s à la moitié inférieure de l’ordre de la courbe. Cette contrainte garantit que chaque message n’a qu’une seule signature canonique par nonce.
5. Les signatures Schnorr, brevetées par Claus-Peter Schnorr (brevet américain accordé en 1991, expiré en 2008) et normalisées pour Bitcoin dans le BIP340, produisent des signatures de taille fixe de 64 octets, sans le surcoût de l’encodage DER. Elles sont linéaires : avec un protocole rigoureux, plusieurs clés publiques peuvent être combinées en une seule clé agrégée, et leurs signatures en une seule signature. Cela permet des schémas multisig MuSig2 qui apparaissent sur la chaîne comme des sorties à signataire unique, ce qui réduit la taille des transactions et améliore la confidentialité.
6. Taproot a été activé en novembre 2021 (bloc 709 632), introduisant la prise en charge native des signatures Schnorr pour les sorties P2TR. Une dépense par chemin de clé ne nécessite qu’une signature de 64 octets dans son témoin, contre une signature ECDSA de 71 à 72 octets plus une clé publique de 33 octets pour une dépense P2WPKH. La taille fixe simplifie l’analyse, et Schnorr permet la vérification par lots, c’est-à-dire la vérification simultanée de nombreuses signatures issues de clés différentes, plus rapide qu’une vérification une à une ; Bitcoin Core n’exploite pas encore cette possibilité.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• BIP340: Schnorr Signatures for secp256k1 (P. Wuille, J. Nick & T. Ruffing, 2020)
• RFC 6979: Deterministic Usage of DSA and ECDSA (T. Pornin, 2013)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• fail0verflow, 'Console Hacking 2010: PS3 Epic Fail', 27C3 (December 2010)