Dérivation renforcée vs dérivation non renforcée

Le renforcement est une frontière dans votre chemin de dérivation, et non un réglage que vous activez. Le BIP-32 a été attribué le 11 février 2012 avec la seule dérivation non renforcée ; la dérivation privée pour les indices supérieurs ou égaux à 0x80000000 a été ajoutée le 16 avril 2013, et ces clés ont été renommées renforcées le 15 janvier 2014. L'endroit où tombe cette frontière détermine la part de votre portefeuille qu'une clé publique étendue partagée livre.

Comment cela fonctionne

La dérivation non renforcée possède une propriété que la dérivation renforcée n'a délibérément pas, et le BIP-32 consigne cette différence sous forme d'identité algébrique. Notez N() la neutralisation, l'étape qui écarte la moitié privée d'une clé étendue et conserve le code de chaîne de 32 octets. Sur les niveaux non renforcés, N(m/a/b/c) est égal à N(m)/a/b/c, si bien que neutraliser avant de dériver et neutraliser après avoir dérivé aboutissent à la même clé. À un niveau renforcé, la réécriture casse : N(m/a') ne peut pas devenir N(m)/a', car la dérivation publique n'est définie que pour les enfants non renforcés et renvoie un échec pour tout le reste.

Mécaniquement, les deux modes diffèrent par un champ. Tous deux alimentent un HMAC-SHA512 avec le code de chaîne du parent et y ajoutent l'indice de 4 octets. Le mode non renforcé fournit la clé publique compressée du parent ; le mode renforcé fournit le secret du parent complété par un octet zéro initial pour atteindre la même largeur de 33 octets. Quiconque ne détient qu'un xpub ne possède pas ce second élément, la dérivation s'arrête donc à la frontière.

Le BIP-32 est d'une franchise inhabituelle sur ce que les clés non renforcées ne protègent pas. Sa section sur la sécurité énumère deux propriétés comme absentes plutôt que présentes : étant donné une clé publique étendue parente et une clé publique enfant, trouver l'indice n'est pas difficile, et étant donné cette même clé publique étendue parente plus une clé privée enfant non renforcée, retrouver la clé privée étendue parente n'est pas difficile non plus. La première vous coûte votre confidentialité. La seconde vous coûte la branche.

Où cela se voit

Les niveaux non renforcés sont ce qui rend une clé publique étendue digne d'être exportée, et le BIP-32 consacre une section aux arrangements de partage bâtis sur eux. Un auditeur à qui l'on remet les clés publiques étendues de compte voit chaque paiement entrant et sortant de chaque compte et pas une seule clé secrète. Deux entreprises qui échangent souvent peuvent partager la chaîne externe d'un même compte comme adresse permanente pour recevoir, si bien qu'aucune n'a à en demander une nouvelle à chaque transfert. Un site marchand peut remettre le même type de clé à son serveur web, qui génère alors des adresses de réception qu'il n'a pas le pouvoir de dépenser.

La disposition qui place la frontière au niveau du compte relève du conseil, pas de la règle. Le BIP-32 qualifie sa structure maître, compte, chaîne et sous-chaîne de purement indicative et indique aux implémentations qu'elles peuvent s'en écarter pour des besoins précis, raison pour laquelle un portefeuille conforme peut renforcer plus de niveaux que le portefeuille conforme voisin.

Un piège d'interopérabilité mérite d'être connu, car la spécification a été corrigée deux fois pour lui. Des vecteurs de test couvrant la dérivation renforcée avec des zéros initiaux ont été ajoutés le 24 février 2017 puis de nouveau le 4 novembre 2020. L'entrée renforcée est fixée à 33 octets, un octet zéro suivi du secret de 32 octets, si bien qu'un logiciel qui supprime un zéro initial au lieu de conserver cette largeur hache des données différentes, produit une branche différente et trouve un portefeuille vide quand quelqu'un restaure cette phrase de récupération dans un autre programme. La dérivation non renforcée ne rencontre jamais ce bug, car une clé publique compressée commence toujours par 0x02 ou 0x03 et n'a donc aucun zéro initial à perdre.