Elle ne sont pas différente dans leur utilisation, mais dans leur génération. A partir de la clé publique mère tu peux générer toutes les filles qui correspondront aux filles de la clé privée mère.
Pour un système de commerce plus anonyme, voila la procédure :
Tu génère une paire (m,M) (privé/publique)
Sur le site de commerce, tu donne uniquement ta clé publique M
Pour chaque client, le site va dériver M/1, M/2, etc
Si tu veux accéder à cet argent, tu dérive m/1, m/2, etc en local pour signer les transactions.
Au final tu n’as mis qu’une seule clé publique sur le site qui peut être dérivée pour une “infinité” de clients, chaqu’un en ayant une différente.
Pour le vérifier il te suffit de dériver M à l’index 1 pour trouver M/1. Mais ce n’est pas le but de ce système.
On note M/1 la “dérivée” de M avec comme paramètre 1. Il y a la formule pour calculer M/1 à partir de M dans le document que j’ai donné. (pareil pour m)
Donc il faut connaitre M, ok. Je me demandais si M/1 pouvait prouver qu’il était bien le descendant de M Ce n’est donc pas le cas.
Ok, je comprends mieux l’intérêt. Si la clé M est compromise, on peut connaitre toutes les clés publiques M/i mais pas les dévérouiller. Et seulement la clé M est fournie aux agents qui vont héberger le système sensible. La partie privée reste hébergée dans une zone sécurisée, offline par exemple.
Je parle de la partie qui utilise scrypt. Car tu me dis « l’intérêt de la dérivation HD c’est qu’on n’a pas besoin de la clé privée », or, l’intérêt de qui est-ce que cela sert ?
Si c’est l’intérêt du web-commerçant, c’est un intérêt économique particulier qu’on n’a pas besoin de favoriser, surtout s’il peut déjà établir un comportement similaire via d’autres méthodes comme scrypt (ou autre, peu importe).
Si c’est l’intérêt des membres de la Ğ1 pour la clé déléguée, alors j’ai déjà répondu qu’on ne gagne qu’un coup sur N, ce qui est négligeable. D’ailleurs cela restreint les clés utilisables à celles dérivées de la clé mère, tandis qu’un mécanisme de déclaration permet de déclarer n’importe quelle clé.
Mais de manière générale, si ce mécanisme peut être obtenu sans rien modifier au protocole Duniter, alors vous faites ce que vous voulez.
Donc en fait si l’une des clé est identifiée comme appartenant au site S, alors on connaît tous ses clients instantanément. Bien.
Dans le cadre du minage ou des comptes membres (dont la clé n’est pas changeable), on peut justement utiliser ce système de dérivation pour créer des “sous-clés” révocables. Tu n’expose pas ta vraie clé privée mais seulement une dérivation, et si cette dernière est compromise, tu pourrais (avec ta clé mère) révoquer cette sous-clé et en utiliser une autre. De cette manière ce n’est pas risqué de miner sur une machine que l’on ne contrôle pas totalement, et pour les wallets mobile/web ça peut permettre d’utiliser son compte membre tout en pouvant révoquer uniquement l’appareil compromis. En tant que membre j’ai ma paire (m,M). J’utilise Cesium avec (m/1,M/1) et mon smartphone avec (m/2,M/2). Si il s’avère que j’ai un keylogger qui à intercepté m/1, je peux avec m publier un document révoquant l’accès avec m/1 sans pour autant révoquer le compte tout entier. C’est comme si tu faisais opposition sur ta carte bancaire sans fermer ton compte (sans les remboursement évidement)
Reste à comprendre comment implémenter ça proprement 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.
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.
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
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.
Va lire le lien que j’ai donné plus haut, c’est expliqué
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.
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)
Ce n’est donc pas le cas.
Idéalement via 
Mais ça me semble être une bonne idée pour les utilisateurs.