Pour redonner les explications autrement : une librairie qui protège l’accès a la clé privée limite fortement les erreurs de fuite de cette clé dans le code du programme.
Les seed peuvent toujours être fuitée suite a une erreur, mais comme elles ne sont théoriquement utilisée qu’à un seul endroit du code (pour générer la clé privée), le risque d’erreur et de fuite est beaucoup plus limité.
Quand on dit « safe by design », c’est donc surtout en terme de limitation des erreurs humaines au sein du code du programme.
Tu as justifié l’impossibilité de Dunitrust à lire des clés privées en nous parlant de Rust et de son écosystème. Il aurait été suffisant de dire :
et :
Point. C’est tout ! Pas besoin de blabla sur “l’écosystème Rust incarne […]” qui n’a rien de pertinent et ne fait que déclencher chez le lecteur le radar “il essaye de noyer le poisson”.
Enfin, un point que tu ne précises pas : est-ce qu’il existe une impossibilité d’utiliser 2 libs en parallèle ? Ring la plupart du temps, ed25519-dalek pour les utilisateurs qui souhaiteraient utiliser leur trousseau existant.
J’ai d’ailleurs un exemple : le trousseau de Remuniter a été généré à partir de données aléatoires que je n’ai pas souhaité conserver. En l’état de Dunitrust, cela signifie-t-il que ce trousseau ne pourra jamais être réutilisé ?
Désolé ça me semblais être au contraire le plus pertinent car c’est la raison même du pourquoi de cette limitation. Ce n’est pas du blabla, c’est une véritable “philosophie” de développement qui permet de limiter les erreurs humaines, et qui me semble donc on en peut pas pertinente dans le cas très critique d’une crypto-monnaie.
Il n’y a pas d’impossibilité à utiliser 2 lib en parallèle, mais ça complexifierai le dev et ça alourdirai le binaire final.
Haaaaaaaaa, merci, je connais enfin la vrai raison qui fait que mon choix te pose problème
Et bien en effet Dunitrust est incapable d’utiliser ce trousseau pour le moment, cela nécessiterai en effet d’utiliser 2 lib de crypto et parallèles, c’est possible mais chiant, ouvre un ticket sur le dépôt Dunitrust pour tracer ce besoin
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¹.
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.
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.
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
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.
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.
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 !
@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
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 :
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.
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.
Je trouve ça fort dommage qu’un standard doivent autoriser le stockage du trousseau de clés en clair
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
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.
