import from old webserver
This commit is contained in:
commit
581270204f
650 changed files with 84412 additions and 0 deletions
219
fahrplan-data/EH2007/track/Treffen/1874.en.html
Normal file
219
fahrplan-data/EH2007/track/Treffen/1874.en.html
Normal file
|
|
@ -0,0 +1,219 @@
|
|||
<?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>
|
||||
Loading…
Add table
Add a link
Reference in a new issue