Réunion des développeurs d'I2P - 28 décembre 2004

13:06 <@jrandom> 0) salut 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) salut 13:06 * jrandom fait coucou 13:06 <+postman> *coucou* 13:06 <ant> <jnymo> bonjour 13:06 <@jrandom> notes d’état succinctes publiées sur http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> on passe à 1) 0.4.2.5 13:07 <@jrandom> comme mentionné, tout fonctionne plutôt bien 13:08 <+postman> ouais, assez impressionnant 13:08 <+postman> plus aucun timeout de lease sur mes systèmes 13:08 <@jrandom> beaucoup de gens ont vu ce que tu as vu jnymo, avec 0 tunnels participants, en grande partie grâce à l’efficacité accrue et à la sélection des pairs (où maintenant on sait qu’il faut sucer la bande de la machine de postman ;) 13:08 <ant> <jnymo> moi aussi 13:08 <@jrandom> sympa 13:08 <ant> <jnymo> et les eepsites sont réactives 13:09 <+postman> :) 13:09 <ant> <jnymo> merci postman :) 13:09 <+postman> la bande passante totale est 29kb / 30.1kb/s 13:09 <frosk> tout le monde se sent moins aimé, mais en réalité l’amour est juste utilisé plus efficacement 13:10 <ant> <jnymo> wow 13:10 <@jrandom> d’enfer, postman 13:10 <mule2> je ne pense pas que ce soit l’idéal. il vaudrait mieux avoir un peu de trafic via tous les nœuds 13:10 <ant> <jnymo> je pourrais gérer ça si seulement on m’aimait :( 13:10 <+postman> yep 13:10 <mule2> comme une forme de trafic de couverture 13:10 <@jrandom> mule2 : c’est une question de charge bien inférieure à la capacité de notre réseau 13:11 <@jrandom> je ne pense pas qu’on puisse garder la capacité supérieure à la charge très longtemps 13:11 <ant> <jnymo> mule2, postman agit aussi comme un mixeur.. donc c’est difficile de dire où vont tes paquets après être entrés 13:11 <@jrandom> donc je ne suis pas trop inquiet de ne pas pousser de données via les pairs plus lents 13:12 <mule2> une optimisation un peu moins parfaite serait probablement bonne pour l’anonymat 13:12 <@jrandom> d’un autre côté, ça incite aussi plus de gens à (implémenter &) utiliser i2pcontent, pour qu’ils puissent faire du miroir et gagner du trafic de couverture ;) 13:12 <jdot__> est-ce un problème de sécurité qu’un seul router gère presque tous les tunnels ? 13:13 <@jrandom> mule2 : commençons par faire au mieux, ensuite on pourra discuter de comment le dégrader volontairement 13:13 <@jrandom> jdot__ : on n’a pas un seul router qui gère tout le trafic, mais on voit des regroupements de routers sur des connexions très rapides (colo, etc.) qui gèrent plus que les utilisateurs en bas débit/dsl/câble 13:14 <@jrandom> plus la réduction des échecs de tunnel signifie qu’on bascule et explore moins 13:14 <mule2> peut-être qu’une distribution du trafic serait possible, tant qu’on est loin des limites des routers 13:14 <@jrandom> oui, le rejet probabiliste de tunnel est dans le router et peut être activé selon les limites de bande passante du router 13:15 <ant> <jnymo> oui, mais un débit si élevé sur le nœud de postman rend plus difficile l’analyse de son nœud.. donc il est peut-être plus sûr d’envoyer via lui que si tous les nœuds faisaient 1 KB/s.. 13:15 <@jrandom> (mais si postman ne met aucune limite, on ne peut pas rejeter en fonction d’un % de ça ;) 13:15 <ant> <jnymo> des regroupements de nœuds plus rapides provoquent une sorte de structure en cascade de mix, non ? 13:15 <@jrandom> oui, c’est une façon de le voir 13:15 <lektriK> puis-je fermer la fenêtre Start I2P ? 13:15 * postman est vraiment désolé de NE PAS restreindre sa bande passante 13:16 <@jrandom> lektriK : malheureusement, pas vraiment, sauf si tu démarres i2p comme un service (See http://localhost:7657/configservice.jsp) 13:16 <@jrandom> heh postman t’inquiète, on allégera la charge sur ton router si/quand on atteint la capacité de ton router 13:17 <lektriK> Ok, ça dit "service started" 13:17 <lektriK> je peux fermer maintenant ? 13:17 <@jrandom> lektriK : non/oui - tu peux arrêter ton router puis le redémarrer via start->run->"net start i2p" 13:18 <mule2> en l’état, quelques très gros routers pourraient gérer tous les tunnels, supprimant tout trafic de couverture depuis les autres routers. mais continuons après la réunion. 13:18 <mule2> je ne veux pas me plaindre que le réseau se comporte trop bien :) 13:18 <@jrandom> hehe 13:20 <@jrandom> il y aura d’autres explorations avec la 0.5, même s’il y a des questions d’anonymat quand on s’étend trop. il y aura plus de détails à régler pour la 0.5 (et dans le doc qui pourrait être prêt la semaine prochaine en première ébauche) 13:21 <@jrandom> bref, quelqu’un d’autre a quelque chose à évoquer pour la 0.4.2.5 ? 13:21 <@jrandom> ou on passe brièvement à 2) 0.5 ? 13:21 <+postman> on passe 13:21 <ant> <jnymo> très stable... on passe 13:21 <@jrandom> considéré comme fait 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> ouais. encore en cours. plus d’infos quand ce sera prêt. 13:22 <ant> <Quadn-werk> Sir Arthur C. Clarke est vivant :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5 est excitant 13:22 <@jrandom> ok, c’est tout ce que j’ai à dire là-dessus - des questions / points à discuter ? 13:23 <@jrandom> oui, il y a clairement des refontes importantes en cours, basées sur ce qu’on a appris ces 16 derniers mois 13:23 <@jrandom> (ou merde, 18) 13:23 <+postman> jrandom : donc 0.5 utilisera surtout un nouveau système de gestion des tunnels ? 13:23 <ant> <Quadn-werk> arg, j’espère que je n’ai pas interrompu la réunion :/ 13:23 <+postman> wow 13:23 <ant> <Quadn-werk> désolé heh 13:23 <ant> <jnymo> heh. j’avais une suggestion 13:24 <@jrandom> ouais postman, nouvelle gestion, mutualisation et construction 13:24 <+postman> quadn : regarde ce que tu as fait - ton collage a causé un netsplit :) 13:24 <@jrandom> salaud ! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> quoi de neuf jnymo ? 13:24 <+postman> jrandom : chaque tunnel sera-t-il encore une destination locale séparée ? 13:25 <@jrandom> hein ? 13:25 <@jrandom> il n’y aura aucun changement à i2ptunnel en 0.5 13:25 <+postman> jrandom : ok 13:25 <@jrandom> (du moins, je n’en prévois pas) 13:26 <mule> postman monte une attaque par intersection ? 13:26 <ant> <jnymo> pour ceux qui n’ont /aucune/ utilisation de bande passante.. et si on laissait des routers construire des tunnels avec eux dedans.. comme ABCABCA 13:26 <+postman> mule : non, c’était la faute de quadn :) 13:26 <ant> <jnymo> et ça serait un tunnel factice 13:27 <@jrandom> jnymo : annoncer un router en disant "hey j’ai de la bande passante en trop, utilisez-moi" est un jeu dangereux 13:27 <+postman> jrandom : quels problèmes seront alors résolus par la refonte (en deux mots) 13:27 <ant> <jnymo> pas sûr que je voulais dire ça, jrandom 13:27 <@jrandom> mais a priori on aura deux ensembles de tunnels - les normaux, et des exploratoires, où ces derniers sont construits à partir de pairs choisis au hasard et non défaillants 13:28 <ant> <jnymo> jrandom : je parlais de créer un tunnel factice, et de me mettre au milieu de ce tunnel juste pour simuler un peu de trafic 13:29 <@jrandom> postman : rendre beaucoup plus difficile la corrélation des pairs dans un tunnel, permettre aux clients de choisir effectivement leur longueur de tunnel sortant, et fournir les options nécessaires pour traiter l’attaque du prédécesseur (avec divers compromis) 13:29 <@jrandom> (oh, et améliorer les performances en supprimant beaucoup d’appels modPow) 13:29 <+postman> ok merci 13:29 <ant> <jnymo> postman : et des IDs de tunnel par saut, c’est important 13:30 <+postman> modpow ? 13:30 <@jrandom> ah jnymo. oui, il y a beaucoup de potentiel pour diverses générations de trafic de bourrage (chaff) 13:30 <ant> <jnymo> comme ça, aucun deux nœuds non voisins ne peuvent savoir qu’ils sont sur le même tunnel, postman 13:30 <@jrandom> postman : exponentiation modulaire, gros usage CPU & gaspillage mémoire 13:31 <ant> <jnymo> jrandom : ok cool 13:31 <+postman> ok 13:31 <scintilla> jrandom, concernant le fait de laisser les clients choisir la longueur du tunnel : y aura-t-il quelque chose pour empêcher les gens de la monter à 99 (ou autre) ? 13:31 <ant> <jnymo> puissance CPU 13:32 <@jrandom> si nécessaire on peut ajouter du hashcash, mais des tunnels excessivement longs finiront de toute façon par échouer 13:32 <scintilla> ah bon point 13:32 <@jrandom> on pourrait même ajouter une astuce - exiger qu’un tunnel ait un message de tunnel valide envoyé à travers lui dans les 60s suivant sa création pour être ‘valide’ 13:33 <@jrandom> (donc si le tunnel faisait 20 sauts, il leur faudrait trop de temps pour construire tous ces sauts) 13:33 <scintilla> c’est une super idée - ça évitera que de telles absurdités persistent longtemps 13:33 <@jrandom> mais ça c’est contre les hackers. les utilisateurs normaux utiliseront juste l’interface exposée 13:34 <ant> <jnymo> d’accord, que tu limites quelque part, non ? 13:34 <ant> <jnymo> on aura plus que le maximum 2 tel qu’il est maintenant, hein ? 13:34 <@jrandom> oui, comme le menu déroulant du nombre de sauts sur /configclients.jsp ou /i2ptunnel/edit.jsp 13:35 <@jrandom> oh je pensais que le max était 3 maintenant ? ok, mais oui, plus que 2 sera disponible 13:35 <ant> <jnymo> 3 tunnels, 2 sauts 13:35 <@jrandom> ah ok 13:35 <@jrandom> ouais, 0.5 ajoutera quelques nouveaux réglages importants, comme le fait de randomiser ces longueurs, et de combien, etc. 13:36 <frosk> le max est bien 3 13:36 <ant> <jnymo> hmm 13:37 <@jrandom> ah c’est 3 sur /configclients 2 sur i2ptunnel 13:37 <frosk> la 0.5 est toujours prévue pour janvier ? 13:37 <ant> <jnymo> ah 13:37 <@jrandom> oui frosk 13:37 <frosk> super 13:37 <@jrandom> je ne traînerai pas beaucoup plus sur la lib de streaming, promis ;) 13:37 <frosk> ça semble juste être beaucoup de travail :) 13:38 <@jrandom> en fait ça va, la partie dure c’est d’avoir les bons algos 13:38 <@jrandom> (les détails, pfff ;) 13:39 <+postman> frosk : et tout est déjà sur papier 13:39 <+postman> :) 13:39 <ant> <jnymo> heh 13:39 <frosk> vrai :) 13:39 <@jrandom> en grande partie ouais ;) 13:39 <@jrandom> ok, quelqu’un a autre chose pour 2) 0.5 ? 13:39 <ant> <jnymo> nada 13:39 <frosk> el zilcho 13:40 <@jrandom> ok, on enchaîne sur le bon vieux 3) ??? 13:40 <@jrandom> salut 13:40 <@jrandom> quelqu’un a autre chose à mettre sur la table ? 13:41 <ant> <jnymo> postman : il n’y a pas d’inproxies smtp/pop3 sur i2pmail.org si ? 13:41 <cat-a-puss> Je vois toujours des délais bizarres côté client... 13:41 <+postman> hrm non 13:41 <frosk> c’est là que je donnerais la bouteille de vin de félicitations pour une belle année de développement ;) 13:41 <+postman> jnymo : POP3 n’est disponible que pour les utilisateurs i2p 13:41 <@jrandom> cat-a-puss : ah j’ai raté ces messages quand tu étais là plus tôt 13:41 <+postman> jnymo : il Y A un SMTP inproxy comme MX pour le domaine i2pmail.org 13:42 <@jrandom> frosk : à la tienne 13:42 <ant> <jnymo> oui oui.. c’est cool.. 13:42 <cat-a-puss> Genre je peux avoir deux Destinations locales et quand l’une essaie de se connecter à l’autre il y a un délai et ce n’est pas lié au CPU 13:42 <mule> cat-a-puss : tu donnes aussi le chèque bonus ? 13:42 * postman offre un bon whisky 13:42 <@jrandom> cat-a-puss : d’accord, tu as vu un délai de .5-1.0s, non ? 13:42 <cat-a-puss> mule : quoi ? 13:42 <cat-a-puss> jrandom : ouais 13:43 <@jrandom> cat-a-puss : parfaitement normal, c’est le SYN différé 13:43 <mule> désolé, le commentaire venait de frosk 13:43 <ant> * jnymo sort ce mauvais cubi de vin 13:43 <mule> frosk : tu donnes aussi le chèque bonus ? 13:43 <@jrandom> (il attend un peu avant d’envoyer le SYN et l’ACK associé au cas où il y aurait plus de données à regrouper) 13:43 <scintilla> oh pour info, je devrais bientôt recevoir le livre avec la spécification de l’algorithme Fortuna... en attendant j’expérimente pour essayer de collecter de l’entropie en java sans détruire une machine 13:44 <@jrandom> ah génial 13:44 <ant> <jnymo> mmm, quelqu’un voulait monter des attaques contre i2p 13:44 <ant> <jnymo> c’était qui ? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> Y a-t-il un moyen d’éviter ça, ou je dois simplement essayer d’éviter les connexions de courte durée quand je peux ? 13:45 <ant> <jnymo> des nouvelles à ce sujet, jr ? 13:45 <@jrandom> cat-a-puss : oui il y a des options que tu peux passer lors de la création de l’I2PSocketManager, laisse-moi les retrouver 13:46 <@jrandom> jnymo : c’est une attaque par intersection à long terme, donc après un moment il aura des données pour aider à identifier sur quels routers se trouvent certaines eepsites. je suis sûr qu’il va nous écrire un résumé une fois qu’il aura ça 13:46 <ant> <jnymo> scintalla : c’est quoi l’algorithme fortuna ? 13:46 <ant> <jnymo> jrandom : ok 13:48 <@jrandom> cat-a-puss : i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> c’est un générateur de nombres pseudo-aléatoires sécurisé cryptographiquement... quelque chose d’absolument essentiel pour un chiffrement digne de confiance 13:48 <jdot__> quelqu’un s’est déjà porté volontaire pour cette attaque ? 13:48 <@jrandom> cat-a-puss : ensuite assure-toi de flush() après avoir write() sur l’I2PSocket 13:48 <@jrandom> jdot__ : ouais, il a 7 sites volontaires 13:48 <cat-a-puss> jrandom : ok 13:49 <ant> <jnymo> concernant le grand débat sur le nommage.. 13:49 <ant> * jnymo ricane 13:49 <@jrandom> oh et i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> ou même =100 13:49 * jrandom lance de la boue sur jnymo 13:50 <ant> <jnymo> en fait je bosse avec x500 et mon job me laisse avoir des winSevers gratuits 13:50 <ant> <jnymo> donc, peut-être que je mettrai en place un DNS central à des fins de test d’ici un mois ou deux 13:51 <@jrandom> heh, avoir un serveur de nommage centralisé hébergé sur un .mil serait foutrement hilarant 13:51 <ant> <jnymo> même si hacker des adresses i2p dans winserver peut ne pas être trivial.. je sais pas 13:51 <ant> <jnymo> heh.. dnsalias est la solution 13:52 <@jrandom> nano a fait du super boulot, intégrant dnsjava avec i2p 13:52 <ant> <jnymo> ooooh 13:53 <@jrandom> va voir nano.i2p pour plus de détails 13:53 <ant> <jnymo> et personne n’allait me le dire.. ah, merci 13:53 <@jrandom> mais, comme dit la dernière fois, les gens devraient poster leurs réflexions et idées sur le nommage sur le wiki 13:54 <@jrandom> ok, quelqu’un d’autre a quelque chose à soulever pour la réunion ? 13:55 <ant> <jnymo> nope 13:57 <@jrandom> ok dans ce cas 13:57 * jrandom s’élance 13:57 * jrandom *baf* clôt la réunion