Suite à la vidéo présentant Ğecko et sa façon de stocker les portefeuilles sur disque, cela soulève une problématique pour Tikka.
Actuellement, je stocke la clef publique des portefeuilles dans la base de données sqlite3 qui sert de mémoire disque.
L’utilisateur peut sauvegarder un portefeuille sur disque au format dewif, le chemin du fichier est alors ajouté à côté de la clef publique dans la base de données.
Ceci permet de donner le code d’accès du dewif pour déverrouiller le compte, plutôt que les identifiants classiques ou mnemonic.
Voyant comment cela fonctionne dans Ğecko, j’ai pensé inclure directement le dewif dans la base de données.
Mais cela présente une faille de sécurité dans la base de données, car la clef publique est alors associé au fichier sensible du dewif, ce qui n’est pas souhaitable.
Comme j’ai besoin de lister les comptes en affichant leurs clefs publiques et aussi que cette clef me sert de clef primaire, je ne vois pas comment faire pour garder la possibilité d’utiliser les fichiers dewif.
Au lieu de choisir d’avoir ou pas la clef publique stockée, c’est le choix de stocker le dewif que j’offre.
Ça tombe bien, c’est le comportement actuel !
La meilleure solution qui me vient est la suivante :
Je conserve le comportement actuel, je stocke les clefs publiques, et l’utilisateur stocke s’il le désire le dewif avec (mais pas où il veut, c’est stocké dans la base de données).
On averti l’utilisateur que c’est déconseillé, sauf pour des comptes peu sensibles ou à faibles montants.
Il y a beaucoup trop d’avantage à avoir les clef publiques en base, pour naviguer de compte en compte via les transactions.
Mais ça peut toujours être utile de chiffrer une partie de ses clés publiques et de son carnet d’adresses ; pour ça il pourrait y avoir des « coffres » chiffrés contenant plusieurs comptes, et lors de leur déchiffrement on ajoute ces comptes dans la base en mémoire, indexés par clé publique.
Tu pourrais faire comme ğecko: associer un nombre entier unique à chaque portefeuille. Et tout gérer en base selon ce nombre entier.
Au démarrage de Tikka, tu demandes les credentials pour dériver toutes les clés publiques et tu créer une map en mémoire vive qui hait correspondre chaque nombre entier avec sa clé publique, rien de bien compliqué
C’est beaucoup utilisé, compréhensible, et non-ambiguë, donc c’est correct
Si tous tes portefeuilles sont dérivés du même trousseau maître il y a un seul truc à taper, c’est le principe du coffre.
Si tu tiens absolument à stocker les clés publiques en local, le code secret des DEWIF doit être plus long que dans Ğecko, au moins 2 caractères de plus.
Je crois que vit voudrais qu’un utilisateur puisse reprendre dans Tikka tous ses portefeuille césium. Donc il faut les retaper.
Mais il me semble que Tikka, pourrais les chiffré, tous, avec un mot de passe unique, déterminé par le logiciel. N’est-ce pas ce que propose Gecko avec l’import de portefeuille cesium ?
C’est pas encore implémenté, pour le moment Ğecko ne permet d’importer qu’un seul portefeuille Cesium.
Mais oui c’est prévu, tous les portefeuilles Cesium seront chiffrés avec le même code, ce n’est pas gênant car Ğecko n’est pas destiné à gérer beaucoup de portefeuilles cesium, toute l’UX est pensée pour utiliser des portefeuilles HD wallet généré par mnemonic.
De plus, l’utilisateur cible de Ğecko aura 99% du temps un seul et urique portefeuille cesium.
Tikka est maintenant entièrement dédié à Duniter V2. La migration depuis Duniter V1 est terminée.
J’ai implémenté, comme Gecko, les « wallets » (trousseau) contenant la seed chiffrée. J’ai choisi le protocole symétrique chacha20_poly1305.
Comme les clefs publiques sont stockées à côté, le mot de passe pour chaque compte est de 6 lettres générées par Tikka.
Si c’est trop peu en terme de sécurité, je peux augmenter à 8 ou 10.
Je viens aussi d’implémenter l’import des comptes Duniter V1 dans Tikka :
par fichier Cesium
par id secret/mot de passe
@tuxmain, comme j’ai vu que tu maniais aussi substrate_interface et Keypair, peux-tu me confirmer qu’un compte Duniter V1 avec les identifiants « test », « test » donne bien :
