Alors voila, c’est le bordel, en réfléchissant sous quel format je devrais sérialiser les trousseaux de clés de Dunitrust je me suis rendu compte que tous nos logiciels (Duniter, Cesium, Silkaj, Ğanonce, etc) avaient chacun leur format
Ce qui est fait est fait, mais cela est très dommageable pour l’interopérabilité, il me semble essentiel que l’on réfléchisse a un format de trousseau de clés standard.
L’objectif à long terme est que ce format standard que l’on aura choisi soit intégré dans tous les logiciels de l’éco-système Ğ1 qui manipulent des trousseaux de clés Ğ1.
Ce format devra respecter les contraintes suivantes :
Être agnostique de algorithme de cryptographie utilisé.
Ne pas stocker directement la clé privée.
Pouvoir garantir son intégrité (checksum ou présence de la pubkey)
Être versionnée
Être chiffré
Voyez-vous d’autres contraintes ?
Les formats proposés qui respectent ces contraintes :
DEWIF
autre ?
(ce post sera mis a jours au fur et a mesure des propositions).
Pourquoi PubSec ne conviens pas (le format le plus répandu actuellement)
Le format PubSec simple pose 5 problèmes :
Il n’est pas versionné
Il n’indique pas l’algo
Il ne permet pas de persister plusieurs trousseaux dans un même fichier
Il n’est pas chiffré
Explications du pourquoi de ces contraintes :
A terme on supportera d’autres algo que Ed25519, peut-être même qu’on abandonnera Ed25519, quitte a prendre le temps de définir un standard et de l’implémenter partout (ce qui vas être très long), autant définir un format agnostique pour qu’on n’aie plus besoin de le changer à l’avenir.
Si on lis un fichier de trousseau corrompu on doit s’en rendre compte, donc par exemple stocker uniquement la seed seule comme le fait silkaj par défaut me semble être une mauvaise pratique.
De plus, Dunitrust ne pourra jamais gérer le format PubSec car il contient directement la clé privée, ce format ne pourra donc jamais être généralisé a tout l’écosystème de la Ğ1.
Je ne propose aucun format particulier, j’expose le besoin
Je demande a ce que l’on définisse un format standardisé qui respecté les contraintes énoncées. Vous pouvez d’ailleurs en ajouter, s’il y a des contraintes spécifiques liés a vos logiciels/technos
Dans le cas de Duniter c’est directement la clé privée encodée au format basee58, on peut considérer que c’est une “transformation”, mais ça ne résout pas mon problème, je ne peut pas m’en servir, il me faut la seed (ou les credentials).
Rappels sur la génération des trousseaux de clés Ğ1 :
Chaque flèche représente une opération a sens unique, il est impossible de revenir en arrière. Nottament, il est impossible de retrouver la seed a partir de la clé privée car l’opération de génération de la clé privée a partir de la seed fait intervenir des fonctions a sens unique (sha512 notamment).
Je ne penses pas non. Je n’ai inventé aucun format, et repris tous ceux que j’avais trouvé à l’époque : ceux de gannonce et Duniter (PubSeb), ceux des wallets paper. La doc doit etre quelque part, sur le forum. @cgeek nous avais proposé d’uniformiser, en ajoutant un Type: <PubSec|EWIF|WIF> etc.
Le format de Silkaj n’est arrivé qu’ensuite, je n’ai pas regardé de ce côté là.
Je peux ajouter sans problème le PubSeed dans Cesium. De préférence avec une ligne (qui peut-etre optionnel) Type: PubSeed.
Nous avions aussi parler d’une extension de fichier commune (pour un fichier ayant le Type: )
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 ?
