I2P-Entwicklertreffen - 22. Januar 2013

20:07:05 <hottuna_> Alles klar, Zeit fürs Meeting? 20:07:27 <str4d> o/ 20:08:28 <RN-> denke schon 20:08:41 <hottuna_> eche|on, zzz, dg: Ping 20:09:46 <hottuna_> Lass uns bis 20:15 warten und sehen, ob dg auftaucht. 20:10:21 <RN-> Hat jeder die Hausaufgaben von zzz gelesen? 20:10:36 <hottuna_> jap, jap 20:11:28 <RN-> war über meinem Horizont 20:11:31 <str4d> Okay, sieht so aus, als wären die drei Meeting-Themen ugha.i2p, das Website-Redesign und die Krypto. Gibt es noch etwas, das wir besprechen wollen? 20:11:50 <hottuna_> Ich denke, das ist mehr als genug 20:11:58 <str4d> Alles klar: 20:12:01 <RN-> hab’s aber gelesen 20:12:04 <str4d> (0) Hallo sagen. 20:12:11 <str4d> (1) Ugha.i2p 20:12:18 <str4d> (2) Website-Redesign 20:12:29 <str4d> (3) Krypto-Diskussion 20:12:32 <str4d> (0) Hallo sagen. 20:12:35 <str4d> Hi! 20:13:00 <RN-> hi 20:13:07 <hottuna_> hallo zusammen! 20:14:44 <RN-> Warten wir auf zzz und ech? 20:15:21 <hottuna_> Ich denke, bis zum Krypto-Teil kommen wir zurecht 20:15:27 <str4d> eche|on war vor etwa einer Stunde da; zzz meldet sich in der Regel, wenn er muss. 20:15:27 <RN-> schätze, die kommen erst am Ende... 20:15:49 <hottuna_> weltende, welterde, eche|on: Ping, bzgl. neuer Website 20:15:52 <hottuna_> alles klar 20:15:58 <RN-> hat jemand den Buffer? 20:15:58 <str4d> Und alle anderen können dazustoßen, wenn sie auftauchen ^_^ 20:16:05 <str4d> (1) Ugha.i2p 20:16:05 <hottuna_> Also... ugha? 20:16:08 <str4d> o/ 20:16:39 <zzz> hier, bleibe bis 3) in Bereitschaft, wenn es halbwegs zügig geht 20:16:52 <hottuna_> Alles klar, ich habe letzte Woche eine Inhaltsanfrage-Seite erstellt 20:16:52 <hottuna_> Syndie/iMule-Inhalte wurden angefragt 20:16:59 <hottuna_> und wurden, soweit ich sehe, eingereicht 20:17:18 * str4d kann 20:17:29 <str4d> tatsächlich ugha gerade nicht laden =P 20:17:41 <str4d> Wissen wir, wer ugha betreibt? 20:18:04 <hottuna_> Ich nicht 20:18:23 <hottuna_> Haben wir weitere Ideen, was wir an ugha ändern/ergänzen sollten? 20:18:31 <str4d> Denn es wäre hilfreich, wenn möglich, eine ordentliche Spam-Schutzmaßnahme zu bekommen. 20:18:38 <eche|on> wir wissen/vermuten teilweise, wer es betreibt. aber das wird hier nicht offengelegt 20:18:47 <eche|on> und der Eigentümer hat noch nicht geantwortet 20:18:54 <dg> Okay, hey 20:18:57 <str4d> eche|on: in Ordnung. 20:18:57 <eche|on> ugha.i2p wurde vom Spam bereinigt 20:19:09 <str4d> eche|on: wie viel Arbeit war das? 20:19:12 <eche|on> und ich habe eine Seite über iMule und Syndie hinzugefügt, KillYourTV hat noch etwas ergänzt 20:19:30 <eche|on> Spam? sehr viel, es waren>200 oder sogar>400 Spam-Nachrichten zu entfernen 20:19:38 <eche|on> die sind über 2 Jahre aufgelaufen 20:20:09 <str4d> Und einfach manuell entfernt? 20:20:24 <hottuna_> kam es über den Inproxy? 20:20:35 <dg> Das habe ich mich auch gefragt 20:20:50 <dg> sorry für die Verspätung, aber ich hab’s noch geschafft :) 20:20:53 <eche|on> ja, str4d, jede Spam-Seite anklicken, „Seite löschen“ klicken, „ja, ich möchte entfernen“ klicken, nächste Spam-Seite anklicken 20:21:08 <eche|on> und IMHO ist es über den INproxy. 20:21:27 <eche|on> ja, ist es 20:21:58 <eche|on> http://ugha.i2p.to/RecentChanges 20:22:01 <hottuna_> alles klar, vielleicht sollte es über den Inproxy nicht zugänglich sein? 20:22:15 <RN-> also... für den Inproxy auf Nur-Lesen setzen? 20:22:15 <eche|on> vielleicht möchte jemand die „Löschen“-Bilder zählen ;-) 20:23:34 <hottuna_> ist es möglich, den Admin über das Wiki zu benachrichtigen? 20:23:45 <eche|on> glaube nicht 20:23:48 <hottuna_> eine Read-only-Regel via Inproxy wäre vermutlich gut 20:23:51 <hottuna_> ok 20:24:06 <hottuna_> eche|on, aber du weißt wer? könntest du das machen? 20:24:28 <eche|on> Ich kann daran nichts machen, ich bin nur ein Nutzer wie alle anderen 20:24:43 <dg> Die Person ist offensichtlich nicht aktiv. 20:24:46 <dg> Also... vielleicht trotzdem nein. 20:24:51 <eche|on> alles, was ich tun kann, ist, tino (i2p.to-Betreiber) zu bitten, es zu blockieren. 20:25:18 <hottuna_> ist ein komplettes Blockieren eine akzeptable Lösung? 20:26:01 <eche|on> ja 20:26:05 <dg> nicht langfristig 20:26:30 <RN-> Ich stimme dg zu 20:26:44 <eche|on> es ist ein Wiki. Es braucht aktive Administration, um unerwünschte Inhalte zu entfernen 20:26:44 <hottuna_> ich denke, es zu blockieren ist akzeptabel.. da es ohnehin nur für Leute nützlich ist, die bereits I2P verwenden 20:26:57 <eche|on> aber da wir auch aktive Spammer innerhalb von I2P haben.... 20:26:57 <zzz> tino wird nichts unternehmen, es sei denn, der Besitzer fordert es an 20:27:04 <zzz> zumindest sollte er es nicht. 20:27:41 <hottuna_> eche|on, könntest du den Eigentümer kontaktieren? 20:27:52 <eche|on> derzeit besuche ich ugha.i2p täglich und entferne den Spam 20:28:15 <eche|on> hottuna_: Ich habe bereits via IRC und E-Mail Kontakt aufgenommen. jetzt ist die Person am Zug, zu reagieren. 20:28:38 <zzz> wenn es weiterhin peinlich ist, können wir es aus der router console entfernen, egal ob wir einen Ersatz haben oder nicht 20:28:41 <eche|on> weißt du, wir hatten dasselbe Problem schon bei forum.i2p. das ist das Problem innerhalb von I2P 20:28:48 <hottuna_> bezüglich Blockieren durch i2p.to? 20:29:02 <eche|on> bezüglich aktiver Admin-Arbeit daran 20:29:25 <hottuna_> ok 20:29:58 <hottuna_> wie auch immer, falls du eine Rückmeldung bekommst, frag nach dem Blockieren 20:31:01 <RN-> tino ist nicht mehr nur Inproxy 20:31:43 <dg> Ja. 20:32:01 <str4d> Abgesehen vom Spam-Problem: Gibt es Inhalte, die ugha haben sollte/aktualisiert werden müssen> 20:32:29 <dg> Ja. 20:32:29 <eche|on> Ich habe mir das russische Wiki angeschaut. Das ist ein sehr sehr sehr schönes. 20:32:44 <str4d> Aus /Requests – „More advanced i2p config options and explanations.“ – hottuna_, du hast davon schon einiges hinzugefügt, oder? 20:32:44 <eche|on> es ist wirklich mit gutem Inhalt gefüllt und strukturiert. aber auf Russisch. 20:32:44 <str4d> eche|on: Link? 20:32:53 <hottuna_> wie lautet die URL für das russische Wiki? 20:33:12 <hottuna_> str4d, ja. Und ich habe eine ähnliche Liste auf echelon.i2p gefunden 20:33:24 <eche|on> wenn ich es wiederfinde... 20:34:10 <eche|on> imho rus.i2p 20:34:56 <eche|on> aber mehr Erklärungen zur erweiterten Konfiguration wären gut 20:34:59 <str4d> Oh, das ist *wirklich* ein schönes Wiki. 20:36:25 <eche|on> zu schade, ich habe gerade wenig Zeit, aber wenn ich Gelegenheit habe, mache ich ein paar Sachen 20:36:32 <RN-> sieht so aus, als würde es die gleiche schöne, aufgeräumte Oberfläche verwenden wie cake why TV auf seiner Cindy-Seite 20:36:42 <dg> ist es auf Englisch? 20:36:45 <RN-> Ich muss in etwa 10 Minuten oder früher los, den Rest des Meetings lese ich im Scrollback nach... 20:38:21 <str4d> Gibt es noch weitere wichtige Punkte zu ugha.i2p, die angesprochen werden müssen? 20:38:36 <hottuna_> nein. 20:38:47 <hottuna_> Ich habe die Anfrage-Seite aktualisiert 20:39:50 <str4d> Die Seite /I2pRfc könnte ein Update vertragen, falls sie jemals als maßgeblich gedacht war (obwohl die Website wahrscheinlich der bessere Ort für Specs ist). 20:40:26 <dg> ugha.i2p hat viele Inhalte, die hinzugefügt oder aktualisiert werden könnten 20:40:33 <dg> es scheint mehr Informationen über die Vergangenheit von I2P und alte technische Dokumente zu haben als sonst irgendwo 20:41:19 <str4d> Zwischenfazit: Spam ist (derzeit) unter Kontrolle, braucht aber aktive Moderation; es gibt zahlreiche alte Seiten, die aktualisiert werden sollten (eine gute Aufgabe für Leute, die gern schreiben). 20:41:34 <hottuna_> einverstanden. 20:41:41 <str4d> Und wenn möglich, sollte das Wiki Bearbeitungen über den Inproxy blockieren. 20:41:56 <str4d> Noch etwas, bevor wir weitermachen? 20:41:59 <dg> Ist das dann alles zum Wiki? 20:42:02 <dg> Ich denke nicht 20:42:52 <str4d> dg: willst du die Ehre übernehmen? ^_^ 20:43:11 <dg> Alles klar :3 20:43:15 <dg> thx 20:43:38 * str4d kommt beim nächsten Thema sowieso viel zu Wort =D 20:43:53 <dg> Okay, also das Website-Redesign – ich finde, dass das neue, von str4d geleitete Design (er macht hauptsächlich das Backend, aber auch einige CSS-Änderungen) I2P einen frischen Look verleiht und die Perspektive und den ersten Eindruck der Leute auffrischen kann 20:44:00 <dg> Das derzeitige ist ziemlich angestaubt, usw., usw.. 20:44:11 <dg> Ich denke, wir sollten schauen, was noch fertiggestellt werden muss, um es live zu schalten 20:44:34 <str4d> Was vor dem Livegang unbedingt erledigt sein muss: 20:44:37 <dg> Kleinigkeiten können wir angehen, wenn es draußen ist – welche Blocker müssen wir hier berücksichtigen? 20:44:48 <str4d> - Übersetzungs-Tagging 20:45:01 <str4d> (naja, nicht zwingend, aber zumindest das meiste) 20:45:17 <str4d> - prüfen, dass alle internen Links aktualisiert und gültig sind 20:45:36 <str4d> Das ist im Grunde alles. 20:45:56 <hottuna_> wie wird das Übersetzungs-Tagging gemacht? 20:46:07 <str4d> Ich habe damit bereits angefangen und den Großteil der Seiten abgedeckt (wenn man die Doku ausnimmt, die für sich genommen groß ist) 20:46:22 <dg> Letzteres ist nicht allzu schwer. Es gibt dafür Tools, IIRC, aber ich kann auch herumklicken (nehme eine fürs Team ;) wenn’s drauf ankommt). 20:46:33 <dg> Übersetzungs-Tagging erklären? 20:46:40 <str4d> hottuna_: Jinja2-Template-Tags 20:46:40 <str4d> Und gettext-PO-Dateien 20:47:05 <str4d> <h2>{% trans %}A Gentle Introduction to How I2P Works{% endtrans %}</h2> 20:47:08 <str4d> <p>{% trans -%} 20:47:08 <str4d> I2P is a project to build, deploy, and maintain a network supporting secure and anonymous 20:47:08 <str4d> communication. People using I2P are in control of the tradeoffs between anonymity, reliability, 20:47:11 <str4d> bandwidth usage, and latency. There is no central point in the network on which pressure can be 20:47:11 <str4d> exerted to compromise the integrity, security, or anonymity of the system. The network supports 20:47:11 <str4d> dynamic reconfiguration in response to various attacks, and has been designed to make use of 20:47:11 <str4d> additional resources as they become available. Of course, all aspects of the network are open and 20:47:11 <str4d> freely available. 20:47:15 <str4d> {%- endtrans %}</p> 20:48:17 <str4d> Die markierten Blöcke werden in eine messages.pot extrahiert, die dann wie die routerconsole übersetzt werden kann. 20:48:36 <str4d> Das ist eine weitere Aufgabe, die aus meiner Sicht vor dem Start erledigt sein muss: 20:48:57 <str4d> - Alte übersetzte Seiten (z. B. /how_intro_fr) in PO-Dateien migrieren 20:49:53 <hottuna_> ok 20:49:56 <hottuna_> wie heißt das mtn-Repo? 20:50:04 <hottuna_> alles klar 20:50:08 <str4d> Dazu kann ich nicht viel beitragen =P Ich habe eine Seite testweise migriert, aber ich kann die Genauigkeit der alten Übersetzungen nicht verifizieren (zumal es nichts gab, um die statischen Seiten synchron zu halten) 20:50:12 <str4d> i2p.www.revamp 20:51:02 * str4d startet die Testseite erneut 20:52:33 <str4d> Okay, http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/ ist wieder online. 20:52:44 <iRelay> Title: I2P Anonymous Network (auf vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p) 20:52:59 <str4d> Außerdem habe ich Mobile-Support zur Website hinzugefügt – das sieht man, wenn man das Browserfenster auf unter 768px verengt 20:53:34 <dg> Was machen wir mit blog/ 20:53:34 <dg> ? 20:53:45 <str4d> dg: was meinst du? 20:53:52 <str4d> (in welcher Hinsicht?) 20:54:04 <dg> Wer wird bloggen und wie richten wir es ein? Wann bloggen wir außerdem? :) 20:54:43 <str4d> Der Blog enthält derzeit nur die (alten) Release-Posts und die (noch älteren) Status-Posts. 20:54:54 <str4d> Zumindest wird es wie üblich die Release-Posts geben. 20:55:50 <str4d> Das ist allerdings ein späteres Thema – wir müssen die Seite erst einmal fertig bekommen! 20:56:09 <hottuna_> einverstanden 20:56:20 <str4d> Ticket #807 enthält ein paar Dinge, die gut wären, aber keine Blocker sind 20:56:32 <iRelay> http://trac.i2p2.i2p/ticket/807 - (angenommene Verbesserung) - Überarbeitung der Website 20:56:44 <str4d> Die sind im Ticket etwas verteilt, aber einige sind: 20:57:02 <str4d> - /about/glossary ausfüllen 20:57:21 <str4d> - Layout und Styling von blog/meetings verbessern 20:58:17 <str4d> - das Theme reparieren oder ersetzen 20:58:36 <hottuna_> bzgl. Übersetzungs-Tagging: ist """{{ _('Friends of I2P') }}""" auf unkomplizierte Weise tagbar 20:59:03 <str4d> hottuna_: Das ist bereits getaggt. 20:59:26 <hottuna_> war nur neugierig wegen der Syntax 20:59:29 <str4d> (Das ist die kompaktere Notation) 20:59:39 <hottuna_> aah 20:59:42 <str4d> {{ }} fügt das Ergebnis der enthaltenen Python-Methode ein 20:59:53 <str4d> _() ist der gettext-Aufruf in Python 21:00:00 <str4d> (naja, der, der in Jinja2 importiert wird 21:00:03 <str4d> ) 21:00:19 <hottuna_> danke 21:00:34 <str4d> {% trans %}{% endtrans %} ist ein ausführlicherer Tag, aber es ist der Jinja2-Tag und unterstützt beliebigen Inhalt zwischen den Tags. 21:00:49 <str4d> (während die _()-Variante z. B. kein ' enthalten kann 21:00:52 <hottuna_> was bleibt noch zu taggen? 21:01:13 <str4d> hottuna_: schau ins mtn-Log für Details, was bereits getaggt wurde, aber IIRC: 21:01:44 <str4d> - get-involved/guides (ich habe dort ides und dev-guidelines getaggt) 21:01:55 <str4d> - misc/* 21:01:58 <str4d> - docs/* 21:02:09 <str4d> Und dann beliebige Blog-Posts, die wir übersetzt haben wollen. 21:03:06 <str4d> (Ich habe die 0.9.4- und 0.9.3-Posts bereits migriert und getaggt, und künftige Posts können ebenfalls getaggt werden; frühere kann man taggen, wenn/sofern sich jemand aufrafft) 21:04:17 <str4d> Okay, wir müssen im Meeting etwas vorankommen. 21:05:18 <str4d> Zusammenfassung: Das Site-Redesign ist fast fertig, Hilfe ist willkommen beim Taggen des restlichen Inhalts für Übersetzungen und beim URL-Check (geht parallel) (danke, hottuna_, fürs Helfen (ich nehme an, darum geht’s?)) 21:05:45 <str4d> Andere Text-/Layout-Änderungen sind willkommen, aber keine Blocker. 21:06:31 <str4d> Oh: Und wenn jemand mit dem Übersetzen der Seiten anfangen möchte (unter Nutzung der alten übersetzten Seiten als Referenz oder per Copy-Paste), *bitte tut das*. 21:06:34 <str4d> Noch etwas? 21:06:49 <hottuna_> ich schaue mir das Tagging an 21:07:48 <str4d> hottuna_: danke. Lass get-involved/guides mir, da habe ich schon angefangen. 21:08:43 <str4d> dg: behältst du das Meeting im Blick (die Zeit)? 21:09:02 <dg> oh, sorry 21:09:14 <dg> Also sind wir mit website/ durch 21:09:41 <dg> Krypto-Zeit :-D 21:10:16 <dg> Ich suche mal die relevanten Themen raus 21:10:16 <dg> Einen Moment 21:11:28 <dg> http://zzz.i2p/topics/1328 + http://zzz.i2p/topics/715 21:11:38 <iRelay> Title: zzz.i2p: Meeting [22. Januar] (auf zzz.i2p) 21:12:10 <dg> TL;DR: Wir müssen darüber sprechen, welche Komponenten des I2P router in Prioritätsreihenfolge geändert werden müssen (oder wie zzz es ausdrückte: „to talk generally about which uses are more vulnerable than others“ 21:12:10 <dg> ) 21:12:17 <dg> (für die DSA-Änderung) 21:12:45 <dg> Es ist ein guter Zeitpunkt, auch andere Krypto-Änderungen zu diskutieren, die man mitnehmen könnte, aber im Moment sollten wir bei dem bleiben, was zzz vorgeschlagen hat, denn das ist ein riesiges Rabbit Hole 21:12:52 <hottuna_> wie im Tor-Cipher-Migrationsdokument angemerkt, sollten wir Änderungen dort anstreben, wo sie am wichtigsten sind, und nicht unbedingt dort, wo sie am einfachsten sind 21:13:26 <dg> (https://gitweb.torproject.org/torspec.git/blob_plain/34ecac0fbac7f476bfcbf813767721fada62c17e:/proposals/ideas/xxx-crypto-migration.txt) 21:15:55 <hottuna_> Meiner Meinung nach sind die wichtigsten Bereiche jene, die potenziell schwache Chiffren für Langzeit-Schlüssel verwenden 21:16:39 <dg> hottuna_: Ich bin kein Krypto-Experte (und halte mich entsprechend raus, außer ich weiß etwas), aber sind die Langzeit-Schlüssel nicht auch die Schlüssel, die einen Flag Day verursachen könnten? 21:17:12 <hottuna_> das Ändern der meisten Chiffren würde einen Flag Day verursachen 21:17:31 <dg> Ich dachte daran, dass alle Destinations im Eimer wären 21:17:38 <dg> also ja 21:17:41 <hottuna_> nun, im Grunde 21:18:03 <hottuna_> ich sehe keinen Weg, dass Destinations nicht kaputtgehen 21:19:03 <hottuna_> Ich habe keine Liste der Stellen, an denen Langzeit-Schlüssel verwendet werden 21:19:22 <hottuna_> aber so eine Liste und die jeweils verwendete Chiffre sollten erstellt werden 21:21:04 <str4d> Einverstanden. Wir sollten auch ihre angenommene Verwundbarkeit einstufen. 21:21:11 <str4d> (Das wäre eine gute Wiki-Seite auf Trac) 21:21:19 <hottuna_> ja. 21:22:02 <hottuna_> wir sollten auch eine Liste von Chiffren erstellen, die sich als sicher erwiesen haben (im Test der Zeit) und für uns ansonsten geeignet sind 21:22:17 <str4d> Abschnitt 2 der Tor-Seite gilt im Grunde auch für uns. 21:22:20 <hottuna_> diese Liste sollte asymmetrisch 21:22:55 <zzz> klingt gut 21:23:11 <hottuna_> asymmetrische* Verschlüsselung, symmetrische Verschlüsselung, Signaturen und HMAC-Chiffren, denen wir vertrauen 21:23:49 <zzz> die Seite how_cryptography ist eine gute Referenz 21:24:32 <hottuna_> str4d, hast du eine Wiki-Seite angefangen oder soll ich? 21:24:40 * str4d macht das gerade 21:25:00 <str4d> /Crypto/CurrentSpecs klingt gut? 21:25:09 <str4d> (für die Zusammenfassungstabelle) 21:25:09 <hottuna_> klar 21:25:16 <zzz> DSA ist ein guter Ausgangspunkt für die Analyse, weil es leicht zu verstehen ist und auf den ersten Blick das Schwächste ist 21:26:15 <hottuna_> ja 21:27:01 <hottuna_> was wo verwendet wird und über welche Zeiträume welche Schlüssel genutzt werden, weiß ich nicht viel 21:28:56 <zzz> der OP auf http://zzz.i2p/topics/715 hat eine Liste 21:29:03 <zzz> ~8 Stellen, an denen wir DSA verwenden 21:29:05 <iRelay> Title: zzz.i2p: DSA 1024/160 Replacement (auf zzz.i2p) 21:29:40 <hottuna_> die mit der längsten Gültigkeit ist routerinfo? 21:30:23 <str4d> || '''Aspekt/Ort''' || '''Verwendete Chiffre''' || '''Chiffre-Details''' || ''' Angenommene Verwundbarkeit''' || '''Kommentare''' 21:30:30 <str4d> Muss noch etwas in die Tabelle? 21:30:30 <zzz> vielleicht Dest., das nicht aufgeführt ist. 21:31:12 <zzz> es gibt sowohl einen Dest-Schlüssel als auch einen LeaseSet-Schlüssel, ich glaube, der Dest signiert das LeaseSet und der LeaseSet-Schlüssel ist ungenutzt 21:31:38 <hottuna_> str4d, Gültigkeitsdauer 21:32:24 <zzz> wäre kein Weltuntergang, einen RI-Flag-Day zu haben, aber alle 2500 in der hosts.txt wegzuwerfen, ist eine andere Geschichte 21:32:38 <str4d> Hmm... vielleicht sollten angenommene Verwundbarkeit / Gültigkeit dann in einer separaten Tabelle stehen. 21:33:07 <zzz> Datagrams sind ein Problem, Dests sind ein Problem 21:33:22 <hottuna_> Hosts wegzuwerfen ist ein riesiges Problem. aber es ist in meinen Augen auch der verwundbarste Schlüssel 21:34:37 <zzz> für jeden Fall müssen wir weitergehen. nicht nur, wie leicht zu brechen, sondern welches Bedrohungsmodell / welche Konsequenz. 21:35:08 <hottuna_> ja. vielleicht für jeden Fall auf eine separate Seite verlinken? 21:35:26 <str4d> http://trac.i2p2.i2p/wiki/Crypto/CurrentSpecs existiert jetzt und hat etwas Basisinhalt 21:35:33 <iRelay> Title: Crypto/CurrentSpecs I2P (auf trac.i2p2.i2p) 21:36:09 <zzz> und das in Relation setzen, angesichts der Größe des Netzes usw. z. B. haben wir derzeit jemanden, der behauptet, er könne eine eepsite 23 1/2 Stunden am Tag abschalten. 21:37:13 <hottuna_> christoph1, ? 21:37:25 <dg> Uff. 21:37:28 <str4d> Mmm. 21:37:35 <dg> Wie funktioniert das? 21:37:58 <hottuna_> Eclipse-Angriff auf unsere floodfills 21:38:01 <christoph1> genug vorkalkulierte routerinfos verwenden, 10 bösartige Knoten in die Nähe der Ziel-Hashblock-Suche setzen 21:38:20 <lillith> warum nicht 24 Stunden? 21:38:35 <christoph1> weil Mitternacht etwas knifflig ist 21:38:46 <christoph1> man kann weitere 10 für morgen positionieren 21:39:05 <christoph1> aber es gibt immer noch eine Phase um die Rotation des Keyspace herum, in der die Dinge instabil sind 21:39:22 <lillith> also bekommt der router eine halbe Stunde, in der die floodfills ungewiss sind? 21:39:33 <christoph1> (der Client kann zufällig einen der guten Knoten treffen, weil er noch nicht alle Angreifer kennt 21:39:52 <str4d> Die Schlüssel für den nächsten Tag sind im Voraus bekannt, also könnte man das Positionieren bösartiger Knoten im Voraus planen, oder? 21:39:59 <christoph1> jep 21:40:22 <christoph1> trotzdem scheint es rund um die Rotation etwas instabil zu sein 21:40:49 <str4d> Wie auch immer, das ist etwas off-topic für dieses Thema (sorry, christoph1) 21:41:05 <christoph1> ack 21:43:08 <str4d> Okay, möchte jemand daran arbeiten, http://trac.i2p2.i2p/wiki/Crypto/CurrentSpecs zu füllen? 21:43:14 <iRelay> Title: Crypto/CurrentSpecs I2P (auf trac.i2p2.i2p) 21:43:26 <zzz> dg, bitte halte uns auf Kurs, nicht davon weg :) 21:43:42 <hottuna_> str4d, ja. Ich habe mich gerade eingeloggt :P 21:44:01 <str4d> Vielleicht sollten wir kurz klären, was genau wir auf dieser Seite wollen (meine Spaltenüberschriften sind ziemlich generisch) 21:44:36 <dg> zzz: sry ;) 21:44:59 <str4d> Erste Tabelle: eine Zusammenfassung der im router verwendeten Krypto. Name, Gültigkeitsdauer, Verwundbarkeit... Schlüssellänge? Primstärke? 21:44:59 <zzz> auch meine Schuld 21:45:48 <str4d> Zweite Tabelle: eine Liste jeder Stelle im router, an der Krypto verwendet wird. Ort und Name der Chiffre (natürlich). Nutzungsdetails? Was ist hier wichtig zu wissen? 21:46:27 <str4d> Wir können bei Bedarf vermutlich auf separaten Seiten zur zweiten Tabelle weiter ausführen (den Ort mit einer Unterseite verlinken) 21:47:41 <hottuna_> str4d, Unterseite hinzugefügt 21:48:06 <str4d> IMHO sollte das eine Seite sein, die man überfliegen kann und den aktuellen Stand versteht (während die Site-Doku die vollständigen Specs sind) 21:48:32 <str4d> hottuna_: ah, jetzt verstehe ich, was du mit Gültigkeitsdauer meinst. 21:48:39 <hottuna_> :) 21:50:20 <str4d> hottuna_: es gibt bereits einen Eintrag für Destinations – LeaseSet-Signierung 21:50:29 <hottuna_> oh 21:50:29 <hottuna_> sorry 21:50:36 <str4d> (zumindest für den DSA-Teil – ich denke, du meinst da die Verschlüsselung) 21:51:56 <str4d> Außerdem würde ich es eher „Security timescale“ als „Validity period“ nennen 21:52:38 <hottuna_> jep 21:52:38 <zzz> FYI für alle anderen – jede RI und jede Dest hat zwei Schlüssel, einen für die Verschlüsselung und einen für die Signatur 21:53:11 <hottuna_> ok 21:53:11 <hottuna_> warum? 21:53:32 <zzz> ElG wurde als viel zu langsam zum Signieren erachtet 21:54:44 <str4d> Mag eine dumme Frage sein, aber wie sind die beiden Schlüssel verifizierbar „verknüpft“? 21:55:23 <zzz> für RI und Dest gilt: der Hash umfasst beide Schlüssel + das (normalerweise null) Certificate 21:55:23 <hottuna_> ein öffentlicher Schlüssel wird aus dem privaten Schlüssel abgeleitet 21:55:51 <zzz> ändere eines der drei und du änderst den Hash. 21:56:13 <str4d> Ah, ok (du meinst den Destination-Hash?) 21:56:23 <str4d> (d. h. das B64) 21:56:26 <zzz> ja 21:56:53 <str4d> Okay... das Problem beim Upgraden der Destination-Krypto ergibt jetzt viel mehr Sinn... 21:56:59 <zzz> und bei Dests gilt: änderst du eines der drei, brauchst du einen neuen hosts.txt-Eintrag 21:58:34 <zzz> und (Hinweis) non-null certs könnten der Weg zu Upgrades mit (teilweiser) Kompatibilität sein, d. h. ohne Gravity zu brechen. Das wird weiter unten in Topic 715 behandelt 21:59:39 <str4d> Ja – das ermöglicht, dass beides nebeneinander funktioniert. 22:00:09 <str4d> Aber es heißt dennoch, dass die End-to-End-Krypto für die alten Destinations unangetastet bleibt. 22:00:52 <str4d> Der Punkt, an dem der Dest-Krypto-Schlüssel am wichtigsten ist, ist die Strecke zwischen dem OPEP und dem IBGW, richtig? 22:01:26 <zzz> nicht sicher 22:01:53 <zzz> eine weitere Komplikation: Es gab früher zwei Schichten von End-to-End-Krypto, eine im router und eine im Client, und einige Schlüssel sind jetzt ungenutzt 22:02:32 <zzz> dito bei den Signierschlüsseln... einer war für die LS-Revokation und ist ungenutzt 22:02:46 <zzz> also vielleicht eine weitere Gelegenheit 22:03:29 <str4d> http://www.i2p2.i2p/how_intro scheint darauf hinzudeuten, dass ElGamal/AES+SessionTags für die End-to-End-router-Verschlüsselung verwendet wird. 22:04:37 <zzz> Krypto ist viel schwieriger zu diskutieren als Signieren. da ist das ElG, das AES und die Tags umschließt, zusammen mit dem DH-Austausch. 22:05:35 <str4d> Ja. Aber was z. B. LeaseSets angeht, müssen wir wahrscheinlich beides im Tandem diskutieren, oder? 22:05:46 <zzz> Ich würde vorschlagen, heute gar nicht erst in die Krypto-Seite einzusteigen. 22:05:53 <str4d> Heute nicht, nein. 22:06:00 <zzz> vielleicht, vielleicht auch nicht 22:06:03 <str4d> Also, zurück zum Thema *derp* 22:06:30 <zzz> änderst du einen Schlüssel, änderst du den Hash. Aber wie das Tor-Dokument sagt: Versuche nicht, alles zu ändern, nur weil du eine Sache änderst 22:06:33 <str4d> Was ist das Problem mit Datagram-Signaturen? 22:07:12 <zzz> es verwendet unseren Signaturalgorithmus, d. h. DSA. Den wir verwenden, um alles zu signieren. (einschließlich suds) 22:07:54 <zzz> was auch nicht auf der Liste in Topic 715 steht und vielleicht der langlebigste Schlüssel von allen ist 22:09:04 <str4d> Richtig, aber das spezifische Problem bei Datagrams ist, vermute ich, sicherzustellen, dass router weiterhin miteinander kommunizieren können 22:09:04 <str4d> ? 22:10:00 <zzz> richtig. änderst du das Signieren, brichst du alle RI- und LS-Lookups und die gesamte signierte End-to-End-Kommunikation 22:10:51 <zzz> weil fast alles signiert ist 22:11:41 <str4d> Also ist der einzige Weg, mit dem Upgrade des Signaturalgorithmus voranzukommen, sicherzustellen, dass jede Stelle, an der er verwendet wird, mehrere Signaturalgorithmen verarbeiten kann? 22:12:27 <str4d> Das Problem wird dann, zu wissen, welche Versionen von einem router unterstützt werden (und die Partitionierungsprobleme aus dem Tor-Dokument sind hier relevant). 22:12:30 <zzz> aber dann bräuchte jede Dest zwei Sätze von Tunnels, einen für alt und einen für neu, afaik 22:12:49 <zzz> es gibt zwei Arten von Kompatibilität zu berücksichtigen. 22:13:19 <str4d> Guter Punkt>_< 22:13:42 <zzz> 1) „Network“-Kompatibilität, d. h. können die RIs und LSs gespeichert und abgerufen werden, kommen Nachrichten durch Tunnels, auch wenn die ffs oder Teilnehmer down-rev sind; 22:14:21 <zzz> 2) End-to-End-Kompatibilität, kann A mit B sprechen. Dafür scheint es nötig, dass A und B dasselbe unterstützen 22:15:43 <str4d> 2) ist für direkte router-zu-router-Kommunikation „einfach“ zu handhaben, da die router-Versionen öffentlich bekannt sind. Wie sieht es mit End-to-End-Kommunikation aus? 22:17:24 <zzz> das andere ist: eine RI hat eine ganze Properties drin, wir können da beliebige Flags hineintun 22:17:27 <str4d> Wo müsste ein router nachsehen, um festzustellen, ob ein anderer router (wie ein eepsite-Server) die neuen Signaturen unterstützt? 22:17:30 <zzz> nichts dergleichen für LS 22:18:01 <zzz> certs sind die Magie 22:18:48 <zzz> in einem cert können wir sowohl Krypto- als auch Signatur-Algorithmus spezifizieren und die Extrabytes speichern, wenn es nicht in die ersten 384 passt 22:18:59 <zzz> wie gesagt, das ist das Topic-715-Zeug 22:19:53 <zzz> das cert muss bei Byte 385 beginnen, um 1) nicht zu brechen 22:20:54 <zzz> ist das für heute in etwa genug? habt ihr das bekommen, was ihr wolltet? 22:21:09 <hottuna_> ich denke, das ist ein Anfang 22:21:34 <hottuna_> spezifischere Probleme und Lösungen können diskutiert werden und die Wiki-Seite als Hilfe dienen 22:23:50 <str4d> zzz: das ist ein guter Start – danke =) 22:24:24 <zzz> viel Arbeit vor uns... 22:24:39 <str4d> Ja, aber irgendwo müssen wir anfangen ^_^ 22:24:54 <hottuna_> str4d, Tags für monotone.html gepusht 22:25:05 <zzz> Ich hätte noch ein Thema fürs Mtg, aber nur, wenn welt welterde weltende da ist 22:25:26 <str4d> hottuna_: die unter get-involved/guides? Dann nehme ich die raus, die ich angefangen hatte einzubauen ^_^ 22:25:37 <hottuna_> ja 22:26:00 <hottuna_> alles klar, sind wir dann fertig? 22:26:11 <dg> würde ich sagen? 22:26:15 <str4d> Ich würde gern noch einen zufälligen Punkt hinzufügen: 22:26:18 * dg hatte nichts beizutragen 22:26:21 <dg> kein Krypto-Gott 22:27:08 <str4d> Ich möchte sponge zu seinen Android-Bemühungen gratulieren – das Standard-I2P läuft jetzt erfolgreich auf Android-Geräten. 22:27:46 <str4d> Und erste Berichte deuten auf bessere Performance und geringeren Akkuverbrauch hin als bei I2P-Android 22:27:53 <hottuna_> das ist schon eine Leistung 22:28:04 <hottuna_> gut gemacht, sponge 22:28:16 <hottuna_> ich muss jetzt los 22:28:23 <hottuna_> dg, startest du den Thread für nächste Woche? 22:28:27 <dg> spogne hat es extrem gut gemacht 22:28:56 <dg> Mach ich. Themen? Scheint, als müsste Krypto in den nächsten Wochen ein wiederkehrendes Thema sein. :) 22:29:03 <dg> Ich sollte nächste Woche auch pünktlich da sein 22:29:47 <str4d> Wenn wir das Redesign bis dahin getaggt bekommen, könnten wir möglicherweise mit der neuen Site live gehen (obwohl ich es bevorzugen würde, vorher echte Übersetzungen reinzubekommen) 22:30:18 <str4d> (hängt auch davon ab, dass welterde da ist) 22:30:25 <hottuna_> str4d, ich denke, echte Übersetzungen werden sehr lange dauern 22:30:52 <hottuna_> alles klar, gute Nacht, Leute 22:30:59 <str4d> hottuna_: vollständige Übersetzungen, ja. Aber es gibt bereits übersetzte Seiten (siehe www.i2p2/pages/translations), die sich schnell migrieren lassen. 22:31:07 <str4d> (für Leute, die die Sprache verstehen) 22:31:14 <str4d> o/ hottuna_ 22:31:45 * str4d *baf*t das Meeting.