La génération des Mnemonic se fait indépendamment de la façon de générer la seed.
On peut le mettre en place dans Duniter/G1 mais il faut qu’on choisisse une convention commune : quels salt et password on injecte dans scrypt a partir d’un Mnemonic et avec quels paramètres pour scrypt.
Je peut faire une proposition, le vrai dilemme étant le choix des param de scrypt, s’il sont trop élevés, ça ne fonctionnera pas sur les vieux téléphones, s’il sont trop faibles, on ne pourra pas utiliser les Mnemonic (le dico ne contenant que 2048 mots il faut des param fort pour la KDF).
Oui, ce serait super qu’on fixe un truc… Parce qu’une fois fourré dans une chaine de blocs, on peut pas trop revenir en arrière… Enfin, je sens que ça va pas être facile de tomber d’accord avant la fin du mois…
Le problème des vieux téléphones… Tu veux parler de ceux à clapet? Ou de smartphones qui n’ont pas assez de RAM/CPU ?
En fait, si on trouve un bon dico, on peut réduire les paramètres pour scrypt.
Un gros dico ferait l’affaire?
Des smartphones qui n’ont pas assez de RAM/CPU, ils pourraient planter au moment la génération de la seed a partir du Mnemonic saisi par l’utilisateur.
Le principe des Mnemonic est d’être simple a retenir pour l’utilisateur, ça a été bien étudié par des linguistes, on a pas les compétences pour refaire le dictionnaire.
En vrai, y a pas besoin d’allonger le dico, avec 9 mots on peut se contenter de param de scrypt soutenables, par contre il faudra imposer 9 mots minimum a tous les utilisateurs des Mnemonic.
ça ne me semble pas tout à fait le même sujet met en lien :
Selon moi, la meilleurs sécurité qu’on peut avoir pour les secrets, ce n’est pas un fichier de trousseau à tel ou tel format, c’est un trousseau dont la clef privée (stockée ou dérivé d’une seed) ne quitte jamais son hardware dédié (carte à puce, ledger, NFC…) ce qui impliquerait de demander à ce hardware d’effectuer le travail de signature à chaque fois qu’on en a besoin. De cette façon, keylogger, ou autre cesium-web serais bien incapable de s’accaparer les secrets de l’usager. Tout au plus ils pourrait proposer au hardware de signer des documents non souhaité par l’usager, et l’usager pourrais ne pas y être attentif.
Mais coté dev, ça demanderait plus que la gestion d’un format supplémentaire puisqu’il faudrait communiquer avec le hardware pour demander la signature des documents.
Autres reférences hardware wallet sur le forum (et lieux je pense plus approprié que ce fils pour continuer à parler hardware-wallet pour les intéressés) :
Je suis évidement à 200% d’accord, mais tous les utilisateurs ne pourront pas se procurer ce matériel, ça coûte des UNL.
De plus, on garde le risque de perte de ses credentials si on perd le matériel.
Personnellement, en tant qu’utilisateur la solution qui me conviendrais le plus c’est le brainstockage d’un mnemotic, que je saisirai a chaque fois sur un matériel hors-ligne qui signerai les documents via qr-code ou autre moyen. Ainsi, si je perd le matériel je ne perd pas mes credentials car ils sont dérivés de ma passphrase mnemotic, ce serait l’idéal
Voici ma proposition de Format DEWIF (Duniter Encrypted Wallet Import Format) :
Ça ressemble un peu au format WIF défini par Tortue en plus safe et plus simple :
Pas de version non chiffrée.
Pas de salt non-chiffré, ce dernier permet de vérifier si le fichier dérobé contient bien le trousseau recherché (en calculant le salt de la pubkey ciblée), et facilite donc les attaques ciblées. Un fichier trousseau bien sécurisé ne doit pas permettre de savoir quel trousseau se trouve à l’intérieur.
Pas de checksum complexe, la pubkey est déjà le meilleur checksum possible.
Pas de base58, cette base complexe et coûteuse n’a été inventée que pour faciliter la saisie manuelle, elle n’a donc pas de sens pour un stockage dans un fichier destiné a être lu uniquement par une machine.
Si ce format vous convient je vais coder une implémentation de référence en Rust avec plusieurs cas de test, ça vous sera utile pour tester vos développements
Dans le cas d’un serveur où on ne veut pas retaper les identifiants à chaque redémarrage, comment fait-on ? Soit on stocke la clé de déchiffrement du DEWIF, soit on n’utilise pas DEWIF ?
@matograine a déjà posé la même question plus haut et j’y ai déjà répondu :
De plus, Dunitrust proposera une options --random-keys qui permettra de le redémarrer sans rien saisir, il utilisera alors un trousseau aléatoire différent a chaque fois, c’est pratique pour les tests.
Donc, en dehors des cas de trousseaux aléatoires, on ne fait pas, c’est une mauvaise pratique de sécurité qui vulnérabilise la monnaie.
Aujourd’hui on s’en fou on est trop petit, plus on sera gros plus les attaques seront fortes et fréquentes, je pense que nous devons poser maintenant les bases d’une meilleure securité a moyen terme pour préserver notre monnaie a long terme. Et cela passe par interdire les mauvaises pratiques qui ne sont pas gênantes aujourd’hui mais qui pourraient être la cause de la mort de notre monnaie demain.
Si on généralise ça, je dois à chaque démarrage de mon ordi perso, et à chaque redémarrage de mon serveur, entrer une commande et un mdp pour chaque logiciel ayant besoin d’un trousseau de clefs. C’est tout de même peu pratique, et l’apport en sécurité me semble faible dans le cas d’un serveur (l’hébergeur pouvant tout autant fouiller le DD que la mémoire).
La mémoire est censée être nettoyée par un mécanisme clear and drop (j’en ai parlé aux rml14), en tout cas se sera le cas dans Dunitrust. Dans les logiciels ou c’est fait correctement, il est alors impossible de récupérer les credentials depuis la mémoire après l’arrêt du logiciel.
De plus, récupérer des infos dans la mémoire vive est infiniment plus compliqué, l’attaquant ne sais pas ou chercher, alors que dans un système de fichier c’est immédiat.
Comme l’a précisé tuxmain…
…et le redémarrage d’un serveur pour l’application d’une màj du kernel par exemple.
Dans ce cas l’administrateur remet sa clé, et c’est reparti.
Ça rend assez difficile la vie des nœuds temporaires (entendre, non serveur), mais ça ne me semble pas pertinent pour faire tourner une monnaie sur le long terme.
Est-ce intéressant d’y inscrire un champ currency: contenant le nom de code de la monnaie ?
Ça permettrait au logiciel de dire que ce fichier d’authentification est fait pour une autre monnaie dans le cas d’usage sur une autre monnaie. Voire d’empêcher son usage sur la monnaie concernée (modifier le fichier ou le logiciel peu quand même contourner le blocage).
Ce champ pourrait être optionnel afin de permettre l’authentification sur plusieurs monnaies.
Mais, je pense que c’est une bonne pratique de forcer l’usage d’un fichier d’authentification/clé publique par monnaie.
Je me disais… En fait quel que soit ce que l’on fasse, il y a toujours cette clef membre qui doit se retrouver sur un noeud calculant… C’est parce que la création du DU est conditionné à ce statut membre « gravé » par un document dans la blockchain.
Mais, si plutôt que de dépendre de cet événement, le DU était fabriqué en fonction des liens établis dans la WOT… En effet, en remontant jusqu’au bloc 0, il est possible de vérifier tous les comptes qui ont des amis qui créent déjà le DU, et si on en a plus que 5 (et que les règles de distance sont bonnes), et bien on crée le DU… Dans ce cas le protocole devient autonome… Il auto découvre les membres… Vous voyez ce que je veux dire?
On pourrait même rendre le paramètre règle de distance et nombre d’amis dynamique.
NB: je n’ai toujours pas vraiment compris quelle machine ajoutait les DU dans la chaîne? L’algo tire au sort, tout le monde en écrit un peu? A l’heure du DU que se passe-t-il, une synchro réseau particulière a lieu?
Non pas du tout, a terme ce ne sera plus le cas, la solution technique est connue depuis longtemps, on manque juste de ressources pour l’implémentée, et on a d’autres priorités aussi : [Idée] Clé déléguée au calcul de blocs
Rien de tout cela. Ça se passe de la même façon que l’expiration d’un abonnement ou d’une certification.
Lorsqu’un nouveau bloc reçu est validé par un noeud Duniter, il l’ajoute a sa chaîne puis déclenche la génération du contenu du bloc suivant, c’est a ce moment la qu’il puise dans sa mempool pour event user a inscrire dans le bloc et qu’il calcule tous les événements automatiques qui doivent êtres générés en fonction de l’heure du bloc qu’il est en train de généré (déterminée donc a la création du bloc).
OK @elois merci pour ces précisions.
Concernant cette idée de rendre le DU indépendant du statut « membre » mais plutôt de sa règle de distance dynamique aux sources du bloc 0, qu’en pensez-vous?
