Il y a moyen de se servir de l’identifier pour versionner et étendre le format
La seed n’est manipulée que pour générer le trousseau de clés, donc sur un très petit scope de la vie du programme, seulement au début.
La clé privée est manipulée tout le long de la vie du programme, car elle vas servir a chaque fois que le programme a besoin de générer une signature, elle est donc beaucoup plus utilisée que la seed, le risque de la faire fuitée est donc bien plus grand.
D’ailleurs, dans Duniter la fuite de la seed ne s’est jamais produite, alors que la fuite de la clé privée si, en en prod (la G1 était déjà lancée).
Non. Elle ne doit être stockée nul part autre que dans le cerveau de l’utilisateur et éventuellement son gestionnaire de mots de passe.
Il indique le nombre de trousseaux présents, ce n’est qu’une proposition, à discuter
En tout les cas j’en ai besoin dans Dunitrust car je souhaite allier sécurité et simplicité d’usage, donc je ne génèrerai et n’accepterai que des formats chiffrés, or Dunitrust à deux trousseaux de clés (network et membre), donc je doit utiliser un format permettant de stocker plusieurs trousseaux.
Avoir 2 fichiers est incompatible avec la simplicité d’usage, je veut que l’utilisateur de Dunitrust n’ai qu’une seule passphrase a saisir au démarrage (donc un seul fichier a déchiffrer).
Vois tu une façon plus “légère” de stocker plusieurs trousseaux dans un même fichier ?
Duniter stocke la clef privée en clair sur le disque dur par défaut. Dunitrust devra bien stocker la speed, sauf s’ il demande les credentials ou la clef de déchiffrement à chaque redémarrage. Dunitrust ne pourrait donc pas être redémarré automatiquement et participer de suite au calcul ?
Oui Dunitrust ne pourra pas être redémarrer automatiquement, et ce n’est pas un besoin.
Le fait que Duniter est besoin d’être redémarré régulièrement est lié à 2 problématiques spécifiques à Duniter :
fuites mémoires (ce qui cause le crash sur 2Go de RAM au bout d’un certain temps)
mauvais élagage des powcluster (problème qui sera normalement résolu en passant à node10)
Je ne vois pas le rapport. Duniter n’a pas besoin de redémarrer pour participer au calcul, ce sera pareil pour Dunitrust.
DATA >–(PRIV)–> DATA*** >–(PUB)–> DATA (signature)
avantage: permet Chiffrage ET Signature de message
inconvénient: mathématiques complexes
Analogie: Courrier en “recommandé avec accusé de réception” en mieux.
Avec le texte écrit à l’intérieur de l’enveloppe et qui se détruit si ce n’est pas le destinataire qui ouvre…
hashage qui permet de créer une “emprunte digitale”: DATA ----> DATA
Toute la sécurité informatique découle de ces propriétés mathématiques!
Pour se protéger d’eux même les ordinateurs en constante évolution augmentent la longueur de KEY ou complexifie l’espace mathématique de relation entre PUB/PRIV. Enfin, chaque espace mathématique définit “l’espace” d’empreinte du HASH (sa quantité de possibilités avant de boucler sur lui-même).
Le problème typique de l’Oeuf et de la Poule", résolu par l’emboîtement des poules ou des oeufs
N’oublions pas que nous faisons cela pour nous, les Humains!!
Et qu’il faut que nous soyons propriétaire et conscient de l’être de NOTRE CLEF
La clef qui chiffre nos comptes concerne notre souveraineté monétaire! Il me semble qu’elle est la plus importante… Et que nous devons pensez à sa sécurité, mais aussi à sa transmission…
“LA CLEF” doit être compréhensible par un Humain (diceware, mnemonic) et pouvoir se déléguer à d’autres sans danger https://darkcrystal.pw/
Les format WIF/EWIT définies par @Tortue sont binaires. DuniterPy et Cesium supportent t’il un fichier binarie contenant directement les octets ? Ou demandent t’il un fichier texte qui contient les octets encodées en base16 ou 64 ? @kimamila@vit ?
@Frederic_Renault pour l’instant l’objectif de définir un format standard pour les trousseaux de clés Ğ1, donc a priori ça ne concerne pas les clés symétriques. Mais on peut essayer de les inclurent si c’est on besoin,a tu un cas d’usage à nous donner ?
DuniterPy supporte uniquement le format fichier texte, mais derrière décode les octets. C’est trivial de lui faire avaler un fichier binaire si besoin. Mais peu importe. Ton souhait est de ne stocker que la seed, ce qui est le cas en WIF.
Le besoin de Rust est donc déjà résolu avec le format WIF/EWIF.
Non, le format simple PubSec est bien implémenté. La il y avait un bug quelconque (le sablier d’attente, encore lui !) suite à l’ajout des portefeuilles secondaires.
C’est juste que ce format est aussi lisible par Cesium en format complet (avec Type: et version). @Matograine monte souvent vite au créneau, sans analyse du code.
Oui, peu importe pour Cesium. L’idée importante pour moi est d’avoir une entête cohérente :
Type: <PubSec|WIF|EWIF|PubSeed|etc.>
Version: 1
...champs en fonction du format
et un point d’extension assiocié (.dunikey.yml ou autre).
En fait, c’est un chiffrage symétrique avec comparaison de la validité de la CLEF fournie par HASH qui nous permet de garantir que la machine ne garde pas la clef.
Plus nous laissons la machine se protéger d’elle même en la faisant évoluer (nous-même), plus le nombre de mots de notre CLEF devient important!! Il n’y a qu’une solution: Arrêter de fabriquer des machines plus puissantes… Pour mon usage quotidien celles dont je dispose sont largement suffisantes.
Cette course que nous menons est faites pour contenter le besoin de croissance de l’UNL.
Une propriété temporelle de l’UNL est sa destruction régulière (bulles spéculatives), seul moyen de maintenir la rareté face à l’inquantifiable abondance… Elle éclate, comme toujours, pour ramasser les biens des perdants. Faisant plus ou moins de dégâts collatéraux. Nous sommes à un de ces points culminants et cycliques. La “3ème” guerre mondiale est en cours (elle est perpétuelle en fait)… Elle est numérique chez nous, à l’ancienne près des zones de ressources…
Voila pourquoi, je pense que nous devons “lever le nez” de la chaîne du vélo. Les gars…
La Monnaie Libre et les logiciels libres qui l’accompagnent sont comme la trouvaille merveilleuse des Gens !! A la différence d’avant, ce n’est pas une arme inventée par des résistants, c’est un “Monde Libre” concrétisé par ceux qui choisissent la Liberté…
Je fais appel à la déclaration d’indépendance du CyberEspace et vous invite à prendre conscience que le plan des véhicules aptes à nous transporter vers ce nouveau monde est là, dans nos mains, autour de nous…
J’ai commencé à connecter Duniter avec Ipfs, maintenant Scuttlebutt, demain Minetest.net
Pendant ce temps Nextcloud, Mastodon et tout le Fediverse progresse et se réplique… Au travers de l’écosystème Libre nous avons la Liberté!
J’arrête ma digression là. Pour revenir au sujet. Où je pense qu’aucune solution idéale n’existe finalement. Votre réflexion est importante et cruciale même. Ne passez pas trop de temps la dessus… Et surtout, pensez qu’un enfant, un handicapé, une mamie doit pouvoir comprendre et utiliser la solution que vous retiendrez.
Le mnemonic (KEY appartient à mon espace de perception) et le darkcrystal (gère ma délégation de confiance, mon testament) me conviennent parfaitement, ils sont en plus utilisés par la meilleure implémentation de réseau social que j’ai pu expérimenter. D’ici peu le tag g1tx (merde pas eu le temps d’écrire une RFC, ah si… je l’ai écrit dans scuttlebutt ) permettra d’y échanger de la G1… De nouveaux développeurs/utilisateurs vont arriver. Nous ne savons pas comment sera le futur on peut juste essayer de le construire en le vivant à l’instant présent…
Je comprend que dans Dunitrust c’est compliqué d’utiliser directement la clef privée, en revanche, je ne comprend pas en quoi stocker la seed dans le trousseau (ou toute autre information dont on peut déduire la clef privée) améliore la sécurité dès lors que le format de stockage est chiffré.
@elois motivé pour m’expliquer ça ? (ou quiconque à bien compris le pourquoi)
Si le format de stockage est chiffré, alors stocker la seed ou la clé privée est égal en terme de sécurité. Mais pour des raisons technique Dunitrust ne pourra pas utiliser un fichier contenant une clé privée, c’est pourquoi je demande a ce que l’on stocke la seed, afin de permettre l’interopérabilité
@kimamila cette remarque me semble déplacée. Un testeur n’a pas a analyser du code, ce n’est pas son rôle.
Si un testeur constate qu’une fonctionnalité ne fonctionne pas, il déclare un bug, c’est normal. Son seul tord serait de conclure que Cesium utilise volontairement un format différent, il doit s’abstenir de conclure cela, il ne peut que conclure que la fonctionnalité…ne fonctionne pas dans au moins 1 cas (le cas testé), et créer un rapport de bogue détaillé
@kimamila@vit il y a plusieurs points qui me posent problème avec le format actuel .duniterkey
Ce que je souhaite, c’est que l’on ait un format de fichier universel, c’est à dire interopérable partout. Or, le format .duniterkey actuel ne l’est pas.
Pour être plus précis, le besoin est d’avoir une extension de fichier .qqh ou l’utilisateur ait la garantie que cette extension peut être lue par tous les logiciels de l’écosystème Ğ1.
Ça implique que ce format ne puisse pas contenir la clé privée, donc pas contenir le type PubSec.
Le nom WIF (Wallet Import Format) n’est pas spécifique a l’écosystème Ğ1, d’autres crypto ont leur propre format WIF qui est différent. Garder le non WIF est confusant pour les utilisateurs ayant utilisés d’autres cryptos.
Je propose de le renommer DUWIF (Pour DUniter Wallet Import Format), mais si vous avez d’autres idées de nom je suis preneur
Les formats WIF et EWIF utilisés dans le format .duniterkey décris par vit ne respectent pas les spec de Tortue, notamment :
a. La version n’a pas à être indiqué à part, elle fait partie intégrante du format WIF (identifier)
b. La sérialisation en base58 n’est pas pertinente. La base58 a été conçue pour des données qu’on est susceptible de saisir manuellement (une clé publique pour payer), les données d’un WIF n’ont pas vocations à être saisies manuellement, on utilise donc une base coûteuse et exotique pour rien. Il serait préférable d’utiliser base64.
Dans le cas d’un EWIF, seule la seed est chiffrée, or pour moi la contrainte « être chiffré » signifie que tout le contenu du fichier de trousseaux de clés soit chiffré (exception faite d’un éventuel préfixe en clair indiquant si le contenu est chiffré ou non).
Pour toutes ces raisons, je pense proposer un nouveau format dont le nom est à trouver, probablement .duwif et qui contiendra directement un WIF versionné conformément aux spec de Tortue.
Les octets de ce WIF versionné seraient sérialisés en base64.
Je compte également étendre le format WIF de Tortue en ajoutant un identifier 0x03 qui comportera en plus :
un identifiant de l’algo
la clé publique du trousseau
la possibilité d’avoir plusieurs trousseaux
Concernant Cesium et DuniterPy, il vous suffirait de traiter le fichier différemment selon son extension (.duwif ou .duniterkey).
