Archiv für den Monat: September 2013

Wahlkampf

Es ist Wahlkampf im Schwarzwald. Doch wen sollte man wählen?


Unseren Profi, von dem man aber nicht weiß, wer er ist? Die Partei, deren Wahlplakate falsch rum hängen und das sogar konsequent im ganzen Stadtgebiet?


Oder eine von denen? Mangels Informationsgehalt der Plakate habe ich unter anderem den Wahl-o-Mat befragt, mit teils erwartetem und teils überraschendem Ergebnis, aber dazu noch an anderer Stelle. Bis dahin überlasse ich dem Leser diese Szenen aus dem Leben und verabschiede mich schmunzelnd vom Ort des Geschehens.

Position:Allmendstraße,Furtwangen im Schwarzwald,Deutschland

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('https://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.eot');
    src: url('https://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.eot?#iefix') format('embedded-opentype'),
         url('https://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.woff') format('woff'),
         url('https://static.spontan-wild-und-kuchen.de/fonts/bitter-bold-webfont.ttf') format('truetype'),
         url('https://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”