Anonymität ist nicht binär. Oder: ein erfolgreicher Versuch, ein sicheres und anonymes Netzwerk zu erstellen.

www.i2p2.de Übersicht I2P ist TOR ähnlich!

 Geringe Latenz auf den Verbindungen  Verbindung von Quelle zu Ziel über mehrere andere Router  Mehrfache Verschlüsselung auf diesem Wege  Jeder Client kann Router, Teilnehmer oder Exit-Node sein Unterschiede zu TOR

 I2P ist ein INTERNES Netz und nicht auf ExitNodes angewiesen  I2P filtert im Client aus manchen Verbindungen verräterische Daten aus (z.B. IP Adressen beim IRC connect)  I2P hat frei wählbare Tunnellängen (in sinnvollen Grenzen)  Der Weg Quelle – Ziel nutzt 2 Tunnel, von dem jeweils die Quelle und das Ziel einen kontrollieren (Länge, Anzahl)  Tunnel werden alle 10 Minuten verworfen und neu aufgebaut  I2P hat keine zentrale Kontrollinstanz, sämtliche Routinginformationen werden von den Routern selber aus eigenen Statistiken gewonnen Zahlen  Größe: ca. 800-1000 Router zu jeder Zeit aktiv  Ca. 650 Server (leasesets)  Router aus ca. 40 versch. Staaten  Latenz ca. 0.5-4 sec im IRC  Transferraten von ca. 10-30 kb/sec im Schnitt  Ca. 100-400 aktive Connections (UDP und TCP)  IRC, Gnutella Client, torrent Clients, edonkey Client in extra angepassten Versionen  Z.Z. 2 aktive Hauptentwickler und diverse weitere FloodFill Router

 Datenbank auf 1-n untrusted FloodFill Router, speichert die Leasesets  Leaseset ist die Information, wie eine Destination erreicht werden kann  Destination: 516bit++ base64 encoded String als ID (auch key-signed) oder base 32 Representant für einen Hash der ID (xvr…a.b32.i2p)  Max. Lebensdauer eines Leasesets: 10 Minuten, danach werden neue Tunnel aufgebaut und in einem neuem Leaseset publiziert  I2P Router fragen die FloodFill Router nach einem Leaseset für eine Destination  Z.Z. 6 FloodFill, sollte bis ca. 100.000 Router ausreichen – bis dahin muss ein Ersatz gefunden sein Routing

 Für eine „normale“ IRC Verbindung werden gewöhnlich 4 Tunnel aufgebaut:  Der Server baut einen IN-Tunnel auf und publiziert den Startpunkt des Tunnels in seinem Leaseset  Der Client baut einen OUT-Tunnel auf und sendet die Daten durch diesen Tunnel  Die Daten gehen durch den OUT Tunnel zum Startnode des IN Tunnel und durch den zum Server  Der Weg vom Server zum Client geschieht unter Austausch der Begriffe Server/Client (auch wieder mit der Unterteilung IN/OUT Tunnel)  Quelle und Ziel können frei über die Anzahl der Hops (Router zwischen Start und Endpunkt des Tunnels) und Anzahl der Tunnel wählen (bisher auf 5 Hops und 3 Tunnel beschränkt in der GUI) Routing Verschlüsselung  Verschlüsselung der Daten wird auf 3 Ebenen ausgeführt  „Garlic“ Encryption  Tunnel Encryption  Inter-router Transport Encryption  ElGamal/AES+SessionTag Encryption meistens, 2048 ElGamal und 256bit AES in CBC mode mit PKCS#5 padding für 16 byte blocks  Mehr infos unter: http://www.i2p2.de/how_cryptography Verschlüsselung Tunnel  Eines der zentralen Elemente von I2P  2 verschiedene Tunnel-Klassen:  Exploratory Tunnels – Werden wie normale Tunnel aufgebaut, Datenerhebung für Erreichbarkeit und Geschwindigkeit der anderen Router werden hierrüber erhoben  Client Tunnels – die eigentlichen „Daten“ Tunnels, Applikationen senden ihre Daten durch diese Tunnels  Participating Tunnels – andere Tunnel die durch den Router geroutet werden (nur Anzahl limitierbar) Applikationen  Eingebaute Applikation als java-Applet im Browser auf der Statuskonsole aufrufbar:  Susimail – einfacher Zugriff auf anon Email Dienst postman.i2p  SusiDNS – einfache HostDB (hosts.txt) Verwaltung  I2PSnark – Snark torrent Client im Browser für I2P  Dazu diverse andere Clients:  Imule – emule client für I2P (ggf. MIT integriertem I2P router => get it, start it, use it)  I2Phex – Phex Gnutella Client für I2P angepasst  Robert /i2p.bytemonsoon tracker – bittorrent client/tracker Fazit  I2P hat vieles eingebaut um „sicher“ zu sein  Einfacher Betrieb möglich  Latenzzeiten sind gering genug für Chats  Kein TOR Ersatz – nicht als anonymen Zugriff aufs normale Netz gedacht  Höhere CPU Last durch viel En/Decryption und hohe Anzahl von Tunnel  „hohe“ Bandbreite (>30 kb/sec) nötig um eigenen Traffic in fremden Traffic zu „verstecken“ Live-Show  Windows mit SSH Tunnel auf root server mittels Putty

 Fragen?