Réunion des développeurs I2P, 29 juillet 2003

--- Journal ouvert Tue Jul 29 16:54:31 2003 17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003 17:11 <@hezekiah> La 51e (je crois) réunion iip-dev. 17:11 <@hezekiah> Ordre du jour : 17:11 <@hezekiah> 1.) Bienvenue 17:11 <@hezekiah> 2.) Les trucs de jrand0m 17:11 <@hezekiah> 3.) Les trucs des autres développeurs 17:11 <@hezekiah> 4.) Tout ce que nop ajoutera quand/s’il arrive 17:12 <@hezekiah> 5.) Questions et commentaires des masses toujours impatientes et crasseuses. ;-) 17:12 <@hezekiah> OK ! 17:12 <@hezekiah> Bienvenue à tous à la 51e (je crois) réunion iip-dev 17:12 <@hezekiah> Point numéro 2 ! 17:12 <@hezekiah> Les trucs de jrand0m 17:12 -!- thetower [none@anon.iip] a rejoint #iip-dev 17:12 * hezekiah tend le micro à jrand0m 17:12 <@jrand0m> sous-ordre du jour : 17:12 <@jrand0m> 2.1) Spécification I2CP & état du développement 17:12 < co> Où sont les logs de la réunion 50 ? 17:12 <@jrand0m> 2.2) Plans SDK 17:12 <@jrand0m> 2.3) crypto 17:12 <@jrand0m> 2.4) feuille de route / état du proto réseau 17:13 <@hezekiah> co: cohesion travaille à les mettre en ligne 17:13 <@jrand0m> (au fait, c'est « mic », pour microphone) 17:13 <@hezekiah> jrand0m: Désolé. :) 17:13 <@hezekiah> jrand0m: (Et cette erreur venant d’un gars du son !) 17:13 -!- luckypunk [~yetalohe@anon.iip] a rejoint #iip-dev 17:13 -!- odargur [odargur@anon.iip] a rejoint #iip-dev 17:13 <@jrand0m> 2.1) I2CP : la spéc est commitée dans CVS avec une légère modif d’un des messages (MessageStatusMessage) 17:14 <@jrand0m> Les commentaires sont toujours bienvenus sur I2CP, mais le plus tôt sera le mieux. 17:14 <@hezekiah> jrand0m: Où est la spéc dans CVS ? ... et est-ce aussi sur le CVS de SF ? 17:14 <@jrand0m> La raison du « plus tôt sera le mieux », c’est qu’on aura une implémentation cliente Java fonctionnelle d’ici vendredi. 17:14 -!- some_random_guy [~dan@anon.iip] a rejoint #iip-dev 17:14 * thecrypto croise les doigts pour ça 17:14 <@jrand0m> Plus un router local-only d’ici la fin du week-end, j’espère 17:15 <@jrand0m> non hez, seulement sur la cathedral 17:15 <@jrand0m> bien vu thecrypto. 17:15 <@jrand0m> Mise en garde : 17:15 <@hezekiah> Argh. Je n’arrive toujours pas à faire marcher CVS avec cathedral. 17:15 <@jrand0m> une partie de la crypto n’est pas à 100 %, mais tout est « stubé » pour nous laisser brancher des implémentations plus complètes ou différentes plus tard 17:15 <@jrand0m> hezekiah> on te mettra au point après la réunion. 17:15 <@hezekiah> jrand0m: Merci. :) 17:16 <@jrand0m> la spéc est dans i2p/doc/specs/data_structure_spec/datastructures.html 17:16 <@jrand0m> thecrypto> as-tu quelque chose à ajouter sur l’impl Java ? 17:16 -!- ArdVark [simple1@anon.iip] a rejoint #iip-dev 17:16 <@jeremiah> le router local-only dont tu as parlé, c’était celui en python, non ? ou il y en a aussi un en java ? 17:17 <@jrand0m> tout dépend :) 17:17 <@jrand0m> jeremiah/hezekiah> où en sont le client python et le router local-only ? 17:17 <@thecrypto> pas vraiment, à part la question crypto dont on parlera dans un instant je crois 17:17 <@jrand0m> clair thecrypto. 17:17 <@hezekiah> jrand0m: Ça avance. J’ai enfin fait marcher le transport TCP hier. 17:17 <@jeremiah> ça semble OK, je pense que la plupart dépendra de la vitesse de dev de hezekiah plus que de la mienne 17:17 <@hezekiah> jrand0m: Jeremiah a de jolies choses sur les structures de messages. 17:18 <@hezekiah> hezekiah: J’espère qu’on pourra tenir l’échéance. 17:18 <@jrand0m> cool. 17:18 <@jeremiah> aussi... vendredi c’est mon anniversaire, donc je prévois de ne pas être devant l’ordi ce jour-là 17:18 <@hezekiah> jeremiah: Compréhensible. :) 17:18 <@hezekiah> jeremiah: Et bon anniversaire d’avance. :) 17:18 <@jeremiah> merci 17:18 <@jrand0m> saut léger à l’item 2.4> quand pensez-vous qu’on pourra avoir le router python local-only ? réalistiquement ? 17:19 <@jrand0m> clair, si tu codes vendredi je te botte le cul 17:19 <@jrand0m> virtuellement, au moins 17:19 <@hezekiah> jrand0m: Je croyais que c’est ce que je code. Le router Python local-only. 17:19 <@jrand0m> oui, c’est bien ça 17:19 <@hezekiah> Eh bien l’échéance est le 1er août. 17:19 <@jeremiah> là on bosse sur la conversion messages ↔ format binaire 17:19 <@hezekiah> Ce n’est pas si dur. 17:19 <@jeremiah> oui 17:19 <@hezekiah> J’espère boucler ça d’ici un jour ou deux. 17:20 <@jrand0m> c’est vendredi :) 17:20 <@jrand0m> génial 17:20 <@hezekiah> J’espère que ce sera fini d’ici le 1er août. Réalistement ça pourrait être avec quelques jours de retard, mais j’espère pas. 17:20 <@jrand0m> ok, je m’abstiens de toucher à quoi que ce soit côté java local-only et je bosse sur la spéc réseau après que l’API client java soit figée. 17:20 <@hezekiah> Oui. Les spécs c’est bien. 17:21 <@hezekiah> Ça rend mon boulot BEAUCOUP plus facile ! :) 17:21 <@jrand0m> clair. 17:21 <@jrand0m> Je vais aussi écrire un petit topo de 2 paragraphes sur le banc de test I2CP en java 17:21 <@jrand0m> Je sors ça ce soir 17:22 <@hezekiah> jrand0m: J’adore la vitesse à laquelle tu écris ces spécs. 17:22 <@hezekiah> C’est fun. :) 17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> autre chose sur I2CP ? 17:22 <@jrand0m> lol 17:22 -!- dm [~hifi@anon.iip] a rejoint #iip-dev 17:22 <@hezekiah> Euh ... 17:22 <@hezekiah> Je veux la spéc crypto ! 17:22 < dm> bienvenue 17:22 * hezekiah boude comme un bébé 17:22 <@hezekiah> ;-) 17:23 <@hezekiah> Sérieusement, ... Je ne vois rien d’autre. 17:23 <@jrand0m> c’est l’item 2.3 17:23 <@thecrypto> j’attends toujours que 2.3 arrive 17:23 <@hezekiah> Si ça me revient, je viendrai te harceler en ligne avec des questions, jrand0m. :) 17:23 <@jrand0m> clair. 17:23 <@jrand0m> ok. 2.2) Plans SDK 17:23 <@hezekiah> Quel point de l’ordre du jour vient-on de finir ? 17:23 <@hezekiah> 2.4 ? 17:23 <@hezekiah> Et a-t-on fini 2.1 ? 17:23 <@jrand0m> 2.1 17:24 <@jrand0m> maintenant 2.2> le SDK 17:24 <@hezekiah> OK. 17:24 < dm> l’ordre du jour a des chiffres décimaux maintenant ? Je vois déjà des progrès. 17:24 <@hezekiah> Je suis retrouvé (par opposition à perdu). 17:24 <@thecrypto> on pourrait avoir 2 décimales :) 17:25 <@jeremiah> qu’est-ce qui compose le SDK à part les différentes APIs ? 17:25 <@jrand0m> le SDK c’est : l’API client (autant qu’on en a), le router local-only, une appli exemple triviale, et de la doc sur l’utilisation des APIs. 17:25 <@hezekiah> jrand0m: J’aurais raison de supposer que c’est toi qui écris la doc ? :) 17:26 <@jrand0m> J’aimerais publier le SDK ASAP, pour que des développeurs tiers (ou même seconds ou premiers) puissent écrire et tester des applications qui tourneront sur I2P, ainsi une fois le réseau opérationnel, on sera opérationnels dès le départ. 17:26 <@jrand0m> hezekiah> En fait je préférerais ne pas le faire. 17:26 <@jrand0m> hezekiah> et je dis ça pas parce que je ne veux pas documenter, mais parce que je suis trop impliqué dedans. 17:26 <@hezekiah> jrand0m: OK. 17:26 <@jrand0m> on devrait faire écrire cette doc par quelqu’un qui n’implémente PAS le code, pour qu’elle soit compréhensible par des gens qui n’ont pas écrit la spéc I2CP 17:26 <@hezekiah> jrand0m: On franchira ce pont quand on y sera. 17:26 <@jrand0m> mais s’il faut, je m’y colle. 17:26 <@jrand0m> clair. 17:27 < dm> quel intérêt les gens auraient-ils à écrire des applis sans réseau opérationnel, et comment testeraient-ils leur appli. 17:27 <@hezekiah> jrand0m: Ou alors quelqu’un qui a conçu le protocole l’écrit, puis quelqu’un qui n’a jamais bossé dessus la relit jusqu’à ce que ça soit clair ? 17:27 <@jrand0m> Ok, il a été question d’une simple appli style « talk ». 17:27 <@jrand0m> dm> les gens pourront tester avec le SDK. 17:27 <@thecrypto> en fait, je me demandais à quoi ça servirait si c’est local-only 17:28 <@jeremiah> dm: l’idée est d’implémenter un réseau simple qui n’est pas entièrement fonctionnel mais peut faire passer des messages 17:28 <@thecrypto> tu ne pourrais parler qu’à toi-même 17:28 <@jeremiah> ce n’est pas réellement local-only, mais ça n’inclut que client-router, pas le code router-router 17:28 <@jrand0m> thecrypto> tu peux parler à d’autres Destinations. I2P est indépendant de la localisation — local = distant. 17:29 <@thecrypto> d’accord 17:29 < dm> c’est sympa tout ça, je ne vois juste personne (à part vous 3-4) écrire quoi que ce soit si on ne peut tester qu’en local. Mais peu importe. 17:29 <@jrand0m> donc une appli talk peut ouvrir deux instances de l’application et parler à soi-même, etc. 17:30 <@thecrypto> mais quand on ajoute le distant, l’appli devrait marcher telle quelle 17:30 <@jrand0m> dm> oui, c’est juste un prérequis pour que d’autres écrivent des applis. 17:30 <@jrand0m> exactement. 17:30 <@jrand0m> l’appli marchera sans AUCUN changement 17:30 < co> dm: C’est une application de test. Une fois le code router-router écrit, tu pourras parler aux autres. 17:30 <@jeremiah> avoir le local-only nous permet seulement de développer en parallèle 17:30 < dm> oui, mais si l’appli suppose 10 ms de latence, et que ça finit à 12 secondes, ça ne marchera pas très bien :) 17:31 <@jrand0m> d’accord dm 17:31 < dm> des estimations de latence d’ailleurs ? :) 17:31 <@jrand0m> si on a 12 secondes de latence, on a du boulot. 17:31 <@jrand0m> mais on n’aura pas ça. 17:31 <@jrand0m> estimations : 0,6–2,7 s 17:31 <@jrand0m> pour un réseau de 5 000 000 routers. 17:31 <@hezekiah> À propos, ça me rappelle qu’on doit parler d’ElGamal. 17:31 <@thecrypto> le plus long c’est la mise en place 17:31 <@jrand0m> (voir les archives iip-dev pour les modèles rudimentaires) 17:32 < dm> plus bas ou plus haut pour des réseaux plus petits ? 17:32 <@jrand0m> hezekiah> 2.3 : crypto. 17:32 <@thecrypto> après ça le temps baisse drastiquement 17:32 <@jrand0m> dm> plus bas. 17:32 <@thecrypto> hezekiah: t’as probablement la même question que moi 17:32 <@jrand0m> thecrypto> exactement, le temps de setup est hors-ligne pour la livraison des messages [aka on prépare les tunnels avant d’envoyer des messages] 17:32 < dm> ok, je te testais ;) 17:32 <@jrand0m> heh 17:33 <@jrand0m> ok. dernière partie du SDK — l’appli 17:33 <@jrand0m> co/thecrypto : des idées sur une impl talk en java ? réalisable ? délai ? plans ? intérêt ? 17:34 <@thecrypto> une fois l’API prête, on peut probablement faire un talk en une semaine environ, 2 max, co d’acc ? 17:34 <@jeremiah> le chat pourrait être intégré en tant que router jabber, non ? 17:34 < co> Ça devrait être assez facile. 17:34 < co> thecrypto: Je suis d’accord. 17:34 <@jrand0m> jeremiah> je ne connais pas jabber, mais si jabber peut tourner sur l’api, cool 17:35 <@jrand0m> clair co & thecrypto 17:35 <@jrand0m> jeremiah> note que c’est juste une appli triviale pour une preuve de concept, pas un Kickass Anonymous IM System :) 17:35 <@jeremiah> pas encore ;) 17:35 <@thecrypto> on pourra ajouter cette fonctionnalité plus tard 17:35 <@jeremiah> ok 17:36 <@jrand0m> heh 17:36 <@thecrypto> commençons petit 17:36 * jrand0m ajoute au planning « ajouter fonctionnalité : être kickass » 17:36 < some_random_guy> heh 17:36 < some_random_guy> jolie fonctionnalité :) 17:36 -!- dm2 [~hifi@anon.iip] a rejoint #iip-dev 17:37 <@jeremiah> jrand0m: Je crois que j’ai raté ça en 2.1, mais un avis sur kademlia comme DHT ? ça demande moins d’entretien que Chord 17:37 -!- nop [nop@anon.iip] a rejoint #iip-dev 17:37 < nop> désolé 17:37 <@jrand0m> et un de ces jours il faudra qu’on mette quelqu’un sur la refonte IIP pour la faire tourner là-dessus. 17:37 -!- dm [~hifi@anon.iip] a quitté [Ping timeout] 17:37 < nop> quoi ? 17:37 < nop> qui 17:37 < nop> où 17:37 < nop> quand 17:37 < nop> ? 17:37 -!- dm2 est maintenant connu comme dm 17:37 <@jrand0m> hey, en parlant du diable 17:37 < WinBear> pourquoi ? 17:37 < WinBear> rien 17:37 < nop> je suis un ange en fait 17:37 <@hezekiah> lol 17:38 <@thecrypto> que quelqu’un passe un log à nop 17:38 < WinBear> azrel 17:38 <@jrand0m> jeremiah> kademila est une bonne DHT, et on passera certainement ça en revue ainsi que la team chord/tapestry, plus les sloppy dht, dans la spéc réseau. 17:38 <@jeremiah> jrand0m: cool 17:38 <@hezekiah> thecrypto: Je m’en occupe. :) 17:38 < nop> j’entendais parler d’une qui déchire 17:38 < nop> appelée chord/middle 17:38 -!- hif [~hifi@anon.iip] a rejoint #iip-dev 17:39 < nop> mais tu sais qui est bien à contacter c’est brandon wiley 17:39 * jrand0m !thwaps nop 17:39 < nop> je savais que ça ferait mal 17:39 <@hezekiah> lol 17:39 <@hezekiah> Qui est Brandon Wiley ? 17:39 < nop> quelqu’un avec qui je suis sûr que jrand0m a eu de nombreuses discussions 17:39 < nop> :) 17:39 < nop> quelqu’un m’email un log 17:39 < dm> Brandon est le vrai nom de jrandom, démasqué ! 17:39 <@hezekiah> J’y travaille. 17:40 <@hezekiah> Doucement, nop. :) 17:40 < nop> haha 17:40 < dm> Brandon Wiley est le premier programmeur Freenet, ayant 17:40 < dm> cofondé l’effort de développement avec l’inventeur du système, Ian Clarke 17:40 < nop> userx est ici ou là 17:40 < WinBear> tu peux parler à mon brandon wiley 17:40 <@hezekiah> OK. Ça arrive ... si mon client mail veut bien envoyer une pièce jointe de 15K. 17:41 <@thecrypto> on a beaucoup parlé :) 17:41 <@hezekiah> nop: UserX n’est ni ici ni là-bas. 17:41 <@hezekiah> OK ! 17:41 <@hezekiah> Le log est envoyé nop ! Va lire. :) 17:41 <@thecrypto> et maintenant on attend 17:41 <@jrand0m> ok, quelqu’un a des idées SDK pendant qu’on laisse une minute à nop pour rattraper ? ;) 17:41 <@hezekiah> jrand0m: Maintenant que j’ai réglé cette histoire de log ... c’est quoi kademlia ? 17:42 <@jrand0m> Encore Une DHT Académique :) 17:42 <@hezekiah> Et où puis-je avoir un lien vers la page de kademlia ? 17:42 -!- Erazerhead [JohnDoe@anon.iip] a rejoint #iip-dev 17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/ 17:42 <@hezekiah> Merci. :) 17:42 <@thecrypto> YAADHT ? 17:42 <@hezekiah> lol 17:42 <@hezekiah> Les noms de nos jours ... je te jure ! 17:43 <@jrand0m> et s’il y a du blabla informatique mentionné que vous ne comprenez pas, allez à citeseer.nj.nec.com/cs 17:43 < WinBear> klamidia ? 17:43 <@hezekiah> OK. 17:43 < nop> jrand0m: j’allais justement dire citeseer 17:43 < dm> c’est quoi l’ETA pour le SDK ? 17:44 * jrand0m évite d’injecter la chaude-pisse dans I2P 17:44 * jrand0m espère que le SDK sortira la semaine prochaine. peut-être vendredi prochain ? 17:44 * thecrypto croise une autre paire de doigts 17:45 <@jrand0m> ok. passage à 2.3) Crypto. 17:45 * hezekiah imagine thecrypto avec environ 13 jeux de doigts croisés ... et réalise qu’il doit être à court maintenant. 17:45 <@hezekiah> Yay ! 17:45 * jrand0m poke nop pour s’assurer qu’il est là 17:45 <@hezekiah> Crypto ! 17:45 <@hezekiah> J’ai un truc pour lancer le sujet. :) 17:46 <@thecrypto> j’ai aussi quelque chose 17:46 <@thecrypto> Dibs ! :) 17:46 * jrand0m n’a rien donc battez-vous 17:46 <@hezekiah> thecrypto peut commencer. :) 17:46 <@jrand0m> thecrypto> à toi 17:46 <@jrand0m> :) 17:46 <@thecrypto> Ok, sur Elgamal 17:47 <@thecrypto> On doit déterminer si on a un p et un alpha communs ou non 17:47 -!- some_random_guy [~dan@anon.iip] a quitté [BitchX: l’interface pointer-cliquer originale.] 17:47 <@thecrypto> le problème avec un p et alpha communs c’est qu’il faudrait trouver un moyen de changer les clés de tout le monde en même temps 17:48 <@jrand0m> aka : vraiment mauvais. 17:48 < co> thecrypto: Désolé, que sont p et alpha ? 17:48 <@thecrypto> l’avantage c’est qu’on peut en choisir des spécialement optimisés et la quantité de données transmises pour une clé publique est très petite 17:48 * jrand0m ne voit pas de bonne raison d’utiliser p et alpha communs, à part économiser quelques bits 17:48 <@thecrypto> co : pour faire simple, de grands nombres spéciaux 17:49 <@jrand0m> thecrypto> on peut toujours optimiser pour les p et alpha du destinataire chiffré couramment 17:49 <@thecrypto> ou je dois entrer dans une explication de comment elgamal fonctionne 17:49 <@thecrypto> jrand0m: oui 17:49 < co> thecrypto: OK. 17:49 <@thecrypto> on peut aussi faire en sorte que chacun ait un p et un alpha différents 17:50 <@jeremiah> pour ceux que ça intéresse : http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem 17:50 <@thecrypto> ça veut dire que la quantité de données transmise est beaucoup plus grande et qu’on doit trouver comment empaqueter ça 17:50 <@jrand0m> clair, merci jeremiah 17:50 <@jrand0m> beaucoup plus grande ? 17:50 <@jrand0m> Je pensais qu’avec des p et alpha variables on peut utiliser des p et alpha plus petits ? 17:51 <@thecrypto> au lieu de nombres 160 bits on parle maintenant de 2 × 1024 bits et 1 × 160 17:51 <@thecrypto> soit 2308 au total 17:51 <@hezekiah> 288 octets 17:51 <@hezekiah> Pas un drame. 17:52 <@jrand0m> ok, ce n’est pas si mal. on avait prévu 256 octets 17:52 <@hezekiah> Ces clés ne sont pas transférées si souvent, si ? 17:52 <@jrand0m> 32 de plus ne font pas mal 17:52 <@jrand0m> hezekiah> elles sont insérées dans la DHT 17:52 <@hezekiah> Ah ! 17:52 <@hezekiah> Voilà pourquoi on les voulait petites. 17:53 <@thecrypto> aussi, un autre problème d’elgamal qu’on pourrait devoir considérer 17:53 <@jrand0m> eh bien, ça ne fait pas vraiment de mal si la structure RouterInfo fait environ 10K 17:53 -!- mrflibble [mrflibble@anon.iip] a rejoint #iip-dev 17:53 <@jrand0m> ok, quoi de neuf thecrypto ? 17:53 <@thecrypto> l’expansion de message est de 2, la taille d’un chiffrement ou d’une signature est deux fois la taille du message 17:54 <@jrand0m> Le chiffrement ElG ne porte que sur la clé AES 17:54 <@jrand0m> La signature ElG ne porte que sur les hachages SHA256 17:55 <@thecrypto> ok, c’est juste quelque chose à mentionner aussi 17:55 <@hezekiah> jrand0m: Ce qui me laisse VRAIMENT perplexe. 17:55 <@thecrypto> pour revenir au problème initial, voulons-nous un p et un alpha partagés ou voulons-nous que chacun ait des p et alphas différents ? 17:55 <@jrand0m> hezekiah> hmm ? tu as lu la spéc de structure de données pour #Payload ? 17:55 <@jrand0m> des avis/questions là-dessus hezekiah ? 17:55 * dm comprend maintenant comment les DHT fonctionnent. 17:55 <@jrand0m> nop> des pensées ? 17:55 <@jrand0m> génial dm 17:55 <@hezekiah> Si une signature fait deux fois la taille des données signées, alors pourquoi la spéc IC2P dit qu’une signature fait 128 octets ? 17:56 < nop> non 17:56 < nop> p partagé 17:56 <@hezekiah> Ça ne devrait pas faire 512 ? 17:56 <@thecrypto> le hash des octets 17:56 < nop> et alphas 17:56 < dm> on dirait qu’il faut pas mal de travail à l’adhésion à une DHT, mais j’imagine que ça marche. 17:56 < nop> base partagée, p partagé 17:56 <@jrand0m> hezekiah> bits / octets. 17:56 < nop> ça éliminera beaucoup de risques 17:56 <@thecrypto> alors on le veut de quelle taille ? 17:56 <@hezekiah> Hmm 17:56 <@jrand0m> nop> dans 3 ans, voudrons-nous que tout le monde change son p et alpha en même temps ? 17:56 < nop> et ça tiendra notre protocole aux standards 17:57 <@thecrypto> puisque ça ouvre de grosses attaques sur p et alpha 17:57 < nop> jrand0m: il y a quelque chose appelé des primes « cuites », en ce moment, et c’est le moment que je considère 17:57 <@thecrypto> qui, si elles aboutissent, font tomber tout le réseau 17:57 < nop> je crois qu’on peut s’adapter avec le temps 17:57 < nop> mais une prime statique approuvée Oakley est conseillée 17:57 < nop> car elles ont été revues à fond comme sûres 17:58 < nop> et c’est une meilleure base que nos hypothèses sur la génération de primes (probables à cela) 17:58 <@thecrypto> si ce n’est pas premier, le chiffrement ou les signatures ne fonctionnent pas donc on jette 17:59 <@jrand0m> d’accord, ils ont de meilleures primes. donc quand une de ces primes est factorisée, tous ceux qui les utilisent sont exposés, correct ? 17:59 < dm> hmmm, je dois y aller. C’est loggé hein ? 17:59 < nop> jrand0m: oui 17:59 <@thecrypto> oui 17:59 < nop> jrand0m: quand ça arrive on le saura tous 17:59 < nop> je ne veux pas risquer la génération de primes 17:59 -!- dm [~hifi@anon.iip] a quitté [il a intérêt] 17:59 <@thecrypto> comment on le saura ? 17:59 < nop> en plus ça augmente notre temps de calcul 17:59 -!- hif [~hifi@anon.iip] a quitté [] 17:59 < nop> thecrypto: si tu utilises un jeu de primes Oakley standard défini, tu sauras quand il a été cassé 18:00 <@thecrypto> comment ? 18:00 < nop> ce sera une nouvelle très publique 18:00 <@jrand0m> nop> on le saura sauf si la NSA le casse. 18:00 < co> nop: Combien y a-t-il de ces primes ? S’il n’y en a pas beaucoup, les utiliser est un risque. 18:00 <@thecrypto> oui, l’écoute passive demeure une menace 18:00 <@thecrypto> et je peux faire un programme pour générer des p et des alphas et les tester en une heure 18:00 <@jrand0m> nop> ce serait très public à moins que ce soit une menace pour la sécurité nationale. 18:00 < co> Attends... non, c’est une question stupide. Laisse tomber. 18:01 < nop> c’est vrai, mais je crois, d’après de nombreux contacts dans la communauté crypto, que si c’est résolu ça le sera avant que la NSA ne le fasse 18:01 < nop> notre génération de primes ne sécurisera pas ça de toute façon 18:01 < nop> s’ils résolvent ces primes 18:01 < nop> autant trouver un nouvel algo à utiliser 18:01 <@jrand0m> ok. 18:02 < nop> s’il vous plaît utilisez du statique, ça soulagera les problèmes d’analyse crypto et réduira les risques d’erreur dans notre crypto 18:02 <@jrand0m> J’étais sur la clôture, et je suis ok pour aller avec des primes partagées connues bonnes. 18:02 <@thecrypto> ok, alors choisissons une prime 18:02 <@jrand0m> nop> on t’a toujours prévu au diagramme de Gantt pour la spéc crypto 18:02 <@thecrypto> et ont-ils des générateurs pour ces primes ? 18:02 < nop> oui 18:02 < nop> oui j’en ai 18:03 < nop> 2 18:03 < nop> c’est une racine primitive des primes que j’aurai 18:03 < nop> quelle taille de primes voulez-vous ? 18:03 <@thecrypto> je pense entre 2048–4096 18:03 <@hezekiah> On utilise une clé 2048, non ? 18:03 < nop> oui, donc utilisez une prime 4096 ou plus 18:04 <@thecrypto> parce que le côté partagé nous met en lumière 18:04 <@thecrypto> et si ça décolle, ce serait une prime très intéressante à casser 18:04 * cohesion a raté la réunion 18:04 < co> Vous utilisez cette prime dans ElGamal, n’est-ce pas ? 18:04 <@hezekiah> Donc les clés feront 4096 bits ? 18:04 <@cohesion> quelqu’un a loggé ? 18:04 < nop> co oui 18:04 < nop> non hezekiah 18:04 < nop> les clés feront 2048 18:04 <@cohesion> ok 18:04 < nop> la prime sera supérieure à 4096 18:04 * cohesion retourne à son travail 18:04 <@hezekiah> OK. Pardonnez ma compréhension horrible ici. :) 18:04 < nop> brb 18:05 <@thecrypto> p et alpha peuvent être fixes, alpha sera 2 et p sera la prime qu’on choisit 18:05 < nop> ok, laissez-moi envoyer par mail les candidates pour prime 18:05 < nop> donnez-moi quelques heures j’ai du boulot 18:05 * jeremiah part dîner, lira les logs plus tard 18:05 <@thecrypto> la clé secrète est a, un nombre entre 0 et p - 2 18:05 <@thecrypto> la clé publique est 2^a mod p 18:06 < nop> peut-on passer au prochain sujet et revenir pour que je sois là pour ça, je reviens tout de suite, je suis au travail et dois faire une tâche vite fait 18:06 <@hezekiah> OK, donc tu appelles mon ‘x’ ‘a’ 18:06 <@hezekiah> ... et mon ‘g’ ‘alpha’. 18:06 < nop> s’il vous plaît déplacez les explications d’algo en message privé 18:06 <@hezekiah> thecrypto: N’est-ce pas ? 18:06 <@thecrypto> oui 18:06 <@jrand0m> ok. donc thecrypto, nop, et hezekiah régleront les détails de l’algo plus tard. 18:06 < nop> ok 18:06 < nop> c’est sûr 18:06 <@hezekiah> OK ... donc thecrypto, as-tu fini avec ta question ? 18:06 <@thecrypto> passons à la suite 18:06 < nop> j’enverrai nos primes 18:06 <@thecrypto> ou 18:06 <@thecrypto> i 18:06 <@hezekiah> OK. À moi ! :) 18:07 <@hezekiah> Pourquoi diable utilisons-nous ElGamal pour la signature ? 18:07 <@jrand0m> ok. 2.4) feuille de route / état du proto réseau 18:07 <@jrand0m> pas encore hez :) 18:07 <@jrand0m> oh hez 18:07 <@hezekiah> Quand puis-je la poser ? 18:07 -!- dm [~hifi@anon.iip] a rejoint #iip-dev 18:07 <@jrand0m> que recommanderais-tu, sachant qu’on a des clés publiques ElG ? 18:07 <@thecrypto> quand nop revient 18:07 <@jrand0m> non, tu as raison, j’ai tort. maintenant c’est le bon moment. 18:07 < co> Sujet suivant, s’il vous plaît. 18:07 <@hezekiah> jrand0m: Eh bien, le problème est celui-ci : 18:07 <@hezekiah> la vitesse 18:08 <@hezekiah> Je jouais avec la crypto aujourd’hui, et j’ai eu un choc désagréable. 18:08 <@hezekiah> ElGamal était astronomiquement plus lent à vérifier une signature que DSA ou RSA. 18:08 <@jrand0m> hezekiah> c’est un problème d’implémentation de bibliothèque ou de l’algorithme ? 18:08 <@hezekiah> Je ne sais pas. 18:09 <@hezekiah> Mais j’ai vérifié Applied Crypto et j’ai vu qu’au moins une partie du problème vient d’ElGamal. 18:09 <@hezekiah> AC a des tableaux des temps pour signature et vérification pour DSA, RSA et ElGamal. 18:09 <@jrand0m> donc tu suggères qu’on passe à RSA pour chiffrement, déchiffrement et signature ? 18:09 <@hezekiah> Je 18:09 <@hezekiah> Je ne suggère pas grand-chose de définitif. 18:09 <@jrand0m> ...quoique on POURRAIT ajouter une seconde clé publique de signature à la structure RouterInfo 18:10 <@hezekiah> Je dis juste qu’AC indique la vérification ElGamal à 9,30 secondes. 18:10 <@hezekiah> RSA est à 0,08 seconde 18:10 <@thecrypto> pour 1024 bits 18:10 <@jrand0m> mince. 18:10 <@hezekiah> DSA est à 1,27 seconde 18:10 <@hezekiah> Maintenant tu vois mon problème. 18:10 <@hezekiah> ElGamal est super lent ... 18:10 <@jrand0m> on a besoin d’une vérif <100 ms. 18:10 <@jrand0m> si ce n’est <10 ms 18:10 <@hezekiah> ... et mon CPU est à 333 MHz. 18:11 <@hezekiah> À propos, ces calculs ont été faits sur un SPARC II 18:11 <@hezekiah> Moi j’ai un AMD K6-2 333 MHz. 18:11 <@jrand0m> un sparc 2 est une machine à 40 MHz. 18:11 <@hezekiah> Vérifier une sig ElGamal avec mon module Python (qui utilise un backend C mais sent un peu le poisson). 18:11 < luckypunk> dieu 18:11 < luckypunk> bon 18:11 <@hezekiah> jrand0m: OK. Je n’y connais rien en SPARC. 18:11 <@hezekiah> Quoi qu’il en soit, ça a pris environ 20 secondes. 18:12 <@hezekiah> Si ce n’est un peu plus. 18:12 < luckypunk> quiconque avec un proc 1–2 GHz n’a pas à s’inquiéter. 18:12 < co> hezekiah: Sur des ordinateurs modernes, donc, la vérification devrait être acceptablement rapide. 18:12 <@hezekiah> DSA et RSA étaient presque instantanés. 18:12 <@jrand0m> hezekiah> Je sais. sparc 2 était rapide en ‘92 18:12 <@hezekiah> Bref, voilà pourquoi j’en parle. 18:12 <@hezekiah> On pourrait ajouter une clé DSA, mais ça ferait 2 clés 18:12 <@thecrypto> on devrait quand même penser aux gens qui n’ont pas des machines ultra rapides 18:12 <@hezekiah> Ou on pourrait aller avec RSA. 18:12 <@jrand0m> de mémoire, notre préférence pour ElG au lieu de RSA n’était pas très tranchée. 18:13 <@hezekiah> Ou on vit avec le long temps de vérif et on utilise ElG. 18:13 <@jrand0m> thecrypto> absolument. 18:13 <@thecrypto> c’est nop qui a dit, utilisons elgamal 18:13 <@hezekiah> thecrypto: Précisément. Papa et Maman utiliseront I2P de manière transparente à terme. 18:13 <@jrand0m> on va vouloir des distros bootables pour 386, ainsi que des implémentations en applet. 18:13 <@hezekiah> Papa et Maman n’auront pas du matériel dernier cri. 18:13 < luckypunk> oh dieu 18:14 < luckypunk> tout le monde qui voudrait ça a au moins un p100 ou approchant. 18:14 < co> N’affaiblissons pas la sécurité en choisissant un algo plus faible mais plus rapide. 18:14 <@hezekiah> co: Je ne suggère pas ça. 18:14 <@thecrypto> elgamal et DSA sont équivalents 18:14 <@jrand0m> ok. donc on va reconsidérer le choix RSA/ElG. les changements de code ne devraient pas poser problème. 18:14 < luckypunk> ils peuvent souffrir. 18:14 <@hezekiah> co: RSA et DSA sont aussi réputés qu’ElGamal. 18:14 < luckypunk> lol 18:14 < luckypunk> si tu te soucies de l’anonymat 18:14 <@hezekiah> thecrypto: Et rien n’est plus faux. 18:14 < luckypunk> tu ne te soucieras pas trop de la vitesse. 18:14 <@thecrypto> hezekiah: ce sont deux implémentations du même algorithme général 18:14 < dm> l’étape évidente ici est que quelqu’un détermine avec certitude l’usage CPU des deux :) 18:14 <@jrand0m> dm> si Applied Crypto a benché la vérification RSA à 1/100 d’ElG, ça me suffit. 18:15 <@thecrypto> on peut utiliser ElG pour chiffrement/déchiffrement et DSA pour signature/vérification 18:15 <@jrand0m> les options sont passer à RSA ou ajouter une clé DSA (~256 octets de plus) à la structure RouterInfo 18:15 <@hezekiah> D’accord. Mais maintenant la DHT a 2 clés publiques. 18:16 <@jrand0m> et alors ? 18:16 < co> Ayons une seule clé publique. Ce sera moins déroutant. 18:16 <@hezekiah> co: Ce ne serait « déroutant » que pour les développeurs ... et on doit savoir ce qu’on fait. :) 18:16 <@thecrypto> je pense qu’il est temps d’attendre nop sur celle-ci aussi 18:16 <@hezekiah> D’accord. 18:16 <@jrand0m> mais si c’est 100 fois plus lent... 18:16 <@jrand0m> bref, on continuera la discussion de conception crypto hors-ligne. 18:17 <@hezekiah> jrand0m: Envoie un mail à la mailing list, d’acc ? 18:17 < luckypunk> jrand0m: dieu, ça ne me dérange pas, si tu ne peux pas attendre 40 secondes pour que ta page charge, va te faire voir. 18:17 <@thecrypto> ou après la partie principale de la réunion 18:17 <@jrand0m> mince, j’email la liste tous les jours :) 18:17 <@jrand0m> heh lucky 18:17 -!- hif [~hifi@anon.iip] a rejoint #iip-dev 18:17 <@jrand0m> d’accord. 18:17 <@jrand0m> ok> 2.4) feuille de route / état du proto réseau 18:17 -!- hif est maintenant connu comme dm2 18:18 <@jrand0m> J’ai fait très peu sur le proto réseau au-delà de répondre aux messages de co, car je bossais sur le java et I2CP. 18:18 <@jrand0m> la feuille de route semble toujours dans les temps. 18:18 <@jrand0m> des changements à la feuille de route ? 18:19 <@jrand0m> ok. s’il y en a, quand il y en a, maillez la liste. 18:19 <@hezekiah> D’accord. 18:19 -!- dm [~hifi@anon.iip] a quitté [Ping timeout] 18:19 <@jrand0m> la roadmap.xml est maintenant dans le module cvs i2p i2p/doc/projectPlan 18:19 -!- dm2 est maintenant connu comme dm 18:20 <@hezekiah> jrand0m: Laisse-moi deviner ... c’est aussi sur cathedral ? 18:20 < nop> de retour 18:20 < nop> désolé pour ça 18:20 <@jrand0m> ok, c’est tout pour ça (mais on peut revenir aux questions de protocole réseau dans la section questions). 18:20 <@jrand0m> Je n’ai plus de sous-items 18:20 <@jrand0m> hezekiah> Je n’utilise pas sf 18:20 <@thecrypto> bon, maintenant que nop est de retour on peut revenir vite fait sur la question de vitesse 18:20 <@hezekiah> D’accord. 18:21 < nop> quelle question de vitesse 18:21 <@thecrypto> Elgamal est lent à vérifier 18:21 < nop> c’est vrai 18:21 < nop> mais rsa aussi 18:21 <@jrand0m> nop> Applied Crypto a benché la vérification RSA à 1/100 d’ElG pour la signature. 18:21 < nop> hmm 18:22 <@hezekiah> RSA et DSA sont instantanés pour moi. 18:22 <@hezekiah> ElG prend 20 secondes. 18:22 < nop> DSA c’est el gamal 18:22 <@jrand0m> Donc on peut soit passer à RSA soit ajouter une clé DSA à la structure RouterInfo 18:22 < nop> DSA 18:22 < nop> j’ai quoi que ce soit avec des R dedans 18:22 < nop> ;) 18:22 * jrand0m ne se souvient pas d’une raison très forte pour ElG plutôt que RSA 18:22 * jrand0m en veut pour ça 18:22 <@hezekiah> nop: Tu nous éclaires ? Pourquoi ne pas utiliser RSA ? 18:22 <@hezekiah> Dans tous les détails croustillants. :) 18:23 < nop> pour ces raisons, et c’est discutable, mais 18:23 < dm> quelqu’un mps l’URL de iip-dev encore quand vous avez un moment. 18:23 < nop> factoriser des nombres est la façon de casser RSA 18:23 < dm> la liste iip-dev. 18:23 < luckypunk> RSA a été cassé. 18:23 < luckypunk> pratiquement. 18:23 < nop> oui, RSA 512 bits a été cassé 18:23 < luckypunk> ou c’était DES ? 18:23 < luckypunk> bah. 18:23 <@hezekiah> DES a été cassé. 18:23 < nop> c’était DES je crois dont tu parles 18:23 < co> luckypunk: Des clés de certaines tailles ont été cassées. 18:23 <@hezekiah> RSA n’en est pas encore là. 18:24 < nop> bref 18:24 < luckypunk> mais ça pourrait. 18:24 < nop> revenons à mon point 18:24 <@hezekiah> Mais la question est : une clé RSA 2048 ou 4096 est-elle sûre aujourd’hui ? 18:24 <@thecrypto> attends une seconde 18:24 < nop> des clés RSA 512 bits ont été cassées avec des ordinateurs de bureau 18:24 <@jrand0m> on regarde du RSA 2048 bits ou ElG 18:24 < nop> hezekiah: elle le serait, mais voilà la partie marrante 18:24 < nop> si tu peux factoriser des nombres 18:24 < nop> tu peux casser RSA 18:24 < nop> si tu peux calculer des logarithmes discrets tu peux résoudre RSA et EL gamal 18:24 < nop> on est plus proches de la factorisation 18:24 < nop> que du calcul de logs discrets 18:24 < nop> en ce moment 18:24 < luckypunk> les logs discrets n’est-ce pas un peu plus dur ? 18:25 <@hezekiah> Si tu peux factoriser des nombres rapidement tu peux casser RSA. 18:25 <@hezekiah> luckypunk: C’est ce que dit nop. 18:25 < luckypunk> les ordinateurs quantiques. 18:25 < luckypunk> sont presque fonctionnels. 18:25 <@hezekiah> lol 18:25 < nop> et le ratio des tailles de clés publiques pour les logs discrets est plus fort que celui des clés RSA 18:25 < nop> par exemple une clé 768 bits n’est pas conseillée par les variantes diffie-hellman, mais elle n’a pas été prouvée cassée 18:25 <@hezekiah> Donc, au final on ajoute une clé DSA. 18:25 <@thecrypto> nop, ne fais pas un bill gates, c’est factoriser un grand n où n = pq 18:25 < nop> alors que des clés RSA 512 bits l’ont été 18:25 <@thecrypto> puisque factoriser des nombres premiers est facile 18:25 < nop> merci 18:25 < nop> désolé 18:25 <@jrand0m> hezekiah> c’est ce que ça semble être. 18:26 < nop> j’essayais de faire comprendre à tout le monde 18:26 < nop> désolé 18:26 <@thecrypto> juste une petite clarification 18:26 <@jrand0m> clair nop, c’est cool, gracias 18:26 <@hezekiah> OK. 18:26 < nop> donc DSA 18:26 < nop> alors 18:26 <@hezekiah> Donc on ajoute une clé DSA ? 18:26 < nop> qui est aussi une variante diffie-hellman 18:26 <@jrand0m> ok, sur cette base, on continue les détails crypto hors-ligne. 18:26 < nop> je préfère les logs aux facteurs 18:27 < nop> ;) 18:27 <@hezekiah> À propos, que reste-t-il à poursuivre ? 18:27 < co> dm: Cette URL est http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel 18:27 <@thecrypto> hezekiah: choisir la prime magique 18:27 <@hezekiah> Oh, c’est vrai ! 18:27 < dm> merci co, j’ai trouvé les spécs de jrand0m. Maintenant tout ce qu’il me faut c’est une imprimante avec beaucoup de toner. 18:27 < nop> j’enverrai ça 18:27 <@jrand0m> hezekiah> mets à jour la spéc de structure de données, ajoute des infos pour la DSA, spécifie la taille de clé pour dsa, etc. 18:27 < nop> faisons ça hors-ligne 18:27 <@jrand0m> lol dm. 18:28 <@hezekiah> OK, tu as encore quelque chose, jrand0m ? 18:28 <@jrand0m> ok, j’en ai fini avec mes sujets. hezekiah> tu avais le # 3 ? 18:28 <@hezekiah> Oui. 18:28 < dm> hmmm. les images ne s’affichent pas. 18:28 <@hezekiah> 3.) Tout ce que nop veut ajouter à l’ordre du jour. 18:28 < dm> jrand0m: y a-t-il un endroit pour obtenir « I2P Network Spec Draft 2003.07.23 » avec les images incluses ? 18:29 < co> dm: Oui, j’ai eu ce problème aussi. 18:29 <@jrand0m> dm/co> prenez la première révision de la spéc réseau (deux semaines auparavant dans le zip), qui inclut les png. 18:30 <@jrand0m> (c’est dans cvs aussi, mais ce n’est pas encore anonyme/public) 18:30 < arj> quand est-ce que ça le sera ? :) 18:30 <@hezekiah> Wow ! 18:30 <@hezekiah> CVS est rapide maintenant ! 18:31 <@jrand0m> arj> on fait de notre mieux pour éviter le buzz, donc une fois que c’est prêt on mettra les choses publiques, mais on reste largement discret jusque-là. 18:31 < nop> hezekiah: lequel, cathedral ? 18:31 <@jrand0m> arj> cependant, tout ce qu’on fait est GPL, du moins jusqu’ici. 18:31 <@hezekiah> nop: Oui 18:31 <@hezekiah> ! 18:31 < dm> deux semaines auparavant dans quel zip ? 18:31 <@jrand0m> oh top, tu as réussi hezekiah ? 18:31 < arj> jrand0m: je voulais juste lire les dernières spécs 18:31 <@jrand0m> dm> network_spec_*.zip si je me souviens bien 18:31 <@hezekiah> jrand0m: Oui ! :) 18:31 < dm> pareil ici, avec images ! 18:31 <@thecrypto> iip-dev a la plupart 18:32 <@jrand0m> arj> http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 a tout sauf un tout petit changement. 18:32 <@jrand0m> (eh bien, sauf la Client Access Layer, qui est dans une spéc différente maintenant) 18:33 < arj> ok merci 18:33 <@jrand0m> la spéc de la client access layer est http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298 18:33 < dm> ok, et le lien vers le zip avec les images ? 18:33 <@jrand0m> ok. nop tu as quelque chose, ou on « 5) ouvre aux questions/pensées des masses » ? 18:34 -!- mihi [none@anon.iip] a quitté [Ping timeout] 18:34 * jeremiah est de retour et a lu le retard 18:34 <@jrand0m> dm> un instant, je le retrouve 18:34 <@jrand0m> http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269 18:35 < dm> merci 18:35 <@jrand0m> ok, des questions / idées ? 18:35 -!- arj [anders@anon.iip] a quitté [EOF From client] 18:35 < co> oui. 18:35 <@jrand0m> np 18:35 < co> Sommes-nous au point 5 maintenant ? 18:35 * jrand0m savait que tu en aurais co :) 18:35 < co> Actuellement, la communication entre client et router (sortant) n’est pas chiffrée. 18:35 <@jrand0m> oui, puisque nop est lent :) 18:35 <@jrand0m> (ces gens avec un travail et tout ça) 18:36 <@hezekiah> lol 18:36 < co> Supposons que j’ai un ami de confiance et que je veuille utiliser son router pour les messages sortants. 18:36 <@hezekiah> jrand0m: Eh bien, tu sais. Tout le monde ne peut pas se permettre de ne pas avoir de vie. 18:36 <@jrand0m> co> en grande partie correct. les payloads des messages sont chiffrés, mais le reste d’I2CP ne l’est pas 18:36 < co> Cela ne me mettrait-il pas en risque de voir mes messages capturés. 18:37 <@hezekiah> Ouais. Ils seraient transférés en clair sur le fil. 18:37 <@hezekiah> À moins que tu ne fasses un tunnel ssh vers son router ou autre. 18:37 <@jrand0m> si tu as un ami de confiance et que tu te connectes à son router, il peut savoir que tu as envoyé ou reçu un message, mais il ne peut pas savoir ce que tu as envoyé. 18:37 <@jeremiah> les messages ne passeraient-ils pas quand même sous chiffrement à clé publique ? 18:37 <@hezekiah> Oups. 18:37 <@hezekiah> Ma faute. 18:37 < dm> Je vais utiliser I2P pour apprendre des trucs nouveaux pour éviter que le job 9–5 (admin windows, outils VB) ne me transforme en zombie. 18:37 <@jrand0m> Je suis ok pour ajouter un support d’écoute SSL, au lieu de juste un écouteur TCP. 18:37 <@hezekiah> J’ai oublié que les clients font du chiffrement de bout en bout. 18:37 < co> Tu supposes que je fais tourner un router local de confiance, mais comme indiqué plus haut, je ne voudrais peut-être pas faire ça pour que les messages ne soient pas reliés à moi. 18:37 <@jrand0m> oui jeremiah, mais ça c’est seulement pour le payload 18:37 <@jrand0m> heh clair dm 18:37 -!- mihi [none@anon.iip] a rejoint #iip-dev 18:38 <@jrand0m> hmm. 18:38 <@hezekiah> jrand0m: Pourquoi ne pas ajouter plus tard un support pour chiffrer la comm client-vers-router ? 18:38 <@jrand0m> tu devrais vraiment toujours avoir un router local de confiance. tu peux le faire se connecter à un autre router non local de confiance aussi. 18:39 < co> Vrai, mais je voudrais appuyer la suggestion de hezekiah. 18:39 <@jrand0m> hezekiah> Je suis d’accord pour l’ajouter plus tard (où plus tard : t=0...releaseDate ;) 18:40 <@jrand0m> Je n’ai aucun problème à ajouter même un support DH+AES pour I2CP 18:40 < nop> bien 18:40 <@jrand0m> en fait, ces fonctionnalités peuvent aussi être ajoutées par router 18:41 < nop> jrand0m: je pense aussi que la rotation polymorphe des clés sera nécessaire ainsi que du trafic « chaffe » 18:41 < nop> je suis sûr qu’on verra ça dans une réunion ultérieure 18:41 < nop> juste mon commentaire 18:41 < nop> en utilisant des ensembles de clés 18:41 <@jrand0m> oui, quand on abordera la comm router-router. 18:41 <@jrand0m> (dans 1–2 semaines) 18:41 < co> nop: Actuellement, je ne vois pas de trafic chaffe dans la spéc, mais ce serait bien d’ajouter. 18:42 <@jrand0m> il y a du chaffe, au sens où les routers et les participants de tunnel se testent eux-mêmes et leurs pairs. 18:42 -!- arj [~anders@anon.iip] a rejoint #iip-dev 18:42 <@jrand0m> plus les requêtes DHT sont du chaffe par rapport aux messages payload 18:42 < nop> jrand0m: je vais plonger dans de la recherche sur l’évasion de l’analyse de trafic et éviter de livrer du clair connu 18:42 <@jrand0m> et les transports individuels auront leur propre style de chaffe (par ex. le transport http interrogera google pour « cute puppy dogs » périodiquement, ou autre) 18:43 < nop> bon, ce chaffe est sympa, mais je veux aussi dire du chaffe chiffré 18:43 < nop> ça aide à faire tourner les clés de session 18:43 < nop> et à garder ton nœud occupé même inactif 18:43 < dm> peut-être changer ça vers hard child porn pour un chaffe plus réaliste 18:43 <@jrand0m> clair. 18:43 < dm> je plaisante ! 18:43 <@hezekiah> dm: Bien. Sinon je devrais te !thwack. 18:43 <@hezekiah> :) 18:44 <@jrand0m> DHT (lien chiffré) et messages de test (free route mix, à la onion/garlic) n’auront pas de problèmes de clair connu 18:44 < nop> puisque les nouveaux nœuds auront moins de trafic au démarrage 18:44 <@jrand0m> plus on aura du support pour des transports à débit constant 18:44 < nop> garlic déchire 18:44 < nop> :) 18:44 < nop> jrand0m: style DC net :) 18:44 * jrand0m va se faire des pâtes avec plein d’ail après cette réunion 18:45 < nop> jrand0m: je parlais de garlic routing 18:45 <@hezekiah> lol ! 18:45 <@jrand0m> je sais ;) 18:45 < nop> jrand0m: de toute façon, le débit constant peut être forcé avec le chiffrement par blocs puisque AES génère des blocs 128 bits 18:45 < nop> ;) 18:45 < nop> donc on pourrait juste bourrer toutes les données à 16 octets par message 18:45 <@jrand0m> co> mes réponses à ton mail faisaient sens ? 18:47 <@jrand0m> *ping* 18:47 <@hezekiah> *pong* 18:47 <@thecrypto> *pong 18:47 <@thecrypto> * 18:47 <@jrand0m> d’autres questions de quelqu’un, ou mon iproxy s’est déconnecté ? 18:47 <@jrand0m> heh clair 18:47 <@hezekiah> thecrypto: Paquet fragmenté ! 18:47 <@hezekiah> lol 18:48 <@thecrypto> j’ai perdu la fin là 18:48 <@thecrypto> MTU plus petit ici :) 18:48 <@hezekiah> jrand0m: Bon, je n’ai pas de questions. 18:48 < co> jrand0m: Oui, les réponses étaient claires. 18:48 < co> Je n’ai plus de questions. 18:48 < dm> Je créerai des questions quand je lirai les spécs demain. 18:49 <@jrand0m> eh bien, j’espère que vous en aurez plus plus tard :) 18:49 <@jrand0m> génial dm 18:49 < dm> génial au début peut-être. 18:49 < dm> bon, j’y vais. bonne chance à tous ! 18:49 -!- dm [~hifi@anon.iip] a quitté [] 18:50 <@jrand0m> on a toujours la grosse période de relecture par les pairs de 2 semaines dans le planning, mais les relectures avant sont appréciées (même si tous les détails ne sont pas encore posés) 18:51 <@jrand0m> ok. d’autres questions, ou on boucle la #52 comme une réunion de 102 minutes ? 18:52 <@thecrypto> #51 18:52 <@hezekiah> Euh, je lis 1:57 minutes. 18:52 <@hezekiah> Duh. 18:52 <@hezekiah> Je suis stupide 18:52 <@hezekiah> Ne faites pas attention à moi. 18:52 <@hezekiah> Je n’ai pas de questions ... 18:52 <@hezekiah> Des questions ! 18:52 * jrand0m n’a jamais su compter... 18:52 <@hezekiah> Parlez maintenant ou taisez-vous jusqu’à mardi prochain ! 18:52 <@hezekiah> Une fois ! 18:53 <@hezekiah> ... Deux fois ! 18:53 <@thecrypto> Adjugé au gars en chemise boutonnée 18:53 <@hezekiah> Vendu ! 18:53 * jrand0m va à la cuisine se faire un dîner très en retard 18:53 <@jrand0m> gracias srs y srtas 18:53 <@hezekiah> Au revoir tout le monde ! 18:53 <@jeremiah> Je devrais checkout la source avant de partir 18:53 <@hezekiah> À mardi prochain ! --- Journal fermé Tue Jul 29 18:53:55 2003