Archiv der Kategorie: Computerkram

Schachcomputer, Computerschach und Systemarchitektur, Teil 1

Da ich mich in meiner Eigenschaft als Professioneller Klugscheißer ja unter anderem mit maschinellem Lernen und Systemarchitektur beschäftige und privat gerne (wenn auch nicht unbedingt gut) Schach spiele, liegt eigentlich nichts näher, einmal das Thema Computerschach und die Schachcomputer zu betrachten.

Weißer Springer

Dedizierte Computer, die nichts anderes können als nur Schach spielen, sind heute doch sehr aus der Mode gekommen, aber zumindest die Schachspieler ab Mitte 30 können sich vielleicht noch an die Blütezeit der Schachcomputer Ende der 80er Jahre erinnern. Damals hat man mit D-Mark bezahlt, es gab noch die DDR, ich war 10 Jahre alt und hatte einen Mephisto Super Mondial geschenkt bekommen.

Mephisto Super Mondial
Mephisto Super Mondial

Aus heutiger Sicht muss man sich natürlich fragen: Warum kam man damals überhaupt auf die Idee, Computer zu bauen, die nur zum Schach spielen gut sind und warum waren diese Spezialrechner auch noch erfolgreich?

Komfort und Stil

Ein wichtiger Grund ist selbstverständlich, dass es einfach viel mehr Spaß macht, auf einem richtigen Schachbrett zu spielen anstatt am Bildschirm. Die Züge kann man dadurch eingeben, dass man schlicht die Figuren zieht. Die Figuren sind magnetisch und Sensoren reagieren darauf, ob auf einem Feld eine Figur steht oder nicht. Bei vielen Computern, wie auch beim Super Mondial, musste man mit der Figur noch kurz das Feld „antippen“, da diese nur mit Drucksensoren und nicht mit Magnetkontakten ausgestattet waren. Die Züge des Computers werden über LEDs am Rand oder in den Ecken der Felder angezeigt, nur die Figuren muss der Mensch dann doch für den Computer bewegen.

Komfortabler als am Bildschirm ist es allemal, denn die Bildqualität auf dem Monitor der damaligen Homecomputer war bei weitem nicht so gut wie heute und konnte auch mal ziemlich stark flimmern. Außerdem hatten die Computer nicht unbedingt eine Maus.

Ein Schachcomputer ist sofort nach dem Einschalten spielbereit, ein Schachprogramm auf einem normalen Computer muss man erst einmal laden. Das bedeutete damals, als die meisten Rechner für den Hausgebrauch noch keine Festplatte hatten, von Diskette oder sogar noch langsamer von der „Datasette“, also vom Band.

Aber vor allem: Damals hatte längst nicht jeder Schachspieler einen Computer zuhause!

Und stilvoller als Schach am Bildschirm zu spielen ist es auf einem schönen Holzbrett wie dem Mephisto Exclusive allemal.

Mephisto Exclusive
Mephisto Exclusive

Systemarchitektur

Die Gründe für den Erfolg dedizierter Schachcomputer sind aber auch technischer Natur. An dieser Stelle kommt jetzt die Systemarchitektur ins Spiel, so dass für den folgenden Abschnitt ein wenig Wissen in dem Bereich von Vorteil ist. Der damals am weitesten verbreitete Homecomputer war der C64 von Commodore mit einem Prozessor (CPU) vom Typ 6510 (eine Variante des 6502) und einer Taktfrequenz von etwa 1 MHz. Dieser Prozessor kann 64 Kilobyte adressieren. Dieser Adressraum steht aber nicht komplett für Arbeitsspeicher (RAM) zur Verfügung. Ein Teil wird für den Nur-Lese-Speicher (ROM) mit dem Betriebssystem gebraucht und ein Teil für die Ansteuerung der Peripherie, also zum Beispiel Bildschirm, Diskettenlaufwerk und Tastatur. Nach dem Einschalten bleiben so nur wenig mehr als die Hälfte der 64 KB für RAM übrig. Tatsächlich hatte der C64 aber volle 64 KB RAM, die über sogenanntes Bank Switching angesteuert werden konnten. Dabei wird der 64 KB Adressraum in mehrere Bereiche, die sogenannten Bänke, unterteilt, in die jeweils in einer umschaltbaren Zuordnung ein Teil des RAM, ROM oder der Peripherie eingeblendet wird. Der komplette Speicher ist somit niemals gleichzeitig nutzbar und die Umschaltung kostet Zeit.

Der Super Mondial dagegen hat eine 6502-CPU mit 4 MHz, das Herz schlägt also schon einmal bedeutend schneller als das des C64. Außerdem schleppt ein Schachcomputer wesentlich weniger Ballast mit sich herum, der für das Schachspielen nicht gebraucht wird, zum Beispiel braucht es keine aufwändige Grafik und keine BASIC-Programmiersprache. Die 64 KB Adressraum stehen somit fast komplett für das Schachprogramm und RAM zur Verfügung. Ein bisschen geht natürlich trotzdem für Peripherie ab, schließlich hat auch ein Schachcomputer eine Tastatur, eine Anzeige und Sensoren im Brett für die Zugeingabe. Aber so etwas wie Bank Switching braucht man nicht. Abgesehen davon braucht sich das Schachprogramm nicht darum zu kümmern, Schachfiguren auf den Bildschirm zu malen, was kostbare Rechenzeit spart.

Ein Schachprogramm läuft also auf einem dedizierten Schachcomputer unter deutlich besseren Bedingungen als auf einem Homecomputer, die gleiche Schach-Engine spielt also allein schon deswegen auf einem Schachcomputer besser als auf einem normalen Homecomputer dieser Zeit.

Außerdem hatten damals die kommerziellen Schachcomputer-Hersteller auch die besseren Programme, aber über die Software soll es dann im zweiten Teil gehen.

Weiterhin außer Kontrolle

Am 28. November fand im Museum für Kommunikation in Frankfurt aus Anlass der noch bis 23. Februar laufenden Ausstellung „Außer Kontrolle? Leben in einer überwachten Welt“ (siehe auch den älteren Eintrag hier) eine Podiumsdiskussion mit dem Thema „Freiheit vs. Sicherheit“ statt.

Podiumsdiskussion im Museum für Kommunikation in Frankfurt
v.l.n.r.: Erich Schmidt-Eeenboom, Publizist und Geheimdienstexperte, Günter Wallraff, Enthüllungsjournalist und Schriftsteller, Dirk Emig, Moderator und Bernd Carstensen, ehem. stellv. Bundesvorsitzender des Bundes Deutscher Kriminalbeamter

Im Zuge der NSA-Affäre bekam die schon bedeutend länger geplante Ausstellung eine ganz neue Aktualität. Während weitere Enthüllungen von einer Diskussionsrunde natürlich nicht zu erwarten waren, so konnte man sich doch an einer sehr unaufgeregten und erfrischend wenig schwarz-weiß-malerischen Debatte erfreuen. So wies zum Beispiel Bernd Carstensen, einerseits Befürworter der Vorratsdatenspeicherung, mehr als ein Mal darauf hin, dass die in Teilen der Bevölkerung weit verbreitete Einstellung, man habe doch nichts zu verbergen und deswegen sei die Bespitzelung durch die Dienste doch nicht so schlimm, falsch ist und ausgetrieben gehört. Erich Schmidt-Eeenboom rief ins Gedächtnis, dass die Fähigkeiten der Geheimdienste auch vor Snowden schon lange bekannt waren, während Günter Wallraff, früher und vielleicht heute immer noch selbst Betroffener von Überwachung, teils recht vergnügliche Geschichten aus der Vergangenheit zu erzählen hatte.

Am Ende stand unter anderem die Erkenntnis, dass es innerhalb der Geheimdienste Zellen gibt, die sich unter dem Druck, konstant Informationen liefern zu müssen, verselbständigt haben. Es sind also die Dienste, die hier außer Kontrolle geraten sind.

Lohnt sich dieses Update?

tl;dr: Mavericks gut, iWork eher mau.

Apple hat neue Versionen von Mac OS X, den iWork-Anwendungen Keynote, Pages und Numbers und den iLife-Anwendungen iPhoto und GarageBand herausgebracht. Im Gegensatz zu früheren Updates sind sie kostenlos, aber lohnen sie sich auch? Nach ersten Tests fällt meine Antwort darauf sehr unterschiedlich aus. Vor ein paar Tagen hat sich übrigens auch der Webanhalter mit Mac OS X Mavericks beschäftigt.

Beim Betriebssystem scheint es endlich wieder so zu sein, dass man die neue Version gefahrlos installieren kann, ohne mindestens bis zum zweiten Bugfix zu warten. In den alten Zeiten von Mac OS X war es so, dass jede neue Betriebssystem-Version ein wenig mehr Performanz brachte, aber spätestens seit Lion konnte man getrost die ungeraden Major-Releases überspringen, ohne was zu verpassen. Nun ist Mavericks eine ungerade Version, trotzdem habe ich den Selbstversuch gewagt und das Upgrade gleich installiert. Tatsächlich kommt es mir bisher so vor, dass das System gefühlt irgendwie runder läuft und aufgrund des neuen Schedulers sogar der Stromverbrauch im Akku-Betrieb gesunken ist. Außerdem ist Safari wieder performanter geworden und muss sich jetzt erst einmal wieder dem Belastungstest als mein Standardbrowser unterziehen. Beim Betrieb mit zwei Bildschirmen gibt es Verbesserungen: Die Menüleiste und das Dock kann jetzt auf beiden Bildschirmen angezeigt werden und erscheint nicht immer nur dort, wo man sie gerade nicht braucht. Auf jedem Bildschirm kann nun ein jeweils anderes Programm im Vollbildmodus laufen. Beim Design des Kalenders und des Adressbuchs wurde auf die „Lederoptik“ verzichtet, die beiden Anwendungen passen meiner Ansicht nach jetzt wieder besser zum Gesamtsystem. Benutzt man X11-Anwendungen, wird man bei der ersten Benutzung nach dem Upgrade zu einer Neuinstallation von XQuartz aufgefordert. Tut man das, funktioniert alles wieder wie gehabt. Gut nur, wenn man davon nicht erwischt wird, wenn man gerade mit seinem MacBook irgendwo ohne Internetanbindung unterwegs ist.

Leider ist mein erster Eindruck bei den anderen Updates nicht ganz so gut.

In der Kombination iTunes und iOS 7 ist keine direkte Synchronisation des Kalenders und Adressbuchs ohne Cloud mehr vorgesehen. Apple will wohl die Benutzer zur Nutzung der iCloud drängen. Glücklicherweise gibt es Alternativen: Wer sich ein wenig Platz bei einem Web-Hoster leistet oder sowieso schon hat und ein wenig Aufwand nicht scheut, kann sich mit ownCloud seine eigene Cloud aufbauen. Systemvoraussetzungen sind Apache und PHP, eine Datenbank wird nicht benötigt. Neben Kalender und Adressbuch ist auch eine Dateisynchronisation wie bei Dropbox möglich, es gibt Clients für alle gängigen Betriebssysteme einschließlich Mac OS X und iOS. Aber wir entfernen uns vom Thema. Der Punkt hier ist: Nutzt man ohnehin Cloud-Synchronisation, stört einen diese Einschränkung nicht. Für alle anderen ist es unangenehm.

Die erste aktualisierte Anwendung, die sich gleich wieder von meinem System verabschieden musste, ist GarageBand. Zunächst einmal das Positive an der neuen Version: Ebenso wie bei den iWork-Anwendungen wird auch bei GarageBand die alte Version beim Update nicht überschrieben, sondern bleibt erhalten.

Ich habe GarageBand bisher dazu benutzt, Podcasts zu erstellen. Leider ist genau diese Funktion in der neuen Version weggefallen. Da ich Audio-Mitschnitte meiner Vorlesungen aber gerne mit Kapitelmarken und Bildeinblendungen versehe und das offenbar nicht mehr geht, ist das aktualisierte GarageBand für mich uninteressant. Wenn Apple nicht die Podcast-Funktion nachliefert, muss ich mich wie sicher auch einige andere Podcast-Ersteller wohl nach Alternativen umsehen oder einfach bei der alten Version bleiben.

Mein erster Eindruck der iWork-Anwendungen ist auch eher schlecht. Als Hochschullehrer ist die am meisten von mir genutzte Anwendung Keynote. Beim Öffnen einer Vorlesungspräsentation aus dem letzten Semester wurde ich mit folgender Meldung begrüßt:

An der Präsentation wurden einige Änderungen vorgenommen
An der Präsentation wurden einige Änderungen vorgenommen

Doch das war nicht die einzige Änderung. Offenbar hat sich irgendwo ganz subtil was bei den Abmessungen der graphischen Elemente verschoben, so dass in die Erläuterungs-Sprechblasen zu meinem Entity-Relationship-Diagramm der Text nicht mehr hinein passt.

Adressdatenbank in Keynote mit Formatierungsfehler
Adressdatenbank in Keynote mit Formatierungsfehler

Weiter hinten im Dokument ist mir dann auch klar geworden, was mit der ursprünglichen Meldung gemeint war.

Zerschossene Tabelle
Zerschossene Tabelle

In der Original-Version der Präsentation sollte eine Tabelle die andere nach einer kurzen Übergangsanimation verdecken. Da die Zellen der Tabelle aus welchen Gründen auch immer nun transparent und nicht mehr undurchsichtig weiß sind, funktioniert das nicht mehr und das Ergebnis ist auf dem Screenshot zu sehen.

Es ist mir völlig unverständlich, warum in der aktuellen Version meine alten Dokumente nicht ohne Formatierungsfehler importiert werden können. Wenn ich nun wirklich allen ernstes jede zweite Vorlesung wegen solcher Formatierungsfehler überarbeiten muss, ist leider auch die neue Keynote-Version für mich so gut wie wertlos.

Wenn ich nicht noch irgendwelche grundlegend bahnbrechenden Dinge im neuen Keynote finde, werde ich auch bei dieser Anwendung wohl erst einmal zur alten Version zurückkehren. Bis jetzt ist mir aber erst mal vor allem aufgefallen, dass die Vorlagen für neue Präsentationen anders sind. Davon ist nicht einmal die standard-weiße Vorlage verschont geblieben, die jetzt nicht mehr in der Schriftart Gill Sans sondern neu in Helvetica daher kommt. Dumm nur, dass ich meine bisherigen Präsentationen in eben dieser schnörkellosen Standardvorlage erstellt habe und ich für neue Präsentationen nun erst einmal die Vorlage anpassen muss, damit das Design konsistent bleibt. Unnötig zu erwähnen, dass sich die mit der neuen Version erstellten Dokumente nicht mehr ohne explizites Exportieren in der alten Version öffnen lassen.

Numbers und Pages wurden von mir seit dem Update noch nicht ausgiebig genug genutzt, um mir ein Urteil bilden zu können. Laut Berichten anderer Benutzer wurde wohl allen ernstes unter anderem die Serienbrieffunktion weggelassen. Kann das sein, dass wirklich eine Funktion entfernt wurde, die eigentlich seit vielen Jahren zum Standard gehört?

Ziel des iWork-Updates ist wohl, die iOS- und Mac OS-Versionen anzugleichen. Aber warum muss das unbedingt auf Kosten des Funktionsumfangs der „großen“ Version gehen? Auch auf die iCloud wird als neues Feature verwiesen, aber die ist eher uninteressant, wenn man nicht wirklich übers Web mit anderen zusammen an einem Dokument arbeitet oder aber schlicht seine Dokumente nicht aus der Hand geben will.

Mein Fazit ist also, dass sich das Update auf Mavericks durchaus gelohnt hat, die iWork-Anwendungen aber sogar schlechter geworden sind. Hier muss Apple dringend nachbessern. Ein kostenloses Update zu liefern, nur um die iCloud zu forcieren, ist jedenfalls nicht in meinem Sinn.

Außer Kontrolle

Im Frankfurter Museum für Kommunikation wird noch bis zum 23. Februar 2014 die Ausstellung „Außer Kontrolle“ gezeigt, die sich mit staatlicher, aber auch sozialer Kontrolle und Überwachung befasst. Dieses sowie weitere aktuelle Ereignisse sind Grund für mich, ein weiteres Mal über das Mitlesen von Kommunikation und Möglichkeiten, sich dem zu entziehen, zu schreiben.

Technisches

Vor ein paar Tagen wurde bekannt, dass die Website des bekannten Kurznachrichtendiensts WhatsApp erfolgreich angegriffen wurde. Dem Bericht zufolge bestand zwar kein Zugriff auf die Kurznachrichten selbst, jedoch wäre es mit der verwendeten Angriffstechnik (DNS-Spoofing) durchaus möglich, sich als „Man in the Middle“ in die Kommunikation einzuschalten. Zeit also, sich nach Alternativen umzusehen. Was man unter Ende-zu-Ende-Verschlüsselung mit asymmetrischer Kryptographie versteht, war schon Thema hier im Blog. Doch welche Dienste bieten das?

Biegekoppler zum Ableiten von Informationen aus einer Glasfaser in der Ausstellung "Außer Kontrolle" im Museum für Kommunikation, Frankfurt
Biegekoppler zum Ableiten von Informationen aus einer Glasfaser in der Ausstellung „Außer Kontrolle“ im Museum für Kommunikation, Frankfurt

Apples iMessage-Dienst verwendet laut Herstellerangaben nicht näher spezifizierte Ende-zu-Ende-Verschlüsselung. Das Protokoll und der Schlüsseltausch-Mechanismus sind jedoch nicht transparent. Schon aus der Eigenschaft, dieselbe Nachricht gleichzeitig auf mehreren Endgeräten empfangen zu können, wird klar, dass der private Schlüssel nicht auf einem Gerät bleibt, sondern zwischen mehreren eigenen Geräten übertragen wird. Die Schlüsselerzeugung ist ebenfalls nicht transparent. Man muss wohl spätestens nach den Vorgängen um den Anbieter verschlüsselter Kommunikation Lavabit davon ausgehen, dass Apple als US-amerikanisches Unternehmen im Falle einer Anfrage der Behörden reagieren muss und technisch auch die Möglichkeit hat, Zugriff auf den privaten Schlüssel zu bekommen.

Eine Alternative ist Threema. Zwar ist diese App ebenfalls nicht quelloffen, aber immerhin ist die Funktionsweise der Verschlüsselung und des Schlüsseltauschs dokumentiert. Der private Schlüssel wird auf dem Endgerät erzeugt und verbleibt dort, somit hat auch der Anbieter selbst keine Möglichkeit, die Kommunikation zu entschlüsseln. Ferner bietet Threema dem Anwender die Möglichkeit, Fingerabdrücke öffentlicher Schlüssel mittels QR-Code offline abzugleichen und so sicherzustellen, dass der beabsichtigte Kommunikationspartner auch jederzeit wirklich der ist, der er zu sein vorgibt.

Soziales

Doch warum sollte man sich nun als Einzelner überhaupt Gedanken darüber machen? Ist es überhaupt schlimm, konstant beobachtet zu werden, wenn man doch nichts zu verbergen hat?

Ja, das ist es! Wer sich beobachtet fühlt, ändert sein Verhalten. Nur das ist der Grund, warum Videoüberwachung überhaupt „funktioniert“. Einen Abschreckungseffekt und somit die einzige Chance, irgendetwas tatsächlich zu verhindern, kann Überwachung ja gerade nur deshalb haben, weil der Betroffene weiß, dass er überwacht wird. Wie gut eine solche subtile Einflussnahme auch in anderem Kontext funktioniert, hat kürzlich eine Studie gezeigt. Mancher Kommentar geht sogar so weit und sagt, das Fehlen privater Rückzugsräume gefährde die Demokratie.

Überwachungskamera in der Ausstellung "Außer Kontrolle" im Museum für Kommunikation, Frankfurt
Überwachungskamera in der Ausstellung „Außer Kontrolle“ im Museum für Kommunikation, Frankfurt

Natürlich spielt bei all diesen Betrachtungen auch eine Rolle, in wie weit wir Vertrauen darin haben, dass der Staat seine Möglichkeiten nicht missbraucht. Beschwichtigungsversuche wie die eines Herrn Pofalla, der sich von einem ausländischen Geheimdienst versichern lässt, es sei schon alles gesetzlich gewesen, wirken da wie Hohn, wenn sich schon im eigenen Land der Bundesverfassungsschutz nicht an die Gesetze hält. Die jetzt für verfassungswidrig erklärte Überwachung des Abgeordneten Bodo Ramelow ist nicht der erste Fall dieser Art. So wurde in einem ähnlichen Fall im Jahr 2011 gerichtlich festgestellt, dass die jahrelange Überwachung des Bürgerrechtlers Rolf Gössner durch den Verfassungsschutz verfassungswidrig war.

Aber sollten wir nicht, selbst wenn eine Überwachung ungerechtfertigt erfolgt, darauf vertrauen können, dass uns die dadurch erlangten Erkenntnisse nicht zum Nachteil gereichen, wenn wir uns nicht strafbar gemacht haben?

Leider ist das nicht so einfach. Zwar können wir in Deutschland unsere Meinung frei äußern und nach Belieben beispielsweise die Regierung kritisieren, ohne dass uns das zum Verhängnis wird. Aber das Klima in einem Land kann sich schnell ändern. Man sehe sich nur einmal Ungarn an, um im Herzen Europas bedenkliche Tendenzen auszumachen.

Außerdem arbeiten auch in Geheimdiensten nur Menschen. Es reicht doch schon, wenn darunter nur einer ist, der seine Position ausnutzt und Informationen in die falschen Hände weitergibt. Was wäre, wenn ein einzelner irregeführter Mitarbeiter des spanischen Geheimdienstes bei Spotify mal nachsieht, wer gerne katalanische Kampflieder hört? Diese Information wäre für Kriminelle, die gerne einmal eine bewaffnete Volkszählung durchführen würden, sicher interessant.

Fazit

Was sollte man nun aus all dem folgern? Für sich selbst den Versuch zu starten, sich der flächendeckenden Überwachung zu entziehen, indem man Verschlüsselung nutzt, ist schön, aber reicht nicht aus. Es ist ein gesellschaftliches Problem, dass Einschnitte in die Privatsphäre unter dem Deckmantel der Sicherheit nicht als Gefahr erkannt werden. Die negativen Folgen werden ignoriert, verdrängt oder sogar aktiv verneint. Das muss aufhören! Ich will mich jedenfalls nicht aus Gründen der Beobachtung konstant verstellen und sei es auch nur unbewusst.

MacBook Pro 2010 aufrüsten?

Kurzfassung

RAM von 4 auf 8 GB aufrüsten kostet wenig, ist wenig Aufwand und bringt viel, zum Beispiel bei Bildbearbeitung. Tausch der Festplatte gegen SSD oder Ersatz des DVD-Laufwerks mit einer zweiten Festplatte oder SSD ist eine Option, die potenziell ebenfalls viel bringt, die ich aber noch nicht selbst ausprobiert habe. Die neuesten Spiele werden aber trotzdem nicht laufen, da der Graphikchip schon zu alt ist und nicht getauscht werden kann.

Die Vollversion

MacBook Pro 2010 aufrüsten? weiterlesen

Kryptographie, Teil 6: Asymmetrische Verschlüsselung

Die in den bisherigen Teilen behandelten Verfahren hatten alle eins gemein: Sender und Empfänger einer geheimen Nachricht mussten sich vor dem Versand auf einen gemeinsamen Schlüssel einigen, der auf einem sicheren Kanal übergeben werden musste. Es handelte sich um sogenannte symmetrische Verschlüsselungsverfahren.

Das funktioniert dann sehr gut, wenn wenige Personen, die zudem die Gelegenheit haben, Schlüssel persönlich zu tauschen, miteinander kommunizieren wollen. Im Internet dagegen funktioniert das so nicht. Wer eine verschlüsselte Webseite besucht, möchte Daten abhörsicher übetragen, hat aber normalerweise keine Gelegenheit dazu, mit dem Betreiber der Seite vor der eigentlichen Datenübertragung abhörsicher Schlüssel auszutauschen.

Kommunikation

Mit der Entdeckung der Public-Key-Kryptographie Ende der 1970er Jahre wurde hier ein Durchbruch erzielt. Sogenannte asymmetrische Verschlüsselungsverfahren arbeiten mit zweigeteilten Schlüsseln. Der Schlüssel, der zum Chiffrieren einer Nachricht verwendet wird, ist ein anderer als der, mit dem die Nachricht wieder entschlüsselt werden kann. Da es mit ersterem Schlüssel nicht möglich ist, einen Geheimtext wieder zu dechiffrieren, braucht er auch nicht geheim gehalten zu werden. Nur der zweite Schlüssel muss geheim gehalten werden und nur der Empfänger muss ihn kennen, der Sender nicht. Es entfällt also die Notwendigkeit, einen gemeinsamen Schlüssel über einen sicheren Kanal auszutauschen, denn der öffentliche Schlüssel, der zum Verschlüsseln ausreicht, ist eben öffentlich und kann somit über den selben unsicheren Kanal ausgetauscht werden wie der Geheimtext!

Doch wie ist das möglich? Es gibt in der Mathematik sogenannte Einwegfunktionen. Diese haben die Eigenschaft, dass sie sich leicht berechnen lassen, ihre Umkehr jedoch nicht. Ein Beispiel dafür ist die Multiplikation zweier großer Primzahlen (leicht) und als Umkehr die Zerlegung des Produkts in seine Primfaktoren (schwer). Oder kurz: n = p * q lässt sich leicht berechnen, aber p und q lassen sich nicht direkt berechnen, wenn nur n bekannt ist. Allerdings gibt es eine Hintertür: Wenn man nicht nur die Zahl n kennt, sondern auch q, kann man p wieder leicht berechnen. Und auf einer Erweiterung genau auf dieses Prinzips basiert der 1978 vorgestellte RSA-Algorithmus.

Der RSA-Algorithmus hat wegen seiner Asymmetrie eine hohe praktische Relevanz bis heute. Doch bevor wir zur praktischen Anwendung kommen, zunächst noch ein klein wenig zum Hintergrund, wie der RSA-Algorithmus funktioniert, denn im Grund ist es gar nicht so schwer. mod ist dabei der Modulo-Operator, also der Rest einer ganzzahligen Division.

RSA-Algorithmus

 

Vorbereitung:

1. Wähle zwei große Primzahlen p und q
2. Berechne n = p * q
3. Berechne ϕ(n) = (p-1)*(q-1)
4. Wähle e teilerfremd zu ϕ(n)
5. Bestimme d mit e*d mod ϕ(n) = 1

Öffentlicher Schlüssel: e und n
Privater Schlüssel: d

Verschlüsseln eines Klartextes m in Geheimtext c:
c = me mod n

Entschlüsseln eines Geheimtextes c in einen Klartext m:
m = cd mod n

 

Genauer kann man das noch unter anderem bei Beutelspacher [1] oder natürlich direkt bei den Entdeckern von RSA, den Herren Rivest, Shamir and Adleman, nachlesen [2]. Wie man erkennt, steht und fällt die Sicherheit dieses Verfahrens damit, dass man auch bei Kenntnis des Geheimtextes, des Klartextes und des öffentlichen Schlüssels nicht den privaten Schlüssel berechnen kann. Außerdem darf sich der Klartext nur mit Kenntnis des privaten Schlüssels aus dem Geheimtext berechnen lassen. Oder mathematisch gesagt: Auch, wenn man c, m, e und n kennt, kann man d nicht berechnen und wenn man c kennt, kann man m nur berechnen, wenn man auch d kennt. Wenn man jetzt noch etwas genauer schaut, dann sieht man, dass sich das alles berechnen ließe, könnte man die Zahl n, die ja Teil des öffentlichen Schlüssels ist, in ihre Primfaktoren p und q zerlegen. Sollte jemand also eine effektive Methode zur Primfaktorzerlegung großer Zahlen finden, wäre das RSA-Verfahren gebrochen.

Mit sogenannten Public-Key-Verschlüsselungen wie RSA ist es also nun kein Problem mehr, auch mit Unbekannten verschlüsselt und abhörsicher zu kommunizieren. Das Problem des vorherigen Schlüsselaustauschs, das bei den symmetrischen Verschlüsselungsverfahren besteht, ist nun keins mehr. Der Ablauf der Kommunikation ist nun ganz einfach. Anke und Andreas haben jeweils zwei Schlüssel, einen öffentlichen und einen privaten. Der öffentliche Schlüssel kann allgemein bekannt gegeben werden. Möchte nun Anke eine verschlüsselte Nachricht an Andreas schicken, muss sie sich zunächst seinen öffentlichen Schlüssel besorgen. Den findet sie zum Beispiel auf seiner Webseite oder aber in einem Schlüsselverzeichnis im Internet, einem sogenannten Keyserver, der ähnlich wie ein Telefonbuch für das Nachschlagen von Personen, Mailadressen und dem dazu passenden Public Key erlaubt. Wenn Anke den öffentlichen Schlüssel von Andreas besorgt hat, benutzt sie diesen Schlüssel, um die Nachricht an Andreas zu verschlüsseln. Die verschlüsselte Nachricht schickt sie ab und nur Andreas kann sie wieder in Klartext verwandeln, weil nur er den passenden privaten Schlüssel hat.

Public Key Kryptographie

Allerdings kommt nun ein anderes Problem neu hinzu: Wie kann Anke sicher sein, dass der öffentliche Schlüssel von Andreas wirklich ihm gehört und nicht heimlich von einem Bösewicht ersetzt wurde? Ein Angreifer, der in der Lage ist, sich zwischen die beiden zu schalten, könnte Anke seinen eigenen öffentlichen Schlüssel statt den von Andreas unterschieben, die Nachrichten mit seinem eigenen privaten Schlüssel entschlüsseln und mitlesen und zum Schluss mit Andreas‘ echtem öffentlichen Schlüssel wieder verschlüsseln und an ihn weiter schicken.

Diesen Angriff nennt man auch Man-in-the-Middle-Attack, weil der Angreifer zwischen den beiden legitimen Kommunikationspartnern sitzt. Doch warum ist dieser Angriff in der Praxis so gefährlich? Stellen wir uns vor, wir wollen Online-Banking betreiben und uns dabei einer verschlüsselten Verbindung bedienen. Wir können uns nun den öffentlichen Schlüssel der Bank besorgen und unsere Überweisungsdaten senden. Nur wer garantiert, dass wir wirklich mit der Bank direkt Verbindung aufgenommen haben und nicht mit einem Bösewicht, der uns vorgaukelt, die Bank zu sein? Um uns zu täuschen, könnte ein solcher Angreifer im Hintergrund unsere Anfrage an die Bank und die Antwort der Bank an uns durchleiten und nur mithören, um im entscheidenden Moment, wenn wir eine Überweisung tätigen, seine eigene Kontonummer und einen höheren Betrag einzusetzen.

Wir brauchen also eine Garantie, dass der öffentliche Schlüssel auch echt ist. Am einfachsten könnten Anke und Andreas diese Garantie bekommen, in dem sie über einen anderen Kanal, zum Beispiel am Telefon oder am besten persönlich, die öffentlichen Schlüssel (oder eine Prüfsumme davon, den sogenannten Fingerprint) vergleichen. Bei diesem Abgleich ist es nicht entscheidend, dass Anke und Andreas nicht abgehört werden, denn die dabei ausgetauschte Information ist ja nicht geheim. Es muss nur sichergestellt sein, dass ein Angreifer diese Information nicht verändern kann.

Man-in-the-Middle-Angriff
Man-in-the-Middle-Angriff

Praktischerweise können Public-Key-Verschlüsselungsalgorithmen wie RSA so „zweckentfremdet“ werden, dass sie nicht verschlüsseln, sondern stattdessen die Echtheit einer Nachricht garantieren! Man muss dazu eine Nachricht (oder eine Prüfsumme davon) mit seinem privaten Schlüssel verschlüsseln. Ein Empfänger kann die Nachricht dann mit dem öffentlichen Schlüssel des Absenders entschlüsseln. Wenn dabei der Klartext herauskommt, ist garantiert, dass die Nachricht tatsächlich unverändert vom Absender kommt, denn nur der Absender hat Kenntnis seines privaten Schlüssels und nur wenn die Nachricht damit verschlüsselt wurde, wird mit dem öffentlichen Schlüssel wieder der Klartext sichtbar.

Die asymmetrische Kryptographie wurde also gar nicht zur Verschlüsselung, sondern zur digitalen Signatur eingesetzt, die wie eine handschriftliche Unterschrift die Echtheit einer Nachricht garantiert.

Das ist schon mal gut, man kann also mit digitalen Signaturen die Authentizität und Integrität von Nachrichten prüfen, aber noch haben wir das ursprüngliche Problem nicht gelöst, da wir ja die Authentizität des öffentlichen Schlüssels an sich prüfen müssen!

Die Lösung besteht darin, dass eine dritte Stelle, der sowohl Anke als auch Andreas vertrauen, den öffentlichen Schlüssel von Andreas digital signiert. Man spricht dann auch davon, dass diese dritte Stelle durch diese Signatur ein Zertifikat erstellt hat, das die Echtheit garantiert. Wenn Anke den öffentlichen Schlüssel der Zertifizierungsstelle kennt, kann sie nun mit dem Zertifikat die Echtheit des öffentlichen Schlüssels von Andreas prüfen. Damit das funktioniert, muss aber immer noch der öffentliche Schlüssel der Zertifizierungsstelle sicher übertragen werden. Außerdem müssen, wie schon geschrieben, Anke und Andreas der Zertifizierungsstelle vertrauen, deswegen nennt man diese auch Trust Center. Bis jetzt klingt das erst mal so, als hätten wir durch die Einführung des Trust Centers noch nicht viel gewonnen, da wir ja immer noch einen öffentlichen Schlüssel, den des Trust Centers, haben, den wir vor unerlaubter Veränderung geschützt verteilen müssen. Wenn wir aber dieses Problem auf das Internet übertragen, so sehen wir, dass tatsächlich eine Vereinfachung eingetreten ist: Wir müssen nicht mehr für jede beliebige Webseite selbst prüfen, ob der öffentliche Schlüssel stimmt, wenn diese ein Zertifikat eines Trust Centers vorweisen kann. Die öffentlichen Schlüssel des Trust Centers bekommen wir schon mit dem Browser oder dem Betriebssystem mitgeliefert! Das Gesamtsystem mit Zertifizierungsstellen und Schlüsselverteilung nennt man auch Public-Key-Infrastruktur.

Wenn man mal bei einer Webseite, die mit HTTPS beginnt, auf der Adresszeile des Browsers an die richtige Stelle klickt, bekommen wir die wichtigsten Informationen eines solchen Zertifikats direkt angezeigt, wie hier zum Beispiel von der Frankfurter Sparkasse, deren öffentlicher Schlüssel in seiner Echtheit von der VeriSign Inc. bestätigt wurde.

Frankfurter Sparkasse

Mit einem Klick auf „Weitere Informationen“ kann man noch viele Details erfahren, zum Beispiel welches genaue Verschlüsselungsverfahren verwendet wird, für welche Web-Adressen das Zertifikat genau gilt, wann es abläuft und so weiter. Es lohnt sich durchaus, sich das einmal genauer anzuschauen. Im übrigen wird die eigentliche Kommunikation symmetrisch verschlüsselt, mit dem asymmetrischen Verfahren wir nur ein temporärer Sitzungsschlüssel übertragen. Ein Grund dafür ist, dass Public-Key-Verfahren wie RSA sehr viel langsamer sind als symmetrische Verfahren wie das in der letzten Folge angesprochene AES. Außerdem sind sie anfälliger für bestimmte Arten von Angriffen. Man spricht von einem hybriden Kryptosystem, wenn symmetrische und asymmetrische Verfahren kombiniert werden.

Doch wo können wir nun Public-Key-Kryptographie einsetzen?

In der Praxis wird Public-Key-Kryptographie in der Variante wie beschrieben mit zentralen Zertifizierungsinstanzen (auch Certification Authority oder CA genannt) für sicheres Surfen im Web mit den Protokollen HTTPS bzw. SSL/TLS eingesetzt.

Für E-Mails gibt es das Protokoll S/MIME, das von den meisten Mailprogrammen unterstützt wird und ebenfalls auf von CAs signierte Zertfifikate setzt. Außerdem ist bei E-Mails das Protokoll PGP sehr weit verbreitet. Freie Implementierungen dieses Protokolls sind GnuPG bzw. Gpg4Win für Windows und GPGTools für den Mac. Wer Thunderbird als Mailprogramm verwendet, sollte sich das Plugin Enigmail anschauen. PGP basiert nicht auf zentralen CAs für die Echtheitsprüfung, stattdessen können Nutzer, die sich kennen, ihre öffentlichen Schlüssel gegenseitig signieren und somit selbst als Zertifizierungsinstanz für andere auftreten. Bei dieser dezentralen Public-Key-Infrastruktur spricht man vom Web-of-Trust.

Wer eine sichere Alternative zu SMS oder WhatsApp sucht, der sollte sich Threema anschauen. Anders als bei Apples iMessage, das laut Hersteller ebenfalls Ende-zu-Ende-Kryptographie verwendet, wird bei Threema der Schlüssel auf dem eigenen Endgerät erzeugt und nur der öffentliche Schlüssel zu einem Keyserver übertragen. Die Echtheit der Schlüssel kann bei einem persönlichen Kontakt über einen QR-Code verifiziert werden.

Ich kann nur jedem empfehlen, sich mit diesen Programmen zu beschäftigen und in Zukunft Mails und Kurznachrichten verschlüsselt zu versenden. Es tut nicht weh, ist innerhalb von ein paar Minuten eingerichtet und wer diesen Artikel bis hier gelesen hat, sollte die Grundprinzipien soweit verstanden haben.

Zum Abschluss in aller Kürze eine Zusammenfassung:

  • Es gibt asymmetrische Verschlüsselungsverfahren mit öffentlichen Schlüsseln zum Chiffrieren und privaten Schlüsseln zum Dechriffrieren.
  • Diese Systeme können auch für digitale Signaturen, also zur Prüfung von Authentizität und Integrität von Nachrichten, verwendet werden.
  • Die privaten Schlüssel darf man niemals herausgeben.
  • Bei öffentlichen Schlüsseln muss sichergestellt sein, dass sie wirklich zu dem Kommunikationspartner gehören, mit dem man Nachrichten austauschen möchte, sonst ist eine Man-in-the-Middle-Attack möglich. Die Prüfung kann durch von Zertifizierungsstellen ausgegebene Zertifikate geschehen.
  • Die Verbindung ist nur sicher, wenn die Nachricht beim Sender verschlüsselt und beim Empfänger wieder entschlüsselt wird, die Nachricht also auf der ganzen Strecke verschlüsselt bleibt. Man spricht dann von Ende-zu-Ende-Kryptographie.

Mit diesem Teil ist meine kleine Serie über Kryptographie abgeschlossen. Ich hoffe, es hat allen Lesern Spaß gemacht, mir von den alten Griechen bis in die Neuzeit zu folgen und ein wenig zum Verständnis beigetragen. Ich hoffe auch, dass ich vielleicht ein paar von Euch dazu motivieren kann, sich mit PGP zu beschäftigen und in Zukunft verschlüsselte Mails zu verschicken, damit es die NSA nicht all zu leicht hat. Ich freue mich über Feedback und verschlüsselte Mails, mein Public Key ist auf meiner Homepage und wer mag, kann mir auch eine Nachricht über Threema auf mein Smartphone schicken!

NSA hört nicht mit

Quellen und weiterführende Literatur:

[1] Albrecht Beutelspacher, Heike B. Neumann und Thomas Schwarzpaul: Kryptografie in Theorie und Praxis

[2] Ron L. Rivest, Adi Shamir und Leonard Adleman: A Method for Obtaining Digital Signatures and Public-Key Cryptosystems

NSA und der Angriff auf Verschlüsselung: Wie funktioniert das?

Die deutschen und internationalen Medien berichten heute darüber, dass die NSA die SSL-Verschlüsselung geknackt habe. Doch über die genaue Funktionsweise ist nicht viel bekannt, da die primären Quellen, der Guardian und die New York Times, einige Details, die sich in den Snowden-Dokumenten finden, absichtlich zurückhalten. Doch wenn man sich nur ein bisschen mit Kryptographie auskennt und Eins und Eins zusammenzählen kann, bleiben nicht viele Möglichkeiten übrig. Hier also eine kleine Auflistung der Angriffsmöglichkeiten und meine Spekulationen über das Wie und Warum der Vorgehensweise der NSA.

1. Zugriff auf die privaten Schlüssel der Zertifizierungsstellen

Die in SSL verwendete Public-Key-Infrastruktur setzt darauf, dass Zertifizierungsstellen die Echtheit der öffentlichen Schlüssel der Gegenstellen zertifizieren und somit bestätigen, dass der Kommunikationspartner auch der ist, der er zu sein vorgibt. Damit das funktioniert, müssen die öffentlichen Schlüssel der Zertifierungsstellen (auch Trust Center genannt) auf einem sicheren Weg auf die an der eigentlichen Kommunikation beteiligten Rechner übermittelt werden. Dies geschieht dadurch, dass in gängigen Browser oder auch im Betriebssystem selbst diese Schlüssel bereits mitgeliefert werden.

Hat nun jemand Zugriff auf die privaten Schlüssel der Zertifierungsstelle, kann dieser Angreifer selbst ein Zertifikat erstellen, das die Echtheit der öffentlichen Schlüssel eines Dritten bestätigt. Dadurch werden Man-in-the-Middle-Angriffe, die vom Angegriffenen nicht bemerkt werden, möglich, sofern der Angreifer in der Lage ist, in den Kommunikationsweg zwischen Sender und Empfänger entsprechend einzugreifen. Von letzterem muss man ausgehen, denn schließlich ist der Sinn und Zweck einer jeden Verschlüsselung, die Sicherheit in genau diesem Fall immer noch zu gewährleisten. Von dem, was vor den heutigen Veröffentlichungen schon bekannt war, muss man auch davon ausgehen, dass die US-amerikanischen und britischen Geheimdienste dies können.

Bewertung

Diese Art des Angriffs ist meiner Ansicht nach die wahrscheinlichste. Es genügt rein theoretisch, dass die Geheimdienste Zugriff auf den privaten Schlüssel einer einzigen Zertifizierungsstelle haben, um das System zu kompromittieren. Da sich ein guter Teil dieser Stellen in den USA befinden und von den früheren Berichten bereits bekannt ist, dass an Firmen wie Microsoft und Google Geld gezahlt wurde, um Hintertüren einzubauen, muss man wohl davon ausgehen, dass auch Zertifizierungsstellen betroffen sind. Damit der Angriff möglichst nicht auffällt, sollten natürlich aus Sicht des Angreifers möglichst viele Zertifizierungsstellen infiltriert werden, da die Angegriffenen bemerken könnten, dass der öffentliche Schlüssel seines Kommunikationspartners auf einmal von einem anderen Trust Center verifiziert wurde.

Vorteile

Für den Angreifer hat dieses Vorgehen den Vorteil, dass es bei Zugriff sowohl auf die Netzinfrastruktur als auch auf die Zertifizierungsstellen – beides ist bei den Geheimdiensten gegeben! – sehr leicht durchzuführen und vom Angegriffenen nur schwer bis gar nicht zu bemerken ist. Außerdem ermöglicht es eine weitreichende oder gar flächendeckende Überwachung, wie sie mit einem Angriff auf die Rechner einzelner Ziele nicht möglich wäre. Bei der Zertifizierungsstelle müssen außerdem nicht viele Personen eingeweiht sein, es reicht im Prinzip eine einzige Person, die Zugriff auf den Private Key hat.

Nachteile

Für den Angreifer eigentlich keine, außer dass die Gefahr besteht, dass beim Trust Center oder dem Geheimdienst jemand die sprichwörtliche Pfeife bläst.

Gegenmaßnahmen

Zertifizerungsstellen, die kompromittiert sind, nicht vertrauen. Leider ist derzeit nicht bekannt, welche das sind. Es wäre wohl davon auszugehen, dass die meisten, wenn nicht alle, Trust Center in den USA und wahrscheinlich auch solche aus Kanada, Australien und dem Vereinigten Königreich betroffen sind.

2. Angriff auf die Algorithmen

Bekannte Public-Key-Algorithmen, die im SSL-Protokoll verwendet werden, sind RSA und Diffie-Hellman. Die Sicherheit dieser Verfahren basiert darauf, dass keine schnellen Verfahren bekannt sind, den diskreten Logarithmus einer großen Zahl zu berechnen.

Bewertung

Es ist mathematisch nicht bewiesen, dass es keinen Algorithmus zur Berechnung des diskreten Logarithmus in polynomialer Laufzeit geben kann. In der Forschung hat es vor kurzem Fortschritte zur Entwicklung eines solchen Algorithmus gegeben. Es gibt Stimmen, die davon ausgehen, dass schon in vier bis fünf Jahren RSA nicht mehr sicher ist. Sollte man bei der NSA schon weiter sein als die internationale Forschungsgemeinschaft und ein schneller Algorithmus zur Berechnung des diskreten Logarithmus bekannt sein, wäre der Verschlüsselungsalgorithmus an sich gebrochen. Kryptographie mit elliptischen Kurven gilt aber derzeit noch als bedeutend sicherer als RSA, da das Problem des diskreten Logarithmus auf elliptischen Kurven schwerer zu lösen ist.

Insgesamt muss man aber sagen, dass es zumindest unklar und nicht unbedingt wahrscheinlich ist, dass es wirklich einen effizienten Algorithmus zur Berechnung des diskreten Logarithmus gibt, der der Öffentlichkeit noch nicht bekannt ist und dass die NSA oder ein anderer Geheimdienst das geschafft hat, was Heerscharen von Mathematikern öffentlich versuchen.

Andererseits war es ja auch schon bei DES so, dass nachweislich differentielle Kryptanalyse bei der NSA und bei IBM schon lange bekannt war, bevor diese Angriffsmethode öffentlich wurde.

Vorteile

Hätte die NSA die Algorithmen an sich gebrochen, wäre auch jedes Protokoll, dass auf diesen Algorithmen basiert, unsicher, selbst wenn das Protokoll keine Hintertüren hat.

Nachteile

Auch wenn es effizientere Verfahren als die derzeit bekannten gibt, um den diskreten Logarithmus zu berechnen, wäre vermutlich immer noch ein riesiger Rechenaufwand nötig, um den Geheimtext zu entschlüsseln. Das wäre aber nicht praktikabel für eine flächendeckende Überwachung, allenfalls für das Abhören einzelner Ziele.

Gegenmaßnahmen

Keine. Nach derzeitigem Stand sind Elliptische Kurven und Diffie-Hellman sicherer als RSA (auch wegen der Forward Secrecy bei Diffie-Hellman), aber wenn das mathematische Problem gelöst ist, wären auch diese betroffen.

3. Angriff auf die Endstellen

Ein direkter Angriff auf die Endstellen der Kommunikation, sprich die Rechner der Angegriffenen, ist natürlich auch denkbar, denn dann besteht Zugriff auf den Klartext. Das hat dann aber nichts mehr mit SSL oder irgend einem Protokoll zu tun.

Bewertung

Ein Angriff auf die Endstellen, oder zumindest der Versuch, im Stil eines „Staatstrojaners“ oder gar einer systematischen Hintertüren in Betriebssystem, Browsern oder anderer Software ist natürlich möglich, hat aber vermutlich nichts mit der aktuellen Berichterstattung zu tun.

Vorteile

Zugriff auf den unverschlüsselten Klartext.

Nachteile

Nicht für flächendeckende Überwachung geeignet. Außerdem könnte die Existenz von Hintertüren oder allgemein eines solchen Angriffs im Vergleich zu den anderen Methoden relativ leicht bemerkt werden.

Gegenmaßnahmen

Das eigene System möglichst gegen Angriffe von außen sichern, was eigentlich sowieso „best practice“ ist. Außerdem Software einsetzen, die wahrscheinlich keine Hintertüren hat, also am besten Open Source Software, die man selber kompiliert.

Schlussbetrachtung

Wahrscheinlich geht es bei der heutigen Berichterstattung, auch wenn keine technischen Details genannt wurden, um Variante 1.

Was sollte man davon als Internetnutzer ableiten? Man sollte jedenfalls nicht auf die Idee kommen, auf SSL zu verzichten. Ein Angriff in diesem Stil setzt Möglichkeiten voraus, die ein Geheimdienst hat, aber ein x-beliebiger Krimineller nicht. Also muss man davon ausgehen, dass SSL immer noch genügend Schutz bietet, das eigene Homebanking gegen kriminelle Machenschaften zu sichern, aber nicht dazu, vertrauliche Kommunikation vor Geheimdiensten geheim zu halten. Das heißt insbesondere, dass solche Werbeversprechen wie die von deutschen E-Mail-Anbietern neulich, SSL zur Kommunikation zwischen den Betreibern einzusetzen, Augenwischerei sind, zumal die Mails dann sowieso auf den Servern der Anbieter unverschlüsselt vorliegen.

Um private Kommunikation zu sichern, sollte man auf End-zu-End-Protokolle wie PGP setzen. Dann bleiben als Angriffsmöglichkeiten, auch für Geheimdienste, nur die Varianten 2 und 3. Zumindest kann man sich so einer flächendeckenden Überwachung entziehen, aber es schützt vermutlich nur unzureichend, wenn man Ziel einer direkten Beobachtung wird.

Einen Schutz gegen alle Angriffe bietet eigentlich nur folgendes: Der Klartext wird nur auf einem Rechner betrachtet, der nicht mit dem Internet verbunden ist und das in Zukunft auch niemals wird. Dort wird auch verschlüsselt, und zwar mit einem sicheren, symmetrischen Algorithmus, dessen Schlüssel auf einem sicheren Weg – das heißt durch persönliche Übergabe – übetragen wird, vielleicht sogar mit einem One-Time-Pad (oder auch lieber ohne One-Time-Pad, wie Schneier meint?). Der Transfer des Geheimtextes von diesem Rechner zur Außenwelt, also über einen Rechner, der mit dem Internet verbunden ist, geschieht ausschließlich über physische Datenträger. Kein Kabel! Ein USB-Stick, Disketten, CD-ROMs oder vielleicht sogar auf einem Blatt Papier, das ausgedruckt und eingescannt wird. Oder durch Abtippen des Geheimtextes. Aber ob man in der Praxis so weit gehen will…?

Wer mir verschlüsselte E-Mails schicken will, kann dazu meinen PGP Public Key verwenden, der auf meiner Homepage veröffentlicht ist. Außerdem benutze ich Threema.

Web-Fonts selber hosten

Schon seit einiger Zeit gibt es die Möglichkeit, mittels downloadbarer Schriften oder Web-Fonts auch andere als die installierten Systemschriften im Browser anzuzeigen. Spätestens seit CSS3 ist es über @font-face kein Problem mehr, statt der allgegenwärtigen Verdana mit den „attraktiv“, weil falsch rum stehenden Anführungszeichen auch vernünftige Schriften plattformübergreifend zu verwenden. Internet-Dienste wie Google Fonts machen es dem Web-Master leicht: Auf die Seite gehen, Schrift aussuchen, „Quick Use“ anklicken und den angezeigten Code in die eigene Webseite aufnehmen, fertig. Die Schrift wird dabei beim Anbieter (in diesem Fall Google) direkt gehostet, man braucht sich um nichts weiter mehr kümmern. Auch Blog- und andere Content-Management-Systeme wie z.B. WordPress machen Gebrauch von dieser Möglichkeit, so werden zum Beispiel beim aktuellen WordPress-Theme „Twenty Thirteen“, das auch hier Verwendung findet, die standardmäßig verwendeten Schriftarten Bitter und Source Sans Pro direkt von Google Fonts eingebunden.

Doch was, wenn man die Fonts lieber selbst unter Kontrolle haben auf dem eigenen Webspace hosten möchte?

Eigentlich ist das auch ganz einfach, doch der Teufel liegt im Detail und es gibt ein paar Fallstricke, die ich hier kurz dokumentieren möchte.

1. Schriftarten aussuchen und Lizenz prüfen

Der erste Schritt ist natürlich immer, sich erst einmal Gedanken zu machen, was man haben will und Schriften auszusuchen, die gut lesbar sind und zueinander passen. Bei der Auswahl von Schriften kann man viel falsch machen und man muss sich eigentlich eingehend mit Typographie beschäftigen, will man ein gutes Ergebnis erzielen. Für meine konkrete Anwendung wollte ich mich daher darauf beschränken, die im bereits erwähnten und hier verwendeten WordPress-Theme Twenty Thirteen benutzten Schriften nicht mehr von Google, sondern von meinem eigenen Webspace aus einzubinden.

Man sollte an dieser Stelle auch gleich die Lizenz, unter der die Schriftart steht, darauf prüfen, ob überhaupt erlaubt ist, den Font in eine Webseite einzubinden. Die bei Google Fonts oder auch FontSquirrel angebotenen Schriften stehen zumeist unter der SIL Open Font Licence, die das erlaubt.

2. Schriftart herunterladen

Als nächstes holt man sich den Font zunächst mal zu sich. Bei Google Fonts klickt man dazu auf der Seite zum Font auf den kleinen Runter-Pfeil ganz rechts, den man angesichts der Prominenz, mit der einem der Code zum Einbinden direkt von Google aus angeboten wird, auch mal übersieht. Auch beim schon erwähnten FontSquirrel kann man jede Menge freie Schriften finden und herunterladen.

3. Schrift fürs Web konvertieren

Üblicherweise bekommt man dabei ein ZIP mit ein paar TrueType- oder OTF-Dateien darin. Das Problem: Zur Einbindung in eine Webseite braucht man je nach Ziel-Browser eine WOFF-, EOT- oder SVG-Datei. Praktischerweise braucht man für die Konvertierung nicht mal eine Software zu installieren, sondern kann einen Web-Dienst wie den FontSquirrel Webfont Generator verwenden. Man lädt dort seine TTF- oder OTF-Dateien hoch und bekommt ein ZIP-Archiv mit den selben Fonts in WOFF, EOT, SVG und TTF zurück. Mit diesen Formaten kann man alle gängigen Browser in aktuellen und nicht mehr ganz so aktuellen Versionen bedienen. Beschränkt man sich auf die aktuellen Versionen, sollte das WOFF (Web Open Font Format) eigentlich schon reichen.

Man muss noch beachten, dass man bei einer Schrift, die in mehreren Stilen bzw Schriftschnitten (wie fett oder kursiv) vorliegt, auch alle die hochlädt, die man später auf der Webseite verwenden will. Tut man das nicht oder macht bei einem der folgenden Schritte einen Fehler, wird der Browser aus dem normalen Stil die anderen Stile selbst berechnen, was meistens zwar funktioniert, aber schlechter aussieht.

FontSquirrel legt praktischerweise zusätzlich zu den Schriftarten in allen benötigte Formaten auch noch eine stylesheet.css mit den passenden @font-face-Definitionen sowie HTML-Testseiten dazu.

4. Stylesheet anpassen

Die @font-face-Definitionen aus der stylesheet.css müssen entweder verlinkt oder in die eigene CSS-Datei eingebaut werden.

Bei WordPress kann man z.B. die @font-face-Definitionen in die style.css des verwendeten Themes an den Anfang stellen (unter Design – Editor).

Dabei sind aber noch kleine Anpassungen erforderlich, insbesondere, wenn eine Schrift mit mehreren Stilen importiert wurde. Das von FontSquirrel generierte CSS sieht beispielsweise so aus:

@font-face {
    font-family: 'bitterregular';
    src: url('bitter-regular-webfont.eot');
    src: url('bitter-regular-webfont.eot?#iefix') format('embedded-opentype'),
         url('bitter-regular-webfont.woff') format('woff'),
         url('bitter-regular-webfont.ttf') format('truetype'),
         url('bitter-regular-webfont.svg#bitterregular') format('svg');
    font-weight: normal;
    font-style: normal;

}

@font-face {
    font-family: 'bitteritalic';
    src: url('bitter-italic-webfont.eot');
    src: url('bitter-italic-webfont.eot?#iefix') format('embedded-opentype'),
         url('bitter-italic-webfont.woff') format('woff'),
         url('bitter-italic-webfont.ttf') format('truetype'),
         url('bitter-italic-webfont.svg#bitteritalic') format('svg');
    font-weight: normal;
    font-style: normal;

}

Hier wurde der selbe Font Bitter in zwei Varianten verwendet, aber in der generierten CSS wurden zwei getrennte Schriftarten daraus, die zudem noch unterschiedliche Namen haben. Die CSS sollte man also bei font-family, font-style (für kursive Schriften) und ggf. font-weight (für fette Schriften) wie folgt ändern (siehe Hervorhebung):

@font-face {
    font-family: 'Bitter';
    src: url('bitter-regular-webfont.eot');
    src: url('bitter-regular-webfont.eot?#iefix') format('embedded-opentype'),
         url('bitter-regular-webfont.woff') format('woff'),
         url('bitter-regular-webfont.ttf') format('truetype'),
         url('bitter-regular-webfont.svg#bitterregular') format('svg');
    font-weight: normal;
    font-style: normal;

}

@font-face {
    font-family: 'Bitter';
    src: url('bitter-italic-webfont.eot');
    src: url('bitter-italic-webfont.eot?#iefix') format('embedded-opentype'),
         url('bitter-italic-webfont.woff') format('woff'),
         url('bitter-italic-webfont.ttf') format('truetype'),
         url('bitter-italic-webfont.svg#bitteritalic') format('svg');
    font-weight: normal;
    font-style: italic;

}

Der Wert von font-style ist entweder „normal“ oder „italic“, bei font-weight setzt man üblicherweise entweder „normal“ oder „bold“. Wenn die Schrift auch in anderen Schriftstärken (Schriftgewichten) vorliegt, trägt man bei font-weight eine Zahl zwischen 100 und 900 ein. Natürlich müssen die Angaben zur Schriftdatei passen, sonst sieht das Ergebnis merkwürdig aus.

Wenn die Schriftdateien nicht im selben Verzeichnis wie die CSS liegen, muss außerdem noch die URL angepasst werden, beispielsweise so (anderes Beispiel mit fettem Schriftstil):

@font-face {
    font-family: 'Bitter';
    src: url('http://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.eot');
    src: url('http://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.eot?#iefix') format('embedded-opentype'),
         url('http://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.woff') format('woff'),
         url('http://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.ttf') format('truetype'),
         url('http://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.svg#bitterbold') format('svg');
    font-weight: bold;
    font-style: normal;

}

Doch Vorsicht: Wenn die Schriftdateien nicht auf dem gleichen Server wie die Webseite liegen – eine andere Subdomain reicht schon! – ist vermutlich noch eine kleine Änderung an der Serverkonfiguration angesagt, wenn das ganze auch mit dem Firefox funktionieren soll.

5. Dateien hochladen

Dazu braucht man wohl nicht viel zu sagen, außer, dass der Ort natürlich der sein sollte, den man auch ins CSS geschrieben hat.

6. Serverkonfiguration prüfen

An dieser Stelle gilt es noch, die Serverkonfiguration zu prüfen, insbesondere wenn das Einbinden der Schrift noch nicht mit allen Browsern funktioniert. Insbesondere Firefox ist da etwas wählerisch und lädt standardmäßig Schriften nur vom selben Host, auf dem auch die Webseite liegt. Firefox lässt sich aber überreden, die Datei auch von woanders anzunehmen, wenn der Server im HTTP-Header Access-Control-Allow-Origin „*“ schickt. Es empfiehlt sich dann auch gleich, in der Konfiguration noch die MIME-Types für die Font-Dateien einzutragen. Sofern man keinen Direktzugriff auf die Serverkonfiguration hat (z.B. beim Webhoster) oder dort nichts ändern will, lässt sich das am einfachsten über eine .htaccess-Datei, die im selben Verzeichnis wie die Fonts zu liegen hat, erledigen. Dort steht dann (für Apache, den die meisten Hoster verwenden) folgendes drin:

AddType application/font-woff .woff
AddType application/x-font-ttf .ttf
AddType application/x-font-opentype .otf
<FilesMatch "\.(woff|ttf|otf|eot)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>

7. Für WordPress-User: Theme anpassen

Die Stylesheet-Änderungen aus Punkt 4 gehören wie schon geschrieben in die style.css des verwendeten Themes. Bei TwentyThirteen beispielsweise muss man nun noch dem Theme austreiben, doch den Link auf Google Fonts zu setzen. Das ist leider etwas versteckt in der functions.php in der Funktion twentythirteen_fonts_url(). Hier muss man dafür sorgen, dass diese Funktionen einen Leerstring zurückgibt, sonst baut WordPress einen <link>-Tag auf ein Google Fonts-Stylesheet ins HTML ein. Am einfachsten und am wenigstens destruktiv ist das, wen man an den entscheidenden zwei Stellen ein „on“ durch ein „off“ ersetzt:

…
   $source_sans_pro = _x( 'off', 'Source Sans Pro font: on or off', 'twentythirteen' );
…
   $bitter = _x( 'off', 'Bitter font: on or off', 'twentythirteen' );
…

8. Fertig

Die Web-Fonts können nun im CSS mit font-family verwendet werden.

Update

In den neuen Versionen von WordPress werden auch im Admin-Bereich Fonts von Google nachgeladen. Jegliches Nachladen von Google-Fonts in den Standard-Themes „Twenty Twelve“, „Twenty Thirteen“ und „Twenty Fourteen“ sowie im Admin-Bereich wird vom WordPress-Plugin „Disable Google Fonts“ unterbunden. Dieses Plugin schaltet die Google-Fonts aber einfach aus. Es ist dann keine Hilfe, wenn man in der Außendarstellung die Schriftarten weiter nutzen und selber hosten will.

Kryptographie, Teil 5: Moderne Blockchiffren

In den Teilen 1 bis 4 waren historische Verschlüsselungsverfahren bis hin schreibmaschinenartigen, mechanischen Rotormaschinen, die etwa ab den 1920er Jahren im Einsatz waren, Thema. Dabei wurde aufgezeigt, dass zwar die besprochenen Verfahren (bis auf das One-Time-Pad) nicht sicher sind, aber viele Grundsätze heute noch Gültigkeit haben.

Zunächst wurden zwar mechanische Verschlüsselungsapparate noch bis in die 1970 Jahre eingesetzt und sogar für sicher gehalten, nicht zuletzt, weil von den Briten lange geheim gehalten wurde, dass die Enigma-Verschlüsselung gebrochen war. Aber natürlich mussten mit Aufkommen der Computertechnik neue Methoden gefunden werden. So wurde in den 1970er Jahren bei IBM die Entwicklung von Verschlüsselungsverfahren gestartet. Ein wichtiges Zwischenergebnis waren die von IBM-Mitarbeiter Horst Feistel entwickelten Feistel-Netzwerke.

Feistel-Netzwerk
Feistel-Netzwerk

Bei einem Feistel-Netzwerk werden Blöcke von Bits über mehrere Runden hinweg nach folgendem Schema verschlüsselt: Zunächst wird eine Bitfolge in einen linken und rechten Halb-Block geteilt. Der rechte Halbblock wird direkt zum linken Halbblock der folgenden Runde. Außerdem dient der rechte Halbblock als Eingabe für eine Funktion, die vom Schlüssel und einem sogenannten Rundenschlüssel abhängt. Das Ergebnis dieser Funktion wird mit dem linken Halbblock exklusiv-oder-verknüpft und zum neuen rechten Halbblock. Diese Berechnung wird über mehrere Runden hinweg wiederholt. Die Rundenschlüssel sind für jede Runde verschieden und werden aus dem Schlüssel berechnet. Durch die Struktur des Netzwerks an sich ist sichergestellt, dass aus einem Geheimtext-Block mit Kenntnis des Schlüssels auch umgekehrt wieder der zugehörige Klartext-Block berechnet werden kann.

Ein Feistel-Netzwerk ist die Basis für den im Jahr 1976 veröffentlichen Data Encryption Standard (DES). Der DES-Algorithmus verschlüsselt Blöcke von 64 Bit Länge in 16 Runden mit Hilfe eines 56 Bit langen Schlüssels.

Die eigentliche Verschlüsselungsfunktion F (siehe Diagramm oben) ist etwas komplexer und basiert unter anderem auf einer fest definierten Substitution von Bitfolgen nach sogenannten S-Boxen, die in Abhängigkeit eines aus dem Schlüssel berechneten Rundenschlüssels ausgewählt werden. Eine genauere Beschreibung würde den Rahmen dieses Artikels sprengen, kann aber in der einschlägigen Literatur (siehe unten) oder auch im Wikipedia-Artikel zum Data Encrpytion Standard nachgelesen werden, denn wie alle guten Algorithmen ist auch der DES komplett offengelegt. Auch für die modernen Verfahren gilt nämlich selbstverständlich der Grundsatz, dass es keine Sicherheit durch Geheimhaltung des Verfahrens gibt („security through obscurity“), sondern dass nur der Schlüssel (und selbstverständlich der Klartext) geheim gehalten werden müssen.

Bei der Entwicklung war interessanterweise auch der heutzutage aus den Schlagzeilen bekannte US-Geheimdienst NSA beteiligt. Die NSA wollte eine kürzere Schlüssellänge, was ein Knacken der Verschlüsselung durch simples Ausprobieren aller möglichen Schlüssel („brute-force-Angriff“) natürlich vereinfacht. Aber abgesehen davon muss man davon ausgehen, dass die NSA nicht etwa versucht hat, durch Einflussnahme den Algorithmus zu schwächen. Vielmehr ist es so, dass die NSA bei den S-Boxen sogar die Resistenz gegen eine damals noch nicht öffentlich, wohl aber IBM und der NSA bekannte Art von Angriffen, der differentiellen Kryptanalyse, gesteigert hat.

NSA

DES gilt heute insbesondere wegen der für heutige Verhältnisse recht kurzen Schlüssellänge und der Weiterentwicklung der Technik nicht mehr als ausreichend sicher, allerdings wird die Variante „Triple-DES“ mit 112 Bit langen Schlüsseln noch stellenweise verwendet.

Der aktuelle Standard heißt AES, Advanced Encryption Standard. Der Algorithmus wurde 1998 unter dem Namen Rijndael (nach den Nachnamen seiner Entwickler Joan Daemen und Vincent Rijmen) entwickelt, setzte sich im Rahmen eines Wettbewerbs durch und wurde 2000 vom US National Institute of Standards and Technology (NIST). AES ist anders als DES kein Feistel-Netzwerk, sondern ein sogenanntes Substitutions-Permutations-Netzwerk. Der grundlegende Ablauf ist aber ähnlich: Es wird ein Block über mehrere Runden hinweg verschlüsselt und dabei S-Boxen (Substitution) und bei AES noch sogenannte P-Boxen (Permutation) verwendet.

AES verschlüsselt 128 Bit lange Blöcke, die Schlüssellänge beträgt 128, 192 oder 256 Bit und die Anzahl der Runden ist abhängig von der Schlüssellänge 10, 12 oder 14. Wie DES ist auch AES offengelegt, über einen langen Zeitraum hinweg von Wissenschaftlern öffentlich diskutiert, analysiert und für sicher befunden worden.

Da DES und AES jeweils Klartext-Blöcke verschlüsseln, spricht man auch von Blockchiffren. Streng genommen handelt es sich also dabei um eine monoalphabetische Substitution, nur dass nicht einzelne Zeichen (oder sagen wir 8 Bit-Blöcke), sondern längere Blöcke subsitutiert werden. Wird eine Blockchiffre so verwendet, spricht man vom ECB– oder Electronic-Codebook-Modus.

Tatsächlich ist es nun so, dass zwar statistische Angriffe, wie sie im zweiten und dritten Teil dieser Serie genannt wurden, zwar durch die längere Blockgröße (oder sagen wir das größere Alphabet) deutlich erschwert werden, aber je nach Klartext nicht völlig unmöglich gemacht werden. Insbesondere bei der Verschlüsselung von unkomprimierten Bilddateien werden Muster nur unzureichend verwischt, wie das Bildbeispiel bei Wikipedia eindrücklich zeigt.

Um diese Schwäche zu vermeiden, setzt man verkettete Verschlüsselungsmodi ein.

Cipher Block Chaining
Cipher Block Chaining

Vor der eigentlichen Verschlüsselung mit der Blockchiffre (also z.B. AES) wird der Klartext-Block mit dem vorhergehenden Geheimtext-Block exklusiv-oder-verknüpft. Da es beim ersten Block noch keinen vorhergehenden Geheimtext-Block gibt, wird stattdessen ein sogenannter Initialisierungsvektor verwendet, der als zusätzlicher Teil des Schlüssels aufgefasst werden kann. Diese Art der verketteten Verschlüsselung nennt man Cipher Block Chaining Mode oder kurz CBC.

Eine solche Verkettung kann auch auf andere Arten geschehen. Besondere Beachtung verdient dabei noch der Output Feedback Mode, kurz OFB.

Output Feedback
Output Feedback

Das Bemerkenswerte hier ist, dass der Klartext gar nicht mit der Blockchiffre verschlüsselt wird! Schaut man sich das Schema einmal genauer an, stellt man fest, dass der eigentliche Verschlüsselungsalgorithmus ausschließlich dazu benutzt wird, eine Pseudo-Zufallszahlenfolge zu erzeugen, die dann mit dem Klartext exklusiv-oder-verknüpft wird. Dieses Vorgehen sollte aus dem dritten und vierten Teil dieser Serie bekannt vorkommen: Aus einem kurzen Schlüssel wird ein langer erzeugt, die eigentliche Verschlüsselung ist dann im Stil eines One-Time-Pads. Im Gegensatz zum echten One-Time-Pad ist aber keine absolute Sicherheit gegeben, da die erzeugte Bit-Folge ja nicht echt zufällig, sondern nur pseudo-zufällig ist.

Beachtenswert ist auch, dass zum Entschlüsseln eines mit einer Blockchiffre im OFB-Modus verschlüsselten Textes die Entschlüsselung der Blockchiffre gar nicht benötigt wird, sondern nur die Verschlüsselung. Die Blockchiffre dient schließlich nur dazu, eine Zufalls-Bitfolge zu erzeugen, die den Schlüssel für die eigentliche Ver- bzw. Entschlüsselung bildet.

Eine kleine Abwandlung des OFB ist der Cipher Feedback Mode CFB.

Cipher Feedback
Cipher Feedback

Vergleichen wir die drei bisher gezeigten Feedback-Modi, so stellt man folgendes fest: Beim OFB und beim CFB kommt der Klartext gar nicht mit dem eigentlichen Chiffrieralgorithmus in Berührung. Der Chiffrieralgorithmus dient in diesen Fällen nur dazu, eine Zufallszahlenfolge zu erzeugen und braucht auch gar nicht zu entschlüsseln. Es kann also statt einer echten Blockchiffre auch eine andere Einwegfunktion verwendet werden.

Beim CBC und CFB wird der Geheimtext als Feedback benutzt. Dies ist dann entscheidend, wenn auf dem Weg vom Sender zum Empfänger Datenblöcke verloren gehen. Beim OFB muss der Empfänger genau wissen, der wievielte Block gerade entschlüsselt werden soll. Beim CBC und CFB reicht es aus, den vorausgegangenen Geheimtextblock zu kennen, um ab diesem Punkt die Nachricht weiter entschlüsseln zu können.

Als letztes betrachten wir noch den Counter Mode (CTR).

Counter
Counter

Statt eines Feedbacks wird dem Initialisierungsvektor (Nonce) lediglich ein Zähler hinzugefügt, aber wie beim CFB und OFB wird die Blockchiffre nur zur Erzeugung des eigentlichen Schlüssels verwendet. Der Vorteil gegenüber den anderen Verkettungsmodi besteht darin, dass alle Blöcke parallel verarbeitet werden können und entsprechend auch komplett unabhängig voneinander wieder dechiffriert werden können, wenn bekannt ist, um welchen Block es sich handelt.

Um den heutigen Artikel noch kurz zusammenzufassen: Die standardisierten Verschlüsselungsverfahren DES und der moderne AES sind sogenannte Blockchiffren, die Blöcke einer bestimmten Länge verschlüsseln und dafür mehrere Runden benötigen. Blockchiffren können entweder direkt blockweise im Electronic-Codebook-Modus verwendet werden, was aber nicht empfehlenswert ist, da Muster im Klartext ähnlich wie bei einer monoalphabetischen Chiffre nur unzureichend verwischt werden. Besser ist, einen verketteten Modus wie die hier gezeigten CBC, CFB, OFB oder CTR zu verwenden.

Die bisher gezeigten Verfahren haben alle die Eigenschaft, dass Sender und Empfänger einer verschlüsselten Nachricht vorher einen gemeinsamen Schlüssel getauscht haben müssen und nur mit Kenntnis des geheimen Schlüssels sowohl ver- als auch entschlüsselt werden kann. Wie man verschlüsselt kommunizieren kann, auch ohne dass man vorher persönlich einen Schlüssel ausgetauscht haben muss, werden wir in der nächsten Folge betrachten.

Quellen und weiterführende Literatur:

[1] Reinhard Wobst: “Abenteuer Kryptologie”

Spaß mit <img>

Das HTML-Tag <img> ist eine tolle Sache. Ohne es gäbe es keine Bilder auf Webseiten. In dem Tag gibt man die URL an, an der sich die anzuzeigende Bilddatei befindet. Meistens befindet sich das Bild auf dem selben Web-Server wie die Seite, aber nicht immer. Man kann sogar fremde Bilder auf eigene Seiten einbinden. Und genau dort beginnt der Spaß!

Triskel
Ein Triskel

Vor einigen Jahren, als ich noch Doktorand in Dublin war, habe ich mal für meine Forschung einen Algorithmus mit dem Namen Triskel geschrieben. Das Triskel (oder die Triskele) ist ein dreiteiliges Zeichen, dass sich in Irland vielfach findet, zum Beispiel an der steinzeitlichen Anlage in Newgrange. Später wurde es von den Kelten verwendet und noch später von Christen als Dreifaltigkeitssymbol gedeutet. Weil die Zahl 3 bei meinem Algorithmus eine Rolle spielt, habe ich den Namen gewählt und zur Illustration ein Bild (siehe oben) gezeichnet, das man immer noch auf meiner Homepage findet.

Das Triskel als keltisches Symbol erfreut sich auch als Avatar in einschlägigen Internetforen einer gewissen Beliebtheit. Und weil ein Teilnehmer eines französischsprachigen Forums mein Triskel wohl ganz gut fand, hat er es verwendet. Und zwar, indem er direkt das Bild von meiner Seite aus eingebunden hat, wie ich schon vor einiger Zeit in meinen Server-Logs gesehen haben. Da das <img>-Tag nun einmal so funktioniert wie es funktioniert, hat das auch ganz gut geklappt. Zumindest bis heute Abend. Heute Mittag sah das Forum jedenfalls noch so aus:

Screenshot: Französisches Rollenspiel-Forum mit von mir gezeichnetem Triskel
Screenshot: Französisches Rollenspiel-Forum mit von mir gezeichnetem Triskel

Bis jetzt hat mich das auch nicht weiter gestört. Heute habe ich aber mal wieder meine Logfiles durchgesehen und festgestellt, dass mein Triskel jetzt auch in einem Blog verwendet wird, das sich mit Esoterik und vor allem Tarot befasst.

Screenshot: Französisches Tarot-Blog mit meinem Triskel
Screenshot: Französisches Tarot-Blog mit meinem Triskel

Und jetzt war mir nach ein bisschen Spaß. 🙂 Die Gefahr, wenn man als Web-Autor ein Bild von einer fremden Seite einbindet, besteht offensichtlich darin, dass man diese Bilddatei nicht unter Kontrolle hat. Zum Beispiel könnte das Bild aus dem Netz genommen werden. Dann ist es weg. Aber das Bild könnte auch unter dem selben Namen mit etwas völlig anderem ersetzt werden. Und so hat man auf einmal einen Katzen-Avatar…

Screenshot: Foreneintrag mit Grumpy Cat-Avatar
Screenshot: Foreneintrag mit Grumpy Cat-Avatar

… oder Strauchratten-Content auf seiner Webseite.

Screenshot: Französisches Tarot-Blog mit Degu
Screenshot: Französisches Tarot-Blog mit Degu

Schlimmstenfalls kommen sogar kubanische Revolutionäre zu Besuch und zerschießen einem das Layout.

Estudio, Trabajo, Fusil (Studieren, Arbeiten, Schießen!)
Estudio, Trabajo, Fusil (Studieren, Arbeiten, Schießen!)

Und die Moral von der Geschicht: Fremde Bilder linkt man nicht! 🙂

Wer sich den aktuellen Zustand des Dramas anschauen will, schaue dort: