Journal Présentation d'idée : PGPID

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
17
23
juil.
2013

Sommaire

Bien le bonjour à toi journal (ainsi qu'à tes lecteurs),

Aujourd'hui, pour mon premier journal, je m'en vais vous présenter une idée qui me taraude depuis bien longtemps.
Vous vous en doutez, vous avez lu le titre, c'est de PGPID dont je vais vous parler.
Avant d'aller plus loin, je ne vais pas vous tromper sur la marchandise : Il y a pas de code, pas de soft à tester. C'est juste une idée jetée sur un clavier.

Pourquoi PGPID

On parle de plus en plus (ici en tout cas) de réseaux sociaux décentralisés.
Certains ne jurent que par eux (quid de la maitrise de ses données ?), d'autres sont plus circonspects (quid de la disponibilité ?).

Il existe de nombreuses solutions pour faire du réseau social plus ou moins décentralisé/a-centralisé/fédéré.
Les citer serait trop long, sans intérêt et ceux que j'oublierai se sentiraient exclus et se vexeraient. Alors, je ne le ferais pas :)

Ces solutions marchent bien mais, de mon point de vue, elles souffrent de deux problèmes communs :

  • l'identification des utilisateurs.
  • la localisation des machines fournissant un/des service(s) auprès des utilisateurs.

La plupart utilisent un identifiant d'utilisateur de la forme "utilisateur@fournisseur.tld" ou "fournisseur.tld/utilisateur"
Le problème de ces identifiants est qu'ils sont dépendant du fournisseur.
Ainsi :

  • C'est le DNS du fournisseur qui permet de localiser la machine qui va bien.
  • Pour deux services différents chez deux fournisseurs différents il y aura deux identifiants.
  • Le jour où mon fournisseur ferme ou que je veux en changer, il me faut changer de fournisseur.

La solution couramment évoquée est d'avoir son propre nom de domaine. Honnêtement, j'y crois pas beaucoup. Malgré l'infinité de possibilité de nom de domaine, les domaines intéressants sont eux limités.
(Mon nom de famille est déjà pris par une société. Et même si j'aurai pu l'avoir il y a pas mal de monde qui a le même nom que moi).
Quant bien même, un tld intéressant serait disponible, il n'est pas donné d'en acheter un (vous voyez votre grand-mère aller sur un registar acheter "tante-Huguette.fr" ?).

Et les noms de domaine ont un sens. Les goûts et les couleurs changeant avec le temps, que faire de ce sens ?
Tous ces problèmes m'amène à penser que les noms de domaine ne sont pas une solution à long terme
(ça marche bien pour un nombre limité d'utilisateurs, pour 6 milliards de personnes c'est plus problématique)

On pourra cependant noter RetroShare (le seul que je connaisse) qui utilise une solution relativement (voir très) proche de celle présentée ici.
Il utilise une clé PGP pour identifier un utilisateur et une DHT pour identifier les adresses IP des machines.
La solution utilisée par RetroShare me semble bonne, elle est par contre dépendante de RetroShare.
La solution que je propose reprend celle de RetroShare, mais sous un axe global et indépendant des applications.
Il ne devrait pas être problématique de porter RetroShare sur PGPID.

Je vous invite à lire le très bon article de Stéphane Bortzmeyer (qui traine aussi ici) au sujet des url : http://www.bortzmeyer.org/no-free-lunch.html

Présentation

PGPID est donc une solution basée sur PGP, qui fournirait :

  • un système entièrement a-centré d'identification et d'authentification des utilisateurs.
  • un système d'association de machines à un utilisateur.
  • un système bas niveau fournissant des services de base aux applications construites au-dessus.

Je vous préviens tout de suite, PGPID n'est pas une solution complète :
C'est une solution pour un réseau social au sens premier du terme. Il ne présume en rien des applications bâties dessus (même si j'en parle un peu).

C'est vous voulez un résumé en une phrase (et donc fausse) : PGPID est au réseau d'humain ce que IP/DNS est au réseau d'ordinateur.

Le principe de base est le suivant :

  • L'utilisateur se crée une clé à chiffrement symétrique (PGP)
  • La clé publique sert d'identifiant.
  • Cet identifiant est mis dans une DHT.
  • À un identifiant est associé un certain nombre de métadonnées dans la DHT.
  • Pour éviter qu'un vilain pirate ne change vos données, l'ensemble des données est signé avec la clé associée.
  • Une donnée principale (si ce n'est pas la seule donnée) est une liste de nœuds.
  • Chacun de ces nœuds, lorsqu'ils sont interrogés, permettent de connaitre quel nœuds fournit quel services associés à la clé.

Définitions

Bon, c'est très loin d'être une spec, mais il faut bien avoir des noms clairs pour savoir de quoi on parle.
J'en conviens c'est un peu imbuvable à première lecture, mais n'arrêtez pas tous de suite, il y a des exemples après.

Service

Fonctionnalité apportée par une application (le plus souvent cliente).
Un service peut être :

  • Un fournisseur d'adresse de machine et des services associés.
  • Une application de messagerie instantanée.
  • Un serveur web.
  • Un service de notifications
  • Un service d'échange de fichiers
  • Un serveur mail.

SN (Service Name)

Le nom d'un service.

PGPID

L'identifiant d'un compte. C'est le fingerprint de la clé PGP.

PGPIDC

PGPID content

La clé publique complète PGP.

SPN (ou Node)

Service Provider Node.

Une machine fournissant un ou plusieurs services.

NDS

Node discovery service

Un service particulier qui permet d'obtenir une liste de SPN associé à une PGPID.

NDN

Node discovery node (Noeud d'aiguillage).

Un SPN fournissant NDS.
Ce sont ces nœuds qui l'on met dans la DHT.
Le NDS n'étant qu'un service particulier, le NDS du NDN doit inclure le NDN dans la liste.

SDS

Service discovery service

Un service fournissant la liste des services associés à un PGPID fournit par le SPN.
Chaque SPN doit avoir un SDS

TS

Table service

Service fournissant la partie DHT (stockage/recherche des clés)

TN

Table node

Un SPN fournissant TS

FPGPID

Full PGPID. Il est de la forme : <PGP fingerprint>[@<SPN>][:<SN>]
Il permet d'identifier jusqu'à un service particulier d'une machine particulière d'un utilisateur.

Identification

L'identifiant de l'utilisateur est le fingerprint de la clé PGP.

Chaque utilisateur peut potentiellement avoir plusieurs nœuds fournissant des services. Ces machines sont identifiées par : ID@SPN
Ici, SPN est un nom choisi arbitrairement par l'utilisateur. Ça peut être «maison», «pc», «portable», …
Ceci peut être comparé au ressource dans les xmppid.

Chaque service à un nom, (plus ou moins standardisé). C'est l'équivalent des ports.
Ainsi un service mail pourra être adressé avec l'identifiant : ID@maison:mail
De même un service de messagerie instantané sur téléphone sera adressé avec : ID@phone:im

Use Case

Inscription

Alice souhaite s'inscrire (si on peut appeler ça s'inscrire) sur PGPID.

  1. Elle lance son programme et crée une paire de clés PGP.
  2. Elle contacte un TN connu et lui envoie sa PGPIDC.
  3. Le TN se charge de diffuser sa PGPIDC dans la DHT.

Alice a maintenant une «identité» sur PGPID

 Identification sur les sites web

Son navigateur web étant configuré, lorsque Alice navigue sur un site supportant l'identification PGPID, elle est automatiquement identifiée.

  1. Échange d'information entre le navigateur et le serveur web pour s'informer qu'ils supportent l'identification PGPID
  2. Le serveur envoie un défi au navigateur
  3. Le navigateur chiffre le défi (avec éventuelle confirmation d'Alice)
  4. Le serveur récupère le PGPIDC d'Alice en contactant un TN.
  5. Le serveur vérifie le chiffrement du défi et Alice est authentifiée.

Aucun mot de passe ne transite et n'est fourni à aucun serveur.

Participation au réseau PGPID

Alice souhaite participer au réseau en installant un TS sur sa machine.

  1. Elle installe un TS sur sa machine.
  2. Elle contacte un TN et enregistre sa machine en tant que nouveau TN.
  3. L'adresse IP:port du TS sont propagés dans la DHT.
  4. Son TN commence à recevoir des PGPIDC à stocké et des requêtes de PGPID.

Installer et fournir de nouveaux services

Pour pouvoir fournir des services la machine d'Alice doit devenir un SPN

  1. Alice installe un SPS. Sa machine devient donc un SPN
  2. Pour que son SPN puisse être contactée Alice doit enregistrer son SPN auprès d'un NDN.
  3. Elle décide d'utiliser le NDN de «la Société À la Mode sur Internet»
  4. Elle contacte donc le NDN et y enregistre son SPS (adresse IP du SPN et port du SPS)
  5. Alice rajoute l'adresse IP du NDN et de port du NDS aux métadonnées associées à son PGPID, les signes et les envoie sur un TN connu (probablement le sien)
  6. Son SDS est configuré pour indiquer que le SPN fourni les services SDS (obligatoirement) et TS (puisque c'est aussi un TN)

Installer un service de messagerie instantané (IM)

1. Alice a installé un service de messagerie supportant le protocole PGPID
1. Alice configure son SDS pour qu'il indique aussi que son SN fourni le service IM

Communiquer avec Bob

  1. Alice rentre le PGPID de Bob dans son logiciel IM
  2. son logiciel contacte un TN, demande le PGPIDC de Bob et la liste de NDN.
  3. le logiciel contacte le(s) NDN et demande au NDS une liste de SPN correspondant au PGPID de Bob
  4. le logiciel contacte le(s) SPN et demande au SDS la liste des services fournit.
  5. si le service IM est dans la liste, on a trouvé le SPN fournissant le service IM
  6. le logiciel d'Alice contacte le logiciel de Bob sur le bon SPN
  7. Une authentification a lieu (défi, chiffrement, déchiffrement)
  8. La communication commence

Avoir un deuxième SPN

Alice a un portable, elle souhaite installer un logiciel IM pour discuter à partir de celui ci

  1. Alice installe un SPS sur son portable
  2. Alice configure le NDS pour qu'il retourne aussi l'adresse de son portable.
  3. Bob peut contacter Alice aux adresses :
    • <Alice PGPID>. Le SPN contacté dépendra de l'ordre de priorité configuré dans le NDS.
    • <Alice PGPID>@pc
    • <Alice PGPID>@portable

Idées de service possible

  • vcard. service fournissant des informations complémentaires sur l'utilisateur (adresse, avatar, …). Le service vcard (comme tous les autres services, y compris NDS et SDS) peut fournir des informations différentes selon le demandeur.
  • service web.
  • réseaux sociaux
  • échange de fichier
  • sauvegarde de données. PGPID1@pc peut envoyer des données à PGPID2@pc/backup. Permet de sauvegarder automatiquement des données chez d'autres personnes et vice versa (échange de bon procédés)
  • synchronisation de données entre les machines d'une même personne. (entre PGPID1@pc et PGPID1@portable)

Utilisation avancée

Avoir plusieurs NDN

Alice a aussi un téléphone portable. Elle souhaite l'utiliser, ainsi que son pc, comme NDN. Le téléphone servant de NDN de secours lorsque son pc est éteint.
De plus elle souhaite aussi s'en servir pour faire de la IM.

Elle installe donc :

  • sur son pc
    • un NDS qui liste son pc.
    • un SDS qui liste les services disponibles sur son pc
  • sur son téléphone portable
    • un NDS qui liste son portable.
    • un SDS qui liste les services disponibles sur son portable (IM)
  • dans la DHT
    • l'adresse de ses deux NDS, le NDS du pc ayant une plus grande priorité.

Itinérance

Bob a un accès internet avec une adresse IP dynamique.
Pour éviter que la DHT soit mise à jour trop souvent, Bob utilise un NDN ne lui appartenant pas qui lui a une adresse fixe.
Celui-ci sert de relais vers son adresse dynamique.
Son SPN contacte régulièrement les NDN qui le référencent pour qu'ils mettent à jour leurs informations. (équivalent des services dynDNS)
C'est d’ailleurs la raison d'être des NDN (au lieu de mettre directement les SPN dans la DHT) : Avoir des SPN dynamiques et utiliser les NDN (fixe) qui servent «d'aiguillage». Le tout sans remettre à jour la DHT trop souvent.

Résilience des données

Alice a fait un blog. Pour cela elle utilise le service blog sur son pc.
Son PC n'est pas toujours connecté mais Alice souhaiterais que ses informations soient toujours disponibles.
Elle s'arrange avec Bob. Lorsque Alice écrit un article, elle le publie sur son pc mais aussi sur une machine de Bob.
Elle configure son NDN pour qu'il retourne le SPN de Bob.
Bob de son côté configure son SPN pour répondre aux requêtes au sujet d'Alice.
Lorsque Charles veut lire les articles d'Alice il se contacte à son NDN. Si le SPN d'Alice est connecté il va lire l'article dessus.
Sinon il se connecte au SPN de Bob pour accéder à l'article.
Les données venant d'Alice devant être signé par la clé privée d'Alice et Bob ne pouvant en aucun cas y accéder (à la clé privée), il faut qu'Alice signe ses articles à l'avance.
Il ne peut donc pas y avoir de contenue dynamique hébergé chez un tiers. (Sauf à mettre en place un protocole de délégation des signatures/réseau de confiance avancé)

Alice, Bob et Charles peuvent aussi se mettre d'accord pour louer un serveur et mettre en place un NDN/SPN commun.

Conclusion

Je pense que vous avez le compris le principe et je laisse votre imagination débordante trouver de nouveaux cas d'utilisation.

J'aimerais pourtant revenir sur quelques points :

  • PGPID se veut neutre quant à son utilisation. Il est tout à fait possible de créer des services a-centrés comme des totalement centrés autour d'une seule entité. Dans les deux cas, l'utilisateur à un identifiant unique. Son réseau personnel et ses son identifiant restent identique, quel que soit son hébergeur du moment.
  • Pour fonctionner, un système de ce genre n'a pas besoin d'être très étendu et utilisé. Un bout de serveur toujours allumé dans un coin pour faire office de TN de référence. PGPID peut même être utilisé «en solo» par un seul utilisateur qui s'en servirait pour identifier ses machines.
  • Pour fonctionner à grande échelle (comprendre madame Michu), il faut que les outils soient le plus simple possible. Il faut donc imaginer que :
    • Le TN de référence soit connu des outils, s'inscrire doit revenir à appuyer sur un bouton et rentrer son mot de passe.
    • Il soit possible de faire des recherches de personnes et ainsi retrouver ses contacts.
    • On utilise des QRCode et autres NFC. Il me suffit de scanner le QRcode d'un ami avec mon téléphone intelligent pour l'ajouter.

Quoi qu'il en soit, il faut voir ce qui est décrit plus au comme un draft. J'insiste sur le fait que c'est très loin d'être une spec (vous vous en serez rendu compte de vous-même). Beaucoup de choses peuvent changer et c'est en partie pour ça que j'en parle. Qu'est-ce que vous en pensez ? C'est l'idée ou la fausse bonne idée du siècle ? Je mérite le Turing Award ou la fosse commune ? Ou un peu entre les deux, voir les deux ?

Conclusion bis (aka vaporware)

Alors, c'est cool, vous voulez vous y mettre. Et vous vous demandez : "Quand est-ce que ça sort ?"

Et bien je vous répondrai : À moins que ma boite veuille copier google et m'offrir 20 % du temps pour des projets perso, ça mettra longtemps avant d'arriver.
J'ai déjà d'autres projets perso en cours et, hélas, mon temps libre a des limites. J'ai bien écrit deux bouts de code en python qui s'échangent des clés PGP mais c'est loin d'être utilisable et je ne sais absolument pas quand ça le sera…

Ça y est, j'ai terminé. C'est à vous d'écrire maintenant : à vos commentaires !!

  • # marrant...

    Posté par  . Évalué à 1.

    J'avais déjà un projet similaire (bien qu'assez différent sur de nombreux points): https://github.com/lordblackfox/pepr ; Pour la question du P2P total, le problème reste la disponibilité des données lorsque personne n'est connecté.

    Sinon, pourquoi ne pas se baser sur GnuNet?

    Autre chose qui devrait t'intéresser: http://www.maidsafe.net/

    • [^] # Re: marrant...

      Posté par  (site web personnel) . Évalué à 5.

      J'ai lu ton papier sur pepr. C'est intéressant. Mais d'un point de vue technique ça se place au dessus de PGPID. Pepr pourrait utiliser PGPID pour identifier les utilisateurs et adresser les machines associées (d'ailleurs, ta section "address" se résume à un gros TODO).

      Pourquoi ne pas passer sur GnuNet ? Parce que d'après GnuNet eux-mêmes c'est : "A first service implemented on top of the networking layer allows anonymous censorship-resistant file-sharing".
      À première vue :

      • "anonymous" : ça va pas trop avec "tout est signé par des clés PGP"
      • "censorship-resistant file-sharing" : C'est pas vraiment le sujet de PGPID. Le file-sharing c'est les applications/services qui se base au dessus de PGPID.

      Pour maidsafe, je connaissais pas, ça a l'air intéressant. Il à fallut que je cherche un peu pour savoir ce qu'il y avait derrière (https://github.com/maidsafe/MaidSafe/wiki "maidSafe parers" sur la gauche) mais ça semble relativement proche de PGPID. Je vais regarder.

      Matthieu Gautier|irc:starmad

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: En résumé & en image

      Posté par  (site web personnel) . Évalué à 3.

      Ouai, je sais c'est long :) Merci pour le résumé.

      Tu loupes quand même dans ton résumé une grosse partie du sujet qui est la localisation des machines (à coup de requêtes sur les NDN/SPN).
      Et puis tout les points que tu as retenu sont dans mon introduction, ça me ferait mal d'admettre que j'aurai pu m'arrêter à l'introduction (même si c'est peut être vrai…)

      Et effectivement, c'est bien un clé de chiffrement asymétrique. J'ai corrigé beaucoup de fautes avant de publier mais celle-ci est passée au travers.

      Matthieu Gautier|irc:starmad

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -8. Dernière modification le 01 août 2013 à 17:15.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # Bitcoin adapté aux réseaux sociaux ?

    Posté par  . Évalué à 1.

    Je vois que ton idée se rapproche de ce que fait bitcoin actuellement. Chaque peer génère une paire de clés RSA, et en tire une adresse unique qui est SHA256(Clé publique).

    La clé privée sert à signer numériquement les messages, et hop :) .

    • [^] # Re: Bitcoin adapté aux réseaux sociaux ?

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 23 juillet 2013 à 11:28.

      D'ailleur, c'est à peu près l'idée derrière Namecoin [http://namecoin.info/]

      Namecoin permet d'associer des données arbitraires à un identifieur. En bonus, l'identifieur a un sens.

      En particulier namecoin permet d'associer a un identifiant des données comme adresse email ou autre: http://dot-bit.org/Namespace:Identity

      • [^] # Re: Bitcoin adapté aux réseaux sociaux ?

        Posté par  . Évalué à 3.

        bitmessage me semble plus simple pour ça

        • [^] # Re: Bitcoin adapté aux réseaux sociaux ?

          Posté par  (site web personnel) . Évalué à 1.

          À ma connaissance, les données de bitmessage ne restent pas dans le réseau à l'infini mais environ deux jours, il n'y a pas de blockchain. C'est plutôt similaire aux mails.

          Namecoin lui est un espace de stockage clé/valeur générique qui ne se perd pas (il y a une expiration artificielle, pour éviter qu'un nom soit pris pour un temps infini, mais le renouvèlement est facile).

          J'ai déclaré ma clé PGP dans le namespace approprié, mais il n'y a aucun logiciel qui le gère, alors c'est moyennement utile.

  • # Parlons projet alors !

    Posté par  (site web personnel) . Évalué à 4.

    Et bien je vous répondrai : À moins que ma boite veuille copier google et m'offrir 20 % du temps pour des projets perso, ça mettra longtemps avant d'arriver.
    J'ai déjà d'autres projets perso en cours et, hélas, mon temps libre a des limites. J'ai bien écrit deux bouts de code en python qui s'échangent des clés PGP mais c'est loin d'être utilisable et je ne sais absolument pas quand ça le sera…

    Tout pareil, mais l'oignon fait la farce l'union fait la force !

    J'ai pas grand chose à discuter sur le technique. A première vue ça me plait, je serais prêt à contribuer, mais je me pose quelques questions sur l'organisation du projet :

    Faire un état de l'art (collaboratif ?)

    D'autres projets similaires n'existent-ils pas? en quoi sont-ils différents, comment on les classe? niveau protocoles et specs. de quoi peut-on s'inspirer? Le travail est très bien dégrossi, mais je formaliserais bien un peu cette partie.

    Faire une spec

    Partir sur un proto Python c'est loin d'être la pire des idées, il faut bien choisir un langage, mais cela ne contentera pas tout le monde. Du coup, faire une spécification propre, à la Bittorent ou autre, permettrait de fédérer le travail de personnes qui auront de toute façon envie de forker ou recoder le proto dans leur langage de prédilection. Encore une fois j'ai cru lire à peu prêt cela, mais je formalise.

    Tester/Déployer

    C'est pas évident de tester des logiciels décentralisés. Du coup il faut vraiment référencer quelques bécanes de test, sinon ça va être dur d'avancer.

    Structurer très tôt

    Un impératif dans les projets libres voués à être gros, c'est l'organisation de la communauté d'une part, et des contributions de l'autre. Je pense que c'est l'élément qui peut faire la différence entre un projet qui réussi et un projet qui foire. A ne pas négliger donc ! Je ne dis pas qu'il faut monter une association 1901 tout de suite, mais définir les sous-projets et y associer des « responsables » c'est peut être une bonne idée. Ce sont des éléments essentiels et souvent douloureux :) Ça serais bête de perdre du code parce que personne veut en prendre la responsabilité, et pourtant ça arrive si souvent.

    Bref autant de questions qui me taraudent et auxquelles je n'ai pas encore de réponse. Mais comptez sur moi pour suivre tout ça avec attention et pour contribuer à ma modeste échelle.

    PS : je suis assez calé en DHT s'il y a besoin.

    • [^] # Re: Parlons projet alors !

      Posté par  (site web personnel) . Évalué à 0.

      Au lieu de recoder un DHT, pourquoi ne pas réutiliser un protocole existant comme bittorrent ?

      "La première sécurité est la liberté"

      • [^] # Re: Parlons projet alors !

        Posté par  (site web personnel) . Évalué à 5.

        Au lieu de recoder un DHT, pourquoi ne pas réutiliser un protocole existant comme bittorrent ?

        Parce que cela ne correspond pas au même service ! Une DHT c'est une table de hachage distribuée. Bittorent est un protocole de diffusion/échange de contenu, qui utilise notamment des DHT pour certaines fonctions.

        Mais sinon, je ne crois pas que quiconque parlait de recoder une DHT. Il y des implémentations qui marchent très bien ! Il Faut juste voir laquelle où lesquelles utiliser et comment y interfacer le reste du protocole/service.

        • [^] # Re: Parlons projet alors !

          Posté par  (site web personnel) . Évalué à 2.

          Il y des implémentations qui marchent très bien

          Au passage si quelqu'un en connais une concise et facile à comprendre …

          • [^] # Re: Parlons projet alors !

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 23 juillet 2013 à 15:51.

            Pour comprendre les DHT (ou THD en français) on commence généralement par Chord. C'est la base théorique des autres on va dire, même si Pastry n'est pas beaucoup plus jeune. En tous cas c'est sur Chord que tu trouveras le plus de cours en Français (je te conseille le cours de Sacha Krakowiak).

            Pour Pastry, il y a Peter Druchel (un des pères de Pastry) qui a fait des supers cours en anglais et en allemand, je les ai suivis, mais j'ai pas les liens. Il faut savoir que c'est assez différent de Chord comme principe, donc il y a pas de mal de boulot pour comprendre les deux (Chord et Pastry). Mais une fois le travail fait, tu pourras te targuer d'avoir compris les DHT, car la majorité des implémentations utilisent les principes de Chord ou de Pastry ou une combinaison des deux.

            • [^] # Re: Parlons projet alors !

              Posté par  (site web personnel) . Évalué à 2.

              Puisque tu as l'air de bien connaitre ces deux-la, est-ce que tu saurais me dire quelle est la différence par rapport a Kademlia ? Je parle surtout en termes de performances dans le monde réel, comme c'est l'algorithme derrière le DHT de Bittorrent, je me disais que ça doit être la plus large installation d'un DHT (en tout cas grand public) et j'aurais aime savoir quelles sont les conséquences derrière.

              En tout cas merci pour le cours, je vais voir un peu plus en détail a quoi ça ressemble.

              • [^] # Re: Parlons projet alors !

                Posté par  (site web personnel) . Évalué à 3.

                Ben je dois t'avouer que niveau performance je ne sais pas trop. Théoriquement c'est les mêmes perfs (à des cacahuètes prêt) pour toutes les DHT, si on considère que tous les nœuds sont homogènes et qu'il n'y a pas de déconnexion (ce qui est pas loin du cas réel, en général). Je sais que les perfs de la DHT de Bittorent ont la réputation d'être pourries, mais je n'ai plus les détails en tête. Mais bon, ça marche alors c'est déjà pas mal !

                Pour ce qui est des perfs DHT pures, j'ai toujours entendu dire que Pastry était meilleur, mais ça se joue sur l'ajout retrait de nœuds il me semble. Après pour de la perfs pure, il faudrait regarder du coté de Dynamo. C'est un peu plus qu'une DHT, mais là au moins on est sûr que ça pédale (c'est qu'il y a au cœur des infrastructures d'Amazon (S3), Akamai, Facebook, …). Mais bon, c'est en design orienté stockage de masse à la NoSQL, donc ça s'éloigne un peu du but recherché.

            • [^] # Re: Parlons projet alors !

              Posté par  (site web personnel) . Évalué à 3.

              je te conseille le cours de Sacha Krakowiak

              Je l'ai parcouru vite fait, effectivement, il est très bon et accessible. Merci

          • [^] # Re: Parlons projet alors !

            Posté par  (site web personnel) . Évalué à 3.

            Kademlia implémentée par Juliusz Chroboczeck (utilisée notamment dans Transmission) :
            https://github.com/jech/dht

    • [^] # Re: Parlons projet alors !

      Posté par  (site web personnel) . Évalué à 1.

      Faire un état de l'art (collaboratif ?)

      Je suis d'accord. C'est en fait le noeud de problème qui m'a fait penser à PGPID. Il y a énormément de projets "applicatifs" mais aucun ne se situant "que" au niveau identification/authentification/localisation. Il y a beaucoup de bonnes idées de partout mais il y a quasiment de rien de compatible. Le plus proche d'une solution globale, c'est xmpp. Mais comme dit précédemment, c'est dépendant d'un nom de domaine, donc d'un fournisseur d'identité.

      Faire une spec

      Clairement !! Le mieux serait carrément une RFC.

      Pour ce qui est du python, je ne peut qu'être d'accord. C'est un proto et python est bien pour ça. À terme, c'est une norme qu'il faut. J'envisage aussi une lib bas niveau en C. Après, chaque langage se fait son wrapping comme il a envie.

      Tester/Déployer et Structurer

      Bien d'accord.

      T'es calé en DHT, c'est bien. Car moi, si je devais me donner une étiquette, ça serait plutôt expert en performance graphique dans l'embarqué. J'ai lu pas mal de chose sur le net et les DHT. Je suis loin d'être idiot et je comprend bien ce qu'il y a derrière mais je manque clairement de background sur comment procéder et gérer un projet de ce genre.

      Matthieu Gautier|irc:starmad

      • [^] # Re: Parlons projet alors !

        Posté par  (site web personnel) . Évalué à 1.

        T'es calé en DHT, c'est bien. Car moi, si je devais me donner une étiquette, ça serait plutôt expert en performance graphique dans l'embarqué. J'ai lu pas mal de chose sur le net et les DHT. Je suis loin d'être idiot et je comprend bien ce qu'il y a derrière mais je manque clairement de background sur comment procéder et gérer un projet de ce genre.

        Enfin je dis calé, je ne suis pas un super expert non plus, mais j'en ai déjà codé, décortiqué, analysé, et lu pas mal de papier de recherches (plus ou moins intéressants)…etc. Et surtout, comme je dis dans un précédent commentaire, ce que je retiendrais de mon expérience, c'est qu'il faut utiliser des implémentations éprouvées comme Chord, Pastry ou Cassandra (pour citer celle que je connais le mieux).

        • [^] # Re: Parlons projet alors !

          Posté par  . Évalué à 4. Dernière modification le 24 juillet 2013 à 13:01.

          je ne suis pas un super expert non plus, mais j'en ai déjà codé, décortiqué, analysé, et lu pas mal de papier de recherches

          Je croyais qu'être expert c'était juste avoir lu la quatrième de couverture d'un bouquin, moi, tu m'en bouches un coin.

  • # Retroshare?

    Posté par  (site web personnel) . Évalué à 4.

    La solution utilisée par RetroShare me semble bonne, elle est par contre dépendante de RetroShare.

    Il y a une libretroshare. Ce n'est pas réutilisable?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Retroshare?

      Posté par  (site web personnel) . Évalué à 2.

      Oui, c'est sur, il y a des trucs à récupérer, mais pas tout, loin de là.

      libretroshare est très complète et orientée Retroshare. Elle comprend notamment toutes leurs fonctionnalités d'échange de fichiers, turtle, cache et compagnie. L'idée de PGPID est justement de reprendre une toute petite partie de RetroShare et de la sortir du projet pour la rendre «application agnostique»

      (ne vous inquiétez pas, j'en parlerait avec eux avant de leur piquer du code :) . Par respect et aussi parce qu'ils peuvent être plein de bonnes idées)

      Matthieu Gautier|irc:starmad

  • # Il existe déjà quelque chose de beaucoup plus simple pour le même besoin

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 juillet 2013 à 12:30.

    Avant tout et sans vouloir t'offenser, pourquoi diable inventer le plus possible de nouveaux acronymes à la c.., dans quel boîte bosse-tu que tu ais pris cette mauvaise habitude ?

    Ensuite tu as l'air d'ignorer pas mal de choses comme le projet monkeysphere, la RFC 6091, implémenté notamment par GnuTLS, et enfin OpenUDC qui a rencontré ce besoin et y a déjà répondu au travers de 2 petites specs, en grande partie implémenté (mais pas encore très utilisées):
    * https://github.com/Open-UDC/open-udc/blob/master/docs/OpenUDC_Authentication_Mechanisms.draft.txt
    * https://github.com/Open-UDC/open-udc/blob/master/docs/HTTP_OpenPGP_Authentication.draft.txt

    NB: Avec OpenPGP on a pas spécialement besoin et on se moque un peu beaucoup du DNS. Pourquoi diable faire quelque chose qui y est dépendant ?

    Je moinsse, tu moinsses, il moinsse, nos bots moinssent ...

    • [^] # Re: Il existe déjà quelque chose de beaucoup plus simple pour le même besoin

      Posté par  (site web personnel) . Évalué à 2.

      En même temps, comment veux tu nommer et différencier des composants différents ?
      Et puis bon, dans l'informatique, il y a quand même vachement d'acronymes, on en mange pas mal à toute les sauces sans que ça ait l'air de déranger beaucoup de monde.

      Ensuite, évidemment que je doit ignorer pas mal de truc, c'est un peu pour ça que je fait un journal :)

      Je vois pas pourquoi tu parle de DNS, justement PGPID ne l'utilise pas, il le remplace.

      Matthieu Gautier|irc:starmad

      • [^] # Re: Il existe déjà quelque chose de beaucoup plus simple pour le même besoin

        Posté par  (site web personnel) . Évalué à 3.

        J'aurai du lire les liens avant de répondre:

        La RFC6091 et MonkeyShere sont des projets qui ont pour but d'utiliser PGP pour établir des connections sécurisé (TLS et SSH respectivement)

        Il n'ont pas grand chose à voir avec le concept de PGPID à part qu'ils sont tout les trois basé sur PGP.
        Par contre, il sont extrêmement complémentaires dans le sens où une même clé PGP serait utilisée comme base pour identification et la sécurisation des échanges.

        Matthieu Gautier|irc:starmad

    • [^] # Re: Il existe déjà quelque chose de beaucoup plus simple pour le même besoin

      Posté par  (site web personnel) . Évalué à 1.

      Bon, je viens de me pencher sur OpenUDC. C'est très intéressant, surtout avec la présentation audio (faites où?). Ça aurait été mieux avec la vidéo pour voir ce que tu affiches mais ça aide pas mal à avoir une idée globale.
      C'est clair que vous êtes pas mal en avance sur moi. C'est pas compliqué en même temps :)

      Je mets de coté les création sheet et le transaction, vu que c'est grandement orienté "monnaie" alors que ce n'est pas le sujet de PGPID.

      Par contre, soit j'ai loupé un truc dans OpenUDC soit c'est vous qui avez mal compris l'idée de PGPID, mais en tous cas il y a une incompréhension. Je ne vois absolument pas en quoi OpenUDC fait déjà PGPID (comme le laisse sous-entendre Galuel).

      PGPID cherche à répondre à la question suivante :
      "J'ai une clé publique appartenant à un utilisateur, j'aimerai accéder au service ****(mail, chat, blog, microblogging, serveur de fichiers) associé a cet utilisateur. Où est la machine qui fournie ce service ?"

      Pour OpenUDC, la question pourrait être (bon c'est pas très adapté à OpenUDC vu comment la communauté se crée mais c'est pour l'idée) :
      "J'ai une clé publique appartenant à un utilisateur, j'aimerai savoir à quelles communautés OpenUDC il appartient et quel serveur gère cette communauté"

      Dans OpenUDC, je vois pas où cette information serait présente (je vois même pas pourquoi elle serait présente vu pourquoi OpenUDC est prévu).

      Vous avez des idées très intéressantes (typiquement les deux liens que tu pointes) et on pourrait les récupérer pour ce qui est des spécifications et sécurisations des échanges dans PGPID. Mais après, d'un point de vue fonctionnel, j'ai l'impression que OpenUDC et PGPID n'ont pas grand chose en commun.
      Je vois même pas comment OpenUDC pourrait se baser sur PGPID.

      En tout cas je continuerai de vous suivre et si je trouve un peu de temps vous risquez de me voir débarquer :)

      Matthieu Gautier|irc:starmad

  • # intéressé

    Posté par  . Évalué à 1.

    Perso ca m'intéresse. J'ai mon projet nodecast dans lequel je souhaiterais intégrer ce genre de fonctionnalité.
    Par contre il permettra en plus à l'utilisateur de stocker ses données via une API. Enfin, mais ceci est un peu particulier, il y a une gestion de workflow/workers qui permet d'enchaîner des workers qui vont faire des traitements sur une donnée.

    Par contre j'ai la chance de bosser dessus au boulot, donc ca peut avancer plus vite, en tout cas si d'autres devs (C++/Qt) rejoignent le projet :)

  • # Une fois la clé perdue ?

    Posté par  . Évalué à 6.

    Un point qui n'est pas abordé dans la présentation : le perte de la clé privée. Si PGPID est largement utilisé, fatalement, de nombreux utilisateurs perdront leur clé privée. si le service est une réussite, c'est à dire utilisable pour de nombreux services, la perte de clé est catastrophique pour son propriétaire… Serait-il possible de prévoir un mécanisme permettant d'associer une nouvelle clé a l'ancienne du type WOT (web of trust) ?

    En schématisant :
    J'ai perdu ma clé -> j'en créé une nouvelle -> je demande à mes proches de signer la nouvelle clé -> à partir d'un certain seuil, le nouvelle clé est reconnue valide pour m'identifier en remplacement de l'ancienne pour différent services, dans la DHT, une requête vers l'ancienne clé renvoie vers ma nouvelle identité.

    Points faibles :
    une coalition d'individus pourraient se mettre d'accord pour signer une nouvelle clé et voler mon identité => il faudrait que mon ancienne clé soit lié d'une manière ou d'une autre à une liste de personnes autorisés à signer une nouvelle clé en cas de perte.

    Bien sur toutes les données chiffrées avec l'ancienne clé sont définitivement perdues. Seul les données en clair et l'identification sur des services peut être récupérée.

    Autre piste :
    Bitmessage prévoit la création d'une identité à partir d'une passphrase (génération déterministe). Il est possible à partir de cette passphrase de régénérer les clés.
    Tant qu'on se souvient de la phrase, l'identité peut etre retrouvée…

    • [^] # Re: Une fois la clé perdue ?

      Posté par  (site web personnel) . Évalué à 1.

      Tu soulèves un point intéressant.

      C'est un peu la contrepartie à vouloir se passer d'un fournisseur d'identité. Si tu pers ton identité, il y a personne pour te la redonner.

      Une solution serait la reconstruction de clé (http://download.pgp.com/pdfs/PGPKeyRecon.pdf). L'idée est de «couper» ta clé privée en N morceaux (chacun protégés par un mdp) de façon que K (K<=N) morceaux soit suffisant pour reconstruire ta clé.

      Tu files les morceaux à N gens de confiance. Le jour où tu perds ta clé, t'en contacte K et tu recrée ta clé (si tu te souviens des K mdp)

      Par contre l'idée de Bitmessage me plait moyen…(en tout cas comme tu le présentes). Si il suffit d'une passphrase pour recréer une clé, toute ta sécurité ne tient qu'a cette passphrase. Si qqun la trouve il prend ton identité. Pire que ça tu n'as plus aucun moyen de l'en empêcher sauf à révoquer la clé (et ainsi perdre ton identité).
      Après je suis d'accord il faut encore retrouver la passphrase. Mais quand on connait la tête de la plupart des mdp, je ne parierais pas sur un système de ce genre à grand échelle.

      Matthieu Gautier|irc:starmad

      • [^] # Re: Une fois la clé perdue ?

        Posté par  . Évalué à 2. 

        Si il suffit d'une passphrase pour recréer une clé, toute ta sécurité ne tient qu'a cette passphrase. Si qqun la trouve il prend ton identité. Pire que ça tu n'as plus aucun moyen de l'en empêcher sauf à révoquer la clé (et ainsi perdre ton identité).

        comme tu le dis, la sécurité de ton identité dépend de ta clé privée. Dans les cas d'utilisation décris : navigateur, smartphone… etc la sécurité de la clé risque de poser problème.

        Si lé clés privés se baladent sur tout les téléphones, elles risquent de se retrouver dans la nature… C'est un problème qu'on connaît déjà avec les mails chiffrés avec PGP sur les smartphones.

        Quelles solutions envisager ? un mot de passe est il suffisant ?
        La possibilité de révoquer une clé puis de lier une nouvelle paire de clés à une identité existante offre une solution en cas de clé compromise.

        • [^] # Re: Une fois la clé perdue ?

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 23 juillet 2013 à 22:40.

          Je suis d'accord que la sécurité de la clé privé est la clé (sans mauvais jeu de mots). Mais en quoi ce serait plus "dangereux" que maintenant ?

          En quoi mettre ta clé dans ton téléphone la rend plus vulnérable que la mettre sur ton pc ?

          Qui plus est, c'est toujours plus sure que le mode actuel où tu n'as qu'un mdp pour accéder à ton compte. Pour accéder à ta clé privée et ta passphrase, un attaquant doit rentrer dans ton système. Si il y arrive, les mdp classiques sont morts eux aussi. Et avec les mdp classiques tu as plus de vecteur d'attaque: le serveur, men in the middle, …

          Quelles solutions envisager ? un mot de passe est il suffisant ?
          La possibilité de révoquer une clé puis de lier une nouvelle paire de clés à une identité existante offre une solution en cas de clé compromise.

          Il y a deux cas:

          • Soit tu t'es fait voler ta clé privée et la passphrase.
          • Soit tu as perdu ta clé ou ta passphrase, mais il n'y a pas de compromission.

          Dans le premier cas, tu n'as pas le choix, il faut révoquer ta clé. Le mieux serait que tu puisses avoir une deuxième clé qui prenne le relais.
          Dans le deuxième cas, il faut soit pouvoir la régénérer (sans qu'un attaquant puisse le faire) soit revenir au premier cas (révoquation+seconde clé)

          Conclusion: je suis d'accord avec ta dernière phrase :) On pourrai imaginer un système de ce genre:

          • Lors de la création de la clé (primaire), une seconde clé de secours (secondaire) est générée.
          • Cette clé secondaire est signée avec la clé primaire.
          • La clé secondaire est "ajoutée" dans la clé primaire comme clé de secours.
          • La clé secondaire est découpée en N morceaux. On garde les morceaux, la clé secondaire en elle même est supprimée
          • L'utilisateur file les morceaux à des gens de confiance, éventuellement en les chiffrant avec leurs clés (pas avec la primaire)
          • Une fois les morceaux distribués, il les supprime de son pc.

          En cas de perte de la clé, il suffit de récupérer K morceaux pour générer la clé secondaire et révoquer la clé primaire. À ce moment on repart pour un cycle (la clé secondaire passe primaire et on recrée un secondaire)

          En cas de vol, c'est pareil, on révoque la clé primaire et on passe à la secondaire. Si on interdit la modification de l'association primaire->secondaire, même si un attaquant récupère les infos sur la clé primaire, il ne peut pas avoir la clé secondaire.

          Matthieu Gautier|irc:starmad

          • [^] # Re: Une fois la clé perdue ?

            Posté par  . Évalué à 3.

            En quoi mettre ta clé dans ton téléphone la rend plus vulnérable que la mettre sur ton pc ?

            Le vol de PC à l'arraché, c'est plus difficile, tout de même.

            • [^] # Re: Une fois la clé perdue ?

              Posté par  (site web personnel) . Évalué à 1.

              Rhaa, c'est tellement gros que j'y ai même pas pensé…

              Dans ce cas, une solution comme celle décrite dans mon commentaire devrait être suffisante.

              Matthieu Gautier|irc:starmad

          • [^] # Re: Une fois la clé perdue ?

            Posté par  (site web personnel) . Évalué à 2.

            Il y de supers idées, mais à mon avis, il faut faire une spec. et implémenter pour se rendre compte de la faisabilité. C'est du boulot !

          • [^] # Re: Une fois la clé perdue ?

            Posté par  (site web personnel) . Évalué à 2.

            Pour complexifié un mot de passe, on peut ajouter un fichier "mot de passe". En gros, le fichier qui peut être n'importe quoi générer par l'utilisateur, et donc plus discret qu'une clef privé, est hashé avec la passe phrase. Cela rajoute un paquet d'entropie au mot de passe.

            Concernant le vol d'identité, il suffit que la clef secondaire soit planqué ailleurs, et signé par la 1er clef. Mais il faut une date de cette signature pour éviter que la clef volée permette de générer une autre clef secondaire. Ou alors, il faut que la clef diffusée soit la secondaire : la primaire ne servant qu'à générer des clefs secondaires et est planqué "ailleurs".

            Le problème du découpage en morceau est dans le protocole pour récupérer les morceaux: comment les gens de confiance peuvent vérifier que celui qui fait la demande est légitime ?

            Attention à la révocation, les protocoles sont très lourd à mettre en œuvre.

            "La première sécurité est la liberté"

            • [^] # Re: Une fois la clé perdue ?

              Posté par  (site web personnel) . Évalué à 1.

              Pour complexifié un mot de passe, on peut ajouter un fichier "mot de passe". En gros, le fichier qui peut être n'importe quoi générer par l'utilisateur, et donc plus discret qu'une clef privé, est hashé avec la passe phrase. Cela rajoute un paquet d'entropie au mot de passe.

              Je suis d'accord, mais il faut faire attention à pas trop complexifier la chose. Si un utilisateur doit stocker sa clé privée et en plus un passfile ça commence à faire beaucoup (voir trop)

              Concernant le vol d'identité, il suffit que la clef secondaire soit planqué ailleurs, et signé par la 1er clef. Mais il faut une date de cette signature pour éviter que la clef volée permette de générer une autre clé secondaire.

              C'est pour ça que j’émettais l'idée de ne pas pouvoir changer la clé secondaire associée à la primaire.

              Le problème du découpage en morceau est dans le protocole pour récupérer les morceaux: comment les gens de confiance peuvent vérifier que celui qui fait la demande est légitime ?

              Par gens de confiance, je pensais à parents, amis, collègues. Des gens qui nous connaissent personnellement et physiquement. Des gens à qui on file une clé usb en leur demandant de la garder précieusement au fond d'un tiroir.

              Pour répondre à ton autre commentaire, c'est le but d'avoir N morceaux avec seulement K (K<N) qui soient nécessaires pour refaire la clé.
              Si tes amis sont partis en vacances ou que tu t'es fâchés avec eux, tant que t'en a encore K tu t'en sort.

              (en écrivant ces lignes, je me rend compte que c'est peut être un peu trop complexe. Je vois mal madame Michu acheter N clés usb, y copier N fichiers dedans après les avoir chiffré avec la clé publique des destinataires pour enfin les filer à ses amis du club de bridge)

              Attention à la révocation, les protocoles sont très lourd à mettre en œuvre.

              Bien d'accord, mais je pense que ça peut être simplifier avec de bon outils. Si l'outil te génère automatiquement t'as clé secondaire et le certificat de révocation quand tu génères ta clé primaire, révoquer une clé peut se résumer à cliquer sur un bouton. (la plomberie derrière restant complexe)

              Matthieu Gautier|irc:starmad

              • [^] # Re: Une fois la clé perdue ?

                Posté par  (site web personnel) . Évalué à 2.

                "(en écrivant ces lignes, je me rend compte que c'est peut être un peu trop complexe. "

                C'est pour cela que je parlais de protocole, de plusieurs clefs et de plusieurs moyens de stoquer les bouts de clef (découpé avec ssss j'imagine)

                "évoquer une clé peut se résumer à cliquer sur un bouton."

                Le problème est que pour révoquer une clef, il faut que chaque client download une liste de révocation d'un serveur de clef qui peut être assez gros (donc pas forcément à jour pour sauver de la bande passante sur smartphone par exemple).

                "La première sécurité est la liberté"

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -3.

            Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Une fois la clé perdue ?

            Posté par  (site web personnel) . Évalué à 2.

            Une manière de d'éviter le défaut d'amis est d'avoir plusieurs clef secondaire, reparti avec des amis différents.

            "La première sécurité est la liberté"

          • [^] # Re: Une fois la clé perdue ?

            Posté par  . Évalué à 5.

            OpenPGP fournit déjà un mechanisme de sous-clef complètement satisfaisant sans à avoir à réinventer la roue.

            Un usage raisonné d'OpenPGP consiste à génerer une clef secondaire de signature (et une clef secondaire de chiffrement), d'exporter la partie privée clefs en détruisant la partie privée de la clef principale, et d'utiliser cette version pour un usage quotidien. La clef privée complète est quant à elle écrite sur un support passif ou sur une machine déconnectée du réseau.

            En cas de compromission, les sous-clefs sont révoqués, de nouvelles sont générés et signées par la clef principale.

            La clef principale n'est utilisé (sauf compromission des sous-clefs) que pour renouveller les sous-clefs ou pour étendre son réseau de confiance.

  • # Intéressante réflexion mais OpenUDC l'a déjà faite !

    Posté par  . Évalué à 1.

    Comme l'a expliqué jbar plus haut OpenUDC est très avancé dans cette direction. Bon.

    Je cite :

    Et bien je vous répondrai : À moins que ma boite veuille copier google et m'offrir 20 % du temps pour des projets perso, ça mettra longtemps avant d'arriver. J'ai déjà d'autres projets perso en cours et, hélas, mon temps libre a des limites.>

    Tout est là. Comment développer des projets libres, au sein d'un système monétaire privateur et donc d'une économie privatrice ?

    Faut-il sur internet attendre que comme sous le Minitiel un centre comme France Télécom donne un aval pour faire quelque chose ?

    Alors pourquoi faudrait-il se contenter d'une économie privatrice où, sans l'aval d'un centre, le centre monétaire, aucun projet d'envergure ne peut véritablement se lancer au delà de 20% du temps au mieux, alors que cela devrait représenter 80% du temps contre 20% de temps contraint au sein d'une monnaie libre ?

    Pourquoi donc se limiter à développer des logiciels libres au sein d'une informatique limitée par un OS privateur, alors qu'en développant GNU/Linux on s'en est ainsi libéré ?

    De la même façon pourquoi se limiter à développer des projets au sein d'une économie limitée par un système monétaire privateur ?

    Mais que pourrait bien être une véritable "Monnaie Libre", quand la liberté est ce qui est défini comme étant relatif aux utilisateurs de la monnaie, et où donc OpenUDC apporte une réponse basée sur OpenPGP ? Deux vidéos pour y réfléchir :

    free software and free money RMLL 2013

    Définition d'une monnaie libre Ubuntu Party PARIS 2013

  • # No free lunch

    Posté par  (site web personnel) . Évalué à 1.

    Je vois que tu cites le billet de bortzmeyer sur la difficulté à remplacer le DNS, et la solution que tu proposes est d'abandonner l'aspect "parlant/mémorable" des identifiants. C'est une idée qui revient régulièrement (e.g. For a truly acentric Internet), ta réflexion est plus centrée sur les personnes que sur les noms de domaines mais en réalité c'est le même problème.

    Je suis plutôt partisan d'abandonner l'aspect totalement décentralisé pour conserver des identifiants "parlants/mémorables", plus stables et plus simples à utiliser que des nombres aléatoires. C'est la base de ma proposition Internet Naming System.

    • [^] # Re: No free lunch

      Posté par  (site web personnel) . Évalué à 1.

      Je ne connaissait pas le texte "For a truly acentric Internet". Il est totalement dans la même idée que PGPID.
      Je pense qu'il y a un gros travail d'étude de l'existant à faire et contacter tout les projets qui pourraient être intéressés par PGPID. Si on arrive à fédérer suffisamment de projet, on peut arriver à quelque chose. Ça doit même être nécessaire si on veut que ça marche.

      Les points qui me posent problème avec les noms parlants:

      • Lequel choisir ? Est-ce que je prend PrénomNom, Nom ou PNom ? Avec quel tld (.org, .com, .fr) ?
      • Comment gérer les conflits ? Premier arrivé premier servi ? Comment tu fais pour ceux qui ont le même nom ?

      Si ta clé PGP est publiée, n'importe quel outils qui veut afficher des clés peut aussi afficher le nom associé.
      La plupart du temps on clique, copie/colle les adresses mail ou web. Peu de gens les tapes au clavier. Ça serait pareil avec PGPID.

      Matthieu Gautier|irc:starmad

      • [^] # Re: No free lunch

        Posté par  (site web personnel) . Évalué à 0.

        Je ne connaissait pas le texte "For a truly acentric Internet".

        Tu devrais parcourir les liens de DNS problems and alternatives, qui est l'équivalent en anglais du billet de bortzmeyer.

        Lequel choisir ? Est-ce que je prend PrénomNom, Nom ou PNom ? Avec quel tld (.org, .com, .fr) ?

        Dans ma proposition tu n'as pas de TLD à choisir, tu enregistres directement un nom top level.

        Comment gérer les conflits ? Premier arrivé premier servi ? Comment tu fais pour ceux qui ont le même nom ?

        Premier arrivé premier servi oui, à part si quelqu'un d'autre a une raison légitime de réclamer un nom qui a déjà été enregistré. Pour les conflits où plusieurs entités sont légitimes une solution possible est de mettre en place l'équivalent d'une page d'homonymie de Wikipedia.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.