0
0
Fork 0
easterhegg-2007-website/fahrplan-data/EH2007/track/Treffen/1874.de.html

220 lines
8.1 KiB
HTML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type"/>
<meta content="Pentabarf" name="generator"/>
<meta content="2007-04-14" name="DC.date"/>
<title>EH2007: Lectures and workshops</title>
<link media="screen,print" type="text/css" rel="Stylesheet" href="/fahrplan/stylesheet.css"/>
</head>
<body>
<div id="conference-logo">
<a href="http://easterhegg2007.hamburg.ccc.de/">
<img alt="Easterhegg 2007" src="/fahrplan/images/conference-128x128.png"/>
</a>
</div>
<div class="noprint" id="menu">
<ul>
<li>
<a href="/fahrplan/index.de.html">
<span class="normal">Index</span>
</a>
</li>
<li>
<a href="/fahrplan/day_1.de.html">
<span class="normal">Tag 1</span>
</a>
</li>
<li>
<a href="/fahrplan/day_2.de.html">
<span class="normal">Tag 2</span>
</a>
</li>
<li>
<a href="/fahrplan/day_3.de.html">
<span class="normal">Tag 3</span>
</a>
</li>
<li>
<a href="/fahrplan/day_4.de.html">
<span class="normal">Tag 4</span>
</a>
</li>
<li>
<a href="/fahrplan/speakers.de.html">
<span class="normal">Referenten</span>
</a>
</li>
<li>
<a href="/fahrplan/events.de.html">
<span class="normal">Veranstaltungen</span>
</a>
</li>
<li>
<ul class="track">
<li class="track-easterhegg">
<a href="/fahrplan/track/Easterhegg/index.de.html">
<span class="normal">Easterhegg</span>
</a>
</li>
<li class="track-amateurfunk">
<a href="/fahrplan/track/Amateurfunk/index.de.html">
<span class="normal">Amateurfunk</span>
</a>
</li>
<li class="track-freifunk">
<a href="/fahrplan/track/Freifunk/index.de.html">
<span class="normal">Freifunk</span>
</a>
</li>
<li class="track-ccc">
<a href="/fahrplan/track/CCC/index.de.html">
<span class="normal">CCC</span>
</a>
</li>
<li class="track-workshop">
<a href="/fahrplan/track/Workshop/index.de.html">
<span class="normal">Workshop</span>
</a>
</li>
<li class="track-treffen">
<a href="/fahrplan/track/Treffen/index.de.html">
<span class="normal">Treffen</span>
</a>
</li>
<li class="track-vortrag">
<a href="/fahrplan/track/Vortrag/index.de.html">
<span class="normal">Vortrag</span>
</a>
</li>
<li class="track-movie">
<a href="/fahrplan/track/Movie/index.de.html">
<span class="normal">Movie</span>
</a>
</li>
</ul>
</li>
</ul>
</div>
<div id="content">
<p class="release">EH2007 - 1.0</p>
<p class="intro">
<strong>Easterhegg 2007</strong>
<br/>
<em>The Workshop Weekend</em>
</p>
<div class="section" id="event">
<div id="infobox">
<table>
<tr>
<th colspan="2">Referenten</th>
</tr>
<tr>
<td>
<a href="/fahrplan/speakers/1401.de.html">
<img src="/fahrplan/images/speaker-1401-32x32.jpg"/>
</a>
</td>
<td>
<a href="/fahrplan/speakers/1401.de.html">apic</a>
</td>
</tr>
</table>
<table>
<tr>
<th colspan="2">Programm</th>
</tr>
<tr>
<td class="keyword">Tag</td>
<td class="value">3</td>
</tr>
<tr>
<td class="keyword">Raum</td>
<td class="value">Work 1 (OG)</td>
</tr>
<tr>
<td class="keyword">Beginn</td>
<td class="value">14:00</td>
</tr>
<tr>
<td class="keyword">Dauer</td>
<td class="value">02:00</td>
</tr>
<tr>
<th colspan="2">Info</th>
</tr>
<tr>
<td class="keyword">ID</td>
<td class="value">1874</td>
</tr>
<tr>
<td class="keyword">Veranstaltungstyp</td>
<td class="value">Workshop</td>
</tr>
<tr>
<td class="keyword">Track</td>
<td class="value">Treffen</td>
</tr>
<tr>
<td class="keyword">Sprache</td>
<td class="value">deutsch</td>
</tr>
</table>
</div>
<h1 class="title">EOF</h1>
<p class="subtitle">!eof</p>
<img class="event-image" src="/fahrplan/images/event-1874-128x128.png"/>
<div class="abstract">
<p>In einem Chat-Kanal im IRCNet kam die Idee auf, ein verschluesseltes Kommunikationsnetzwerk zu implementieren.
</p>
</div>
<div class="description">
<p>Es gibt natuerlich bereits Ansaetze zu 'sicherer' verschluesselter Kommunikation, jedoch haben alle gerade im Umlauf befindlichen Lösungen markante Defizite: IRC ist unverschluesselt, und selbst IRC-SSL loest nicht alle Probleme: So ist die Server-zu-Server-Kommunikation meist weiterhin ablauschbar,
und die Clients sind gezwungen, sämtlichen am Netzwerk teilnehmenden Serverbetreibern zu vertrau-
en. Sowohl die Alternative SILC als auch das &quot;fish&quot; Plugin für einige IRC-Clients machen aktuell
einen sehr unausgereiften Eindruck, und gaben in der Vergangenheit, und auch jetzt noch, Anlass zu
derben Sicherheitsbedenken. Außerdem stört, dass nicht bereits etablierte Standards wie SSL oder
GPG genutzt werden, sondern das Crypto-Rad neu erfunden wurde, weswegen ein Audit des gesam-
ten Systems wesentlich diffiziler ist als beim Aufbau auf stabilen, halbwegs sicheren, Komponenten.
Kommunikation über TOR (Tor Onion Routing) ist aktuell schon recht nett, ist aber für Schnüffler
mit zu geringem Aufwand zu brechen, da die Routen der Pakete über einen gewissen Zeitraum sta-
bil bleiben und von den Teilnehmern relativ einfach getraced werden können. Mittels statistischer
Analyse ist zudem wohl mit verhältnismäßig erstaunlich geringem Aufwand (und die Blackboxen der
großen Brüder stehen schon lange bei jedem ISP - und niemand weiß, wie viele TOR-Fnords von der
Regierung betrieben werden) zuordenbar, dass ein bestimmtes Paket mit hoher Wahrscheinlichkeit
die Response auf ein zeitlich eher gesendetes gewesen sein muss.
Realisiert werden soll das ganze mit chaotischem (erisianischem :-), verschlüsseltem Onion-Routing:
Es gibt keinerlei fixe Pfade für die Datenpakete, sondern jeder Teilnehmer sendet einfach verpeilt
irgendwo hin an einen oder mehrere Peers. Zudem werden von sämtlichen Teilnehmern kontinuierlich
Fake-Pakete (aus /dev/random o.dgl.) verschickt, um statistische Zuordnungen nahezu unmöglich zu
machen. Der 'echte' Traffic, der beim angestrebten Content (vorrangig Chat und Mail) absolut nicht
von großer Menge ist, geht für Beobachter einfach komplett im Noise unter. Jeder Node verschlüsselt
beim Erhalt eines Paketes dieses neu und schickt es $IRGENDWOHIN weiter. Irgendwann werden
dann zufällig mal für ihn bestimmte Daten ankommen (oder auch nicht ;-). Es ist klar, dass die Soft-
ware, die an der Kommunikation in einem solchen Netz teilnimmt, immens gute Algorithmen braucht,
um eine auch nur halbwegs akzeptable Skalierbarkeit zu gewährleisten. Außerdem sollte irgendwie
der Erhalt der Daten auch acknowledged werden können, worauf aber geachtet werden muss, dass der
Rückkanal nicht zu offensichtlich statistisch zuordenbar wird! Auf jeden Fall sollten vor der Imple-
mentierung der eigentlichen Weichware, und wohl auch am geschicktesten noch vor dem Schreiben der letztendlichen Spezifikation, intensive Simulationen durchgeführt werden, die aufzeigen, wie, wo
und wann das Programm in spe dann an Parametern wie Datenrate der Noise-Erzeugung, Anzahl der
Peers, an die multicasted werden soll, wann ein Paket wieder zufällig verworfen werden soll (da natür-
lich ansonsten der Traffic exponenziell steigen würde und das Netz sofort zusammenbrechen würde),
und so fort, drehen müssen wird. Die Simulationen werden auch zeigen, ob die natürlich inhärent hohe
Latenz Realtime-Kommunikation überhaupt ermöglicht, oder ob das Ganze doch nur für Messaging
verwendet werden kann, was aber auch schon nicht zu verachten wäre.
</p>
</div>
<div id="navigation">
<a href="/fahrplan/track/Treffen/1790.de.html">
<span class="previous" title="Chaos Communication Camp 2007">&lt;&lt;&lt;</span>
</a>
<a href="/fahrplan/track/Treffen/1789.de.html">
<span class="next" title="PGP Keysigning Party">&gt;&gt;&gt;</span>
</a>
</div>
</div>
</div>
</body>
</html>