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

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

1 J'aime

Dis donc, on a eu une tortue ninja avant-gardiste.

Pas actuellement non. Je pense étendre le format WIF/EWIF (avec un identifier 0x03) pour permettre le stockage de plusieurs trousseaux :slight_smile:

les octets sont encodé en quelle base du coup ? 16 ? 58 ? 64 ? autre ? Faudra que je le précise dans la spec du format.

Le mieux serait de faire une RFC avec les formats utilisés actuellement dans Cesium/DuniterPy/Silkaj.

Je peux le faire si vous voulez.

1 J'aime

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

1 J'aime

Oui :smiley:

Oui ça m’aiderait beaucoup, et je pense que ça en aidera d’autres :slight_smile:

1 J'aime

Il y a aussi l’outil de @1000i100 : DuniterkeyMaker

2 J'aimes

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

2 J'aimes

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

2 J'aimes

Merci @vit, je viens de lire ta RFC (ça a pop dans ma boite mail) : https://git.duniter.org/nodes/common/doc/blob/authentication_file_format/rfc/0012_authentication_file_format_v1.md

@kimamila @vit il y a plusieurs points qui me posent problème avec le format actuel .duniterkey

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

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

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

  4. 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).

Qu’en pensez-vous ?

Pourquoi en base 64 et pas en binaire ? Pour permettre de copier/coller à la main, de le mettre dans des URL et d’être sûr d’éviter les problèmes d’encodage avec JS ?

Pour le copier a la main et éviter les problèmes d’encodage oui. Aussi certains antivirus sous windows n’aiment pas bien les fichiers binaires de format inconnus.

Je ne suis pas d’accord, ce format est juste un container yaml. En quoi un fichier texte standardisé en yaml n’est pas interopérable ? Tu peux tout à fait charger le WIF ou le EWIF avec Rust car ils ne contiennent que la seed.

Pas du tout. Ce n’est pas parce que ta bibliothèque rust exige de ne pas prendre la clef privée que le monde entier doit faire pareil. Les clients codent ce qu’ils veulent, seed, clef privée, peu importe. Rust ne doit pas nous gouverner.

J’ai vraiment l’impression que la limitation de ta bibliothèque rust doit s’imposer à tous. C’est bien évidemment hors de question.

La RFC traite de l’existant et si tu désires ajouter un nouveau format dans le container yaml, pas de problème, propose le. Tu veux également un autre format de fichier ? Fait une autre RFC avec ce format binaire avec seed et utilise une autre extension.

La RFC 0012 traite du format duniterkey qui fait le job et qui n’a pas besoin d’être modifié dans l’immédiat. Amha.

Le champ Version n’a rien à voir avec l’octet de format en entête de la clef WIF/EWIF. C’est juste un champ de versioning en cas d’évolution du format .duniterkey.

1 J'aime

On ne peut pas dire a l’utilisateur, votre trousseau au format .dunikeys est utilisable partout. Car si ce format contient un PubSec alors moins un logiciel de l’éco-système ne pourra pas le lire.
Donc ce n’est pas interopérable.

Un format interopérable est un format pouvant être reconnu par tout l’éco-système dans tout les cas. C’est la raison d’être de cette discussion, si on reste sur le .dunikey tel qu’il est actuellement alors ça ne sert a rien.

Ben oui c’est justement ce que j’ai proposé, je n’ai pas demandé a ce que soit modifié ta RFC, elle décrit l’existant et c’est très bien. J’explique justement pourquoi l’existant ne peut pas répondre a l’objectif d’interopérabilité, cet objectif nécessite la création d’un nouveau format.

3 J'aimes

Très juste. En fait le format .duniterkey n’étant qu’un container avec à l’intérieur plusieurs formats risque de reproduire l’enfer des formats vidéo (j’ai un mkv mais y morche po… Ah oui y a du VC1 dedans, moi je lis que le h264…).

Donc il faut un format qui fonctionne avec le plus petit dénominateur commun (PPDC), déterminé en l’occurrence ici par la bibliothèque rust ring : contenir obligatoirement la seed.

C’est l’occasion de créer la RFC 0013 !

3 J'aimes

Pour le débat binaire/texte, l’avantage du fichier texte est de pouvoir être imprimé ! C’est important pour un hardware wallet.

Je reformule : @Matograine monte souvent vite au créneau, sans attendre l’analyse du code.

Je suis d’accord pour remonter les bugs, mais pas pour en tirer les conclusions. La différences entre une affirmation (qui demande une analyse), et un suspicion. Ca fait plusieurs fois qu’il réponds "comme s’il il savait exactement de quoi il en retourne, sans attendre de confirmation. Mais t’inquiète je lui ai déjà dit directement.

2 J'aimes