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

Reste à comprendre comment implémenter ça proprement :slight_smile: Idéalement via libsodium qui est la librairie qui nous sert à faire les clés de signature et de chiffrement. (scrypt ne fait que générer les seeds)

Oui, en cas de hack de la plateforme ou si le vendeur la révèle. Si la personne accepte des paiement sur son site il ne donnera pas M, seulement des dérivés. L’avantage c’est qu’il n’expose jamais les clés privés permettant de voler l’argent.

Il peut très bien y avoir un document “Je mine avec la dérivation /3 de ma clé publique” signé par la clé privée père, ainsi qu’un 2ème pour révoquer cet état.

Pour le côté utilisateur, je ne sais pas si cet algo est pour ed25519 ou curve25519 (ou les 2), mais si ce n’est pas le cas il suffirait de rajouter 1 opcode, voir un 2eme pour payer sur le hash d’une clé (la clé publique est alors demandé en input).

Pour le côté mineur/compte membre, ça serait en effet une modification du protocole pour autoriser les mineurs d’utiliser les sous-clés, de même pour les comptes membres.

C’est une simple proposition d’amélioration du protocole qui pourrait régler certains problèmes (exposition de la clé privé “principale” sur la machine qui mine, exposition de la clé privé “principale” sur un wallet)

Je vais regarder ça.

EDIT : @cgeek J’avais mal lu ta remarque. On pourra connaître tous les clients uniquement si M fuite. De plus si les clients utilisent des HD wallets avec adresses à usage unique, le risque est bien moindre, puisqu’à la prochaine transaction de cette adresse tu pourras difficilement savoir à qui appartient les adresses de destination.

1 J'aime

Si le protocole doit être modifié pour autoriser les clés déléguées, je ne vois pas de raison valable de se limiter aux clés dérivées :

  • car déjà il n’y a pas de gain particulier en nombre de documents car soit 1) on utilise des clés dérivées, et alors il faut un document pour les révoquer ; soit 2) on autorise tout type de clé, et alors il faut un document pour les déclarer.

  • mais en plus avec 1), on est contraint de mémoriser en blockchain tout l’historique des révocations pour être sûr qu’une clé déléguée n’a pas déjà été révoquée, ce qui va nous faire stocker inutilement de la donnée et multiplier les accès en lecture. Tandis qu’avec 2), on a juste à mémoriser en blockchain la dernière clé déclarée qui est la seule à pouvoir calculer, on peut aussi revenir sur une clé précédente, et on peut même utiliser une clé générée par nos soins d’une toute autre façon que la dérivation. Bref, on a le choix et une taille constante de clés déléguées possibles en blockchain.

Alors sauf à ce que les clés dérivées apportent un autre bonus vraiment intéressant pour le calcul de blocs, je trouve contre-productive leur utilisation dans ce cadre.

Oui c’est la meilleure option.

E fait outre cette histoire de clé déléguée, la seule modif du protocole qui me semnle importante c’est de se doter d’un système d’adressage permettant de payer le hash d’une clé plutot que la clé directement. On pourrais inclure ça en même temps que P2SH :wink:

Pourquoi “en même temps” ? C’est pas déja ce que doit faire P2SH ?

EDIT : Ah pardon, tu parles de ça : https://github.com/duniter/duniter/issues/1002

Je suis d’accord. À voir ce que vous en pensez pour avoir le même système avec l’utilisation des comptes membres.

@cgeek De toute façon les clés dérivées ne remplace pas scrypt, puisqu’il faut bien générer un paire valide en premier lieu.

J’ai fais des recherches, et ça semble bien être avec ed25519, donc même système de clés.

Du coup l’OP SIG et P2SH seront utilisables.
Le côté HD sera du côté client.

Comme pour le mineur, on pourrait autoriser un compte membre à “déléguer” son identité sur une autre clé (générée à la main ou dérivée), avec l’originale seule pouvant faire ce changement.

D’autant qu’avec 2), on peut notamment inclure les clés dérivées, mais aussi d’autres types comme les clés VRF permettant de faire du tirage aléatoire secret, ce qui ouvre les portes du tirage au sort des calculateurs. Ce serait dommage de se priver de telles fonctions !

Mais d’ailleurs tu noteras que scrypt n’est pas du tout dans le protocole, Duniter étant totalement agnostique du mode de génération des clés. Tout ce qu’il faut, c’est une compatibilité avec Ed25519.

1 J'aime

Très bien. J’ai pas de problème avec ça, surtout que ça fait moins de travail :wink:

En tout cas, je serai intéressé de comprendre comment se font techniquement les clés dérivées. Effectivement côté client il y a plein d’intérêts.

Va lire le lien que j’ai donné plus haut, c’est expliqué :slight_smile:

Penses-tu que la délégation de clé d’un compte membre pour le minage pourrait aussi servir d’accès “révocable” à un compte sans avoir besoin de révoquer le compte en lui meme ?

EDIT : J’ai réfléchi un peu à la question.

Chaque membre peut à l’aide d’un document définir la condition cryptographique qui permet de faire des actions avec son compte (certifier, proposer un bloc, renouveler son compte, envoyer de l’argent). S’il n’y a pas eu de document de ce genre, alors ça correspond au système actuel. Un nouveau document invalide l’ancien. Cependant pour produire ce document de changement de condition, il faut utiliser la paire principale du compte (sinon la clé compromise permettrais de changer ces conditions, ce qui serait dangereux).

On peux aussi penser que les certifications en attente sont invalidées si changement de clé, pour éviter qu’un compte compromis puisse certifier n’importe comment. Bien évidement les certifications déjà validées par la WoT ne sont pas concernées (comme actuellement pour les certifications issues de comptes révoquées, non ?).

Les éléments à rajouter au protocole sont donc :

  • Un document spécifiant une condition alternative pour utiliser un compte membre, signé obligatoirement avec la clé privée principale. Il annule automatiquement l’ancienne version (s’il y a)
  • Toute opération sur un compte membre (sauf le document ci-dessus et la révocation du compte) peut être signée soit avec les clés principales, soit doivent respecter la condition définie dans le document.
  • Toute opération non instantanée (comme une certification en attente) signée avec la condition personnalisé deviennent invalides si changement de condition (la signature est en fait vérifiée à la publication sur la blockchain et à l’application)

Il ne me semble pas bon de permettre ça sur n’importe quel compte portefeuille pour éviter des spams de changements. On pourrait d’ailleurs imposer un certain laps de temps entre 2 changements de conditions pour éviter les abus.

1 J'aime

Il est décrit comment générer ces clés, mais je voulais comprendre quel était le lien cryptographique permettant de conserver le lien k -> K (ou dit autrement, qu’une signature de m/1 soit vérifiée par M/1) malgré une dérivation totalement indépendante des chaînes de clés privées et clés publiques.

Car autant il est facile de déduire M/1 de m/1 (toutes les libs de crypto permettent de le faire), autant avoir une fonction qui dérive d’abord M/1 (la clé publique) à partir d’une autre clé publique puis qu’on soit aussi capable de dériver m/1 (la clé privée) après connaissance de M/1 est délicat.

C’est ce que j’aimerais comprendre, mais j’ai l’impression qu’il va falloir se plonger dans la crypto elliptique pour réussir.

Je n’ai pas trop compris ta question, mais j’ai des réponses à apporter sur tes remarques.

C’est une chose à laquelle on a déjà pensé, l’idée est simplement de pouvoir permettre le changement de cryptographie pour un membre ou les signataires d’une transaction. C’est une vision long terme qui permettra de s’adapter aux évolutions de ce domaine.

Concernant les transactions, il suffit de les faire passer dans une version supérieure où l’on autoriserait de spécifier la cryptographie utilisée, et alors les fonctions SIG s’adapteront à ce contexte.

Concernant les documents de WoT, on peut imaginer la même chose : les faire passer en version supérieure et autoriser d’indiquer la cryptographie utilisée parmi une liste prédéfinie. Le plus simple me semble être d’utiliser le document d’adhésion pour déclencher ce changement, document qui peut être renouvelé au mieux tous les 2 mois dans la Ğ1.

Oui, changer de clé (et/ou de crypto) annulerait et remplacerait l’ancienne. De fait, les certifications en attente qui utiliseraient l’ancienne clé ne seraient plus valides. Les certifications écrites resteront écrites et valides, oui.

Ce deuxième cas me paraît compliqué. Pourquoi pas juste « doit être signé par les clés principales » ?

En effet, c’est une propriété de la fonction point de la crypto elliptique, et lié directement aux transformations sur courbes elliptiques quand tu fais des opérations.

Il serait bien de pouvoir mettre une clé “révocable” de son compte sur son smartphone pour pouvoir certifier des personnes quand on est pas chez soit par exemple, sans compromettre le compte en lui même. C’est pour ça que je considèrerais des signatures avec la clé personnalisée pour tous documents sauf la révocation du compte et le change de clé personnalisé. Il ne faut pas qu’avec cet accès “restreint” on puisse révoquer le compte. Mais pouvoir certifier, pourquoi pas, surtout si

Avec ça il devient possible d’utiliser son compte membre sur un smartphone ou un ordi moins secure sans prendre trop de risque.

Pour tout le reste de ton post je suis d’accord, ça pourra permettre aussi d’utiliser les signatures de Schnorr (quantum-proof)

1 J'aime

C’est discutable, car ça alourdit quand même le système. Mais après tout pourquoi pas.

En effet ça alourdit un peu le système :stuck_out_tongue: Mais ça me semble être une bonne idée pour les utilisateurs.

Tu as déjà des documents sur comment tu veux faire le P2SH (sript hash) et P2PKH ( Public key hash) ?

Le P2PKH est décrit dans le ticket#1002, tu y trouveras un lien vers une explication plus détaillée sur le forum.

Le P2SH est décrit dans le ticket#1165.

Pour l’instant, je m’exclu de ces développements. Mais je veux bien écrire des tests :slight_smile:

2 J'aimes

Merci je vais regarder ça.

Pas de problème. Je veux bien le faire quand je serais en train d’implémenter cette partie là dans duniter-rs. Je pense que je vais avoir besoin de plonger dans le code de duniter-ts pour bien le faire, du coup je devrait pouvoir rajouter ça ensuite :slight_smile:

J’ai un peu cherché sur le sujet, j’ai trouvé un article sur l’adaptation de cette BIP32 à ed25519 :

Je ne sais pas si une implémentation existe. J’aimerais bien créer un client HDWallet POC pour Duniter, mais je vais devoir grandement monter en compétences :rofl: ce ne sera pas avant 1 ou 2 ans.

Il semble que le projet Cardano a déjà implémenté des HDWallets compatibles avec ed25519 :

Il existe plusieurs implémentations des HD wallet pour Ed25119, mais attention a utiliser impérativement une implémentation récente et qui indique explicitement ne pas être exposée a cette faille de sécurité :

Il existe par exemple une implémentation en Rust qui est récente et robuste à l’attaque citée au dessus :

2 J'aimes