En discutant avec @elois (et en explorant l’intégration d’outils tiers depuis un moment), je pense que c’était une erreur d’utiliser sr25519 pour la génération des phrases mnémoniques des portefeuilles dans Gecko et dans l’ensemble des clients v2s.
Les avantages de sr25519 (créé et utilisé uniquement par l’écosystème Polkadot) ne nous concernent pas, et nous ferment les portes de toute une série d’interopérabilités avec des outils tiers qui fonctionnent nativement avec ed25519.
Nous pouvons en discuter pour approfondir le sujet des pour et des contre, mais je propose de revenir en arrière sur cette implémentation et d’utiliser exclusivement ed25519 pour la génération de tous nos portefeuilles.
Il est encore temps de faire ce changement avant que nous soyons en production, seules nos adresses gdev vont changer.
After discussing with @elois (and exploring third-party tool integration for a while), I believe it was a mistake to use sr25519 for generating wallet mnemonics in Gecko and across all v2s clients.
The benefits of sr25519 (created and used solely by the Polkadot ecosystem) do not apply to us, and it closes the door to a whole range of interoperability with third-party tools that natively work with ed25519.
We can discuss this further to explore the pros and cons, but I propose we roll back this implementation and exclusively use ed25519 for generating all our wallets.
There’s still time to make this change before we go into production; only our gdev addresses will change.
Petit rappel pour moi-même sur l'utilisation de Sr25519 dans DuniterV2S.
Distinction pour les signatures
A priori, Substrate n’a aucune idée du fait qu’une clé est de type Sr25519 ou Ed25519. Ce dernier ne fait que considérer des clés publiques et leur adéquation avec une signature.
Autrement dit, du point de vue de Duniter, les clients font bien ce qu’ils veulent.
Utilisation dans Duniter
Par contre : 3/4 des clés du trousseaux de session sont formés de clés Sr25519, seul Grandpa utilise Ed25519. Donc ça veut dire que migrer sur une utilisation avec Ed25519 implique un reboot de la ĞDev si l’on ne veut pas trop se casser la tête. Mais je ne vois aucun intérêt à changer cela, ni même si c’est possible (il y peut-être des fonctionnalités de Sr25519 utilisées dans ce protocoles).
Oui je précise que je ne parle que des clés clients, pas du tout des clés de sessions Duniter qui doivent nécessairement être en sr25519 pour faciliter l’usage de la vrf avec ces clés.
Si, en fait on peut regarder sur quelle courbe se situe un point, @1000i100 a fait un petit programme typescript (codé avec windsurf) pour déterminer si une clé publique est sr ou ed.
Oui, mais on na va pas toucher à ça. Sr et Ed seront tous les deux disponibles (ainsi que ECDSA) et Sr continuera d’être utilisé pour les session keys. Comme dit poka, c’est juste les applis client qui vont dériver par défaut en Ed pour les utilisateurs grand public.
Si on part là dessus, est-ce que ça vaudrais le coup de dire :
compte forgeron et comité technique : sr25519 pour renforcer la sécurité ?
Ou bof et on lache le sr partout ?
Sr25519 n’est pas plus sécurisé que Ed25519, cela permet juste d’offrir plus de fonctionnalités que nous n’utilisons pas (par exemple, l’agrégation de signatures offchain).
Pour les membres du comité technique, ce qui ferait sens serait plutôt d’utiliser des hardware wallets.
Je possède deux YubiKeys et un Ledger, donc je peux essayer de les intégrer à GLCI ou autre pour voir ce que cela donnerait.
Concernant les membres forgerons, on peut recommander l’usage de hardware wallets dans la charte, mais l’exiger pourrait être trop excluant.
Si on veut promouvoir les comptes Ed25519; est-ce que l’on veut revoir également la possibilité d’ajouter des dérivations sur ces comptes ou non ?
Pour info, ça peut être supporté dans Gcli, mais on avait décidé qu’il valait mieux retirer cette possibilité : J’ai toujours un test qui montre qu’on peut faire la dérivation:
J’ai fait une MR qui le permet, je t’ai mis relecteur @Nicolas80
Je parlais à l’époque de ne pas chercher à ajouter des fonctionnalités aux account id/password, mais pas spécialement au type ed25519 (qui sont deux choses différentes)
Je regarde la merge request et effectivement, je n’avais pas compris que l’on voulait utiliser Ed25519 pour les comptes avec mnémonic également (pas juste “g1v1”).
Mais du coup, comme en DB on ne sauve que le crypto-scheme; on ne pourra plus empêcher les gens de faire une dérivation sur un compte “g1v1”.
Je ne sais pas si c’est un soucis ou pas ?
(Je regarderai plus en détail la merge request dans les jours qui viennent)
Je pense que ce n’est pas un souci dans la mesure où les utilisateurs de GCLI sont des utilisateurs avertis et savent qu’il est préférable d’utiliser des comptes créés via un mnémonic.
(pas juste “g1v1”).
