rakoo a écrit 921 commentaires

Je connais l'existence des procédures standardisées de chiffrement. Mais cela implique des modifications sur les logiciels client.

Ben non, justement; bien que nous autres amateurs du libre auront une préférence naturelle pour PGP et dérivés, il y a aussi S/MIME qui est déjà reconnu par la majorité des MUA commerciaux (même l'iPhone le fait!), et qui fournit plus de fonctionnalité que PGP.

A priori:

1. Dans la mesure ou les records nécessaires a SPF, DKIM et DMARC transitent via DNS, il faut aussi s'assurer qu'ils ont voyagé sans encombre, c'est-a-dire les signer de ton cote avec DNSSEC et être sur que le destinataire fait aussi du DNSSEC et les vérifie correctement (c'est-a-dire que si les records sont invalides, l'email doit être considéré comme invalide… ce qu'aucune application ne fait aujourd'hui)

2. Effectivement, un MD5 ou meme un SHAx d'un document ne sert a rien, dans la mesure ou les pièces jointes font partie du body qui est signé par DKIM. Surtout que MD5 peut tranquillement être considéré comme cassé aujourd'hui.

Après, au niveau légal, je ne peux pas me prononcer. Même pour la solution qui me parait la plus adaptée (S/MIME) je ne sais pas quelle est sa valeur légale.

Riot games (les gens qui font LoL) utilisent XMPP pour la messagerie instantanée, les rosters et la présence. Ils ont fait un ensemble de post de blogs intéressants la-dessus:

• Aperçu du protocole
• Un petit talk avec le recapitulatif qui explique comment ils ont fait pour scaler
• Plus de détails sur l'architecture exacte qu'ils utilisent en interne

Je ne me souviens pas avoir vu un compte-rendu aussi détaillé de l'utilisation d'XMPP ailleurs.

Non mais tout le monde ici sait ce qu'est un glider; c'est a l’extérieur que les gens pourraient se demander ce qu'un caractère braille vient faire dans le texte.

Ah oui, tu as raison, je n'avais pas pensé à ça.

Je ne connais pas vraiment les autres solutions donc je ne sais pas si elles pourront t'aider. Pour rester dans ce que je connais et dans les bup et autres restic, une autre solution serait de faire un truc à la rdiff-backup:

• Le serveur de backup garde une zone "staging" avec la hiérarchie à backuper
• Le serveur de prod rsync ses données vers la zone de staging, ne transférant ainsi qu'une partie des données
• Le serveur de backup déduplique via bup, de son côté, une fois que le transfert est fini

Le gros inconvénient c'est que ça demande de la bonne synchronisation pour que les différents processus ne se marchent pas sur les pieds. En plus de ça tu stockeras toutes les données sur la zone de staging en plus du vrai backup dédupliqué. Une solution serait peut-être de faire en sorte que la zone de staging soit en fait un mount FUSE du backup qui pointe vers le dernier backup. Ou, encore plus poussé un server qui fait rsync+ssh+déduplication, qui n'existe pas mais dit comme ça ça a l'air plutôt alléchant.

J'ai pas entièrement compris la question: tu as un serveur distant que tu aimerais backuper sur un autre serveur distant, sans envoyer la totalité des données sur le réseau ?

bup et associés permettent de faire sans en feintant le système: monte le dossier de backup sur la machine à backuper. Seuls les index seront transférés du serveur de stockage vers le serveur à backuper, et dans l'autre sens seuls les blocks complètement nouveaux seront envoyés.

Ou alors j'ai pas tout saisi.

Le mieux reste encore d'aller voire la page DESIGN de bup que j'ai pointée plus haut. Pour faire simple, l’idée est la suivante:

Rolling checksum

Deja tu prends un algorithme qui te permet de calculer des rolling checksum; c'est une checksum qui permet de calculer efficacement une somme de contrôle a partir de n'importe quel offset du fichier. Imagine une fenêtre de calcul qui donne la valeur de l'octet N a l'octet M. Tu veux calculer la somme de l'octet N+1 a l'octet M+1, c'est a dire décaler la fenêtre d'un octet vers la droite. Avec une somme de contrôle "standard", il faudra tout recalculer octet par octet. Avec une rolling checksum pour calculer cette nouvelle valeur tout ce dont tu as besoin c'est:

• la valeur precedente, c'est-a-dire de l'octet N a l'octet M
• l'octet que tu rajoute, a M+1
• l'octet que tu enlèves, a N

En pratique, il y a adler32, créée par Mark Adler (le créateur de rsync, qui a mis au point cette checksum justement pour rsync vu son fonctionnement particulier) et Rabin-Karp, du même nom que l'algorithme de recherche de string dans une string (justement parce que l'algorithme a besoin d'une rolling checksum)

Trouver une limite aux chunks

Une fois que tu as une rolling checksum, tu peux calculer la somme de contrôle "a chaque octet", c'est a dire que tu calcules de 0 a W, de 1 a W+1, etc…

A chaque somme tu appliques une petite heuristique, du style "est-ce que les 13 premiers bits sont a 1". Une telle heuristique a une probabilité de 1 / 2¹³; dit autrement, la réponse devrait être oui si tu calcules cette somme 2¹³ = 8192, c'est-a-dire que après avoir avancé de 8192 octets tu devrais avoir un oui. Comme c'est juste une probabilité, en pratique tu te retrouves avec des valeurs différentes, mais en gros tous les ~8kio tu es capable de définir une limite; a partir de la, un bloc est l'ensemble des octets entre deux limites (qui devrait donc avoir une taille moyenne de 8kio, donc).

La ou il faut bien faire la différence, c'est que la rolling checksum est calcule sur une petite fenêtre, typiquement 128 octets. Si tu as trouve une limite, on dira qu'elle correspond au dernier octet de la fenêtre. Par contre tu peux être certain que la limite précédente est en-dehors de la fenêtre. Voici un schéma fait a l'arrache, dans lequel les octets sont alignes, tu vois la limite precedente, la fenêtre ou la valeur est calculée, et comme la rolling checksum matche la condition, on met une limite a la fin de la fenêtre.

____________________________________________________________________________________________________
              |                                                   [     ]|
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
            limite                                               fenêtre  limite

Et voila, tu peux calculer une somme de contrôle forte (type SHA-1, SHA-256) sur chaque bloc, qui lui donnera une identité, et ne le stocker qu'une seule et unique fois; si le même bloc se retrouve dans un autre fichier ou dans une version ultérieure du même fichier (qui n'est qu'un cas particulier d'un autre fichier, après tout), il existera déjà, pas besoin de le stocker une 2nde fois.

(note: la valeur exacte de la première somme de contrôle ne sert a rien; tout ce qu'on regarde c'est si elle passe le test des x premiers bits)

Pourquoi c'est top

Dit comme ça on ne voit pas vraiment l'avantage par rapport a, par exemple, du chunking statique tous les X octets. La ou ça fait la différence c'est si tu modifies le fichier, par exemple en plein milieu. En refaisant passer la moulinette, bien entendu le début suivra exactement la même procédure, et tu te retrouveras avec les même blocs. Par contre a l'endroit ou il y a eu une modification le contenu a change, donc la rolling checksum va changer, et la limite se retrouvera a un autre endroit. Le truc c'est que après la modification le contenu n'a pas changé, donc la rolling checksum donnera la même valeur qu'avant, et ce jusqu’à la fin du fichier. Du coup tu te retrouves avec les mêmes blocs avant et après la modification, et seule la modification crée de nouveaux blocs, le tout sans même avoir besoin de faire un traitement spécial. La grosse différence par rapport a un diff classique c'est que les deux versions sont totalement indépendantes; tu peux tout a fait supprimer les blocs uniques a une version donnée sans pour autant affecter les autres versions, a la différence des rdiff-backup et autre duplicity, ou tu as une longe chaine de backups "incrémentaux" qui se suivent tous les uns les autres depuis un backup "full". Dans les backups qui utilisent du content-defined chunking, il n'y a plus de "full" et d’"incrémentaux", tous les backups sont considérés comme full et c'est le stockage derrière qui fait de la magie.

Je suis tombé sur le sujet de la déduplication avec bup, que j'aime beaucoup parce que le code est lisible et la démarche est documentée. Je pense qu'il a plus ou moins engendré les autres qui fonctionnent de la même manière (à savoir content-defined chunking), mais je n'en suis pas sûr à 100%:

• ddar, qui n'a pas l'air d'avoir beaucoup bougé mais qui a priori marche. L'auteur a choisi d'utiliser SQLite pour stocker les métadonnées, ce qui peut s'avérer intéressant pour le futur (supprimer des blocs est par exemple
• attic, déja mentionné
• restic, encore une autre implémentation des mêmes idées
• zbackup, qui contient quelques liens vers la fin

Tout ça pour un rendement énergétique (pour l'homme) moindre que si on mangeait directement l'équivalent de la nourriture des bêtes.

Ben non, à la base si on mange de la viande c'est parce que c'est bon, ça n'a rien à voir avec l'apport énergétique. De l'autre côté je suis d'accord avec toi, la consommation que l'on fait par chez nous de viande est source de problèmes environnementaux et même de santé si on en mange trop.

Du coup j'ai d'abord pensé au tofu. […] Soit je suis infoutu de le préparer comme il faut, soit c'est vraiment fade avec une texture bizarroïde.

En même temps c'est du tofu, hein. La réponse 2 est la bonne réponse.

Donc mon FAI le vois aussi.

Pas tout à fait, tout ce que voit ton FAI est que tu utilises Whatsapp, quand et pendant combien de temps. Il manque l'information la plus juteuse, qui est de savoir avec qui tu parles.

Ok, c'était un peu rapide mais je pensais que le contexte était clair: il y a un canal chiffré end-to-end du contenu entre les participants, et un canal chiffré entre chaque participant et Whatsapp. Le contenu est invisible par Whatsapp, mais les métadonnées (qui parle avec qui, quand, combien de temps, …) leurs sont accessibles. Le monde extérieur n'a accès à rien, bien sûr.

Le contenu est chiffré mais les métadonnées sont en clair. Qui parle a qui, combien de temps, etc… Ça peut avoir l'air anodin en termes de monétisation mais avec l’arrivée des bots qui communiquent directement avec le client, ça peut être très intéressant pour Facebook de voir que tu passes ton temps a parler avec le bot de Coca-Cola…

(Grosse spéculation bien sur, je n'ai aucune donnée pour confirmer ça)

Il y a deux choses différentes:

Et il faut de vrai compétence pour ça : avoir un serveur bien sûr, mais au delà de ça, des admin, de la sécurité, des sauvegardes…

C'est pour moi une perte de temps et de moyens de chercher a héberger ses outils sur des serveurs a l'ancienne depuis que le cloud existe. Il faut penser comme une startup: quand t'es a la rache en termes de moyens, il faut concentrer le peu de temps et d'argent que tu as sur la construction de ton produit/projet, pas se perdre en infrastructure.

des personnes qui réfléchissent à l’outil le plus pertinent, démocratique, etc…

Ca c'est la vraie question, parce que l'outil doit servir la fonction. J'ai pas de vraie réponse de cote la, pour moi un *pad ou, mieux, un Google Docs (ou équivalent libre, hein, mais j'en connais pas) bordelique-mais-persistent reste la meilleure solution dans un mouvement comme celui-ci quitte a réorganiser après coup quand les choses sont en place, dans un wiki ou un site ou un blog ou autre.

En fait la vraie question dans mon message est: existe-t-il des logiciel facilement hébergeable dans le Claude sans administration qui passent a l’échelle facilement ? Des trucs qui s'"hébergent" sur un PaaS comme AppEngine plutôt que sur un VPS en gros.

Déjà, on peut lire l'annonce côté OpenWhisperSystems (ie les gens qui font Signal) par ici.

Pourquoi mettre en place ce chiffrement dans un outil privateur concurrent de celui qu'il développe dans sa propre société ?

Mon intuition: parce que en fait le boulot d'OpenWhisperSystems n'est pas Signal, mais le Protocole Signal. L'application est aujourd'hui le moyen qui rassemble le mieux sécurité et facilité d'utilisation, et toute sa puissance vient du protocole. Moxie est un cryptographe et un codeur; avec ses copains son centre d'intérêt majeur c'est avoir un protocole standard et simple de chiffrement qui peut être intégré partout.

On peut d'ailleurs le voir dans le message d'annonce originel (emphasis mine):

For the past three years, we've been developing a modern, open source, strong encryption protocol for asynchronous messaging systems, designed to make seamless end-to-end encrypted messaging possible.

Today we're excited to publicly announce a partnership with WhatsApp, the most popular messaging app in the world, to incorporate the TextSecure protocol into their clients and provide end-to-end encryption for their users by default.

Je n'imagine pas une seule seconde que l'intégration du Protocole Signal dans Whatsapp ait été faite gratuitement, et au vu de leur propre communication on sent bien que répandre le protocole est le but final. C'est même dit explicitement dans l'annonce d'aujourd'hui:

Over the next year, we will continue to work with additional messengers to amplify the impact and scope of private communication even further.

Pour le reste:

Rien ne permet d'affirmer qu'une porte dérobée n'a pas été ajoutée avec ou sans son concours

Au pire on a la même situation qu'aujourd'hui. Sinon on fait confiance à OWS comme on ferait confiance à une boîte qui fait l'audit d'un logiciel, proprio ou non, et on envisage la possibilité que le chiffrement dans les applications se répand petit à petit, que les développeurs commenceront à intégrer l'intégrer comme fonctionnalité de base et pas comme ajout facultatif (n'est-ce pas, Telegram) et que du coup les communications sont de moins en moins en clair.

Et clairement, un Debian GNU/kFreeBSD est plus proche de "l'écosystème Linux" qu'un Android, alors qu'il n'utilise pas une ligne de code du noyau Linux.

Pire: Microsoft vient de sortir son GNU/NT: pas une ligne de Linux, et pourtant tu fais tout comme sur ton Linux (enfin, Ubuntu) standard.

Certainement donc des binaires compilés pour Windows..

D'après ce post (en angliche, pardon aux puristes) c'est encore mieux que ça. En fait de la même manière que wine permet (théoriquement) de lancer un exécutable Windows dans un univers Linux, ici Microsoft a rajouté une couche appelée "Windows Subsystem for Linux", qui permet de prendre un binaire censé tourner dans un univers Linux et de l’exécuter dans Windows. C'est-à-dire qu'il n'y a pas de recompilation spécifiques, il y a juste une couche d'adaptation pour qu'en dessous ça tourne avec le Windows natif. Une sorte d'émulateur. La page Wikipédia du noyau NT (en angliche encore) donne plus de détails et devrait permettre de se faire une meilleure idée.

En tout cas c'est plutôt sympa de la part de Microsoft, on ne peut s'empêcher de penser à "Embrace->Extend->Extinguish". En tout cas si ça peut permettre à plus de gens de découvrir Linux (pas besoin d'install, de double boot, pas de "ouais mais je peux pas jouer"), et ça, saybien.

En tant que développeur, l'un des intérêts que je vois c'est de tester la compatibilité d'une application avec Windows, ou en tout cas d'en avoir une idée fiable, sans avoir besoin de payer une licence et de pourrir son ordinateur avec tout plein de mouchards.

EDIT: doublon

Je suis plutôt d'accord avec toi et avec la vague de rejet de gpg comme solution (déjà évoqué ici ou ici), j'ai compris que le problème n'est pas gpg en lui-même, mais comme toujours l'horrible expérience utilisateur. Se créer son trousseau de clés et le diffuser est un cauchemar (j'en veux pour preuve les tutos "Comment se créer une clé pgp parfaite en 723 étapes") et que pour améliorer la situation il faudra s'attaquer aux interfaces utilisateurs, et abandonner l’éducation sur le fonctionnement interne du machin, sur comment faire des keysigning parties et tout le tralala semi-social que personne ne fait et qui explique pourquoi gpg est si peu déployé (en valeur relative, hein).

D'ailleurs c'est pas un constat nouveau, Werner Koch lui-même a identifie le problème et esquisse un début de solution (plus un ensemble de bonnes pratiques qu'un logiciel en tant que tel) avec STEED:

• Un logiciel qui fait du pgp doit générer une clé correcte des le premier lancement
• Les clés doivent être diffuses via DNS, sur le domaine de l'utilisateur, de manière a ce qu'un correspondant éventuel puisse les récupérer facilement
• Un logiciel qui fait du pgp doit faire le maximum pour récupérer les clés pgp des correspondants, ou qu'elles soient, et chiffrer avec. Quitte a ce qu'elles soient fausses parce que …
• Un logiciel qui fait du pgp doit partir du principe qu'une clé est bonne a partir du moment ou c'est la première qui a été vue pour le contact en question; a partir de la on regarde si la même clé est utilisée dans les échanges futurs, et tout changement est considéré comme suspicieux. Ce mode de fonctionnement n’empêche pas de confirmer la confiance lors d'un rendez-vous physique ultérieur, bien sur.

Dans la même veine, j'irais même encore plus loin: s'il est possible d'automatiser la création de clés et leur distribution, autant créer une nouvelle cle pour chaque utilisation de manière a réduire l'impact des métadonnées et faire tourner plus fréquemment les clés afin qu'elles ne soient plus utilisées. Il est même possible de ne pas afficher le destinataire d'un message chiffré. Il y a donc ce qu'il faut pour répondre aux points 1 et 3, a condition d'avoir le bon logiciel…

… Et c'est la qu'on touche le point le plus important. La crypto dans gpg a beau être hideuse et antique, elle reste solide. Il nous faut créer des outils qui utilisent ça et fournissent l’utilisabilité qui permettront a gpg d'avoir de nouvelles utilisations un peu plus modernes et un peu plus utiles, et faire en sorte que plus personne n'ait besoin de taper "gpg" en ligne de commande.

C'est une des raisons pour lesquelles je garde cet article sous la main dans l'espoir de pouvoir jouer un peu avec du CSP en Javascript, ça donnerait quelque chose du genre:

go(function*() {
  let results1 = yield take(first())
  let results2 = yield take(second(results1))
  console.log(results2)
})

C'est un peu du async/await en première approximation, sauf qu'avec CSP on gagne la puissance des select par exemple, le tout en javascript "standard" (bon, c'est faux, il faut quand même du javascript récent avec générateurs)

Au pifomètre, 10 hébergeurs sur 10 proposent du PHP, aucun autre langage ne fait pareil (sauf peut-être perl…). Ça facilite l'installation sur hébergement mutualisé.

le principe de le confidentialité persistante, du moins telle qu'implémentée dans OTR, fait que tu as une clef temporaire, jetable, et qu'il faut être en ligne en même temps pour échanger le message, du coup c'est à cause de PFS que tu ne peux pas utiliser OTR hors ligne.

Pas exactement. Il y a deux-et-demi choses importantes à séparer:

• PFS, Perfect Forward Secrecy: La définition est simple: étant donné une clé lié spécifiquement à un correspondant sur le long terme (nécessaire pour l'identification et l'authentification) et une communication chiffrée avec quelqu'un d'autre, si la clé long-terme est leakée alors les conversations passées ne sont pas dévoilées. Par exemple, PGP, tel qu'utilisé partout (que ce soit dans les mails, dans l'ancienne XEP ou dans la nouvelle), n'a pas de PFS: si ta clé privée fuite alors toutes tes conversations seront en clair. Par contre si tu hackes le truc et que tu crées une nouvelle paire de clés asymétriques pour chaque message et que tu signes chacune de ces nouvelles paires avec ta clé identité long-terme, alors tu as du PFS: si la clé long terme fuite, il est impossible de déchiffrer les messages passés. La définition peut aller plus loin en disant que si une clé éphémère (cad celle utilisée pour chaque message) fuite, alors l'intégrité des messages précédents n'est pas compromise.
• PFS', Perfect Future Secrecy: Le terme n'est pas très répandu parce que la plupart des gens ne voient pas la différence avec le point précédent, ou alors ils pensent que l'un inclue l'autre. En partant de la même configuration, à savoir une clé identité long-terme et une clé éphémère par message: un système a de la PFS' si une clé fuite et que l'intégrité des messages futurs n'est pas compromise. Les deux ne sont pas forcément équivalents. Si par exemple tu utilises une clé symétrique pour chiffrer un message, et qu'à chaque message que tu envoies tu prends la clé précédente et tu la passe dans un KDF, alors tu auras de la forward secrecy (vu que tu passes dans une KDF il est impossible de remonter le "courant") mais pas de la future secrecy (parce que suivre le "courant" vers l'aval est trivial).
• otr, Off-the-Record: c'est quelque chose qui pour le coup vient du monde "physique", où deux participants à une conversation veulent qu'il n'y ait pas de traces de ce qu'il s'est passé. Il y a d'ailleurs une section là-dessus dans la XEP-0136 (Archive Management): l'émetteur dit simplement "n'enregistre pas ce message stp". Une autre manière de faire, c'est de donner les billes pour que techniquement, quelqu'un qui veut faire de l'otr puisse dire "c'est pas moi qui ai écrit ça, regardez, n'importe qui aurait pu écrire ça et se faire passer pour moi" (bien sûr ceci arrive après la conversation, de sorte que ceux qui discutent savent que l'autre est bien l'autre, mais qu'après coup un tiers n'en ait aucune assurance). On parle aussi de Plausible deniability. D'ailleurs le concept me plait moyen, mais c'est autre chose.

Du coup quand on parle de l'archivage c'est pas lié à PFS, qui ne regarde que le chiffrement des messages en cours de transition, mais bien à la plausible deniability, où les participants veulent à tout prix effacer les traces et pour le peu qui subsistent faire comme si ils n'avaient jamais écrit ça. Malheureusement OTR est à la fois une politique de "pas de traces svp" et un protocole répandu dans XMPP, qui fait bien de la deniability mais aussi de la PFS. À cause de ça à chaque fois qu'on parle de chiffrement de bout en bout, il y a des gens pour se plaindre que les messages ne sont pas chiffrés au bout ou qu'il reste une trace, parce qu'ils s'attendent à avoir les même garanties qu'OTR.

Un autre point: le fait qu'OTR nécessite que les deux partis soient en ligne pour discuter n'est pas lié au fait qu'OTR essaie de faire de la PFS où de la deniability, mais juste que c'est un mauvais protocole. J'en veux pour preuve la crypto dans Signal, à savoir Axolotl, qui est capable de fournir la même chose qu'OTR tout en fonctionnant hors-ligne. Bon, c'est un peu du marketing, parce que pour que ça fonctionne hors-ligne il faut quand même le support d'un serveur (que Signal fournit) pour que ça marche. Mais c'est possible.

Pour (beaucoup) plus de détails, voir les articles de blog sur les parties crypto croustillantes de Signal (ex-TextSecure) par les gens d'OpenWhisper (c'est principalement de là que je sors tout ça):

• Asynchronous Security, où ils montrent comment faire de l'asynchrone tout en ayant de la PFS
• Simplifying OTR deniability, où ils regardent un peu plus précisément à quoi ressemble la deniability d'OTR, en quoi elle est pas parfaite et comment ils l'ont amélioré
• Advanced Ratcheting, où ils rentrent en détails dans le protocol utilisé par Signal, à savoir Axolotl (cf lien précédent), et où ils font justement la différence entre forward secrecy et future secrecy, que c'est pas si simple que ça

les présences qui étaient à la base de MUC sont facultatives dans MIX. L'absence de présence est surtout utile pour réduire (de beaucoup) le trafic (et donc améliorer la durée de vie de la batterie sur appareils mobiles)

Le deuxième avantage c'est qu'on peut découpler la présence (ie connecté ou pas, disponible a la conversation ou pas) de la participation au salon de discussion. Parce que par défaut, si je ne m'abuse, lorsque l'utilisateur se déconnecte il quitte automatiquement tous les salons ou il est, et les re-rejoint (automatiquement si c'est configure pour) quand il se reconnecte. Ce qui a du sens pour un protocole oriente messagerie instantanée type IRC, mais vu que XMPP permet les communications asynchrones, ce cote est perdu avec MUC. Avec MIX, on peut dire que l'on est intéressé par un salon et recevoir les messages, que l'on soit connecte ou non… Un peu comme une mailing list, en fait.

ça veut dire que mon client xmpp doit tourner au moment où je fais la requête HTTP.

Presque: ça veut dire qu'un client xmpp qui peut recevoir des messages doit tourner. Si tu es chez ton pote, tu peux recevoir la notification sur ton téléphone avec Conversations, par exemple, répondre dessus avec "YES", et te voila connecté sur ton site.

Pour les deux autres points, c'est quelque chose de très judicieux, et c'est vrai que c'est peut-être mort pour une intégration dans un navigateur…

Ça a l'air intéressant tout ça, mais il me manque un bout: l'identification se fait auprès de qui ? Si elle se fait auprès d'un nœud en particulier, ça veut dire que je reste dépendant de ce nœud au moins pour l'authentification (le contenu peut effectivement être répliqué un peu partout). Si elle se fait auprès de n'importe quel nœud, ça veut dire que n'importe quel nœud a mon mot de passe…