220 lines
8 KiB
HTML
220 lines
8 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.en.html">
|
||
|
|
<span class="normal">Index</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<a href="/fahrplan/day_1.en.html">
|
||
|
|
<span class="normal">Day 1</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<a href="/fahrplan/day_2.en.html">
|
||
|
|
<span class="normal">Day 2</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<a href="/fahrplan/day_3.en.html">
|
||
|
|
<span class="normal">Day 3</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<a href="/fahrplan/day_4.en.html">
|
||
|
|
<span class="normal">Day 4</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<a href="/fahrplan/speakers.en.html">
|
||
|
|
<span class="normal">Speakers</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<a href="/fahrplan/events.en.html">
|
||
|
|
<span class="normal">Events</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<ul class="track">
|
||
|
|
<li class="track-easterhegg">
|
||
|
|
<a href="/fahrplan/track/Easterhegg/index.en.html">
|
||
|
|
<span class="normal">Easterhegg</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li class="track-amateurfunk">
|
||
|
|
<a href="/fahrplan/track/Amateurfunk/index.en.html">
|
||
|
|
<span class="normal">Amateurfunk</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li class="track-freifunk">
|
||
|
|
<a href="/fahrplan/track/Freifunk/index.en.html">
|
||
|
|
<span class="normal">Freifunk</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li class="track-ccc">
|
||
|
|
<a href="/fahrplan/track/CCC/index.en.html">
|
||
|
|
<span class="normal">CCC</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li class="track-workshop">
|
||
|
|
<a href="/fahrplan/track/Workshop/index.en.html">
|
||
|
|
<span class="normal">Workshop</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li class="track-treffen">
|
||
|
|
<a href="/fahrplan/track/Treffen/index.en.html">
|
||
|
|
<span class="normal">Treffen</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li class="track-vortrag">
|
||
|
|
<a href="/fahrplan/track/Vortrag/index.en.html">
|
||
|
|
<span class="normal">Vortrag</span>
|
||
|
|
</a>
|
||
|
|
</li>
|
||
|
|
<li class="track-movie">
|
||
|
|
<a href="/fahrplan/track/Movie/index.en.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">Speakers</th>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td>
|
||
|
|
<a href="/fahrplan/speakers/1401.en.html">
|
||
|
|
<img src="/fahrplan/images/speaker-1401-32x32.jpg"/>
|
||
|
|
</a>
|
||
|
|
</td>
|
||
|
|
<td>
|
||
|
|
<a href="/fahrplan/speakers/1401.en.html">apic</a>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
<table>
|
||
|
|
<tr>
|
||
|
|
<th colspan="2">Schedule</th>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="keyword">Day</td>
|
||
|
|
<td class="value">3</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="keyword">Room</td>
|
||
|
|
<td class="value">Work 1 (OG)</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="keyword">Start time</td>
|
||
|
|
<td class="value">14:00</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="keyword">Duration</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">Event type</td>
|
||
|
|
<td class="value">Workshop</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="keyword">Track</td>
|
||
|
|
<td class="value">Treffen</td>
|
||
|
|
</tr>
|
||
|
|
<tr>
|
||
|
|
<td class="keyword">Language</td>
|
||
|
|
<td class="value">German</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 "fish" 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.en.html">
|
||
|
|
<span class="previous" title="Chaos Communication Camp 2007"><<<</span>
|
||
|
|
</a>
|
||
|
|
<a href="/fahrplan/track/Treffen/1789.en.html">
|
||
|
|
<span class="next" title="PGP Keysigning Party">>>></span>
|
||
|
|
</a>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|