Définir un format standard pour les trousseaux de clés Ğ1

@Moul @kimamila @cgeek @vit et tout les dev qui manipulent des trousseaux de clés ed25519 :

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 :laughing:

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 :

  1. Être agnostique de algorithme de cryptographie utilisé.
  2. Ne pas stocker directement la clé privée.
  3. Pouvoir garantir son intégrité (checksum ou présence de la pubkey)
  4. Être versionnée
  5. Être chiffré
  6. Voyez-vous d’autres contraintes ?

Les formats proposés qui respectent ces contraintes :

  • EWIF étendu (identifier 0x03, spec a venir)
  • 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 persiste directement la clé privée
  • Il n’est pas chiffré

Explications du pourquoi de ces contraintes :

  1. 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.

  2. Pour être standard, le format doit être implémentable par tous les logiciels de l’éco-système Ğ1 qui manipulent des trousseaux de clés Ğ1. Or, Dunitrust ne peut pas et ne pourra probablement jamais lire directement une clé privée Ed25519[1].

  3. 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.


[1] Pourquoi Dunitrust ne peut pas lire les clés privées ed25519

L’écosystème Rust incarne le principe « safe by design », et la plupart des développeurs de librairies Rust appliquent cette philosophie, cela signifie que beaucoup de librairies Rust sont conçues de manière a ce qu’il soit impossible (ou très difficile) de mal les utilisées (undefined behavior, leaks of secrets, etc), et la librairie ed25519 utilisée par Dunitrust n’échappe pas à la règle.

Dunitrust utilise ring, cette librairie est conçue de façon a ce qu’il est impossible d’accéder a la clé privée, a aucun moment, pas même lors de la génération du trousseau (on donne une seed et on reçoit une struct « keypair »).
L’avantage d’utiliser une librairie ainsi faite, c’est que l’on est certain qu’aucun contributeur de Dunitrust ne pourra exposer la clé privée par inadvertance (moi le premier :sweat_smile:), cela apporte donc plus de sécurité.

EDIT: une telle faille s’est d’ailleurs déjà produite par le passé dans Duniter : https://git.duniter.org/nodes/typescript/duniter/issues/1212

4 J'aimes

Ils seraient pas un peu dans la programmation fonctionnelle tes copains de Rust ? :grin:

Bon ben je vais creuser la question côté Python (…donc il nous faut la clef privée sans la clef privée…). :thinking:

1 J'aime

Ils gèrent tous le format PubSec. Plus ou moins compatibles. Ça apporte quoi de plus le format que tu proposes ?

Le format PubSec n’est pas clairement défini, et pas très interopérable pour le moment, la preuve ici : Format des fichiers de trousseaux de clés

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 :slight_smile:

Tu propose d’aller vers un autre format qui n’est pas encore définit ?

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 :slight_smile:

Ah bon ?

Oui « sec » est le diminutif de « secret key », c’est la clé privée.

Oui, mais c’est pas directement la clée privé. Elle est transformée.

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 :

(salt, password) -> seed (32bytes) -> secret key (64 bytes) -> public key (32 bytes)

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: )

A vous lire…

En quoi exposer la seed par inadvertance est-il plus sécurisé ? Édit - ok, la seed est chiffrée et c’est le programme qui gère le déchiffrement.

Mais du coup, la clef de déchiffrement doit bien être stockée qq part dans certains cas, non ? Les séparer évite des fuites involontaires ?

Que représente le champs count ?

1 J'aime

Le nombre de trousseau dans le fichier. Mais je suis pas fan du format que ce count induit. Ca fait usine à gaz.

Je comprend bien mais j’ai dit cela car « le » format PubSec semble être implémenté différemment dans Cesium : Format des fichiers de trousseaux de clés .

De toute façon qu’importe, le format PubSec ne conviens pas pour plusieurs raisons exposées sur le 1er post (que je viens de mettre à jours).

Le format WIF défini par Tortue est de loin le plus intéressant : https://tmp.tednet.fr/paperwallet/AddressFormat.html

Il y a moyen de se servir de l’identifier pour versionner et étendre le format :slight_smile:

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 :slight_smile:

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 ? :slight_smile:

2 J'aimes

Pour info, le WIF et sa version chiffrée le EWIF sont déjà supportés par DuniterPy et Cesium.

3 J'aimes

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.

3 J'aimes

Je suis ravi que cette discussion sur la recherche de cohérence « inter-cryptographique » se prolonge.

Résumons les outils dont nous disposons :

  • symétrique: DATA <–(KEY)–> DATA*

    • avantage: symétrique, rapide …
    • inconvénient: partage « physique » de KEY

    Analogie: UN Coffre avec UNE Clef.

  • asymétrique:

    • DATA >–(PUB)–> DATA** >–(PRIV)–> DATA (chiffrage)
    • 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 :wink:

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/

1 J'aime

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 ?