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

C’est fait, pour ne pas alourdir ce sujet j’ai récapitulé tous les résultats des tests de performance dans un nouveau sujet : Tests de performances : sodium et ring

Non, comme dit plus haut que tu fasses des choix ne me pose pas de problème (du moins, je trouve ce choix effectivement pénible, mais rien de bloquant car les fonds de Remuniter peuvent être transférés à une autre clé compatible Dunitrust).

Quelle surpoids ed25519-dalek impliquerait, à peu près ? Sur quelle taille de binaire actuel ?

C’est justement l’objet de mon reproche : je prétends que tu « te caches » derrière une philosophie. Pour quelle raison ? D’après ce que j’ai lu c’est principalement parce qu’elle te rassure¹.

N’est-ce pas ?


¹ : je viens juste de m’en faire la réflexion.

1 J'aime

Du coup j’y est réfléchi et je pense que le mieux soit que le futur module remuniter utilise sa propre lib de crypto pour signer ses transactions. Ainsi pas d’ajout de complexité dans le cœur. Et si une erreur humaine se glisse dans le code du futur module de remuniter alors elle n’exposera pas tous les noeuds Dunitrust mais seulement ceux qui auront ce module.

Je ne m’en cache pas, j’adhère pleinement a cette philosophie « safe by design » et je pense même que c’est un devoir moral vis a vis des utilisateurs que de faire « de notre mieux » pour minimiser les risques. L’erreur est humaine, même les plus grand expert font des erreurs (cf faille Heartbleed).

Je prétend au contraire que c’est pour le moins irresponsable de ne pas adopter un paradigme « safe by design » pour quelque chose d’aussi critique que la monnaie.

1 J'aime

Si tu sécurises, tu le fais forcément au détriment de libertés (« sécuriser » signifiant restreindre un champ des possibles). Si l’on pousse le raisonnement à l’extrême, la position la plus responsable de toutes consisterait à ne pas réaliser de monnaie libre, ou bien tellement sécurisée qu’elle en deviendrait inutilisable. Ce qui serait absurde.

Par ce raisonnement on voit bien que la sécurité n’est qu’un aspect et certainement pas le plus important s’agissant de créer une monnaie libre.

Tu fais ici un choix discutable. A mes yeux et dans ce cas précis, c’est encore acceptable.

Mais ce que je souhaite souligner, rappeler, c’est que la sécurité n’est pas l’élément déterminant et qu’il convient de le laisser à sa juste place, autrement dit ne pas le mettre sur un piédestal.

2 J'aimes

Oui tout à fait. C’est pour cela que la bonne approche, c’est de restreindre par défaut, et selon les use case, de ne lever certaines limitations qui s’il y a un use-case qui le nécessite. Ainsi la surface d’attaque n’est pas plus grande que nécessaire.

Sophisme de l’homme de paille. On sait tous que le risque zéro n’existe pas, ce n’est pas pour autant qu’il faudrait tous autoriser. Une partie importante du travail de sécurisation consiste justement à définir ce qui est nécessaire et suffisant à exposer pour répondre aux besoins, tous le reste devant être interdit.

Je n’ai jamais dit que c’était le seul aspect, ni le plus important, tu fais encore un sophisme de l’homme de paille. Le sujet de ce fil concerne le format des trousseaux de clés, tu me poses des questions sur une limitation du format dont la motivation 1ère est la sécurité (même s’il y a d’autres motivations, que j’ai évoqué), forcément on parle de sécurité ici, ça ne veut pas dire que c’est le seul aspect ou le plus important. Sur ce coup là c’est toi qui te « caches » derrière un homme de paille au lieu de me dire honnêtement que ta crainte est la perte de libertés d’usage.

Je n’ai jamais dit le contraire, nous ne sommes tout simplement visiblement pas d’accord sur ce qu’est « sa juste place ».

L’un de mes objectifs à travers le développement de Dunitrust est justement d’améliorer sensiblement la sécurité de la Ğ1 (entre autre). Et cela passera forcément par minimiser la surface d’attaque, donc interdire les fonctionnalités risquées qui ne sont pas nécessaires.

Évidemment, le but n’est pas d’empêcher l’utilisation, tous les besoins nécessaires doivent être autorisés, mais parfois cela impliquera des changements cotés utilisateur.

Chaque limitation sera évidemment discutée, comme on l’a fait ici pour le format des trousseaux :slight_smile:

De mon côté, ça me poserait un problème de conscience d’ouvrir des potentielles brèches pour donner un confort non indispensable a l’utilisateur. Donc tous ce que je livrerai de manière « officielle » sera le plus possible « safe by design », quitte à limiter certaines fonctionnalités ou/et les rendre moins confortables à utiliser.
Le code étant libre, chacun est libre de forker pour lever une limitation qui ne lui conviendrait pas, mais dans ce dernier cas ce n’est pas de mon ressort.

1 J'aime

Quelle ironie, c’est précisément ce que je reproche à ton argumentation initiale. Selon moi ton homme de paille dans ce message pour le non-support des trousseaux PubSec est la sécurité, la véritable motivation : pas envie de rajouter la librairie ed25519-dalek.

Ceci étant dit, j’estime avoir suffisamment donné mon point de vue. Je vous laisse donc continuer la discussion.

2 J'aimes

Je penses d’ailleurs qu’on pourrait retirer le terme « standard » du titre du post.
Qu’elles propose un nouveau format ne me pose pas de problème, mais le définir d’emblée comme standard un peu plus.
C’est juste un nouveau format, quoi.

Bon elois, à toi de jouer avec ta petite équipe : bon courage à tous !

1 J'aime

@cgeek tu fait là un procès d’intention en décidant a ma place quelles sont mes véritables motivations, ça deviens très grave. Te rend tu compte une seconde de l’absurdité et du manque de respect d’une telle affirmation ? Ne pas être d’accord c’est une chose, mais décréter les intentions de l’autre a sa place NON ! Si tu te permet de faire cela alors plus aucune discussion n’est possible.

Franchement je ne comprend pas, il me semble essentiel de définir un format standard pour les trousseaux de clés, pas toi ?

S’il n’est pas « standard » a quoi bon en discuter ici ? Vous avez discutés quelque part du format .dunikeys décris par vit ? C’est ça que tu considère être le « standard » ?
Ou alors tu considère qu’il ne doit pas y avoir de standard du tout ?
Tu t’en fiche de l’interopérabilité et de son importance pour l’expérience utilisateur ?
Tu préfère que ça reste le bordel ou chacun a son propre format afin que notre écosystème reste un truc de geek incompréhensible ?

J’ai la désagréable impression de me démener seul pour définir des standard plus fiables et permettant une meilleure expérience utilisateur. Je ne comprend pas pourquoi je n’ai pas plus de soutien, vous pensez que ce n’est pas important d’avoir des standard et de l’interopérabilité dans l’écosystème Duniter/Ğ1 ? Vous pensez que la sécurité on s’en fou et qu’on avisera le jours où on subira une attaque avec une crise de confiance envers la Ğ1 (donc quand il sera trop tard quoi) ?

J’avoue ne pas comprendre, j’espère qu’il y a une majorité silencieuse qui comprend ces 2 objectifs on ne peut plus basiques et élémentaires (interopérabilité et sécurité). Mais savoir que 2 des principaux développeurs de l’éco-système Duniter/Ğ1 s’en fichent c’est sincèrement très inquiétant :confused:

1 J'aime

Le problème est que le format que tu proposes impose la sécurité.
Plus de sécurité signifie moins d’usages possibles.
Il en résulte, en conséquence, que ce format ne peut pas devenir un standard.

J’ai l’impression qu’il est en train de se passer ce qui suit :

Est standard ce qui a été validé par la théorie et surtout par l’expérience, et pas seulement la théorie. Les usages sont importants.

Je t’ai dit que pour ma part j’implementerai ce nouveau format dans Cesium. Voudrais tu que je supprime en plus les autres formats disponibles ?

Ne prends pas la mouche, s’il te plait.

Ce nouveau format subira des MR, des évolutions, etc. Et ensuite chacun verra s’il doit en faire la promotion, comme plus sécurisé ou non. Les plus utilisés et mis en avant par les developpeurs deviendront des standards de fait.

2 J'aimes

Par exemple, @tuxmain n’a pas cherché à dire que son protocole d’anonymisation était le standard. Il l’a d’abord fait, décrit, puis présenté, etc. On verra s’il devient le standard, s’il résiste aux critiques de ceux qui s’y intéresseront. Cela peut être long. C’est tout un processus, qui ne dépend pas uniquement de la volonté de ceux qui réalise le prototype et les specs.

1 J'aime

Je trouve ça fort dommage qu’un standard doivent autoriser le stockage du trousseau de clés en clair :confused:

Car si on l’autorise, l’utilisateur ayant tendance a vouloir aller au plus simple, il ne chiffrera pas son trousseau de clés.

Quel sont selon toi les usages qui nécessiteraient de stocker le trousseau de clés en clair ?

Si on part sur un format qui le permet, comment faire en sorte que l’utilisateur soit poussé a chiffre son trousseau de clés par défaut ?

Par format « standard » j’entends format recommandé. Peut-être que le mots clés « standard » est mal choisi de ma part. Je souhaite surtout que le format recommandé officiellement soit un format chiffré.

Il y a un principe fondamental en sécurité: la configuration par défaut doit apporter une sécurité satisfaisante, car 95% des utilisateurs utilisent la configuration par défaut.

Non, bien sûr que non :slight_smile:

Ma crainte est que « les plus utilisés et mis en avant par les développeurs » ne correspondent pas forcément aux formats satisfaisant en terme de sécurité mais au format préférés par les développeurs pour d’autres raisons.

1 J'aime

Oui tout a fait :slight_smile:

Bon la 1ère version « finalisée » des spec est là : https://git.duniter.org/nodes/common/doc/blob/dewif/rfc/0013_Duniter_Encrypted_Wallet_Import_Format.md

N’hésitez pas, si vous avez des remarques constructives :slight_smile:

J’ai déjà codé une implémentation de référence en Rust, que je vais partager dans un autre fils.

L’implémentation de référence du format DEWIF se trouve dans la bibliothèque dup-crypto-rs.

Documentation : https://docs.rs/dup-crypto/0.12.0/dup_crypto/dewif/index.html#handle-dewif-format

Code : https://git.duniter.org/libs/dup-crypto-rs/-/tree/dev/src/dewif

Des tests sur la Ğ1-test. J’ai pas envie de déchiffrer mes fichiers d’authentification à chaque test. Je m’en fous un peu que matograine me vole mes Ğ1-test si je commite par erreur mon authfile. Les fichiers d’authentifications non chiffrés remplissent bien ce rôle.
Ça peut également être le cas pour les portefeuilles Ğ1. Si j’ai pas envie de chiffrer mon authfile pour pouvoir dépenser sans me prendre la tête mes Ğ1 lors d’une rencontre physique. Le risque que je prends et de les perdre. C’est un risque à prendre, mais ça serait dommage d’être imposé d’utiliser le chiffrement pour une petite somme.

Ce qui pourrait être fait, c’est que le client, à la création de l’authfile, propose (ou impose (refuse de le générer)) un format chiffré pour une clé membre ou un portefeuille avec beaucoup d’unités. Au cas contraire, un authfile non chiffré est bienvenue.

Ben, le format de fichier que tu proposes est bien pour cela au même titre que EWIF. Mais imposer son usage c’est trop. On dirait que tu n’as pas vu l’usage client ou du moins que tu t’occupes du côté client sans avoir trop mis les mains dans le cambouis. Même d’un point de vue nœud, je m’en fous d’avoir un format chiffré pour une clé générée aléatoirement. Aurai-je besoin de déchiffrer ma clé générée aléatoirement au redémarrage ?

C’est la contrainte que tu t’es imposée avec ce format de fichier. Est-ce qu’il est possible de l’imposer ? Est-ce judicieux de l’imposer ? Est-ce qu’imposer aux autres sa définition de bien est toujours bien pour l’autre ?

Sinon, il y a déjà PubSec, WIF. Tu peux proposer deux formats de fichier d’authentification : un chiffré et un non chiffré. Comme pour WIF et EWIF. Avec les apports qu’apportent tes fichiers sur ces derniers.

1 J'aime

Pour les tests il me semble avoir abordé plus haut la génération de trousseaux aléatoires a chaque démarrage. En fait je pense qu’il y a beaucoup de cas d’usages ou l’on a pas besoin de stocker le trousseau de clés dans un fichier.

Mouais, perso ça me choque pas de rentrer mes crédentials pour payer, même un epetite somme.
En fait l’idéal serait d’avoir un client permettant d"éméttre plusieurs transactions et de les signer toutes d’un coup en différé.
Par exemple lors d’un gmarché, je fais mes paiements, les documents transactions restent en local sur ma machine. Et quand j’ai fini mes emplettes, je rentre mes credentials une seule fois et mon client va alors signer et envoyer toutes les transactions qu’il a prégénéré pendant mes emplettes, ça ce serait pratique et secure.

Ce n’est pas mon avis, mais c’est notamment parce que je compte me baser sur la clé publique du nœud pour authentifier le réseau pkstl. Avec cette approche, l’utilisateur indique la clé publique du nœud de confiance auquel il se synchronise, si cette clé est corrompue, alors il peut tomber sur un nœud menteur, on ne peut alors plus avoir confiance en le réseau.
Et je parle bien du trousseau réseau généré aléatoirement, pas de trousseau membre ici.

Si le trousseau est généré aléatoirement :

  • Soit c’est pour des tests => alors pas besoin de le stocker dans un fichier, il peut changer a chaque test.
  • Soit c’est pour le trousseau réseau du nœud => alors il sert de certificat, c’est la seule façon de s’assurer que l’on communique bien avec le nœud avec lequel on croie communiquer, ce trousseau doit être chiffré.

oui

Dans le cas du logiciel Dunitrust je pense que oui :slight_smile:
Pour les autres logiciels j’entends que ce n’est pas souhaité.

Du coup j’ai changé d’approche et renommé le titre de ce fils.
Je pense qu’on se dirige vers 2 formats « standards » différents :

  • Un standard permissif, dont l’utilisation n’est pas recommandée, mais l’utilisateur reste libre de prendre des risques sur les applications qui acceptent ce standard permissif (il convient d’alerter explicitement l’utilisateur du risque qu’il encourt, ce qui n’est pas le cas aujourd’hui).
  • Un standard sécurité (format DEWIF), qui sera recommandé dans les recommandations de sécurité officielles, et qui sera le seul format accepté par Dunitrust.

Concernant le standard permissif, je vous laisse faire le boulot de standardisation (qui me semble souhaitable pour éviter les problèmes des formats « conteneurs »). Le temps étant une ressource trop limitée, je me concentre sur ce qui est prioritaire pour moi.

1 J'aime

Désolé par avance pour la mauvaise blague.
Je sais que ça a été compris et je ne doute pas des choix techniques faits par l’outil utilisé et par son usage.

Juste envie de rigoler un peu sur la résultante de ce post :

2 J'aimes

Heureusement l’auto-dérision ça me connaît :rofl: Il est bon de savoir rire de soit même dans la vie :wink:

2 J'aimes