Réunion des développeurs I2P - 7 février 2006

15:36 <jrandom> 0) salut 15:36 <jrandom> 1) État du réseau 15:36 <jrandom> 2) Avancées du réseau _PRE 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) salut 15:37 * jrandom fait signe de la main 15:37 <jrandom> notes d'état hebdomadaires publiées @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> bonjour 15:38 <jrandom> pendant que vous fouillez ce matériau oh combien passionnant, passons directement à 1) État du réseau 15:38 <jrandom> il n’y a pas eu beaucoup de changements sur le réseau en production la semaine dernière, du point de vue i2p, donc je n’ai pas grand-chose à ajouter ici 15:39 <jrandom> quelqu’un a quelque chose à soulever concernant l’état actuel du réseau ? 15:39 <KBlup> J’ai vu d’horribles pics de clients en échec quand i2p tourne longtemps… je ne sais pas si ça rentre dans 1) 15:39 <jrandom> KBlup: ça correspond à une forte charge CPU ou à une consommation de bande passante ? 15:40 <KBlup> ça se traduit par msg-delay> 10000ms :-/ 15:40 <jrandom> ah, c’est très probablement l’une des raisons pour lesquelles le réseau _PRE est développé :) 15:40 <KBlup> Je pense qu’il essaie alors d’établir de nouveaux tunnels et échoue constamment, ce qui aboutit parfois à 300+ jobs… 15:41 <KBlup> ma machine est assez puissante mais est surchargée avec ça… 15:41 <jrandom> oui, tout cela a été revu au passage pour la 0.6.1.10, tenez bon jusqu’à ce que ce soit prêt 15:43 <jrandom> ok, autre chose sur 1) ou on se dirige tranquillement vers 2) Avancées du réseau _PRE 15:43 <+Complication> 0.6.1.10 semble effectivement contenir des changements substantiels 15:45 <jrandom> oui, il y a du lourd là-dessous. À ce stade, le nouveau code de création est en place et semble fonctionner correctement, mais j’en profite maintenant pour déboguer davantage certains problèmes sous-jacents 15:46 <+Complication> Tu as mentionné qu’il fallait consacrer pas mal de temps CPU à l’avance 15:47 <+Complication> Ce coût serait-il désormais associé à la construction de n’importe quel type de tunnel ? 15:48 <+Complication> (autrement dit, avant la construction, pendant un court moment, il faudrait effectuer une série d’opérations crypto lourdes) 15:48 <jrandom> oui, toutes les demandes de construction de tunnel devront effectuer k opérations cryptographiques lourdes (où k = le nombre de sauts dans le tunnel en cours de construction) 15:49 <+Complication> Ce que je voulais demander… l’intervalle est-il simplement plus serré qu’avant, ou la quantité est-elle aussi plus grande ? 15:50 <jrandom> la quantité est à la fois plus grande, plus petite et plus serrée. Plus serrée, parce qu’elles sont toutes faites en amont. Plus grande, parce qu’on ne peut pas court-circuiter et éviter le chiffrement pour un saut si un saut antérieur le rejette, et plus petite parce que les sauts antérieurs échouent beaucoup moins 15:51 <jrandom> de plus, toutefois, contrairement aux versions précédentes, nous n’utilisons plus ElGamal/AES+SessionTag pour les requêtes de tunnel — nous utilisons un ElGamal (assez) direct 15:52 <+Complication> …et cela ne pourrait pas être pré-calculé, à moins de connaître l’ensemble final qui va réussir ? 15:52 <jrandom> cela signifie que, même si nous pouvions auparavant tricher sans opération asymétrique, nous n’essayons plus de tricher (car la tricherie elle-même exposait une classe d’attaques) 15:53 <+Complication> (ensemble de pairs) 15:53 <jrandom> hmm, cela pourrait certainement être pré-calculé, en supposant que tu connaisses les pairs du tunnel qui vont être sollicités 15:54 <jrandom> le nouveau processus de création de tunnel est effectué dans un thread séparé, afin de ne pas engorger la file de jobs principale sous charge, et pour pouvoir mieux se réguler 15:54 <+Complication> Pourrait-on aussi supposer que, sauf changement dans les connaissances disponibles, on sait à l’avance quelques-uns de ceux qu’on va solliciter si les tentatives échouent ? 15:54 <jrandom> hmm, je ne suis pas sûr de suivre entièrement 15:55 <+Complication> Ou bien les connaître à l’avance est-il inutile, puisque la structure doit être refaite depuis zéro ? 15:56 <+Complication> (c’est-à-dire : les ElGamal refaits depuis zéro, au moins) 15:56 <jrandom> ah, la structure est http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> donc oui, si le prochain saut change, l’ElGamal doit être refait 15:56 <jrandom> (si tu pré-calcules) 15:56 <+Complication> D’accord, je n’en étais pas assez sûr sur le coup 15:57 <+Complication> Maintenant je le réalise, toutefois 15:57 <jrandom> d’un autre côté, nous essayons vraiment d’augmenter notre taux de réussite de construction, et le nouveau processus de construction devrait pouvoir s’adapter pour minimiser les créations inutiles 15:58 <+Complication> Comment cela semble-t-il se comporter en pratique ? 15:58 <jrandom> (oh, cette structure a été légèrement modifiée sur la branche _PRE : http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ) 15:59 <+Complication> J’ai remarqué le détail selon lequel les chiffrages ElGamal font un bond en rapidité… 15:59 <jrandom> eh bien, le taux de réussite de construction est bien, bien plus élevé que sur le réseau en production, mais cela peut simplement être dû à la petite taille du réseau _PRE 16:00 <jrandom> oui, créer une structure à 2 sauts, par exemple, prend en moyenne 44ms sur 1120 exécutions, contre 542ms pour le temps de chiffrement ElGamal sur le réseau en production (sur 1344 exécutions) 16:02 <jrandom> (sur la même machine) 16:02 <+Complication> Ces 542 incluent-ils aussi les réessais en cas d’échec, ou seulement la construction pure ? 16:02 <+Complication> Si c’est la construction pure, il faut que je retrouve ma mâchoire inférieure… elle est quelque part par terre. :P 16:02 <KBlup> à propos de ce changement d’exposant : à quelle échelle cela affecte-t-il l’anonymat ? 16:02 <jrandom> non, c’est la statistique d’ElGamal pure, puisque le réseau en production ne construit pas la nouvelle structure du réseau _PRE 16:04 <jrandom> KBlup : anonymat ? aucun. sécurité ? d’après ce que j’ai lu, 228 bits suffisent largement pour correspondre à un ElGamal 2048 bits 16:04 * Complication ne connaît pas grand-chose aux x et y d’ElGamal 16:04 <+Complication> Pas assez pour commenter de manière significative 16:06 <+Complication> Si des chercheurs sérieux considèrent que le x plus court est suffisamment difficile, et que ces gourous de la crypto ne se sont pas enfuis en hurlant… 16:06 <@cervantes> eh bien pas seulement ça, mais aussi les implications de passer à 1024/160 16:07 <KBlup> je suppose que je dois lire l’article plus tard ;) 16:07 <+Complication> cervantes : oui, c’est mieux que ça, c’est sûr 16:08 <+Complication> D’ailleurs, quelle est l’attaque principale que ce chiffre doit repousser, et combien de temps cette attaque est-elle viable ? 16:09 <+Complication> Est-ce quelque chose qui ne te profite que si tu le casses rapidement, ou cela apporte-t-il aussi un bénéfice si tu le casses plus tard ? 16:11 <+Complication> Si je comprends bien, le secret immédiat qu’il protège est le prochain participant du tunnel, n’est-ce pas ? 16:11 <+Complication> (ou plus précisément, le suivant du suivant) 16:11 <@modulus> réunion en cours ? 16:11 <+Complication> (que seul le suivant peut connaître) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> pour un adversaire pratique (mais incroyablement puissant), il serait nécessaire de le casser durant la durée de vie du tunnel. Le casser après cette durée de vie n’aiderait que si tu avais journalisé tout le trafic réseau et cassé tous les tunnels (c’est-à-dire, après avoir cassé le chiffrement éphémère de la couche de transport et en travaillant sur le chiffrement de la couche de tunnel) 16:11 <jrandom> donc, on parle ici d’un ordre de grandeur de minutes, pas de décennies 16:12 <jrandom> (donc 1024 bits est probablement même excessif) 16:12 <@cervantes> y a-t-il un moyen de mesurer le risque de manière significative ? 16:13 <+Complication> De plus, pour un tunnel avec plus de sauts, l’adversaire devrait en casser plusieurs, non ? 16:13 <+Complication> (bien que le constructeur doive lui aussi en construire plusieurs) 16:13 <@cervantes> si nous n’avons pas besoin de plus de 1024 bits, est-il vraiment nécessaire d’en utiliser plus ? 16:14 <@cervantes> nous pouvons toujours utiliser un algo plus fort dans 3 ans quand nous aurons des ordinateurs quantiques bien plus puissants 16:14 <@modulus> jrandom : si l’adversaire savait qu’à l’heure hh:mm quelque chose d’important va être acheminé via un tunnel, est-il probable qu’il puisse le casser d’une manière ou d’une autre en journalisant ? 16:14 <jrandom> Complication : oui, ils devraient en casser plusieurs (ainsi que les clés DH protégeant la couche de transport) 16:14 <@modulus> à ma connaissance, 1024 bits est break()able avec beaucoup de puissance 16:15 <jrandom> beaucoup de puissance et une décennie 16:15 <jrandom> (ou trois) 16:15 <@cervantes> jrandom : est-ce difficile d’essayer le chiffre plus faible ? 16:15 <@modulus> j’avais l’impression que des composites 1024 bits étaient factorisables de nos jours en quelques mois. 16:15 <@cervantes> pourrions-nous déployer sur le réseau _PRE 16:15 <@cervantes> et voir si cela offre vraiment beaucoup d’avantages 16:16 <@cervantes> modulus : oui mais ils devraient en casser plusieurs 16:16 <@modulus> si c’est basé sur le domaine du logarithme discret et tout ce bazar alors je n’y connais rien 16:16 <@modulus> cervantes : aha 16:16 <jrandom> cervantes : cela nécessite des changements à beaucoup de structures, puisque nous utilisons actuellement des créneaux de 512 octets. quoique, peut-être pourrions-nous simplement remplir les 256 premiers octets avec 0x00 pour tester 16:17 <jrandom> modulus : ElGamal est basé sur le logarithme discret 16:17 <@cervantes> jrandom : ça vaut la peine de tester ? 16:17 <@modulus> oui oui, j’imaginais RSA 16:17 <@cervantes> ou mieux vaut se concentrer sur d’autres choses et y revenir si nécessaire 16:18 <jrandom> ça vaut clairement le coup d’être testé, même si pour le moment je bidouille des évaluations de la couche de transport 16:18 <+Complication> J’imagine que ça dépend de la façon dont leur calcul peut être géré dans la vraie vie. 16:18 <jrandom> (et les 44ms de temps de chiffrement sont suffisantes pour le moment, même si 4ms seraient encore mieux :) 16:19 <+Complication> Si ça tient avec les ordinateurs actuels, ça s’améliorera avec les nouvelles machines. 16:19 <@modulus> surtout s’il arrive du matériel crypto, comme on commence à en voir dans certains 16:19 <jrandom> mais bien sûr, changer ce paramètre ne se fera ni à la légère ni immédiatement. mais si quelqu’un a une bonne raison de l’éviter, merci de me contacter 16:21 <jrandom> modulus : j’ai entendu parler de puces dédiées AES et RSA, mais rien sur DH/ElGamal. d’un autre côté, si l’on considère la NSA/etc comme adversaire, qui peut construire les siennes, c’est possible 16:22 <@cervantes> ils ont des machines de crypto basées sur une technologie de donuts saupoudrés en anneau 16:23 * Complication est prêt à passer du Celeron 300 à l’Athlon 600, si cela retient la marée de donuts saupoudrés en anneau :D 16:23 <tethra> héhé 16:24 <jrandom> mmMMmm donuts 16:25 <jrandom> ok, quelqu’un a autre chose sur 2) Avancées du réseau _PRE ? 16:25 <jrandom> sinon, passons à 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication : tu veux nous donner les grandes lignes ? 16:26 <+Complication> Eh bien, ça semble fonctionner. :) 16:26 <+Complication> Il y a l’espoir d’obtenir plus de webcaches pour une redondance supplémentaire bientôt. 16:27 <jrandom> cool 16:27 <jrandom> hmm, penses-tu qu’il nous faut plus de webcaches ? il ne nous en faut pas juste un en ligne ? pas que plus fasse du mal, bien sûr 16:27 <+Complication> (si legion parvient à résoudre les mystères qui ont hanté sa tentative initiale) 16:27 <+Complication> Il y a aussi un bug mystérieux là-dedans, mais il ne mord pas fort, et j’essaie de le trouver. 16:28 <+Complication> Un seul en ligne suffit 16:28 <+Complication> En avoir plus augmente juste les chances qu’il y en ait un en ligne 16:28 <jrandom> cool 16:28 <+Complication> Parce qu’à ce stade, il ne marquera jamais les webcaches comme mauvais. Ils sont trop peu nombreux au total. 16:29 <+Complication> (cette routine s’activera s’il en existe plus de 10) 16:29 <+Complication> (si je me souviens bien) 16:29 <+Complication> Quant au bug : après un long fonctionnement, le sous-système webcache se fige parfois 16:30 <+Complication> Probablement parce qu’une requête GET d’un httpclient ne peut pas être interrompue avec succès 16:31 <@modulus> donc il doit mourir de temps en temps ? 16:31 <+Complication> C’est sans risque, et ça ne semble jamais mordre les machines qui viennent de rejoindre 16:31 <jrandom> hmm, qu’est-ce que cela signifie, fonctionnellement ? après un moment, il cessera de s’enregistrer auprès du webcache, donc les nouveaux n’obtiendront pas de références vers eux ? 16:31 <+Complication> Si ça mord une machine déjà bien intégrée, cette machine peut obtenir suffisamment de pairs à partir des pairs auxquels elle est déjà connectée 16:31 <+Complication> Donc pour l’instant l’impact semble proche de 0 16:31 <@modulus> cool 16:32 <+Complication> C’est juste curieux 16:32 <@modulus> aucune règle sur le moment où cela va échouer ou quoi que ce soit ? 16:32 <+Complication> modulus : généralement pas avant 20 heures 16:33 <+Complication> Et comme je n’ai aucun moyen de le provoquer, le débogage est un peu lent 16:33 <@modulus> :_) 16:34 <+Complication> Quoi qu’il en soit, si je le trouve, je le corrigerai, et si je ne le trouve pas, je trouverai d’autres trucs à bidouiller :) 16:34 <jrandom> :) 16:34 <jrandom> on dirait que ce n’est qu’un symptôme de quelques bugs que nous avons vus dans la bibliothèque de streaming / eepproxy, donc corriger ceux-là devrait corriger celui-ci 16:35 <+Complication> Possible 16:38 <jrandom> ok génial, beau travail Complication 16:38 <jrandom> quelqu’un a autre chose sur 3) I2Phex 0.1.1.37, ou passons-nous au fourre-tout, 4) ??? 16:41 <jrandom> (considérez que nous avons sauté) 16:41 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 16:42 <tmp> Ou retenez votre souffle pour toujours ? 16:43 <jrandom> et à jamais et à jamais 16:43 * jrandom se prépare 16:43 * jrandom *baf* clôt la réunion