I2P Entwicklertreffen - 22. April 2014

20:32:31 <str4d> Hallo zusammen 20:34:53 <str4d> 0) Hallo 20:34:53 <str4d> 1) TODO 0.9.13-0.9.16 http://zzz.i2p/topics/1600 20:34:53 <str4d> 2) Neuer Transport für Tor-PTs http://zzz.i2p/topics/1551 20:34:53 <str4d> 3) Alle Punkte, die sich aus 1) ergeben 20:34:53 <str4d> Aktivität nach dem Treffen: Mumble-Stresstest (Sprachchat über I2P) 20:35:07 <iRelay> Titel: zzz.i2p: TODO 0.9.13 - 0.9.16 (auf zzz.i2p) 20:35:10 <iRelay> Titel: zzz.i2p: Supporting Tor Pluggable Transports (auf zzz.i2p) 20:35:29 <str4d> 0) Hallo 20:35:57 <hottuna> Hallo 20:37:37 <str4d> Noch jemand? 20:38:01 <str4d> zzz2 orion psi kytv meeh_ 20:41:17 <str4d> Hoffentlich tauchen einige von ihnen auf. 20:41:17 <str4d> 1) TODO 0.9.13-0.9.16 http://zzz.i2p/topics/1600 20:41:22 <iRelay> Titel: zzz.i2p: TODO 0.9.13 - 0.9.16 (auf zzz.i2p) 20:41:26 <zzz2> hier 20:41:58 <str4d> Auf zzzs Bitte hin haben wir einen Diskussionsfaden gestartet, um Ideen für die zukünftige I2P-Roadmap vorzuschlagen. 20:42:27 <str4d> Es gab viel Gerede, aber es wurde kein wirklicher Konsens erzielt. 20:43:14 <str4d> Ich habe einige der ersten Vorschläge auf der Roadmap-Seite zusammengefasst http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:43:17 <iRelay> Titel: Roadmaps/1.0 I2P Bugtracker (auf trac.i2p2.i2p) 20:45:01 <str4d> zzz2: Ich sehe, du hast dich in susimail reingekniet (yay) 20:46:19 <zzz2> ja, bin in dieses Kaninchenloch gefallen, während wir versuchen zu entscheiden, was wirklich wichtig ist 20:52:07 <str4d> Ich denke, das war nützliche Arbeit, schon allein wegen eines langjährigen Bugs zu Anmeldeproblemen, und susimail ist eine der ersten Apps, die Nutzer ausprobieren werden 20:52:08 <str4d> http://trac.i2p2.i2p/ticket/747 20:52:12 <iRelay> Titel: #747 (Anmeldeprobleme mit Susimail) I2P Bugtracker (auf trac.i2p2.i2p) 20:54:45 <psi> str4d: ohai 20:54:47 * psi ist zu spät? 20:55:19 <str4d> ja, psi ist es 20:55:25 <str4d> Es ist bisher nicht viel passiert :/ 20:55:58 * psi scrollt hoch 20:56:07 <str4d> Zusammenfassung dessen, was seit der Veröffentlichung des RFC passiert ist: 20:56:18 <str4d> - zzz hat an susimail gearbeitet 20:56:59 <str4d> - psi hat sich in PTs, neues DH und JNI eingearbeitet 20:57:23 <str4d> - Ich habe an I2P-Bote Android gearbeitet und jetzt an Java-EdDSA 20:57:39 * psi hat den ganzen Tag damit verbracht, die Struktur von PT für i2p auszuarbeiten 20:58:59 <zzz2> wenn str4d und psi bei EdDSA, 25519 und PTs Fortschritte machen, dann ist meiner Meinung nach die beste Nutzung meiner Zeit, bei der Migration auf neue Signaturalgorithmen voranzukommen, z. B. mehrere Destinations (Zieladressen in I2P) über einen tunnel, und eine Art Adressbuch-Unterstützung 21:00:27 <jenkins@kyirc> Starte Build #581 für Job I2P 21:01:01 <zzz2> wie ist der Status von psis mtn-Schlüsseln und der Entwicklervereinbarung? Ich habe nichts per Post bekommen. 21:01:23 <str4d> psi hat die Entwicklervereinbarung unterschrieben, ich habe sie auf die Website gepusht 21:01:36 <str4d> (also sind seine öffentlichen Schlüssel vermerkt) 21:02:10 <zzz2> ist sein Key-Fingerabdruck dort auch drauf? 21:02:32 <zzz2> wenn ja, füge ich ihn hinzu und kündige es an 21:03:02 <psi> mein GPG-FP ist auf meinem Twitter 21:03:05 <str4d> nicht der Fingerabdruck, aber der Schlüssel selbst ist es 21:03:47 <zzz2> es muss in dieser Beispiel-monotonerc-Vorlagendatei stehen. psi, vielleicht kannst du das als deinen ersten Test deiner mtn-Fähigkeiten machen? 21:04:23 <jenkins@kyirc> Juhu, Build repariert! 21:04:24 <jenkins@kyirc> Projekt I2P Build #581: FIXED in 3 Min 55 Sek: http://jenkins.killyourtv.i2p/job/I2P/581/ 21:04:36 <psi> das kann ich machen 21:04:40 <psi> das habe ich lokal schon gemacht 21:04:53 <str4d> zzz2, psi, ich habe das Gantt der Roadmap aktualisiert - http://trac.i2p2.i2p/wiki/Roadmaps/1.0 21:04:56 <iRelay> Titel: Roadmaps/1.0 I2P Bugtracker (auf trac.i2p2.i2p) 21:05:21 <psi> der monotone-Key-FP für meinen NICHT-Transport-Schlüssel ist "1ceb85b992114bae1bcb156ef238f8f3044a6bfe", -- ampernand@gmail.com 21:06:04 <psi> meinen Transport-Schlüssel-FP kann ich auch besorgen 21:06:29 <zzz2> ok, super, willkommen im Team! Wie ich allen sage: Bitte vorsichtig sein, übe zuerst auf www 21:06:30 <str4d> psi: du musst das an eche, kytv und welt schicken 21:06:43 <str4d> +1 21:06:56 * kytv hat es erhalten und fügt es seinem Server hinzu 21:07:08 <zzz2> psi, wir haben sehr genaue Anleitungen, wie man das alles macht, auf der Webseite... :) 21:07:27 <psi> ich werde mir das ansehen 21:07:38 <zzz2> z. B. mir Mail schicken (aber für dich nicht mehr nötig) 21:08:15 <str4d> Wie sieht die Gantt-Roadmap jetzt für alle aus? Gibt es Punkte, die unrealistisch erscheinen, oder solche, die fehlen 21:08:16 <str4d> ? 21:09:37 * psi prüft die Roadmap 21:09:43 <jenkins@kyirc> Projekt I2P UnitTests Build #528: SUCCESS in 5 Min 6 Sek: http://jenkins.killyourtv.i2p/job/UnitTests/528/ 21:09:57 <jenkins@kyirc> Starte Build #82 für Job I2P-Android 21:09:59 <str4d> zzz2: Ich schlage vor, dass du den Punkt zu neuen GPG-Schlüsseln lieber früher als später erledigst ;) 21:10:19 <zzz2> str4d, sag uns bitte, was es dir darüber sagt, was wichtig ist 21:10:33 <str4d> psi: findest du viele Überschneidungen zwischen deiner PTs-Arbeit und NTCP2? 21:10:34 <zzz2> ja, ich mache es vor dem nächsten Release, versprochen 21:11:24 <str4d> Meiner Meinung nach (IMHO) gibt es drei wichtige Dinge: 21:11:32 <jenkins@kyirc> Projekt I2P-Android Build #82: SUCCESS in 1 Min 34 Sek: http://jenkins.killyourtv.i2p/job/I2P-Android/82/ 21:11:40 <str4d> 1) Fortschritte beim Crypto-Upgrade – das kommt jetzt endlich in Gang 21:12:01 <psi> str4d: im Moment habe ich mir NTCP2 noch nicht angesehen 21:12:13 <str4d> (Fortsetzung der Vorarbeiten) 21:13:28 <zzz2> 1) 'kommt jetzt in Gang'? Ich schufte seit 6 Monaten daran 21:13:32 <str4d> 2) Audit-Vorbereitung – IMHO müssen wir unser Threat Model usw. so schnell wie möglich (ASAP) in den Griff bekommen 21:15:33 * psi ist für 30 Minuten afk 21:15:33 <psi> unerwartetes Ereignis, bbl 21:15:33 <psi> ich schaue mir den Scrollback später an 21:16:21 <zzz2> Es scheint da draußen einige Verwirrung über die 'neue Signatur-Krypto' zu geben. Sie ist fertig, sie ist in 0.9.12 drin, sie funktioniert. Für Destinations (Zieladressen in I2P). 21:17:06 <zzz2> Das 'Einzige', was nicht erledigt ist, ist die Migration bestehender veröffentlichter Destinations auf eine neue. 21:21:13 <str4d> ja, was zuerst darauf beruht, eine neue auszuwählen, was IMHO Ed25519 sein sollte, was wiederum eine schnelle Implementierung voraussetzt. 21:21:15 <str4d> Und gleichzeitig stimme ich zu, dass die verbleibende erforderliche Migrationsinfrastruktur implementiert werden sollte. 21:21:16 <str4d> <str4d> Seit Jahren haben wir das beiseite gelassen und an Dingen gearbeitet, von denen wir glauben, dass sie den Nutzern zugutekommen; aber IMHO, wenn wir mehr Forschungsinteresse wecken und es effektiv nutzen wollen, müssen wir uns stärker bewusst machen, was I2P leisten kann und was nicht. 21:21:17 <str4d> <str4d> Ich weiß, dass du das hast, zzz ;P 21:21:18 <str4d> <str4d> (Ich meinte speziell den Teil, der die eigentliche neue Krypto betrifft) 21:21:19 <str4d> <str4d> danke für den Aufwand, den du hineingesteckt hast, um es so weit zu bringen :) 21:21:20 <str4d> <str4d> 3) Usability, UX – das ist ein dritter wichtiger Punkt, der nicht im Roadmap-Diagramm steht 21:21:22 <str4d> <str4d> Nun – zzzs susimail-Arbeit fällt in diese Kategorie, ebenso Verbesserungen beim Streaming 21:21:41 <str4d> <str4d> Wichtig ist auch, unsere Fehler- und Hilfeseiten zu überprüfen und wie wir dem Nutzer helfen, seine Aufgaben zu erledigen. 21:21:41 <str4d> (nach meinem Punkt '2) Audit-Vorbereitung') 21:22:00 <str4d> Ich muss in 10-15 Minuten AFK 21:22:50 <str4d> Und da psi AFK ist, nehme ich '2) Neuer Transport für Tor-PTs' aus diesem Treffen heraus 21:23:55 <str4d> zzz2: was müssen wir deiner Meinung nach tun, bevor wir ein Treffen mit Lance bzgl. Bedrohungsmodell organisieren? 21:24:59 * str4d würde gerne ein Treffen mit Lance im Mai anstreben 21:26:04 <str4d> also müssen wir herausfinden, was wir bis dahin tun müssen, damit wir das Treffen so organisieren können, dass genug Zeit ist, das vorher abzuschließen. 21:29:27 <zzz2> Ich bin nicht damit einverstanden, dass wir zuerst auswählen müssen. 21:29:59 <zzz2> Oder, dass wir jetzt (P256) wählen und später noch einmal, wenn mehr Optionen verfügbar sind. 21:30:02 <MTN@kyirc> [ I2P ] compile fix [zzz@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/12396c3ee88d1194482fc2cc3751db1169cc52e3 21:30:34 <zzz2> Wir könnten den Standard für neue Destinations in 0.9.13 auf P256 umstellen, wenn wir wollen. 21:30:35 <str4d> zzz2: wenn wir an dem Punkt sind, dass das Namenssystem mit dynamischen Enc-Auswahlen umgehen kann, stimme ich zu 21:31:05 <zzz2> P256 ist eindeutig besser als DSA 21:31:34 <str4d> Dem stimme ich auch zu. 21:31:43 <zzz2> Ich denke, die P256-Hasser sollten einen Schritt zurücktreten und darüber nachdenken, wie schlecht DSA 1024 ist. 21:32:03 <MTN@kyirc> [ WWW ] adding psi's transport key [kytv@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/029163d2d446f10ab1a129b559802fabac2ef8b7 21:32:52 <str4d> zzz2: Ich verstehe deinen Punkt. 21:33:39 <zzz2> bezüglich Audit und Lance: Es ist immer eine gute Zeit. Hast du ein Update zum Audit-Prozess für uns von der Mailingliste? 21:33:40 <str4d> Ein Grund dafür, EdDSA vor dem Umstieg zum Laufen zu bringen, ist, dass ich basierend auf dem, was du zuvor in Threads gesagt hast, nicht zweimal den Signaturalgorithmus der Destination umstellen möchte. 21:34:14 <str4d> ja, das zweite Mal wäre etwas einfacher, weil Unterstützung für mehrere Destinations usw. vorhanden wäre, aber die Namensseite ist weiterhin die Schwachstelle. 21:34:48 <zzz2> für Server willst du nicht zweimal wechseln, aber für Clients ist es egal 21:35:04 <str4d> guter Punkt. 21:35:23 <str4d> Gibt es irgendetwas, das verhindern würde, dass neue Destinations mit alten sprechen? 21:35:31 <nombre_> also, ich entnehme, ihr macht Crypto-Upgrades? Gibt es vielleicht eine Seite, die im Detail darauf eingeht, was ihr alles plant? Und für eine 25519-Implementierung könntet ihr einfach NaCl via JNI oder Kalium verwenden, auch wenn das etwas einschränkend sein könnte 21:35:34 <zzz2> und selbst für Server: Wenn man auf P256 wechselt, scheint es kaum lohnend, noch einmal zu wechseln, es sei denn, es gibt wirklich schlechte Neuigkeiten über P256 21:35:54 <str4d> Wenn nicht, könnte es eine gute Idee sein, Clients früher auf P256 zu bringen 21:36:08 <zzz2> neue Destinations können mit alten sprechen und umgekehrt, solange beide auf 0.9.12 oder später sind 21:36:39 <str4d> zzz2: http://blog.cr.yp.to/20140323-ecdsa.html ist für mich Grund genug, nicht auf ECDSA zu bleiben 21:36:43 <iRelay> Titel: cr.yp.to: 2014.03.23: How to design an elliptic-curve signature system (auf blog.cr.yp.to) 21:37:56 <str4d> nicht wegen eines einzelnen Punktes (noch), aber wenn wir eine effektive, *korrekte* Implementierung von EdDSA bekommen, fände ich einen Wechsel sehr vorteilhaft 21:38:27 <str4d> nombre_: http://trac.i2p2.i2p/ticket/856 21:38:30 <iRelay> Titel: #856 (Krypto-Review/Migration) I2P Bugtracker (auf trac.i2p2.i2p) 21:38:30 <str4d> (und Links darin) 21:38:40 <nombre_> danke, str4d 21:38:53 <zzz2> nichts davon sagt mir jedoch, dass wir das Loswerden von DSA verzögern sollten. Es gibt dort auch nichts, was mich wegen P256 in Panik versetzt. Gibt es etwas Besseres als P256? Klar. 21:39:15 <str4d> keine wirklichen Updates von der OpenITP-Mailingliste; es gab in letzter Zeit nicht viel echte Aktivität. 21:40:38 <zzz2> Ich habe 65.536 Signaturalgos vorgesehen und 7 implementiert. 65.529 stehen noch aus, wir können bei jedem Release ein paar hinzufügen, wenn wir möchten. 21:43:27 <str4d> zzz, ich würde unterstützen, Clients in 0.9.13 auf P256 umzustellen 21:44:47 <str4d> aber wenn der Server-Umstieg noch nicht reibungslos sein wird, würde ich lieber noch etwas warten und schauen, wie die EdDSA-Arbeit vorankommt. 21:45:49 <nombre_> ich auch (nicht, dass meine Meinung irgendetwas zählt), NIST-ECDSA ist besser als DSA, auch wenn sich einige von uns Aluhutträgern erst sicher fühlen, wenn es 25519 ist 21:46:48 <nombre_> dest/b32 bricht dabei quasi zwangsläufig, oder? 21:47:13 <str4d> es hat lange gedauert und viel Arbeit gekostet, bis wir an diesem Punkt sind; es ergibt keinen Sinn, in letzter Minute zu überstürzen 21:49:48 * RN streckt den Kopf rein und schaut sich um 21:54:36 <zzz2> es gibt 1) Clients 2) neue Server und 3) Migration bestehender Server. 21:54:43 <zzz2> 1 und 2 können wir jetzt machen, 3) erfordert viel mehr Arbeit. 21:54:59 <zzz2> 1 und 2 brechen allerdings die Kompatibilität mit alten routers, i2pcpp und i2pd, bis diese nachziehen 21:55:16 <nombre_> arbeitet jemand daran, eine Java-Implementierung von 25519 zu finden/zu erstellen? und was ist der geschätzte Zeitrahmen, bis sie nutzbar wäre? 21:55:28 <nombre_> ich nehme an, mit P256 ist es schon machbar, weil das in Bouncy Castle enthalten ist? 21:55:52 <zzz2> P256 ist in der JVM 21:56:06 <nombre_> ah, noch besser 21:56:17 <zzz2> wir haben 25519 in Java jetzt, aber es ist viel zu langsam, um nutzbar zu sein. str4d und psi versuchen, es zu beschleunigen 21:57:39 <nombre_> hmm, da ich nichts über Krypto weiß, würde ich denken, dass die Verwendung von JNI der einfachste Weg wäre, es zu beschleunigen. Vielleicht sollte ich mir 25519 genauer ansehen, um zu verstehen, welche Teile die Engpässe sind 23:02:36 <str4d> Niemand hat es tatsächlich beendet, als ich AFK gegangen bin, also: 23:02:53 * str4d schließt das Treffen *baf*.