Hello tous,
Je me demandais s’il était possible d’utiliser nos clés duniter pour chiffrer mails, sms et autres.
Si oui ce serait intéressant de pouvoir l’inclure dans thunderbird comme une clé pgp et de bénéficier du chiffrement avec toute la toile de confiance direct.
Tiens, c’est marrant, on en discutait justement récemment sur Signer / déchiffrer avec sa clé Ğ1. Oui, c’est possible, il faut juste trouver le format qui va bien 
Ben ce serait pratique et ça aurait du sens : permettre à chacun de préserver la confidentialité de ses messages grâce à son portefeuille G1. Ça permettrait d’utiliser la G1 pour autre chose que d’échanger de la monnaie. On pourrait aussi imaginer le vote ou d’autres fonctionnalités… Multifonction, la G1 ?
Ces réflexions remontent déjà à un moment. Par exemple l’année dernière, je pensais développer un module XMPP pour utiliser les clés Ğ1 : Communication XMPP × Ğ1 (entre temps j’ai priorisé d’autres choses 
).
Et par rapport au vote, on a un gros sujet en cours pour le vote on-chain au moins pour les runtime upgrade, mais il faut assurément l’étendre au delà. En fait ce qu’il nous manque principalement pour développer toutes les fonctionnalités autour de la toile de confiance de manière décentralisée, c’est du stockage off-chain décentralisé. Et ça aussi on en a discuté, mais pour l’instant on n’a pas les moyens humains de le mettre en oeuvre rapidement. D’où l’idée de faire grandir Axiom Team ou autre structure jusqu’au moment où on sera capable de salarier une dizaine de développeurs pour permettre tout ça.
Hello !
J’ai rédiger une RFC pour des envois chiffrés par email il y a longtemps (la RFC 007):
Et de mémoire, j’ai rédigé la RFC 008 pour formaliser le chiffrement utilisé par Cesium+.
Et la bibliothèque duniterpy le permet (pour les geeks).
@HugoTrentesaux : pour info, les liens vers les RFCs 007 et 008 sont brisés. La branche master ne les contient pas.
Il semble qu’aucune branche ne les contienne. Il faudrait un jour reprendre ce travail, mais plutôt dans le contexte de la v2 je pense.
Fred ou jbar ont peut-être des outils d’interopérabilité de crypto Duniter<->GPG ?
GPG supporte ed25519 donc on devrait pouvoir convertir une clé facilement. Je verrai si je peux ajouter ça à natools.
Le dépôt des RFCs mérite un peu de ménage on dirait. 
Au moins pour être fonctionnel. Pas d’urgence cependant.
Je veux bien aider, car j’ai mon dépôt avec les RFCs manquantes et je peux repousser les branches manquantes en MR pour rétablir ce travail qui me semble utile.
Mon dépôt a un remote sur nodes / common / doc · GitLab, qui est archivé et doit contenir ce qui manque.
En fait les clés GPG sont bien plus complexes que juste une clé publique, il y a des signatures, des sous-clés, etc.
Donc on doit pouvoir importer une clé GPG (si elle est bien ed25519, ce qui n’est pas le paramètre par défaut, et l’option pour en générer une ne se devine pas), et exporter une clé GPG avec peu de fonctionnalités.
Les clé PGP ne nous servent strictement à rien pour chiffrer les mails.
On a déjà nos clé G1, il suffit de coder un plugin thunderbird pour ça et basta.
@Attilax si ta un budget pour ça, ça se fait, il faut un dev C et un JS/front pendant 1 mois.
Au tarif G1 ou au tarif € ?
En G1 je suis partant. Mais je sais pas si je suffirais. Il me faut un devis
Ben si ça sert à ça justement. Et ça marche bien, je trouve, avec ceux qui veulent jouer le jeu.
Mais je veux bien les remplacer par mes clés G1 si c’est possible…
Au tarif du dev qu’on trouvera pour ça si quelqu’un s’occupe de le recruter.
N’ayant pas trouvé rapidement de documentation sur le format des clés GPG, et parce que ce n’est pas forcément très utile, j’ai abandonné. Mais en cherchant bien on doit pouvoir trouver, et alors la solution tiendra peut-être en 20 lignes de Python.
J’ai aussi un doute sur la pertinence de GPG pour les mails. Les correspondances privées devraient être chiffrées avec des clés symétriques temporaires, établies de manière sécurisée au début de l’échange par les deux parties en utilisant leurs clés asymétriques (telles que des clés GPG ou G1).
Comme ça, la fuite d’une clé privée ne compromet pas tous les échanges, le destinataire d’un message signé ne peut pas prouver à un tiers que la signature est authentique et le chiffrement est plus rapide.
Mais ça demande un échange préalable.
HTTPS fonctionne comme ça, Matrix aussi. Mais pour les mails c’est plus compliqué, ce protocole est vieux, obsolète et plein de rustines encombrantes.
Il vaut mieux aussi utiliser des clés déléguées ou au moins des dérivations, plutôt que tout miser sur une même clé : ça évite de tout perdre ou de tout se faire pirater d’un coup en cas de problème, et ça facilite l’anonymat.
Un système unifié pour rendre la crypto interopérable entre les différents logiciels et protocoles, prenant tout ça en compte, serait super. Il existe des keystores dans les distros linux mais j’ai l’impression que très peu de programmes les utilisent, et du coup c’est plutôt embêtant qu’autre chose.
Oui c’est déjà ce qu’on peut faire avec nos dérivations bip39, et les délégations de clés.
On le fait déjà avec nos sessions_keys
Je verrais bien quelque chose d’encore plus universel, accessible par clic-droit quand un bout de texte est sélectionné:
Est-ce que ce serait possible?
Tu aurais pas reparlé de PKSTL avec elois par hasard ?
Oui, c’est même une très bonne idée. J’avais jamais pensé à cette manière de faire mais en terme d’UX ça me paraît super clair !!
ya plu ka
Oui (au hackathon) mais ce n’est pas lié. C’est juste que maintenant (depuis la première fois qu’on avait parlé de pkstl en fait 
) j’essaie de me demander quelles sont les propriétés dont j’ai besoin pour telle application de chiffrement, et que la boîte à outils cryptographique est beaucoup plus fournie que juste chiffrer/déchiffrer/signer/vérifier.
L’inconvénient c’est de se rendre compte que pour faire de la crypto correctement, ba c’est compliqué.
D’où les prix.
ED25519 est “l’endroit” où toutes les fonctions se rejoignent.
Toutes les application qui chiffrent avec cette crypto se trouvent écrire au même endroit!!
Change ta duniker.key en ssb.key et tu découvres que tu avais déjà un compte ScuttleBut sans le savoir Transformé en clef pour Gchange, hop tu es au marché.
Convertie en clef IPNS, tu pointes le secteur #0 de ton disque IPFS
https://astroport.copylaradio.com permettra de “booter son disque” avec 2 phrases et un email. Les index du “filesystem” sont écrits dans un TW ou en json.
ça donne un espace de stockage et partage multimédia stocké sur IPFS.
Voila celui de toto@yopmail.com
https://ipfs.copylaradio.com/ipns/toto.yopmail.com.libra.copylaradio.com
Pour la conversion gpg, c’est aussi prévu, jbar et aya sont dessus…
En ce moment, on regarde comment embarquer G1lib.js et G1companion dans TiddlyWiki pour pouvoir signer et chiffrer nos tiddlers avant de les partager sur IPFS