Proposition d'un modèle de portefeuilles "HD"

[nanocryk]

@cgeek

Je ne dis pas qu’il n’y a pas un intérêt supplémentaire à l’utilisation de scrypt que je ne vois pas, par contre il faudrait le révéler pour qu’on puisse comprendre

Je l’ai fait plusieurs fois :

@nanocryk

Soit la clé m la clé maître privée, et M la clé maître publique associée.
Avec m tu peux générer m/i pour tout i, sans connaître M.
Avec M tu peux générer M/i pour tout i, sans connaître m.
Et ce de manière récursive.

Tu peux générer la partie publique de la hiérarchie sans connaître la clé privée, ce que l’on ne peut pas faire avec les exemples de code que tu me propose avec scrypt. Ce point là permet notamment de générer des clés publiques sur un site web de commerce sans qu’il ne stocke jamais une seule clé privée sur le serveur.

De même pour le minage avec clé dérivée (ou accès à compte membre par clés dérivées), avec la clé publique les utilisateurs pourront générer les clés publiques filles sans connaître la clé privée (heureusement), et du coup vérifier la signature produite par la clé privée dérivée utilisée par le membre. La clé privée dérivée est compromise ? On la révoque avec un nouveau type de document dans ce but, et on en utilise une nouvelle dérivée avec un autre index. Avec la clé publique mère, la signature et le chemin de dérivation, les utilisateurs pourront vérifier le message signé.

Le public ne connait que M et peux calculer M/0, M/1, M/1/0 etc, et du coup vérifier les signatures issues des clés privées m/0, m/1, m/1/0.

En plus de ça il y a la possibilité d’avoir des clés “renforcées” qui empêche certaines dérivations, noté par exemple M/0'. Cela permet d’empecher de remonter ou de decendre dans la hierarchie si on ne connait pas clé publique + chain code (appelée clé étendue). Tout ça est très bien expliqué dans ce lien que j’ai déjà donné au dessus.

@Inso

Comment vérifier, avec l’info de dérivation, que m est une clé dérivée de M ?

Une clé dérivée de M (publique) se note M/i, m c’est la clé privée.
Mais si tu définie m comme étant M/0 par exemple, alors tu peux dériver M/0 à partir de M, ce qui ne sert pas à grande chose.
Ce qui est beaucoup plus intéressant et non faisable avec scrypt (il me semble) :

• Dériver m/i à partir de m.
• Dériver M/i à partir de M.
• Signer un message avec m/i
• Vérifier le message avec M/i

Et ce peu importe i, m et M tant que (m;M) est une paire de clés.

Le but ce n’est pas de prouver que A est dérivé de B (il suffit de dériver B pour le savoir), mais de pouvoir vérifier un message signé par a dérivé de b avec la clé A.

Dans ces cas là je ne parle pas des clés “renforcées” (m/i' et M/i') qui permettent justement de restreindre les dérivation pour rajouter des “barrages” en cas de fuites d’informations.