I2P Entwicklertreffen - 07. Februar 2006

15:36 <jrandom> 0) hi 15:36 <jrandom> 1) Netzstatus 15:36 <jrandom> 2) _PRE-Netz-Fortschritt 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) hi 15:37 * jrandom winkt 15:37 <jrandom> Wöchentliche Statusnotizen veröffentlicht unter @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> hallo 15:38 <jrandom> Während ihr euch durch dieses ach so spannende Material wühlt, springen wir rüber zu 1) Netzstatus 15:38 <jrandom> Im Live-Netz hat sich aus I2P-Sicht in der letzten Woche nicht viel geändert, daher habe ich hier nicht viel hinzuzufügen 15:39 <jrandom> Hat jemand etwas zum aktuellen Netzstatus? 15:39 <KBlup> Ich habe schlimme Spitzen von ausfallenden Clients gesehen, wenn I2P lange läuft... keine Ahnung, ob das zu 1) passt 15:39 <jrandom> KBlup: korreliert das mit hoher CPU-Last oder Bandbreitenverbrauch? 15:40 <KBlup> führt zu msg-delay> 10000ms :-/ 15:40 <jrandom> ah, sehr wahrscheinlich einer der Gründe, warum das _PRE-Netz entwickelt wird :) 15:40 <KBlup> Ich denke, es versucht dann neue tunnels aufzubauen und scheitert ständig, was manchmal in 300+ jobs resultiert... 15:41 <KBlup> Meine Maschine ist ziemlich stark, aber damit überlastet... 15:41 <jrandom> jau, das wurde auf dem Weg zu 0.6.1.10 alles überarbeitet, haltet durch, bis das fertig ist 15:43 <jrandom> ok, noch etwas zu 1), oder sollen wir gemütlich rüber zu 2) _PRE-Netz-Fortschritt schlendern 15:43 <+Complication> 0.6.1.10 scheint tatsächlich erhebliche Änderungen zu enthalten 15:45 <jrandom> ja, hier steckt eine Menge drin. Der aktuelle Stand ist, dass der neue Erstellungscode vorhanden ist und offenbar korrekt funktioniert, aber ich nutze jetzt die Gelegenheit, einige der zugrunde liegenden Probleme weiter zu debuggen 15:46 <+Complication> Du hast erwähnt, dass man im Voraus viel CPU-Zeit aufbringen muss 15:47 <+Complication> Wäre diese Kosten nun mit dem Aufbau jeglicher Art von tunnel verbunden? 15:48 <+Complication> (heißt: vor dem Aufbau, für kurze Zeit, müsste man einen Schwung schwere Krypto berechnen) 15:48 <jrandom> ja, alle Anfragen zum Erstellen von tunnels müssen k aufwendige Krypto-Operationen durchführen (wobei k = Anzahl der Hops im zu bauenden tunnel) 15:49 <+Complication> Was ich fragen wollte ... ist das Intervall nur enger als zuvor, oder ist die Menge auch größer? 15:50 <jrandom> Die Menge ist sowohl größer, kleiner als auch straffer. Straffer, weil alles im Voraus erledigt wird. Größer, weil wir nicht mehr abkürzen und die Verschlüsselung für einen Hop auslassen können, wenn ein früherer Hop sie ablehnt, und kleiner, weil frühere Hops viel seltener fehlschlagen 15:51 <jrandom> außerdem verwenden wir – anders als in früheren Releases – für die tunnel-Anfragen nicht mehr ElGamal/AES+SessionTag, sondern (ziemlich) pures ElGamal 15:52 <+Complication> ...und das ließe sich nicht vorab berechnen, es sei denn, man wüsste die endgültige Menge, die erfolgreich sein wird? 15:52 <jrandom> das bedeutet, dass wir zwar früher ohne eine asymmetrische Operation tricksen konnten, wir versuchen es aber nicht mehr (da das Tricksen selbst eine Klasse von Angriffen ermöglicht hat) 15:53 <+Complication> (Menge der Peers) 15:53 <jrandom> hmm, es könnte sicherlich vorab berechnet werden, vorausgesetzt, man weiß, welche Peers im tunnel angefragt werden sollen 15:54 <jrandom> der neue tunnel-Erstellungsprozess läuft in einem separaten Thread, damit er unter Last nicht die Haupt-Job-Queue verstopft und sich besser drosseln kann 15:54 <+Complication> Könnte man auch annehmen, dass man – sofern sich das verfügbare Wissen nicht ändert – ein paar kennt, die man als Nächstes fragen wird, falls Versuche scheitern? 15:54 <jrandom> hmm, ich bin mir nicht ganz sicher, ob ich folge 15:55 <+Complication> Oder ist es nutzlos, sie schon zu kennen, weil die Struktur komplett neu aufgebaut werden muss? 15:56 <+Complication> (sprich: die ElGamal-Verschlüsselungen zumindest komplett neu machen) 15:56 <jrandom> ah, die Struktur ist http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> also ja, wenn sich der nächste Hop ändert, muss das ElGamal neu gemacht werden 15:56 <jrandom> (wenn du vorrechnest) 15:56 <+Complication> Richtig, da war ich mir nicht sofort sicher genug 15:57 <+Complication> Jetzt ist es mir allerdings klar 15:57 <jrandom> andererseits versuchen wir wirklich, unsere Erfolgsrate beim Erstellen zu erhöhen, und der neue Erstellungsprozess sollte sich anpassen können, um unnötige Erstellungen zu minimieren 15:58 <+Complication> Wie sieht es in der Praxis aus? 15:58 <jrandom> (oh, diese Struktur wurde im _PRE-Branch leicht geändert: 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> Mir ist das Detail aufgefallen, dass ElGamal-Verschlüsselungen einen Sprung in Richtung Schnelligkeit machen... 15:59 <jrandom> nun, die Erfolgsrate beim Erstellen ist viel, viel höher als im Live-Netz, aber das kann einfach an der kleinen Größe des _PRE-Netzes liegen 16:00 <jrandom> ja, das Erzeugen einer 2-Hop-Struktur dauert beispielsweise im Durchschnitt 44 ms über 1120 Durchläufe, verglichen mit der ElGamal-Verschlüsselungszeit im Live-Netz von 542 ms (über 1344 Durchläufe) 16:02 <jrandom> (auf derselben Maschine) 16:02 <+Complication> Sind die 542 auch mit Wiederholungen bei Fehlschlägen, oder nur das reine Erstellen? 16:02 <+Complication> Wenn es reines Erstellen ist, muss ich meinen Unterkiefer suchen ... er liegt irgendwo auf dem Boden. :P 16:02 <KBlup> wegen der Änderung des Exponenten: in welchem Maß beeinflusst das die Anonymität? 16:02 <jrandom> nein, das ist die reine ElGamal-Statistik, da das Live-Netz die neue _PRE-Netz-Struktur nicht erstellt 16:04 <jrandom> KBlup: Anonymität? keine. Sicherheit? Nach dem, was ich gelesen habe, sind 228 Bit mehr als ausreichend, um 2048-bit-ElGamal zu entsprechen 16:04 * Complication weiß nicht viel über ElGamals x und y 16:04 <+Complication> Nicht genug, um sinnvoll zu kommentieren 16:06 <+Complication> Wenn ernsthafte Forscher das kürzere x für ausreichend hart halten und diese Krypto-Nerds nicht schreiend davongelaufen sind... 16:06 <@cervantes> nun, nicht nur das, sondern auch die Implikationen, auf 1024/160 herunterzugehen 16:07 <KBlup> ich schätze, ich muss das Paper später lesen ;) 16:07 <+Complication> cervantes: ja, es ist sicher besser als das 16:08 <+Complication> Außerdem: Was ist der wichtigste Angriff, den diese Chiffre abwehren muss, und wie lange ist der Angriff praktikabel? 16:09 <+Complication> Könnte es etwas sein, das dir nur nützt, wenn du es schnell brichst, oder nützt es auch, wenn du es irgendwann später brichst? 16:11 <+Complication> Wenn ich richtig verstehe, ist das unmittelbare Geheimnis, das sie schützt, der nächste tunnel-Teilnehmer, richtig? 16:11 <+Complication> (genauer gesagt: der übernächste) 16:11 <@modulus> Meeting noch im Gange? 16:11 <+Complication> (den nur der nächste kennt) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> für einen praktischen (wenn auch wahnsinnig mächtigen) Gegner wäre es notwendig, sie während der Lebensdauer des tunnels zu brechen. Sie nach dieser Lebensdauer zu brechen, würde nur helfen, wenn du den gesamten Netzwerkverkehr geloggt hättest und alle tunnels brechen würdest (also nachdem du die ephemere Transportschicht-Krypto gebrochen hast und an der tunnel-Schicht-Krypto arbeitest) 16:11 <jrandom> wir reden hier also von Minuten, nicht von Jahrzehnten 16:12 <jrandom> (also sind 1024 Bit wahrscheinlich sogar Overkill) 16:12 <@cervantes> gibt es eine Möglichkeit, das Risiko sinnvoll zu messen? 16:13 <+Complication> Außerdem müsste der Gegner bei einem tunnel mit mehr Hops mehrere brechen, oder? 16:13 <+Complication> (obwohl der Ersteller auch mehrere bauen müsste) 16:13 <@cervantes> wenn wir nicht mehr als 1024 Bit brauchen, ist es dann wirklich nötig, mehr zu verwenden? 16:14 <@cervantes> wir können immer in 3 Jahren einen stärkeren Algo verwenden, wenn wir deutlich leistungsfähigere Quantencomputer haben 16:14 <@modulus> jrandom: Wenn der Gegner wüsste, dass um hh:mm etwas Wichtiges getunnelt wird, ist es wahrscheinlich, dass er es irgendwie durch Logging brechen könnte? 16:14 <jrandom> Complication: genau, sie müssten mehrere brechen (und die DH-Schlüssel, die die Transportschicht schützen) 16:14 <@modulus> soweit ich weiß, ist 1024 Bit mit viel Power break()able 16:15 <jrandom> viel Power und ein Jahrzehnt 16:15 <jrandom> (oder drei) 16:15 <@cervantes> jrandom: ist es schwierig, die schwächere Chiffre auszuprobieren? 16:15 <@modulus> ich war der Meinung, dass 1024-Bit-Komposite heutzutage in ein paar Monaten faktorisierbar sind. 16:15 <@cervantes> könnten wir es im PRE-Netz ausrollen 16:15 <@cervantes> und sehen, ob es tatsächlich viel Nutzen bringt 16:16 <@cervantes> modulus: ja, aber sie müssten mehrere brechen 16:16 <@modulus> wenn das auf dem diskreten Logarithmus und all dem Kram basiert, weiß ich nichts 16:16 <@modulus> cervantes: aha 16:16 <jrandom> cervantes: das erfordert Änderungen an vielen Strukturen, da wir derzeit 512-Byte-Slots verwenden. Vielleicht könnten wir für Tests einfach die ersten 256 Bytes mit 0x00 füllen 16:17 <jrandom> modulus: ElGamal basiert auf dem diskreten Logarithmus 16:17 <@cervantes> jrandom: einen Test wert? 16:17 <@modulus> genau, ich hatte an RSA gedacht 16:17 <@cervantes> oder besser auf andere Dinge konzentrieren und bei Bedarf darauf zurückkommen 16:18 <jrandom> definitiv einen Test wert, aber im Moment hacke ich an einigen Transportschicht-Evaluierungen herum 16:18 <+Complication> Ich schätze, es hängt davon ab, wie sich ihre Berechnung in der Praxis bewältigen lässt. 16:18 <jrandom> (und die 44 ms Verschlüsselungszeit ist fürs Erste gut genug, obwohl 4 ms noch besser wären :) 16:19 <+Complication> Wenn es mit aktuellen Rechnern zusammenhält, wird es sich mit neueren Maschinen verbessern. 16:19 <@modulus> insbesondere wenn Krypto-HW kommt, wie es bei einigen gerade anfängt 16:19 <jrandom> aber natürlich wird dieser Parameter nicht leichtfertig oder sofort geändert. Wenn jemand einen guten Grund hat, ihn zu vermeiden, bitte melden 16:21 <jrandom> modulus: Ich habe von dedizierten AES- und RSA-Chips gehört, aber nichts zu DH/ElGamal. Andererseits, wenn man die NSA/etc als Gegner betrachtet, die ihre eigenen bauen können, ist es möglich 16:22 <@cervantes> sie haben Krypto-Maschinen, gebaut auf Ring-Donut-Technologie mit Streuseln 16:23 * Complication ist bereit, den Celeron 300 auf einen Athlon 600 aufzurüsten, wenn er der Flut von Ring-Donuts mit Streuseln standhält :D 16:23 <tethra> heheh 16:24 <jrandom> mmMMmm Donuts 16:25 <jrandom> ok, hat noch jemand etwas zu 2) _PRE-Netz-Fortschritt? 16:25 <jrandom> wenn nicht, springen wir rüber zu 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication: magst du uns die Kurzfassung geben? 16:26 <+Complication> Nun, es scheint zu funktionieren. :) 16:26 <+Complication> Es gibt Hoffnung, bald mehr Webcaches für zusätzliche Redundanz zu bekommen. 16:27 <jrandom> word 16:27 <jrandom> hmm, brauchen wir deiner Meinung nach mehr Webcaches? Reicht nicht, wenn einer up ist? Mehr schadet natürlich nicht 16:27 <+Complication> (falls legion es schafft, die Mysterien zu lösen, die seinen ersten Versuch heimgesucht haben) 16:27 <+Complication> Es gibt auch einen mysteriösen Bug, aber er beißt nicht hart, und ich versuche, ihn zu finden. 16:28 <+Complication> Einer, der up ist, reicht 16:28 <+Complication> Mehr erhöht nur die Chance, dass einer up ist 16:28 <jrandom> cool 16:28 <+Complication> Denn im derzeitigen Stadium werden Webcaches nie als schlecht verworfen. Insgesamt sind es zu wenige. 16:29 <+Complication> (diese Routine wird aktiv, wenn es mehr als 10 gibt) 16:29 <+Complication> (wenn ich mich recht erinnere) 16:29 <+Complication> Zum Bug: Nach langer Laufzeit hängt sich das Webcache-Subsystem manchmal auf 16:30 <+Complication> Wahrscheinlich, weil sich ein GET-Request des httpclient nicht erfolgreich abbrechen lässt 16:31 <@modulus> also muss es von Zeit zu Zeit sterben? 16:31 <+Complication> Es ist unkritisch und scheint frisch beigetretene Maschinen nie zu beißen 16:31 <jrandom> hmm, was bedeutet das funktional? Hört es nach einer Weile auf, sich beim Webcache zu registrieren, sodass neuen Leuten keine Referenzen auf sie gegeben werden? 16:31 <+Complication> Wenn es eine bereits gut integrierte Maschine beißt, kann diese genug Peers von den Peers bekommen, mit denen sie bereits verbunden ist 16:31 <+Complication> Der Einfluss scheint derzeit also nahezu 0 zu sein 16:31 <@modulus> cool 16:32 <+Complication> Es ist nur kurios 16:32 <@modulus> keine Regel, wann es ausfällt oder so? 16:32 <+Complication> modulus: im Allgemeinen nicht vor 20 Stunden 16:33 <+Complication> Und da ich keinen Weg habe, es herbeizuführen, ist das Debuggen etwas langsam 16:33 <@modulus> :_) 16:34 <+Complication> So oder so: Wenn ich ihn finde, fix ich ihn, und wenn nicht, finde ich anderes Zeug zum Basteln :) 16:34 <jrandom> :) 16:34 <jrandom> klingt, als wäre es nur ein Symptom einiger Bugs, die wir in der streaming lib / eepproxy gesehen haben, also sollte das Fixen dieser auch das hier beheben 16:35 <+Complication> Könnte sein 16:38 <jrandom> ok, super, gute Arbeit, Complication 16:38 <jrandom> hat noch jemand etwas zu 3) I2Phex 0.1.1.37, oder springen wir rüber zum Sammelpunkt, 4) ??? 16:41 <jrandom> (betrachte uns als gesprungen) 16:41 <jrandom> ok, hat noch jemand etwas fürs Meeting? 16:42 <tmp> Oder für immer die Luft anhalten? 16:43 <jrandom> und immer und ewig 16:43 * jrandom holt aus 16:43 * jrandom *baf*t das Meeting zu