La mémoire est censée être nettoyée par un mécanisme clear and drop (j’en ai parlé aux rml14), en tout cas se sera le cas dans Dunitrust. Dans les logiciels ou c’est fait correctement, il est alors impossible de récupérer les credentials depuis la mémoire après l’arrêt du logiciel.
De plus, récupérer des infos dans la mémoire vive est infiniment plus compliqué, l’attaquant ne sais pas ou chercher, alors que dans un système de fichier c’est immédiat.
1 Like
Comme l’a précisé tuxmain…
…et le redémarrage d’un serveur pour l’application d’une màj du kernel par exemple.
Dans ce cas l’administrateur remet sa clé, et c’est reparti.
Ça rend assez difficile la vie des nœuds temporaires (entendre, non serveur), mais ça ne me semble pas pertinent pour faire tourner une monnaie sur le long terme.
Oui c’est ce que je fais quand je maj un serveur ou j’ai Duniter dessus, je ne vois pas le problème, sauf peut-être avec le TPV 
Est-ce intéressant d’y inscrire un champ currency: contenant le nom de code de la monnaie ?
Ça permettrait au logiciel de dire que ce fichier d’authentification est fait pour une autre monnaie dans le cas d’usage sur une autre monnaie. Voire d’empêcher son usage sur la monnaie concernée (modifier le fichier ou le logiciel peu quand même contourner le blocage).
Ce champ pourrait être optionnel afin de permettre l’authentification sur plusieurs monnaies.
Mais, je pense que c’est une bonne pratique de forcer l’usage d’un fichier d’authentification/clé publique par monnaie.
3 Likes
Je me disais… En fait quel que soit ce que l’on fasse, il y a toujours cette clef membre qui doit se retrouver sur un noeud calculant… C’est parce que la création du DU est conditionné à ce statut membre « gravé » par un document dans la blockchain.
Mais, si plutôt que de dépendre de cet événement, le DU était fabriqué en fonction des liens établis dans la WOT… En effet, en remontant jusqu’au bloc 0, il est possible de vérifier tous les comptes qui ont des amis qui créent déjà le DU, et si on en a plus que 5 (et que les règles de distance sont bonnes), et bien on crée le DU… Dans ce cas le protocole devient autonome… Il auto découvre les membres… Vous voyez ce que je veux dire?
On pourrait même rendre le paramètre règle de distance et nombre d’amis dynamique.
NB: je n’ai toujours pas vraiment compris quelle machine ajoutait les DU dans la chaîne? L’algo tire au sort, tout le monde en écrit un peu? A l’heure du DU que se passe-t-il, une synchro réseau particulière a lieu?
Non pas du tout, a terme ce ne sera plus le cas, la solution technique est connue depuis longtemps, on manque juste de ressources pour l’implémentée, et on a d’autres priorités aussi : [Idée] Clé déléguée au calcul de blocs
Rien de tout cela. Ça se passe de la même façon que l’expiration d’un abonnement ou d’une certification.
Lorsqu’un nouveau bloc reçu est validé par un noeud Duniter, il l’ajoute a sa chaîne puis déclenche la génération du contenu du bloc suivant, c’est a ce moment la qu’il puise dans sa mempool pour event user a inscrire dans le bloc et qu’il calcule tous les événements automatiques qui doivent êtres générés en fonction de l’heure du bloc qu’il est en train de généré (déterminée donc a la création du bloc).
1 Like
OK @elois merci pour ces précisions.
Concernant cette idée de rendre le DU indépendant du statut « membre » mais plutôt de sa règle de distance dynamique aux sources du bloc 0, qu’en pensez-vous?
Que c’est incohérent. Car la règle de distance est défini sur la WOT qui elle même est définie sur les identités membres inscrites en blockchain et leurs certifications.
S’il n’y a plus d’identité membre “gravée” en blockchain, alors il n’y a plus de WOT, plus de DU et donc plus de monnaie.
Tous découle de se statut “membre” en blockchain, sans lui il n’y a plus rien, plus de règle de distance, plus de WOT, plus de DU, plus de monnaie.
Dans la mesure où des applications non-monétaires sont possibles (voir ssb), ce champs pourrait être nommé application :
Oui du coup je met a jours la spec en ce sens 
Non, c’est une mauvaise pratique que d’utiliser un même trousseau de clés pour plusieurs applications. C’est aussi grave que d’utiliser le même mot de passe sur tous les sites web ou l’on a un compte.
Ce que propose @Frederic_Renault d’utiliser sa clé G1 dans ssb est une très mauvaise pratique.
Pour lier son identité G1 avec son identité ssb, une bonne façon de faire est par exemple de signer sa clé publique ssb avec sa clé privée G1 et de publier la signature sur son feed ssb, cela permet de “prouver” le lien entre l’identité G1 et l’identité ssb
3 Likes
OK. dans ce cas c’est effectivement incohérent car impossible à implémenter… cette idée a du me venir en découvrant les propriétés des blockchain fabriqué par scuttlebutt. Dans leur protocole, l’identité et la wot sont la source…
tu as toujours de bonnes idées, merci
Ce genre de messages provocateurs me semble très inapproprié, en l’état je n’ai pas envie d’y répondre.
j’ai écris à @cgeek en privé pour qu’on en parle.
Tu prends un peu vite la mouche je trouve.
Cette histoire de Rust qui ne pourrait pas gérer de signature en lisant directement la clé privée, je n’y crois pas une seconde. Il va falloir être un peu plus convaincant.
En première lecture @elois ça paraît bizarre en effet. Mais tu veux sans doute signifier autre chose, pourrais-tu alors préciser ce point clairement ? C’est sans doute que tu ne voudrais pas ? Quelle que soit la raison il est préférable de l’expliciter, ça aidera
2 Likes
C’est exactement ce que je prétend : qu’il ne veut pas. Et je n’y verrai aucun problème, quelle qu’en soit la raison. Mais nous raconter que ce n’est pas possible en se cachant derrière l’écosystème Rust, c’est vraiment nous prendre pour des jambons.
Ça peut paraît anodin bien sûr. Mais considérant qu’Eloïs a été capable de s’approprier de gros sujets techniques, j’y vois une manipulation malsaine ici.
Et qu’on ne me dise pas que c’est une maladresse, vu l’insistance du « ne peux pas », d’un gros pavé d’explications et du pointage d’un bug Duniter (justifiant … son choix, précisément).
Quant à la provocation, @elois, là ce n’est que moi, et l’idée est bien de te faire réagir et, je l’espère, te permettre d’évoluer face à ce qui t’attend. Comment réagiras-tu quand les ennemis seront bien plus costauds et relèveront chacune de tes incohérences ?
2 Likes
Je suis globalement d’accord avec l’analyse de sécurité d’elois . Surtout avec son analyse ci-dessous :
Ceci dit :
Les OS savent stocker des données dans des espace sécurisés qui sont débloqués au boot. Pas de raison que Dunitrust ne puisse pas profiter de telles fonctionnalités. De plus, c’est assez facilement contournable avec un script de type expect. Une fonctionnalité de sécurité qui va agacer les utilisateurs pour finalement être contournées va générer encore plus de problèmes.
Pour gérer les seed de manière sécurisée, je te conseille plutôt de permettre de les récupérer via des variables d’environnement. Ca évite que l’utilisateur contourne ça via expect, et ça te permet de donner des conseils dans la doc de setup des variables sur comment bien sécuriser son système hébergeant le noeud dunitrust.
D’accord avec kimamila. Si elois veut stocker ses clés membre et network avec le même chiffrement… Ben il chiffre les 2 fichiers avec le même mot de passe. C’est plus KISS.
4 Likes
Ce mode de communication ne me conviens plus en fait. La provocation me donne juste envie de ne pas répondre.
Je sais que ce fût hélas régulièrement un moyen de communiquer entre nous par le passé, mais je le regrette. Les tord out souvent été partagés, de mon coté j’ai compris qu’il était nécessaire que je fasse un travail sur moi pour changer, ce que j’ai entrepris, j’ai encore du chemin a faire mais je souhaite que notre façon d’échangée devienne ce qu’elle aurait toujours du être : respectueuse, cordiale, chacun à l’écoute de l’autre
Cela m’aurais aidé a l’époque que l’on refuse de répondre a mes questions lorsque j’étais trop incisif. Le fait qu’on y répondais quand même me faisait comprendre “c’est ok d’être agressif”.
Je n’ai pas “d’ennemis” @cgeek, si une personne extérieure a l’équipe est agressive avec moi par écrit, ça m’est égal, je ne la connais pas, ça ne me touche pas, je signale a la modération et ne répond pas. Face à l’agressivité écrite la meilleure reste l’absence de réponse. Ceux qui cherchent sincèrement à comprendre poseront leur question avec respect, et ceux qui cherche a plomber le projet ce feront modérés, c’est tout. La seule “préparation” qui me semble nécessaire, c’est la modération
Sur le sujet de ce thread, si tu me relis bien, tu verra que je n’ai jamais écris nul part que le Rust ne pourra pas faire ceci ou cela, j’ai bien parlé de Dunitrust uniquement. Il est vrai que je n’ai pas précisé totalement pourquoi Dunitrust ne le peut pas, car l’explication est longue, et a l’époque ou j’ai posté je pensais que ça ferai trop long, et je manquais de temps aussi, j’avais déjà prévu d’attendre qu’on me pose la question. C’est ce qu’a fait @Galuel, je vais donc y répondre dans la soirée (dans un post séparé pour des questions de lisibilité).
Merci @Inso j’y avait en fait déjà pensé mais uniquement pour le use case docker. J’avais prévu de permettre la récupération de la passphrase via variable d’environnement uniquement pour le livrable docker. Je n’ai en effet pas pensé a l’incentive de contournement via expect que cela pourrai produire, il faudrait donc que j’élargisse cette feature a tous les livrables.
2 Likes
Pas tout a fait. Je t’avais déjà posé la question clairement, ne comprenant pas le soucis véritable :
J’ai relu ton argumentaire de départ, et tu sembles croire que laissé l’accès au seed (aux développeurs) est moins grave que l’accès a la clef privé. Quelle différence cela fait il ? L’un entraînant l’autre, d’un point de vue de la sécurité, ça me semble équivalent. Ou alors j’ai loupé quelque chose ?
Pourquoi Dunitrust ne peut pas lire les clés privées ed25519 ?
J’ai déjà répondu a cette question dans le 1er post en indiquant que cela est dit au fait que Duniter utilise ring, et que ring ne peut pas lire les clés privées ed25519 ce qui est vrai.
Mais personne ne m’a demandé pourquoi je ne pourrais pas tout simplement utiliser une autre lib de crypto ou forker ring ? II y a des raisons précises à cela, que je n’ai volontairement pas explicité dans mon 1er post pour ne pas faire trop long, me disant qu’on finirait de toute façon par me poser la question.
J’ai préféré insister sur le fait que cette limitation n’est pas spécifique a ring mais s’inscrit dans la continuité de l’esprit « safe by design » qui est un des fondements du langage Rust et qui est fortement respecté par la plupart des librairies Rust, ce qui est vrai.
Évacuons déjà la possibilité du fork :
Je ne souhaite pas maintenir un fork d’une librairie de crypto tierce, cela représente plus de travail et augmente les risques de failles de sécurité par maintenance non assidue du fork. C’est exactement ce qui s’est produit dans Duniter avec le bug de TweetNacl, ce dernier a été corrigé dans TweetNacl dés 2015, mais cgeek ayant créé son propre fork “naclb”, ce dernier n’a pas bénéficié du correctif.
C’est précisément parce que je sais qu’un tel problème pourrais se reproduire dans Dunitrust si j’utilise un fork d’une lib de crypto tierce que je me refuse à le faire.
Nous avons eu beaucoup de chances que le bug de tweetnacl n’était pas exploitable de façon malveillante, mais on ne peut pas parier qu’il en sera de même à l’avenir (ce serait un pari très dangereux qui me semble irresponsable de faire).
Enfin concernant la possibilité d’utiliser une autre lib de crypto, je me suis fixé plusieurs contraintes :
- La lib doit être activement maintenue par beaucoup de développeurs et depuis longtemps, pour s’assurer qu’elle sera bien maintenue dans les années à venir lorsque des failles de sécurité seront découvertes dans les algorithmes qu’elle expose.
- La lib doit dépendre d’aucune librairie dynamique (donc exclu un wrapper rust de libsodium), afin de faciliter le build et l’installation sur tous type de plateforme et d’OS.
- La lib doit être la plus performante parmi celles qui respectent les autres contraintes.
- Si d’autres dépendances de Dunitrust utilisent déjà indirectement une lib de crypto gérant ed25519, utiliser celle-ci de préférence pour ne pas alourdir le binaire Dunitrust avec 2 lib de crypto.
Historiquement, Dunitrust utilisait rust-crypto. C’est @nanocryk qui avait choisi cette lib a l’époque. Mais cette lib n’est plus maintenue depuis plus de 4 ans, car les dev initiaux de cette lib ont décidé il y a un peu plus de 4 ans de faire exploser cette grosse crate en plein de petites crates pour être plus “rusty way”. Ed25519 n’a jamais été réimplémenté, l’équipe de rust-crypto s’est contenté de l’écriture d’une abstraction utilisable par le “backend” de son choix : GitHub - RustCrypto/signatures: Cryptographic signature algorithms: DSA, ECDSA, Ed25519.
Il me fallait donc choisir un “backend” une implémentation concrète d’ed25519. J’ai donc passé plusieurs semaines (voir mois je ne sais plus) à étudier l’état de l’art dans l’éco-système rust, j’ai retenu 3 librairies sérieuses : ed25519‑dalek, sodiumoxide et ring.
Ne souhaitant pas dépendre de lib dynamiques, j’ai exclu sodiumoxyde. je trouvais également très dommage de faire une implémentation en Rust pour se baser sur du code C++ pour la partie la plus critique(la crypto), on perd les garanties apportées par le Rust.
J"ai donc expérimenté les 2 restantes :
ed25519‑dalek : 17 contributeurs, projet qui n’a que 3 ans et qui a déjà connu des trous d’inactivités importante dans le graphe des contributions. 340000 téléchargements, utilisé par 63 crates rust.
ring: 171 contributeurs, projet qui a déjà 6 ans et qui n’a jamais connu aucun trou d’inactivité depuis 6 ans. 2,8 millions de téléchargements, utilisé par 236 autres crates rust.
Les chiffres sont explicites, et confirme les conseils que j’ai reçu en meetup rust ou dans les channel irc rust, ring est l’état de l’art de Rust pour la crypto, c’est LA librairie que tous le monde recommande d’utiliser.
De plus, ring présente de meilleurs benchmark que ed25519‑dalek.
Et pour couronner le tous, ring est déjà utilisé par rustls , une implémentation en Rust de TLS/httpS, qui est utilisée par actix, le framework web que j’utilise dans Dunitrust. Donc je dépends déjà de cette crate.
Pour toutes ces raisons, je ne souhaite pas utiliser une autre lib. je vous avait prévenu que ce serait long 
4 Likes