Kurzer Überblick
Anwesend: co, jrand0m, LeerokLacerta, mihi, mrflibble, mrsc, nop, shardy, thecrypto, w0rmus
Sitzungsprotokoll
[22:53] 0) willkommen [22:54] 1) Apps: [22:54] 1.1) IM [22:54] 1.2) NS [22:54] 2) Entwicklungsstatus: [22:54] 2.1) Teilsysteme [22:54] 2.2) Persistenz von Verschlüsselungsschlüsseln [22:54] 2.3) To-do [22:54] 3) Spezifikationsthemen [22:54] 3.1) Änderungen [22:54] 4) Administratives: [22:54] 4.1) anonymes CVS [22:54] 5) ? [22:55] ok, 0) willkommen [22:55] willkommen zu Sitzung 58 [22:55] das ist alles [22:55] si sr, es sei denn, jemand hat noch etwas hinzuzufügen? [22:55] * nop bemerkt, dass jrand0m mit seiner Nummerierung objektorientiert ist :) [22:56] 3.1.2.2.4.5.8() ;) [22:56] hey, es könnten Structs sein ;) [22:56] haha [22:56] das stimmt definitiv [22:56] ok, 1.1) IM. thecrypto? [22:56] obwohl [22:56] 2 hat Vererbung [22:57] ;) [22:57] heh [22:57] achtet nicht auf mich [22:57] ok [22:57] sorry [22:57] weiter [22:57] *** mihi_ (~none@anon.iip) ist dem Kanal #iip-dev beigetreten [22:57] okay, ich lade gerade ein paar grundlegende Spezifikationen für IM hoch [22:58] (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw für oowriter [22:58] und ich bin dabei, das PDF hochzuladen [22:59] wenn du willst, kann ich es auf die i2p-Seite stellen [22:59] gib mir eine Sekunde [22:59] klar [22:59] *** mrflibble (mrflibble@anon.iip) ist dem Kanal #iip-dev beigetreten [22:59] willst du das in i2p/apps/IM/doc/ ablegen? [22:59] *** mihi_ heißt jetzt mihi_backup [23:00] kann ich [23:00] ja [23:00] ich meinte im CVS :) [23:00] kann ich auch machen [23:00] (aber im Web ist auch gut) [23:00] oh [23:00] haha [23:00] (Link: http://www.thecrypto.org/i2pim.pdf)http://www.thecrypto.org/i2pim.pdf [23:01] "the file is damaged and could not be repaired" AR-Fehler [23:01] nochmal versuchen [23:01] * jrand0m hat es problemlos geladen [23:01] MrEcho: Die PDF-Datei? [23:01] (das sxw) [23:01] damals nur teilweise hochgeladen [23:01] jetzt funktioniert's [23:01] hehe [23:02] im Grunde habe ich nur die Presence-Sachen, Online-/Offline-Nachrichten und eine eigentliche Nachricht aufgenommen [23:02] ich habe schamlos einige Abschnitte aus dem I2NP-Dokument kopiert [23:02] :) [23:02] heh, ich dachte mir schon, dass mir manches bekannt vorkam :) [23:02] ich bin auch dabei, die UI hochzuladen, an der ich [23:02] gearbeitet habe [23:03] jrand0m: muss ich die Verzeichnisse apps/IM/doc anlegen [23:03] ja, und jeweils mit cvs add hinzufügen [23:03] -kb? [23:03] ja [23:03] thecrypto: ich glaube, apps/ ist jetzt da. [23:04] was ist eine Präsenz? [23:05] lass mich ein update laufen lassen [23:05] aber es kommt rein [23:05] *** Abmeldung: shardy (Ping-Timeout) [23:05] ich sage nur: zerpflückt die Spezifikationen [23:05] und die UI wird auch bald drin sein [23:05] und wenn irgendetwas klärungsbedürftig ist, dann schickt mir anonymail, E-Mail, was auch immer, und ich passe es an [23:05] habe ich das Meeting verpasst? [23:05] *** shardy (~shardy@anon.iip) ist dem Kanal #iip-dev beigetreten [23:05] thecrypto: Du solltest es auch auf der E‑Mail‑Liste ankündigen, mit einem Link zu den Dokumenten. [23:05] ich dachte, das hätte ich da rein getan? [23:05] nein, wir sind noch beim ersten Punkt, mrflibble [23:05] mrflibble: Das Meeting läuft. [23:05] oh sorry, konnte nur „logger“ nicht sehen [23:06] thecrypto> du sagst, es ist eine Destination (Zieladresse) – ist das die Destination, an die Nachrichten gesendet werden? Wie funktionieren Offline‑Nachrichten? [23:06] keine mids hier, also kein logger ;) [23:06] k [23:06] * mrflibble geht zurück zum Mitlesen [23:06] oh warte, das sind nur Präsenzbenachrichtigungen, sorry [23:06] wie kann man eine Präsenz abonnieren? [23:06] jrand0m: keine Offline-Nachrichten [23:07] im Grunde [23:07] die Präsenz packt einfach eine Destination und einen Namen zusammen [23:07] um die Dinge zu vereinfachen [23:08] wenn wir zu NS übergehen wollen, können wir das tun, und später wieder darauf zurückkommen? [23:09] 'k cool [23:09] und ihr könnt mir weiterhin Fragen schicken [23:09] eigentlich eine schnelle Frage [23:09] schieß los [23:09] ist das IM streng textbasiert? [23:10] bei dieser Basisversion ja, aber ich werde Dateisupport hinzufügen [23:10] cool [23:10] ich möchte erst einmal den Anfang des Systems erledigen und darauf aufbauen [23:10] (iterativ und inkrementell)++ [23:11] ok, super. Ich schaue mir das genauer an und andere sollten das auch tun... fürs Erste weiter zu 1.2) NS. co? [23:11] Version 1.1 (final) der Naming-Service-Spezifikation wurde heute früher veröffentlicht. [23:12] (und es gab großen Jubel) [23:12] Im Wesentlichen habe ich die Abschnitte zu den benötigten Datenstrukturen und Netzwerk-Nachrichten fertiggestellt. [23:12] Die Client-API veröffentliche ich am Donnerstag. [23:12] Und beginne mit der Implementierung der NS-Anwendung. [23:12] großartig [23:13] Eine Idee hat sich geändert, nämlich was die CA (Zertifizierungsstelle) macht, wenn Entitäten sich registrieren. [23:13] co: wie wirst du das umsetzen? [23:13] co: den Namensserver oder den Client? [23:14] thecrypto: Nun, zuerst implementiere ich die benötigten Datenstrukturen. [23:14] Dann den Client, danach die Server- und CA-Komponenten. [23:14] okay [23:15] Wie gesagt, ich möchte jetzt, dass die CA neu registrierten Entitäten ein Zertifikat ausstellt. [23:15] Dieses Zertifikat legen sie bei Änderungen ihrer Einträge den Namensservern vor. [23:15] Was das Zertifikat enthält, ist in dieser Version noch nicht festgelegt; das kommt in die nächste Version der Spezifikation. [23:16] Hält das jemand für eine schlechte Idee? [23:16] hmm. Wäre es nicht einfacher/sicherer, wenn der Client einfach einen öffentlichen/privaten Schlüssel benutzt? [23:16] sprich, bei der Registrierung einen öffentlichen Schlüssel für Updates angeben und die Registrierung signieren, und wann immer man wieder aktualisieren möchte, ein Update signieren [23:16] (sodass die CA den privaten Schlüssel niemals erhält) [23:17] Nebenbei: Der ganze I2PIM-Kram ist jetzt ins CVS-Repository eingecheckt [23:17] super [23:17] Das wäre vermutlich einfacher. Ich denke darüber noch einmal nach. Danke für den Hinweis. [23:17] Mehr habe ich zum Naming Service derzeit nicht, falls keine weiteren Fragen sind. [23:18] sieht gut aus; ich habe 1.1 noch nicht durch, aber ich maile dir, wenn mir etwas auffällt [23:19] OK. Nächstes Thema? [23:19] ok, 2.1) Entwicklungsstatus der Teilsysteme. [23:19] *** w0rmus (o0o@anon.iip) ist dem Kanal #iip-dev beigetreten [23:20] Das Transport-Teilsystem ist gut genug, um weiterzumachen. Das Peer-Management-Teilsystem ist angedeutet, mit primitiven Algorithmen, aber funktionsfähig. netDb, Tunnel-Management und Statistik-Management sind noch ausstehend. Das Client-Teilsystem wird trivial (wir verwenden einfach den SDK local only router wieder) [23:21] Was meinst du mit „primitiven Algorithmen“? [23:21] nicht schnell? [23:21] äh, das Peer-Management-Teilsystem verfolgt die Peer-Leistung nicht, es liefert einfach zufällige Peers. [23:22] Der Algorithmus wird mit dem Fortschritt aktualisiert und abgestimmt, um die Peer-Auswahl angemessener zu gestalten [23:22] aktuell baue ich und handhabe garlic messages (Garlic‑Nachrichten), was eine Qual ist. [23:23] aber machbar, nur nervig [23:23] das führt direkt zu 2.2) Persistenz von Verschlüsselungsschlüsseln. [23:24] garlic messages verwenden ElG+AES-Verschlüsselung, um die Schichten der „cloves“ zu umhüllen [23:24] und private Schlüssel werden auch an anderen Stellen verwendet (Transport, Client-Management) [23:25] *** Abmeldung: thecrypto (Ping timeout) [23:25] Private Schlüssel und Sitzungsschlüssel stets nur im Speicher zu halten und nie auf die Platte zu schreiben, ist ideal, aber schlecht für Zeiten, in denen der router herunterfährt (absichtlich oder durch Fehler) [23:26] Hat jemand eine Meinung dazu, ob wir 1) die Schlüssel nie auf Platte schreiben und übermäßigen, unnötigen Nachrichtenverlust riskieren (da sie nicht entschlüsselbar wären) 2) sie vor dem Schreiben auf Platte verschlüsseln oder 3) sie einfach im Klartext auf die Platte schreiben sollten? [23:26] Option 2. [23:27] jrand0m Option 2, oder das, was wir vorher gesagt haben [23:27] wir müssen localhost vertrauen [23:27] *** Abmeldung: cohesion (class) [23:27] wir nehmen an, dass localhost nicht kompromittiert ist [23:27] Das Verrückte an Option 2 ist, dass entweder der Nutzer beim Start des routers eine Passphrase eingeben muss, oder dass sich der Sitzungsschlüssel ermitteln lässt [23:27] guter Punkt, nop. [23:28] wir sind wieder ein Transport, darum können wir uns nicht allzu sehr kümmern, das kann auf Client-Seite angepasst werden, oder wir geben Optionen [23:28] je nach Paranoia-Level [23:28] Abwägung Sicherheit vs. Bequemlichkeit [23:29] Dann schlage ich vor, standardmäßig 3 zu verwenden und dem Nutzer die Option 2 anzubieten. [23:29] genau [23:29] genau. ok, das Gute ist, dass Leute den router‑Code nehmen und ändern können (und sollten!) – ein „Aluhut‑I2P-router“ und ein „I2P-router für Otto Normalverbraucher“ [23:29] ok, cool, dann nehme ich vorerst einfach 3) [23:30] ok, 2.3) To-do [23:30] * co würde das NS-Thema gern am Ende des Meetings noch einmal aufgreifen. [23:30] * nop muss die NS-E-Mail noch zu Ende lesen [23:30] 'k, du bist jetzt Punkt #5 [23:30] Ich kann bis zum Ende warten. [23:31] mihi hat einige Tests gebaut, um Bugs in der SDK‑Implementierung aufzuzeigen. Einige sind schon behoben, andere nicht. Das Fixen steht auf der To‑do‑Liste :) [23:32] außerdem gab es etwa ein Dutzend Änderungen an diversen Spezifikationen. Sobald ich Zeit habe, aktualisiere ich die Dokus und schiebe sie raus, evtl. stelle ich derweil eine Errata‑Seite ins Wiki [23:33] word [23:34] weitere To-dos... um, ich habe heute Morgen das „Wrong Size generating key“-Ding gefixt, plus ein paar zufällige Bugs [23:34] ok, das war's zum Entwicklungsstatus. 3) Spezifikationsthemen [23:35] 3.1) siehe To‑do bzgl. Änderungen. Es waren überwiegend typografische Änderungen, ich bin heute beim Implementieren der garlics über eine etwas größere gestoßen. Kein Problem, erfordert nur etwas Umstrukturierung von Datenstrukturen und ein bisschen Fingerfertigkeit bei der Verschlüsselung. Ich packe das in die Errata. [23:35] 3.2) [ich weiß, das stand nicht auf der Agenda, aber hier ist es trotzdem] Fragen zu Spezifikationen [23:35] (bin gleich zurück, ich lese weiter mit, falls ihr mich braucht) [23:35] hat jemand Fragen zu irgendeiner der Spezifikationen? [23:35] cool, shardy [23:36] jrand0m: Bitte sag uns noch einmal, welche Spezifikation in welchem Dokument ist. [23:37] (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs hat sie zugeordnet [23:37] Ich schaue es mir an. [23:38] (beim Blick darauf fällt mir ein, dass ich den sicheren, zuverlässigen UDP‑Transport dokumentieren muss. Noch ein To‑do...) [23:39] Es gab Fragen von verschiedenen Leuten bzgl. der relevanten Spezifikationen – grundsätzlich gilt: Wenn ihr nicht wissen wollt, wie die router funktionieren (oder sie implementieren helfen wollt), müsst ihr die I2NP‑Spezifikation nicht lesen. I2CP und der I2CP‑Abschnitt bei den Datenstrukturen reicht aus [23:40] jrand0m [23:40] si sr? [23:41] meinst du echtes UDP, also UDP‑Pakete [23:41] oder UDP im Sinne eines allgemeinen UDP‑Protokolls [23:41] ja, UDP im Sinne von UDP‑Paketen [23:41] für I2P [23:41] *** thecrypt1 (~thecrypto@anon.iip) ist dem Kanal #iip-dev beigetreten [23:41] *** thecrypt1 heißt jetzt thecrypto [23:41] i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp für die Implementierung [23:42] zurück [23:42] wb [23:42] mag mir jemand sagen, was passiert ist, während ich weg war? [23:43] Die UDP‑Implementierung ist ziemlich einfach – sie macht einen DH‑Austausch, Nachrichten werden in 1‑K‑Pakete aufgeteilt und mit dem erzeugten Schlüssel per AES‑256 verschlüsselt [23:43] Rekeying wird unterstützt, ist aber im Moment nicht automatisch [23:43] ACKs werden gebündelt zurückgeschickt (aka „Ich habe für Nachricht 42 alle Pakete bis Paket 18 erhalten, aber nicht 3 oder 7“) [23:44] (und der praktische Grund, warum ich die UDP‑Implementierung vor der TCP‑Implementierung gemacht habe, ist, dass UDP quasi „gratis“ asynchrones I/O liefert, mit nahezu 0 Overhead) [23:45] natürlich [23:45] In der UDP‑Implementierung sind noch zwei Dinge zu tun – Station‑to‑Station gegen MITM‑Angriffe und ein Paket für „oh Scheiße, ich habe den Sitzungsschlüssel vergessen“ hinzufügen [23:45] gut [23:46] nach dem UDP‑Transport möchte ich als Nächstes das Polling‑HTTP implementieren – so unterstützen wir sowohl den normalen Nutzer (UDP) als auch den Nutzer hinter Firewall/NAT/Proxy (Polling‑HTTP) [23:47] ok, ja, das muss zu einer Spezifikation dokumentiert werden :) [23:48] * jrand0m !versetzt sich selbst eine für Coden vor dem Spezifizieren [23:48] Erst coden, dann spezifizieren hilft mir [23:48] ja, es funktioniert iterativ am besten [23:48] (weil wir beim Implementieren Probleme in den Spezifikationen finden, etc) [23:49] ok, das war 3) Spezifikationen. 4) Administratives [23:49] 4.1) anonymes CVS. thecrypto? :) [23:49] gerade noch rechtzeitig [23:49] nun, ich schaue mir das an, ich glaube, 2401 ist derzeit blockiert [23:49] kannst du cvs -d :pserver: lokal? [23:49] und es gibt wohl auch noch inetd‑Kram zu erledigen, danke jrandom [23:50] ah, cool [23:50] lass mich das testen, ich hatte vergessen, dass man das machen kann :) [23:51] wäre das einfach cvs -d :pserver: ? [23:51] cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p [23:52] außerdem wäre es super, wenn wir dort auch ein Bugzilla bekämen [23:52] acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused [23:52] 'k, nachdem du die inetd.conf‑Zeile hinzugefügt und ein kill -HUP identd gemacht hast? [23:52] ich probiere die inet‑Zeile und melde mich [23:52] äh, inetd :) [23:52] 'k cool [23:53] kommt der pserver in dieselbe Zeile? [23:53] ja, das ist alles in einer Zeile [23:55] ok, das war's mit dem Administrativen, zumindest fällt mir gerade nichts mehr ein [23:55] 5a) co, du bist dran [23:56] Wenn zwei Personen denselben Entitätennamen registrieren wollen, wird die zweite abgelehnt. [23:56] Aber wenn wir einen signaturbasierten Ansatz verwenden, [23:56] könnte die abgelehnte Person dem Namensserver [23:56] trotzdem eine Nachricht schicken und ihn anweisen, den Eintrag zu ändern. [23:56] Es gibt zwei Möglichkeiten: [23:57] 1) Die CA schickt dem Namensserver eine Kopie des öffentlichen Schlüssels der genehmigten Entität. [23:57] 2) Die CA sendet der registrierenden Person ein Zertifikat, von ihrem privaten Schlüssel signiert. Der Namensserver besitzt den öffentlichen Schlüssel der CA, um es zu verifizieren. [23:58] Wenn ein böswilliger Nutzer dem Namensserver sagt, er solle einen bestimmten Datensatz ändern, verhindert das Fehlen eines Zertifikats die Änderung. [23:58] Das war meine Überlegung. [23:59] aber in dem Fall kennt die CA den Schlüssel – asymmetrische Kryptographie hieße, die CA kennt immer nur den öffentlichen Schlüssel, außerdem würde die CA diesen öffentlichen Schlüssel nie herausgeben wollen oder müssen – er dient nur dazu, dass der legitime Aktualisierer bei einer Update‑Anfrage dagegen signiert [00:00] was du beschreibst, klingt eher nach symmetrischer Kryptographie – im Wesentlichen nur eine Passphrase [00:00] CVS macht mir zu schaffen! [00:00] (wobei das Zertifikat das gemeinsame Geheimnis zwischen CAs und dem legitimen Besitzer des Nyms ist) [00:00] *** mrsc (~efgsdf@anon.iip) ist dem Kanal #iip-dev beigetreten [00:01] was ist los, thecrypto? [00:01] ich habe den Benutzer anonymous ohne Passwort angelegt, ihn zu readers und in die cvsgroup aufgenommen, und bekomme cvs login: authorization failed: server localhost rejected access to /home/cvsgroup/cvsroot for user anonymous [00:01] jrand0m: Guter Punkt. Sagen wir, dieser Teil der Spezifikation ist noch nicht final, und ich denke noch einmal darüber nach. [00:01] cool [00:01] *** LeerokLacerta (~leerok@anon.iip) ist dem Kanal #iip-dev beigetreten [00:02] Konnichiwa. [00:02] hmm, thecrypto, ich glaube nicht, dass du einen anonymen Systembenutzer willst [00:02] heya LeerokLacerta [00:02] Hallo, jrand0m. [00:02] nun, ich habe ein Passwort vergeben und jetzt funktioniert es [00:03] jrand0m: Und wenn du nach dem Lesen der Spezifikation noch mehr Vorschläge hast, schick sie mir. [00:03] mach ich, co [00:03] cool, thecrypto.. ist /bin/false deren Shell? [00:03] jetzt muss ich nur noch den Abschnitt im CVS‑Handbuch finden, wie man einen Benutzer anlegt [00:03] -> *thecrypto* wie lautet das PW? [00:04] jetzt ja [00:05] ok, das können wir nach dem Meeting durchgehen. [00:05] ok, letzter Punkt auf der Agenda: 5b) ? [00:05] irgendwelche Fragen/Ideen/Bedenken? [00:05] schaut euch einfach die IM‑App an [00:06] im Moment baut sie nur einen Baum, aber man sieht, wie es anfängt auszusehen [00:06] Kein SOCKS? [00:06] ohh ja, das habe ich vergessen [00:06] ah cool, thecrypto [00:06] SOCKS? Also das Proxy‑Protokoll? [00:06] kann hier jemand gut Icons erstellen? [00:06] Jupp. [00:06] Die Antwort war jedes Mal „Nein“, wenn ich gefragt habe. [00:07] ah. ja, wir wollen definitiv einen SOCKS‑Proxy, aber aktuell arbeitet niemand daran. [00:07] Hm. [00:07] das wird eine der Apps sein, die wir bis zur öffentlichen 1.0 haben wollen, damit Leute i2p‑basierte Sites browsen können, und damit Leute auch das normale Web anonym browsen können [00:07] es gibt genug kostenlose SOCKS‑Proxies, würde ich sagen ;) [00:08]