Stockage des portefeuilles pour Tikka

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.

Et si la clé primaire des comptes est un numéro, et qu’on peut choisir de stocker ou non la clé publique en clair pour chaque ligne ?

1 J'aime

Tu m’as donné une idée :wink:

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.

Merci pour ton aide !

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.

1 J'aime

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é :wink:

Ce n’est pas souhaitable (ah ah dit moi si cette formulation est adéquate si on est pas d’accord… :wink: )

Je ne vois pas l’utilisateur taper tous ses codes de tous ses portefeuilles pour que Tikka fonctionne normalement.

C’est beaucoup utilisé, compréhensible, et non-ambiguë, donc c’est correct :wink:

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.

1 J'aime

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.

1 J'aime