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.
@poka Si tu n’as pas trop de temps pour le moment et que c’est ok avec toi, je peux regarder pour tenter de finaliser la première MR “Can choose between ed25519 ans sr25519 (!44)” que tu link plus haut.
Par contre, je voudrais avoir des retours sur le fait que l’on veuille ajouter ou non une colonne supplémentaire pour le format exact (ou juste le fait que c’est basé sur une clé g1v1) ?
Pour résumer, actuellement dans la DB, on a déjà le crypto_scheme: ed25519 ou sr25519; qui est suffisant pour gérer la sérialisation / désérialisation des clés.
La question est:
Est-ce que l’on veut ajouter un champ supplémentaire en DB juste pour avoir l’information que la clé (avec scheme ed25519) provient d’une clé g1v1 générée avec id & passwsord
Cela amène également le soucis que les utilisateurs devront re-créer la DB; ou bien il faut voir comment appliquer un script de “migration” pour ajouter la colonne (pas encore testé si facilement faisable avec le crate sea-orm pour ma part)
Ou est-ce que c’est mieux de ne pas l’ajouter, avec la limitation qu’on ne peut pas distinguer une clé ed25519 faite depuis identifiants g1v1 ou non.
En y réfléchissant encore un peu, je pense que c’est inutile d’ajouter l’information que la clé (ed25519) provient d’une clé g1v1…
La raison est que l’on peut tout de même passer outre cettre restriction en récupérant le seed de cette clé et en faisant un (nouvel) import au format substrate (et crypto ed25519).
Exemple avec la version Gcli adaptée dans la MR:
Ajout de la clé comme “g1v1”:
gcli vault import -S g1v1 -c ed25519 --g1v1-id "test_cesium_id" --g1v1-password "test_cesium_pwd" -n "g1v1_normal" --no-password
The G1v1 public key for the provided secret is: '86pW1doyJPVH3jeDPZNQa1UZFBo5zcdvHERcaeE758W7'
Creating <Base> account Base[address:5ET2jhgJFoNQUpgfdSkdwftK8DKWdqZ1FKm5GKWdPfMWhPr4, g1v1_pub_key:86pW1doyJPVH3jeDPZNQa1UZFBo5zcdvHERcaeE758W7, name:Some("g1v1_normal"), crypto_scheme:Some(Ed25519)]
Change done
gcli vault list all --show-type
available SS58 Addresses:
┌──────────────────────────────────────────────────────────────────────────────────────────┐
│ SS58 Address Crypto Type Path Name │
╞══════════════════════════════════════════════════════════════════════════════════════════╡
│ 5ET2jhgJFoNQUpgfdSkdwftK8DKWdqZ1FKm5GKWdPfMWhPr4 ed25519 G1v1 <Base> g1v1_normal │
└──────────────────────────────────────────────────────────────────────────────────────────┘
vault inspect de la clé pour avoir la suri (seed préfixée par “0x”):
gcli vault inspect -a 5ET2jhgJFoNQUpgfdSkdwftK8DKWdqZ1FKm5GKWdPfMWhPr4
Enter password to decrypt the <Base> account key
> Password ********
Substrate URI: '0x2101d2bc68de9ad149c06293bfe489c8608de576c88927aa5439a81be17aae84'
ré-import de la clé comme “substrate”
gcli vault import -S substrate -c ed25519 -u "0x2101d2bc68de9ad149c06293bfe489c8608de576c88927aa5439a81be17aae84" -n "g1v1_hidden" --no-password
> Account Base[address:5ET2jhgJFoNQUpgfdSkdwftK8DKWdqZ1FKm5GKWdPfMWhPr4, g1v1_pub_key:86pW1doyJPVH3jeDPZNQa1UZFBo5zcd
vHERcaeE758W7, name:Some("g1v1_normal"), crypto_scheme:Some(Ed25519)] already exists. Do you want to update it? Yes
Updating vault account Base[address:5ET2jhgJFoNQUpgfdSkdwftK8DKWdqZ1FKm5GKWdPfMWhPr4, g1v1_pub_key:86pW1doyJPVH3jeDPZNQa1UZFBo5zcdvHERcaeE758W7, name:Some("g1v1_hidden"), crypto_scheme:Some(Ed25519)]
Change done
gcli vault list all --show-type
available SS58 Addresses:
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ SS58 Address Crypto Type Path Name │
╞══════════════════════════════════════════════════════════════════════════════════════════════╡
│ 5ET2jhgJFoNQUpgfdSkdwftK8DKWdqZ1FKm5GKWdPfMWhPr4 ed25519 Mnemonic <Base> g1v1_hidden │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
Du coup, à moins que quelqu’un trouve tout de même utile de garder ce “type” sauvé en DB, je compte retirer ce changement de la MR.
La seule raison que je vois c’est d’empêcher de gérer un compte en ID+pass si ce n’est pas un compte du genesis. Pour obliger à basculer en mnémonique pour tous les nouveaux comptes.
Mais pas sûr qu’un champ soit utile. Juste vérifier qu’un compte en id+pass existe bien et est connu dans le genesis avant de manipuler le compte.
Je suis preneur d’une méthode pour savoir si un compte est connu dans le genesis via l’api RPC, car pour l’instant je ne sais que demander à l’indexer si la date de création est 0.
(pas juste “g1v1”).
