Projektgruppe STEGO: Theoretischer Teil – Formate und Algorithmen

C.v.O. Universität Oldenburg
Abteilung: Parallele Systeme
Projektgruppe STEGO:
Theoretischer Teil –
Formate und Algorithmen
Jan Christian Busch, Rene Frerichs, Lars Herrmann,
Matthias Kloppenborg, Marko Krause, Christian Kuka,
Sebastian Schnell, Ralf Treu
Dieses Dokument beschreibt diverse Medienformate und
Algorithmen im Hinblick auf das steganographische Einbetten
von Geheimnachrichten in Trägermedien. Es stellt
die Grundlage für den Entwurf und die Entwicklung einer
allgemeinen Softwarebibliothek für die computergestützte
Steganographie dar.
17. Dezember 2008

Inhaltsverzeichnis
1 Einführung/Motivation 5
2 Ziele des Projekts 5
3 Gruppenvorstellung 6
4 Untersuchte Dateiformate 7
4.1 GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 WAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Vorhandene steganographische Algorithmen 43
5.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Einbettung in GIF-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 GIFShuffle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2 FriRui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.3 Sortieren/Umsortieren . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Einbettung in JPEG-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.1 F5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.2 MB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3.3 Perturbed Quantization – PQ . . . . . . . . . . . . . . . . . . . . . 55
5.4 Einbettung in Rastergrafiken . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.1 BattleSteg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.2 CPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Einbettung in Audio-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.5.1 Echo-Hiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.5.2 Phase-Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.3 LSB – Least Significant Bits . . . . . . . . . . . . . . . . . . . . . . 66
6 Verbesserungen bestehender und neue Algorithmen 67
6.1 Einbettung in Bild-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.1.1 T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2 GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.1 Fortgeschrittener GIFShuffle . . . . . . . . . . . . . . . . . . . . . 73
6.3 Einbettung in Audio-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.1 WPC-Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.4 Einbettung in SVG-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.1 SVG-Winkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.5 Einbettung in PDF-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3

6.5.1 PDFShuffle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.6 Einbettung in CSS-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.6.1 CSS-Steganographie . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7 Die Bibliothek libstego 81
7.1 Aufbau der Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2 Implementierungsdetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Glossar 82
4

1 Einführung/Motivation
Die Steganographie beschäftigt sich mit der Einbettung von geheimen Nachrichten in
unauffällige Trägermedien. Im Gegensatz zur Kryptographie ist hier das Ziel, dass ein
eventueller Angreifer vom Informationsaustausch überhaupt nichts bemerkt. Ein weit
verbreitetes Beispiel für die Anwendung der Steganographie ist das sogenannte Gefangenenproblem:
Alice und Bob sitzen in getrennten Zellen in einem Gefängnis und wollen ihren Ausbruch
planen. Ihre einzige Kommunikationsmöglichkeit besteht darin, sich Briefe zu schicken,
die jedoch alle vom Gefängniswärter untersucht werden. Sollte dieser den Verdacht
schöpfen, dass Alice und Bob einen unerlaubten Plan schmieden, so wird er die Briefe
nicht weiter übermitteln und jegliche weitere Kommunikation verhindern. Bei diesem
Szenario ist die Verwendung einer Geheimschrift oder -Sprache nicht möglich, da der
Wärter diese sofort als solche erkennen und sich weigern würde, die Briefe zuzustellen.
Der Informationsaustausch muss also nicht verschlüsselt, sondern verdeckt erfolgen. Steganographie
findet also überall Anwendung, wo die Informationskanäle zwischen zwei
Parteien überwacht werden und der Austausch von geheimen Nachrichten unbemerkt
geschehen muss.
In der heutigen Zeit sind viele Menschen von Restriktionen bezüglich des Versendens
von verschlüsselten Nachrichten betroffen. In vielen Ländern ist das Verschlüsseln verboten
oder die Menschen werden vom Staat zur Herausgabe der Schlüssel gezwungen.
Gerade für die Einwohner solcher Länder ist es wichtig, eine Möglichkeit zu haben, geheime
Nachrichten zu verschicken, ohne dass jemand außer dem Empfänger der Nachricht
überhaupt von dieser Nachricht erfährt.
Insbesondere die computergestützte Steganographie ist noch ein recht junges Forschungsgebiet.
Im Gegensatz zur Kryptographie gibt es hier nur sehr wenige standardisierte
Verfahren zur Einbettung. In vielen Fällen sind die Einbettungsalgorithmen nicht
offengelegt, sondern existieren nur in Form von vorkompilierten Programmen, die sich
meistens nicht auf allen Betriebssystemen und Hardwareplattformen nutzen lassen.
Dies erschwert einerseits den Informationsaustausch, andererseits führt es dazu, dass
die Einbettungsmethoden nicht von einer ausreichend großen Personenzahl geprüft werden
und somit immer eine Unsicherheit besteht, ob die gängigen Verfahren nicht beispielsweise
bereits von Geheimdiensten oder ähnlichen Organisationen gebrochen wurden.
Die Entwicklung einer offenen, plattformunabhängigen Softwarebibliothek, die einerseits
einige vorhandene Einbettungsalgorithmen für eine Vielzahl unterschiedlicher
Trägermedien implementiert, andererseits leicht um neue Algorithmen erweitert werden
kann, soll diesen Problemen entgegenwirken.
2 Ziele des Projekts
Die Projektgruppe ” Stego“ wird im Laufe eines Jahres vorhandene steganographische
Algorithmen analysieren, wenn möglich verbessern und eine quelloffene Bibliothek ent-
5

werfen und implementieren, die eine Auswahl von Algorithmen enthält.
In den letzten Jahren entstand eine Vielzahl an steganographischen Algorithmen für Dateiformate,
die insbesondere im ” World Wide Web“ häufig Verwendung finden. Wie so
oft wurden dabei teils sehr allgemeine Algorithmen entwickelt, die sich beispielsweise auf
die Sortierung von Daten in einer Datei beziehen, und teils sehr spezielle Algorithmen,
die nur auf wenige oder gar einzelne Dateiformate anwendbar sind. Die Sicherheit der
Algorithmen ist bei der Steganographie die wichtigste Anforderung. Es gilt, den Zielkonflikt
zwischen Sicherheit und Einbettungsrate zu analysieren und potentiell sichere oder
deutlich verbesserbare Algorithmen aus den vorhandenen Implementierungen herauszufiltern.
Der Fokus wird auf jene Algorithmen gelegt, die auf die am häufigsten verwendeten
Formate im ” World Wide Web“ anwendbar sind; in der heutigen Zeit werden mehr und
mehr multimediale Inhalte über das Internet verbreitet, so dass die Wahl eher auf Bildund
Audio-Formate fällt; darüber hinaus muss der Trend berücksichtigt werden, Dateiformate
mit bestimmten Kompressionsverfahren den unkomprimierten vorzuziehen, weil
– trotz immer schnellerer Internetverbindungen – jene kleineren Dateien oft verwendet
werden.
Die Algorithmen sollen, wenn möglich, verbessert werden, jedoch soll auch eine feste
Basis an etablierten Algorithmen übernommen werden. Ergebnis soll eine in der Programmiersprache
C implementierte und vollständig dokumentierte, quelloffene Bibliothek
sein, mit deren Hilfe unterstützte Dateien von jedem Interessierten auf mehrere
Arten mit zusätzlichen Daten angereichert werden können. Um den Funktionsumfang
präsentieren zu können, wird neben der Dokumentation weiterhin ein Programm mit
grafischer Oberfläche entwickelt, das die Möglichkeiten der Bibliothek aufzeigen wird.
Beide Programme werden zunächst von der Projektgruppe ingeneurmäßig entworfen
und anschließend implementiert und werden mit Programmcode und Dokumentation
bereitgestellt, um die Nutzung und weitere Forschung zu ermöglichen.
3 Gruppenvorstellung
Die Projektgruppe Stego setzt sich aus den folgenden Studenten der Carl-von-Ossietzky-
Universität zusammen:
Jan Christian Busch Student an der Carl-von-Ossietzky-Universität seit 2004 mit
Schwerpunkt Informationssysteme und Software-Engineering.
Aufgabe . . . GUI-Entwicklung.
Rene Frerichs Student an der Carl-von-Ossietzky-Universität seit 2004 mit Anwendungsfach
Musik.
Aufgabe . . . Sonstige Aufgaben.
Lars Herrmann Student an der Carl-von-Ossietzky-Universität seit 2003 mit Anwendungsfach
Physik.
6

Aufgabe . . . Server Administration.
Matthias Kloppenborg Student an der Carl-von-Ossietzky-Universität seit 2004 mit
Schwerpunkt eLearning/Wissensmanagement.
Aufgabe . . . Quelltext Dokumentation.
Marko Krause Student an der Carl-von-Ossietzky-Universität seit 2003 mit Anwendungsfach
Physik.
Aufgabe . . . Server-Administration.
Christian Kuka Student an der Carl-von-Ossietzky-Universität seit 2006 mit Schwerpunkt
Informationssysteme und Software-Engineering.
Aufgabe . . . Webserver-Administration.
Sebastian Schnell Student an der Carl-von-Ossietzky-Universität seit 2004 mit Anwendungsfach
Physik.
Aufgabe . . . Dokumentation.
Ralf Treu Student an der Carl-von-Ossietzky-Universität seit 2004 mit Schwerpunkt
eLearning/Wissensmanagement.
Aufgabe . . . Projektleiter.
4 Untersuchte Dateiformate
Um computergestützte Steganographie anzuwenden ist es notwendig, den genauen Aufbau
der Datenformate zu kennen, in die Geheimnachrichten eingebettet werden sollen. Im
folgenden werden Medien- und Datenformate beschrieben, die sich für steganographische
Einbettungen eignen. Einige der Formate werden bereits von vorhandenen steganographischen
Algorithmen verwendet, andere – wie das PDF- oder CSS-Format – werden für
neue, von der Projektgruppe entwickelte Algorithmen, benötitgt.
4.1 GIF
Zusammenfassung Das GIF (Graphics Interchange Format) ist ein palettenbasiertes
Bildformat. Es bietet die Möglichkeit der Animation und es ist möglich Pixel transparent
erscheinen zu lassen. Der zur Kompression der Bilddaten verwendete Algorhmus ist,
anders als zum Beispiel bei JPEG, nicht verlustbehaftet.
Geschichtlicher Hintergrund CompuServe präsentierte im Jahre 1987 das GIF als freie
und offene Spezifikation. Nicht nur der gute Algorithmus zur Komprimierung ließen das
GIF zu einem beliebten Format im Internet werden. Die Fähigkeit, das auf Seite 12 beschriebene
Zeilensprungverfahren anwenden zu können, bei dem aus Sicht des Benutzers
Bilder schneller aufgebaut werden können, indem beispielsweise zunächst nur jede vierte,
7

dann jede zweite Zeile angezeigt wird, trug ebenfalls dazu bei. Auch die Übertragung
von Farbbildern war zur damaligen Zeit nicht Standard. Die Spezifikation 89a erweiterte
die Funktionen des Formates, so dass nun auch Transparenzeffekte und Animationen
verwendet werden konnten. Als CompuServe das GIF und damit auch die Spezifikation
87a präsentierte, fiel zunächst niemandem auf, dass der zur Komprimierung eingesetzte
LZW-Algorithmus lizenzrechtlich bedenklich war. Der LZW-Algorithmus verwendete
Prozeduren, die sowohl Unisys als auch IBM im Vorfeld patentiert worden waren. Im
Dezember des Jahres 2004 gaben Unisys und CompuServe bekannt, dass Entwickler,
die weiterhin mit den von Unisys patentierten Technologien, welche im Zusammenhang
mit dem GIF-Format stehen, arbeiten wollten, von nun an Lizenzgebühren zu zahlen
hätten. Diese Gebühren, die zu Beginn nur für kommerzielle Software zu zahlen waren,
wurden kurz darauf auch auf kostenlose Software ausgeweitet. Dies war ein zu erwartender
Schritt von Unisys, da die kommerziellen Hersteller nach Einführung der Gebühren
Teile ihrer eigenen Software, die der Erstellung von GIF-Dateien dienten, als kostenlose
Erweiterungen zur Verfügung stellten. Verwirrung entstand, da im Internet das Gerücht
verbreitet wurde, dass sowohl für Programme zum Erstellen als auch für Programme
zum Anzeigen von GIF-Dateien Gebühren zu entrichten wären. Dies führte letztlich
dazu, dass CompuServe die Planung von GIF24 als freie, offene und gebührenfreie Spezifikation
unterstützte.Dies konnte später bei der Entwicklung von PNG verwendet werden.
Tatsache ist jedoch, dass Programme, welche GIF-Dateien nur auslesen, nicht von
der Gebührenpflicht betroffen waren([GIFa] [GIFb]). Trotz der Entwicklung von PNG
und JPEG finden GIF-Dateien noch heute Verwendung im Internet und sind durch ihre
Fähigkeit zur Animation und Transparenz beliebt.
Der Aufbau einer Datei nach GIF-Spezifikation 89a Der Aufbau einer GIF-Datei
nach Spezifikation 89a ([GIFc]) lässt sich anhand einer einfachen Grammatik darstellen.
Die mit < und > geklammerten Begriffe sind Nichtterminale. Die mit [ und ] geklammerten
Begriffe sind optional. Das * bedeutet, dass der davor stehende Block mehrfach
vorkommen kann. Sind Begriffe durch | getrennt, so ist dies als Exklusiv-Oder zu verstehen.
Ungeklammerte Begriffe sind Terminale und werden im Folgenden erläutert.
:= HeaderGIF-Endsymbol
:= Bildschirmbeschreibung [globale Farbpalette]
:= |
:= [Erweiterung zur Grafikkontrolle]
:= |
Erweiterung zur Darstellung von ASCII Text
:= Bildbeschreibung [lokale Farbpalette] Rasterdaten
:= Erweiterung für Anwendungen |
Erweiterung für Kommentare
Der Header Anhand des sechs Byte großen Headers, kann man die GIF-Datei als
solche erkennen: In den ersten drei Bytes ist die sogenannte Signatur gespeichert,
8

durch die man erkennt, dass die folgenden Daten eine GIF-Datei beschreiben. Die
Versionsnummer beschreibt die Spezifikation, anhand derer die Datei erstellt wurde. Es
gibt zwei verschiedene Spezifikationen: 87a und 89a. Neuerungen in der Spezifikation
89a sind z. B. der Farbwert für Transparenz, die Fähigkeit der Animation und die
Möglichkeit zur Darstellung von ASCII-Text.
Der Aufbau des Headers
• 001011112 �= ASCII g
• 001100012 �= ASCII i
• 001011102 �= ASCII f
• 001110002 �= ASCII 8
• 001110012 �= ASCII 9
• 011000012 �= ASCII a
Die Bildschirmbeschreibung Die Bildschirmbeschreibung enthält die globalen Parameter
für alle enthaltenen Rasterbilder, so zum Beispiel die Dimensionen des logischen
Bildschirms, der zur Darstellung genutzt wird, Informationen über die zu verwendenden
Farbpaletten, die Hintergrundfarbe des logischen Bildschirms und die Farbtiefe. Aus
den ersten vier Bytes lassen sich Höhe und Breite des logischen Bildschirms auslesen.
Das anschließende Byte muss bitweise interpretiert werden:
Ist das erste Bit auf Eins gesetzt so existiert eine globale Farbpalette und diese
folgt auf die Bildschirmbeschreibung. Bei einem Wert von Null existiert diese Farbpalette
nicht. Implementierungsabhängig können auch für jedes Rasterbild eigene sogenannte
lokale Farbpaletten oder eine im Speicher vorliegende Farbpalette verwendet werden.
Die folgenden drei Bits zeigen an, wie viele Bits pro Primärfarbe im Originalbild
zur Verfügung standen. Zu dem gespeicherten Wert addiert man eins hinzu, um den
korrekten Wert zu erhalten. Speichern diese Bits beispielsweise den Dezimalwert drei,
so standen im Originalbild vier Bits pro Primärfarbe zur Verfügung um das Bild herzustellen.
Das fünfte Bit gibt an, ob die globale Farbpalette sortiert ist. Die Sortierung
hängt ab von der Häufigkeit der Verwendung des Farbindexes in den Rasterdaten. Je
öfter der Farbindex verwendet wird, desto eher findet man den Wert in der Farbpalette,
wenn man diese von Null an aufsteigend durchsucht. Die letzten drei Bits zeigen an,
wieviele Bits pro Pixel zur Adressierung der Farbindizes verwendet werden. Aus diesem
Wert x lässt sich mit folgender Formel die Größe der Farbpalette, gemessen in Anzahl
der Farben, errechnen.
F arbpalette = 2 (x+1)
(1)
Das nächste Byte interpretiert man als Verweis auf einen Eintrag in der Farbpalette,
es gibt die Hintergrundfarbe des logischen Bildschirms an. Die Bildschirmbeschreibung
9

endet mit einem Byte, anhand dessen Wert y man näherungsweise das Verhältnis von Pixelhöhe
zu Pixelbreite im Ursprungsbild errechnen kann. Die Formel für die Berechnung
der Näherung:
y + 15
V erhältnis = (2)
64
Bei einem Wert y von 255 hat die rechte Seite der Gleichung etwas den Wert 4,21, das
Verhältnis von Pixelbreite zu Pixelhöhe ist also ungefähr 4:1. Ist der Wert von y mit 1
angegeben, so lautet das Ergebnis 0,25. Das Verhältnis ist damit 1:4. Liest man an der
Stelle ein Nullbyte ein, so gibt es keine Informationen zum Verhältnis.
Aufbau der Bildschirmbeschreibung
• Breite des Bildschirms in Pixeln (2 Bytes)
• Höhe des Bildschirms in Pixeln (2 Bytes)
• Ein Byte
– Bit für globale Farbpalette (1 Bit)
– Bits pro Primärfarbe im Originalbild (3 Bits)
– Bit für Sortierung der Farbpalette (1 Bit)
– Bits pro Pixel (3 Bits)
• Farbindex für Hintergrundfarbe (1 Byte)
• Verhältnis von Höhe zu Breite eines Pixels (1 Byte)
Die Farbpaletten Die Farben, die in einer GIF-Datei verwendet werden, werden in
Farbpaletten organisiert. Es besteht sowohl die Möglichkeit eine globale Farbpalette zu
beschreiben, als auch eine lokale Farbpalette für jedes einzelne Rasterbild zu definieren.
Eine Farbpalette kann, egal ob lokal oder global, bis zu 256 Farben speichern. Definiert
man sowohl globale als auch lokale Farbpaletten, werden die Farbeinträge der lokalen
Farbpaletten verwendet. Um eine Farbe aus dem RGB-Farbraum zu beschreiben,
verwendet man drei Bytes, jeweils eines pro Grundfarbe. Die Indizes der Farbpalette
verweisen direkt auf einen solchen Dreierblock von Bytes. Um einen hellen Blauton zu
erhalten, wie er zum Beispiel bei der Darstellung eines Himmels genutzt werden könnte,
speichert man folgende Werte.
Der Aufbau der Farbpaletten
• Rotwert: 011010002 = 104
• Grünwert: 101010112 = 171
• Blauwert: 110011002 = 204
10

Diese drei Werte beschreiben eine Farbe in der Farbpalette und lassen sich anschließend
über einen Index adressieren. Die Größe des Index ist auf ein Byte beschränkt, wodurch
die Größe der Farbpalette auf 768 Bytes begrenzt ist.
Die Bildbeschreibung Die Bildbeschreibung enthält Informationen zum einzelnen
Rasterbild. GIF-Dateien können mehrere Rasterbilder enthalten, die sich zu einem
Gesamtbild oder einer Animation verknüpfen lassen. Jedes Rasterbild kann zur
Darstellung auf eine eigene lokale Farbpalette zugreifen oder die globale Farbpalette
verwenden. Das erste Byte der Bildschirmbeschreibung enthält ein Komma, das als
Trennsymbol für die einzelnen Rasterbilder dient. Die folgenden vier Bytes geben die
Koordinaten an, an denen mit der Darstellung des Rasterbildes begonnen wird. Dabei
bezeichnen jeweils zwei Bytes den linken sowie den oberen Abstand zum Rand des
in der Bildschirmbeschreibung definierten logischen Bildschirms. Die Breite sowie die
Höhe des Rasterbildes werden ebenfalls mit jeweils zwei Bytes angegeben. Das letzte
Byte der Bildbeschreibung ist wie folgt aufgeteilt.
Das erste Bit zeigt an, ob für das Rasterbild eine eigene lokale Farbpalette definiert
ist, ob also nach den Bytes der Bildbeschreibung eine Farbpalette zu erwarten ist.
Der Aufbau der Farbpaletten wurde im vorherigen Abschnitt bereits beschrieben. Das
zweite Bit zeigt an, wie die Rasterdaten zu interpretieren sind. Ist dieses Bit gesetzt,
so sind die Rasterdaten im Zeilensprungverfahren gespeichert. Ist dies nicht der Fall,
so können die Rasterdaten sequenziell ausgelesen und dargestellt werden. Das dritte
Bit gibt an, ob die lokale Farbpalette sortiert ist. Die folgenden zwei Bits sind laut
Spezifikation reserviert und müssen mit Null belegt werden. Die letzten drei Bits geben,
genau wie zuvor in der Bildschirmbeschreibung erläutert, an, wieviele Bits pro Pixel zur
Adressierung der Farbindizes verwendet werden. Außerdem lässt sich mit Formel (1),
wenn vorhanden, die Größe der lokalen Farbpalette errechnen.
Der Aufbau der Bildbeschreibung
• Trennzeichen 001011002
• Abstand, in Pixeln, zum linken Rand des logischen Bildschirms (2 Bytes)
• Abstand, in Pixeln, zum oberen Rand des logischen Bildschirms (2 Bytes)
• Breite des Bildes (2 Bytes)
• Höhe des Bildes (2 Bytes)
• (Ein Byte)
– Bit für lokale Farbpalette (1 Bit)
– Bit für Zeilensprungverfahren (1 Bit)
11

– Bit für Sortierung (1 Bit)
– Reserviert mit Null (2 Bits)
– Bits pro Pixel (3 Bits)
Das Zeilensprungverfahren im GIF Bei dieser speziellen Anwendung des Verfahrens
wird zunächst nur jede achte, dann jede vierte, anschließend jede zweite Zeile und letztendlich
die verbliebenen Zeilen in den Rasterdaten gespeichert. Beim Auslesen werden
diese dann jeweils in acht-, vier-, zwei- und einfacher Höhe dargestellt,siehe Abbildung
auf Seite 12. Dies ermöglicht einen schnellen Bildaufbau, der Betrachter erhält zu Beginn
eine grobe Übersicht des Bildes, deren Auflösung sich stets verdoppelt, bis das Rasterbild
vollends aufgebaut ist.
111111 111111 111111 111111
111111 111111 111111 222222
111111 111111 333333 333333
111111 111111 333333 444444
111111 555555 555555 555555
111111 555555 555555 666666
111111 1. 555555 2. 777777 3. 777777
111111 → 555555 → 777777 → 888888
999999 999999 999999 999999
999999 999999 999999 aaaaaa
999999 999999 bbbbbb bbbbbb
999999 999999 bbbbbb cccccc
999999 dddddd dddddd dddddd
999999 dddddd dddddd eeeeee
999999 dddddd ffffff ffffff
Abbildung 1: Zu Beginn werden die Zeilen 1 und 9 in 8-facher Größe angezeigt. Im
nächsten Schritt werden die Zeilen 5 und d ebenfalls in die Anzeige aufgenommen
und alle Zeilen in 4-facher Größe dargestellt. In den folgenden
Schritten wird dementsprechend weiter verfahren.
Die Rasterdaten Nachdem die Rahmendaten für das Rasterbild festgelegt sind, folgt
die Beschreibung der eigentlichen Bilddaten. Zu Beginn der Rasterdaten steht ein Byte,
das die Anzahl an Bits pro Codewort ausgibt. Arbeitet man mit nur 17 Farben, so würde
dieses Byte mit 00000101 initialisiert, da fünf Bits zur Darstellung benötigt würden,
bei 70 Farben wäre der Wert also 00000111. Das nächste Byte beschreibt, wieviele
Bytes in dem folgenden Datenblock übertragen werden. An diesem Punkt müsste man
zeilenweise, von oben beginnend, für jedes Pixel einen Verweis auf eine Farbe aus der
Farbpalette speichern. Da dies jedoch zu einer recht großen GIF-Datei führen würde,
12

werden die Rasterdaten mit dem Lempel-Ziv-Welch-Algorithmus komprimiert. Dieser
Algorithmus dient der Mustererkennung, so dass nicht für jedes Pixel ein Byte übertragen
werden muss. Für die erkannten Muster generiert der Lempel-Ziv-Welch-Kodierer
eine Codetabelle. Reicht die Anzahl an Bits, die zur Übertragung genutzt werden dürfen,
nicht mehr aus, so wird ein weiteres Bit hinzugenommen. Dies lässt sich, wie später
erläutert wird, leicht in den Dekodierungsvorgang einbauen. Die unkomprimierten
Rasterdaten werden auf die so erzeugte Codetabelle abgebildet, und die erzeugte Folge
von Codewörtern ersetzt die unkomprimierten Rasterdaten im GIF. Das Besondere am
Lempel-Ziv-Welch-Algorithmus ist, dass die Codetabelle nicht Teil der GIF-Datei ist,
sondern vom Decodierer aus den komprimierten Rasterdaten erstellt werden kann. Die
Anzahl an Bits, die für einen Verweis in diese Codetabelle zu Beginn benötigt werden,
kann, wie bereits erwähnt, aus dem ersten Byte der Rasterdaten ausgelesen werden. Die
Anzahl an Bits pro Codewort zu Beginn ist abhängig von der Größe der zugeordneten
Farbpalette. Die komprimierten Rasterdaten, welche jetzt bitweise vorliegen, werden zu
Byte-Ketten verbunden und können dann als Datenblock gespeichert werden. Nachdem
klar ist, wie groß ein Codewort ist und wie viele Bytes sich in einem Datenblock
befinden, können die LZW-komprimierten Datenbytes übertragen werden. Am Ende
der Rasterdaten steht als Endzeichen ein Nullbyte.
Der Aufbau der Rasterdaten
• Anzahl an Bits pro Codewort (1 Byte)
• Anzahl an Bytes im folgenden Datenblock (1 Byte)
• Datenblock
Ist ein Datenblock verarbeitet, so gibt es zwei Möglichkeiten:
0. Es folgt ein weiterer Datenblock, dem wieder ein Byte zur Beschreibung der Länge
des Datenblocks voransteht.
1. Es folgt das Endzeichen für Rasterdaten (000000002)
Der Erweiterungsblock Die Unterschiede zwischen der Spezifikation 87a und 89a sind
nicht gravierend. Es finden sich jedoch in der Spezifikation 89a konkrete Implementierungen
des in der Spezifikation 87a vorgestellten Erweiterungsblockes.
Implementierte Erweiterungen sind:
• Erweiterung für Grafikkontrolle (vor Bildbeschreibung)
• Erweiterung für Kommentare
• Erweiterung für ASCII-Text
• Erweiterung für Anwendungen
13

Erweiterung für Grafikkontrolle Der Erweiterungsblock für die Grafikkontrolle
ermöglicht zum Beispiel das Erstellen von Animationen. Das erste Byte enthält, wie bei
jeder Erweiterung, die Bits zur Darstellung eines Ausrufezeichens. Um die Erweiterung
als Grafikkontrolle zu identifizieren, enthält das nächste Byte den Dezimalwert 249.
Das dritte Byte beschreibt die Anzahl an Bytes bis zum Endzeichen. Das folgende Byte
betrachtet man bitweise:
Laut Spezifikation sind die ersten drei Bits reserviert und standardmäßig mit
Null zu belegen. Die folgenden drei Bits zeigen an, wie mit dem folgenden Rasterbild,
beziehungsweise mit dem folgenden ASCII-Text-Erweiterungsblock, zu verfahren ist,
nachdem die Anzeige stattgefunden hat. Die vordefinierten Werte und ihre Bedeutung
werden im Folgenden dargestellt. Nachdem der folgende Block ausgelesen und angezeigt
wurde,
0. muss der Decoder nicht reagieren.
1. wird die Anzeige belassen wie sie ist.
2. werden die Pixel des logischen Bildschirms, die zur Anzeige benutzt wurden, wieder
auf die Hintergrundfarbe gesetzt.
3. werden die Pixel des logischen Bildschirms, die zur Anzeige benutzt wurden, auf
den Wert vor der Anzeige des Blocks gesetzt.
Die übrigen Belegungen der drei Bits sind nicht definiert. Das folgende Bit zeigt an,
ob während der Anzeige des Bildes eine Eingabe durch den Nutzer erwartet wird.
Wie diese Eingabe durchgeführt wird, ist abhängig von der Implementierung des
Anwendungsprogramms, das mit den GIF-Dateien arbeitet. Ist dieses Bit gesetzt,
so wartet das Programm bis zum Ablauf der Verzögerungszeit auf Eingaben vom
Benutzer und fährt danach mit der Verarbeitung weiterer Datenblöcke der GIF-Datei
fort. Die Empfehlung von CompuServe ist, dass wenn dieses Bit gesetzt ist, auch eine
Verzögerungszeit angegeben wird. Das letzte Bit gibt an, ob im Grafikkontrollblock der
Index für die Transparenz gesetzt ist.
Im fünften und sechsten Byte ist der Wert für die Verzögerungszeit gespeichert.
Der enthaltene Wert beschreibt die Verzögerungszeit in Hundertstel einer Sekunde. Ist
das Bit für Eingaben durch den Benutzer nicht gesetzt, so wartet die Anwendung für
die Dauer der Verzögerungszeit, bevor sie mit der Verarbeitung der folgenden Blöcke
beginnt. Das vorletzte Byte der Erweiterung zur Grafikkontrolle gibt den Index des
transparenten Farbwertes an. Der Abschluss des Erweiterungsblockes ist am letzten
Byte zu erkennen, welches den Wert Null speichert.
Der Aufbau der Erweiterung zur Grafikkontrolle
• Allgemeines Startsymbol für Erweiterungen (001000012)
14

• Symbol zur Identifizierung als Erweiterung zur Grafikkontrolle (111110012)
• Anzahl an Bytes bis zum Endzeichen (000001002)
• (Ein Byte)
– Reserviert mit Null (3 Bits)
– Verfahren nach Anzeige (3 Bits)
– Nutzereingaben (1 Bit)
– Transparenz-Bit(1 Bit)
• Verzögerungszeit (2 Bytes)
• Index für die transparente Farbe (1 Byte)
• Endsymbol (000000002)
Erweiterung für Kommentare In dem Erweiterungsblock für Kommentare lassen sich
Metainformationen zur GIF-Datei abspeichern, wie zum Beispiel eine Beschreibung des
Inhaltes oder der Name des Urhebers. Die Erweiterung beginnt mit dem Startsymbol,
zur Identifizierung dient wieder das zweite Byte, das den dezimalen Wert 254 speichert.
Anschließend können beliebig viele Datenblöcke folgen, denen ein Byte voransteht, das
die Anzahl an Bytes im Datenblock angibt.
Der Aufbau der Erweiterung für Kommentare
• Allgemeines Startsymbol für Erweiterungen (001000012)
• Symbol zur Identifizierung als Erweiterung für Kommentare (111111102)
• Anzahl an Bytes im folgenden Datenblock (1 Byte)
• Datenblock
• Endsymbol (000000002)
Erweiterung für ASCII-Text Diese Erweiterung vereinfacht die Darstellung von Text.
Da eine solche Erweiterung in der Spezifikation 87a nicht angedacht war, müssen
viele Parameter in diesen Block integriert werden. Das Startsymbol ist wie bei jeder
Erweiterung der dezimale Wert 33. Das identifizierende Byte speichert den Dezimalwert
1. Das folgende Byte gibt die Anzahl an Bytes an, die zur Parametrisierung der
eigentlichen ASCII-Daten dienen. Dieser Wert ist fest angegeben mit 12 Bytes. Die
nächsten Bytes beschreiben die Maße des Gitters, in dem der Text dargestellt wird,
linker und rechter Abstand zum Rand des logischen Bildschirms (jeweils zwei Bytes),
sowie Breite und Höhe des Gitters in Pixeln (jeweils zwei Bytes). Um herausfinden zu
können, wieviel Text gespeichert werden kann, benötigt man noch Breite und Höhe
15

der Buchstaben (jeweils 1 Byte). Zur Verwendung des Erweiterungsblocks für Text
benötigt man eine globale Farbpalette, denn die folgenden zwei Bytes beschreiben
Text- und Hintergrundfarbe und enthalten Verweise auf Einträge in der globalen
Farbpalette. Nachdem alle Parameter angegeben sind, folgen die Datenblöcke mit den
eigentlichen ASCII-Kodierungen, denen jeweils ein Byte vorangeht, welches die Länge
des Datenblocks angibt. Das Nullbyte beendet auch diese Erweiterung.
Der Aufbau der Erweiterung für ASCII-Text
• Allgemeines Startsymbol für Erweiterungen (001000012)
• Symbol zur Identifizierung als Erweiterung zur Darstellung von ASCII-Text
(000000012)
• Anzahl an Bytes der zur Darstellung benötigten Parameter (000011002)
• Linker Startpunkt des Gitters, in dem der Text dargestellt wird (2 Bytes)
• Oberer Startpunkt des Gitters, in dem der Text dargestellt wird (2 Bytes)
• Breite des Gitters, in dem der Text dargestellt wird (2 Bytes)
• Höhe des Giters, in dem der Text dargestellt wird (2 Bytes)
• Breite eines Buchstabens (1 Byte)
• Höhe eines Buchstabens (1 Byte)
• Textfarbe (1 Byte)
• Hintergrundfarbe (1 Byte)
• Anzahl an Bytes im folgenden Datenblock (1 Byte)
• Datenblock
• Endsymbol (000000002)
Erweiterung für Anwendungen Die Erweiterungen für Anwendungen dienen zum
Beispiel der Darstellung von sich stets wiederholenden, animierten Bildern, wie sie oft
im Internet zu finden sind. Das erste Byte beschreibt das allgemeine Startsymbol für
Erweiterungen. Durch den Wert des folgenden Bytes, Dezimalwert 255, ist die Erweiterung
für Anwendungen zu erkennen. Die nächsten acht Bytes speichern ASCII-codierte
Buchstaben, die sich zur Ausgabe in den Programmen verwenden lassen. Anhand eines
Algorithmus können die Anwendungen einen 24-stelligen Binärschlüssel generieren,
anhand dessen sich das Programm authentifizieren lässt. Dieser ist in den folgenden drei
Bytes enthalten. Es folgen die Blöcke mit den eigentlichen Anwendungsdaten, denen
jeweils ein Byte vorangeht, das die Länge des Datenblocks beschreibt. Letztendlich folgt
das Nullbyte.
16

Aufbau der Erweiterung für Anwendungen
• Allgemeines Startsymbol für Erweiterungen 001000012
• Symbol zur Identifizierung als Erweiterungsblock für Anwendungen 111111112
• Anzahl an Bytes der für die Anwendung benötigten Parameter 000010112
• Bytes zur Identifizierung der Anwendung 8 Bytes
• Bytes zur Authentifikation der Anwendung 3 Bytes
• Anzahl an Bytes im folgenden Datenblock 1 Byte
• Datenblock
• Endsymbol 000000002
Der Lempel-Ziv-Welch-Algorithmus zur Kompression Der LZW-Algorithmus wurde
1984 von Terry A. Welch in der Arbeit ” A technique for high-performance data compression”
vorgestellt, [Ter84]. Ein Nachteil des Algorithmus ist allerdings, dass die Symbole
immer so groß sind wie der Tabellenindex. Das bedeutet, dass nicht codierte Symbole
mehr Bits benötigen als ursprünglich. Der Algorithmus ist einfach und gut dokumentiert
und wird nicht nur im GIF, sondern auch in der TIFF-Spezifikation sowie in verschiedenen
Komprimierungsprogrammen erwähnt.
Der Algorithmus, funktioniert beim erstellen von GIF-Dateien wie folgt:
Wir nehmen an, es existiere eine Farbpalette, deren enthaltene Farben mit den
Indizes Null und Eins angesprochen werden können. Die Codetabelle wird zu Beginn
mit den Werten für die Indizes gefüllt. Zusätzlich erstellt man zwei neue Einträge. Zum
einen einen Code, mit dem die Codetabelle gelöscht werden kann, zum anderen einen
Code, der das Ende der LZW-Daten markiert. Diese Codetabelle füllt man weiter mit
Mustern, die man beim Einlesen der Farbwerte für ein Rasterbild erhält. Dazu liest man
die Rasterdaten ein und versucht, die gelesenen Werte durch Zeichen in der Codetabelle
zu ersetzen. Findet man ein Muster aus dem Eingabestrom in der Symboltabelle, so
schreibt man den zugehörigen Code in die komprimierten Daten, und erstellt einen
neuen Eintrag in der Codetabelle für dieses Muster, inklusive dem nachfolgenden
Zeichen.
Ein Beispiel:
17

Eingabe Erkannt Ausgabe Neues Muster Neues Codewort
10000101 1 10
0000101 0 00
000101 00 000
0101 0 01
101 10 101
1 1 – –
– – – –
Wie zu erkennen ist, lassen sich mit der Anzahl an Bytes, die man sonst zum Kodieren
eines Zeichens braucht, mehrere Zeichen kodieren. Die Codeworte und sind
definiert als ” Codetabelle löschen” und ” Ende der LZW-Daten”. Die Codetabelle zu
löschen ist keine gängige Praxis, kann jedoch unter Umständen Platz sparen. Hierauf
gehen wir jedoch nicht näher ein. Den komprimierten Datenstrom zu dekomprimieren
erfordert etwas mehr Aufwand, was anhand der folgenden Tabelle deutlich wird.
Eingabe Neues Muster Neues Codewort Ausgabe
– – 1
10 0
00 00
000 0
01 10
101 1
– – –
Zu Beginn erkennt man die 1 und gibt diese aus. Als nächstes wird die 0 erkannt
und ausgegeben. Man erstellt das neues Codewort , das für das Muster 10 steht,
aus der letzten Ausgabe und dem gelesenen Zeichen. Das nächste Zeichen ist in der
Codetabelle noch nicht zu finden. Aus dem Komprimiervorgang wird aber ersichtlich,
dass das nächste Muster mit 0 beginnen muss. Die letzte Ausgabe wird in die Bildung
des neuen Codewortes miteinbezogen, und somit steht das neue Codewort für das
Muster 00 und wird direkt auf den Code angewandt. Ausgegeben wird 00. Anhand dieser
Ausgabe wird mit der im nächsten Schritt erkannten 0 ein neues Muster gebildet. Das
Codewort ist jetzt mit dem Muster 000 verbunden. Die neue Ausgabe ist 0. Das
Codewort wird eingelesen und das Muster 10 in die Ausgabe geschrieben. Der erste
Buchstabe des zuletzt erkannten Musters war eine 1. Die diesem Schritt vorangegangene
Ausgabe war 0. Somit wird als neues Muster 01 mit dem Codewort notiert. Hier
wird nicht, wie vielleicht erwartet, 010 als Muster unter beschrieben, da noch kein
Muster 01 in der Codetabelle kodiert ist. Muster in der Codetabelle können, wie auch
bei der Kompression, immer nur um einen Farbpaletteneintrag erweitert werden. Die
nun gelesene 1 führt aufgrund der letzten Ausgabe von 10 dazu, dass als neues Muster
101 mit dem Codewort gepeichert wird. Das Codewort bedeutet das Ende
der LZW-Daten.
18

Das Fazit zur Steganographie mit GIF Aufgrund der verlustfreien Komprimierung
und der häufigen Verwendung von GIF-Dateien im Internet scheint dieses Format geeignet
für steganographische Verfahren. Problematisch ist aber die Möglichkeit, dass
sich Farben, deren Positionen in der Farbtabelle sich nur um Eins unterscheiden, völlig
unterschiedliche RGB-Werte haben können. Dies schränkt die unauffällige Veränderung
des LSBs eines Pixels ein. Die Möglichkeit, mehrere Farbtabellen definieren zu können,
sollte nicht ausgenutzt werden, da dies die Größe der GIF-Dateien auffällig ansteigen
ließe. Nicht definierte oder reservierte Bits und Bytes sollten ebenfalls nicht verwendet
werden, da dies leicht zu entdecken wäre.
4.2 JPEG
Zusammenfassung JPEG bezeichnet ein standardisiertes Verfahren zur verlustbehafteten
Speicherung von Fotos bzw. fotoähnlichen Bildern. Der Grad der Komprimierung
und damit der Qualität kann stufenlos eingestellt werden und wird ausschließlich durch
die sogenannte Quantisierungsmatrix gesteuert, dazu später mehr. JPEG macht sich bestimmte
Eigenschaften des Auges zunutze, um effektiv Details zu entfernen, die ohnehin
kaum oder nur schwer wahrnehmbar sind.
Geschichte Die ” Joint Fotographic Experts Group“ wurde 1986 gegründet. Ihr offzieller
Name lautet ” ISO/IEC JTC1 SC29 Working Group 1“. Dieses Komitee entstand aus
einem Zusammenschluss von Experten der ISO und der ITU-T (früher CCITT). ISO
steht für die ” International Organization for Standardization“. Die französische Bezeichnung
” Comité Consultatif International Télégraphique et Téléphonique“ der CCITT
wurde später durch den englischen Ausdruck ” International Telecommunication Union“,
kurz ITU, ersetzt. Sowohl die ISO als auch die ITU sind Organisationen, die Standards
überprüfen und entwickeln.
Der 1992 von der Expertengruppe verabschiedete JPEG-Standard trägt die offizielle Bezeichnung
” ISO/IEC IS 10918-1 | ITU-T Recommendation T.81“. Auf der offiziellen
ISO-Homepage [ISO92a] können sich Interessierte das Papier gegen Entgelt herunterladen.
Mit anderer Überschrift aber gleichem Inhalt gibt es das PDF bei der ITU aber
auch kostenlos [ISO92b].
Die Entwicklung des JPEG-Standards ermöglichte es, fotoähnliche Bilder mit variabler
verlustbehafteter Kompression zu speichern oder zu laden. Durch den öffentlichen Zugang
zur Spezifikation hatten Softwareentwickler die Möglichkeit, auch größere Bilder
untereinander auszutauschen. Diese Eigenschaften waren für den Siegeszug des Standards
im Internet verantwortlich. Nach seiner Entwicklung wurde es neben dem Graphics
Interchange Format GIF das verbreitetste Format im Internet und ist es, trotz starker
Konkurrenz durch neuere Formate wie PNG oder JPEG-2000, auch heute noch.
Das JPEG-Komitee hat es während seiner ersten JPEG-Version versäumt, ein passendes
Dateiformat zu definieren. Eric Hamilton, der in keinerlei Verbindung zur JPEG-Group
stand, entwickelte das heutzutage gängige JFIF-Format Anfang der Neunziger. Es wurde
im Hinblick auf Einfachheit entworfen, wodurch einige Fähigkeiten von JPEG ungenutzt
blieben. Trotzdem haben nahezu alle JPEG-Dateien im Internet dieses Format.
19

Bei JPEG-2000 wurde dieser Fehler nicht wiederholt und ein passendes ISOstandardisiertes
Dateiformat namens JP2 zeitgleich veröffentlicht. Jenes unterstützt im
Gegensatz zu JFIF alle im Standard vorgesehenen Möglichkeiten.
Der offizielle Nachfolger mit der Bezeichnung ” ISO/IEC-Norm 15444-1:2000 | ITU-
Empfehlung T.800“war eine konsequente Weiterentwicklung, die das hauptsächliche Problem
des Vorgängers, nämlich Blockbildung bei hohen Kompressionsraten, durch Nutzung
von Wavelet- statt Fourier-Transformationen löste. Die verantwortliche Expertengruppe
rangierte unter der Bezeichnung ” ISO/IEC JTC l/SC 29/WG1“. Es existieren
diverse JPEG-Derivate. JPEG-LS dient zum verlustfreien Speichern fotoähnlicher Bilder,
wobei dieses Verfahren ohne die in JPEG verwendete Quantisierung auskommt, die
selbst bei 100-prozentiger Qualitätstufe angewandt wird und verlustbehaftet ist. Daneben
gibt es JBIG bzw. dessen Nachfolger JBIG2 für die Komprimierung von Grauwertund
Binärbildern, was beispielsweise für die Verwendung in Faxgeräten interessant ist.
Im Videobereich existiert auf der einen Seite Motion-JPEG, kurz M-JPEG, und auf der
anderen Seite das bekannte MPEG, das auf Video-DVDs verwendet wird.
Aufbau des Formates
Farbmodell-Konvertierung Als erster Schritt der JPEG-Kompression findet eine Konvertierung
vom Quell-Farbmodell zum YCbCr-Farbmodell statt. Als Quelle findet sich
meist das auf Computern eingesetzte RGB-Modell, welches jede Farbe aus den Komponenten
Rot, Grün und Blau zusammensetzt. Ein anderes gebräuchliches Format ist
CMYK, welches sich aus den Grundfarben Cyan, Magenta und Gelb zusammensetzt
und zumeist von Druckern verwendet wird. YCbCr teilt die Farbe auf in Luminanz Y
und Chrominanz Cb bzw. Cr. Durch diese Definition kann man sich bestimmte Eigenheiten
des menschlichen Auges zunutze machen: Es besitzt eine hohe Empfindlichkeit
gegenüber Helligkeits-/Luminanzunterschieden. Farben, also Chrominanz, werden hingegen
schlechter wahrgenommen, wobei der Farbunterschied Blau zu Gelb (Cb) wiederum
besser ausgemacht werden kann als der von Rot nach Grün (Cr). Abbildung 2
verdeutlicht dies: Das Original-Bild oben links wurde in Chrominanz und Luminanz
aufgesplittet. Das Luminanz-Signal oben rechts erscheint sehr konturiert, während die
beiden Chrominanzkanäle unten hingegen einen verschwommenen Eindruck machen. Der
Cr-Kanal unten rechts wird von Menschen mit einer Rot-Grün-Schwäche meist nur als
monoton graue Fläche wahrgenommen.
Es bietet sich daher an, die einzelnen Kanäle mit unterschiedlicher Genauigkeit zu speichern.
Dieses Vorgehen wird Chroma-Subsampling genannt. Im JPEG-Standard sind
drei Varianten definiert:
• YCbCr 4:4:4 Chrominanz-Auflösung identisch zur Luminanz-Auflösung.
• YCbCr 4:2:2 horizontale Chrominanz-Auflösung halbiert.
• YCbCr 4:2:0 horizontale und vertikale Chrominanz-Auflösung jeweils halbiert.
Am verbeitetsten ist der letztgenannte FourCC-Code; weitere finden sich in [Fou08]. Bei
Umwandlung von RGB nach YCbCr 4:2:0 findet eine Reduktion der Datenmenge auf die
20

Abbildung 2: Chrominanz und Luminanz Kanäle: Oben links das Originalbild. Daneben
der Helligkeitskanal. Darunter die beiden Chrominanzkanäle Cb und Cr.
[Wik08h]
21

Hälfte des ursprünglichen Wertes statt. Dies ist schon der erste verlustbehaftete Schritt
der Komprimierung, der in Bildern mit ausgeprägten Farbunterschieden bei gleichmäßiger
Helligkeit bereits sichtbar werden kann.
Mathematisch wird die Umwandlung mittels einer Matrixmultiplikation vollzogen:
⎡ ⎤ ⎡ ⎤ ⎡
⎤ ⎡ ⎤
Y 0 0,299 0,587 0,114 Rd
⎣Cb⎦
≈ ⎣128⎦
+ ⎣−0,168736
−0,331264 0,5 ⎦ · ⎣Gd⎦
(3)
Cr 128 0,5 −0,418688 −0,081312
wobei [Rd, Gd, Bd] T und [Y, Cb, Cr] T die Farbvektoren darstellen, deren Komponenten
sich im Intervall [0, 255] befinden. Werden die Komponenten nun gerundet, so passen sie
exakt in ein Byte. JPEG sieht auch 12-Bit-Genauigkeit vor, was in der Praxis jedoch
kaum Anwendung findet.
Spektralanalyse Die einzelnen Kanäle werden nun getrennt voneinander komprimiert.
Zunächst werden die Daten in 8×8-Pixel-Blöcke unterteilt, und für jeden Block wird eine
Frequenzanalyse mittels diskreter Kosinus-Transformation, kurz DCT, durchgeführt:
Fxy = 1
4 CxCy
7� 7�
� � � �
(2m + 1)xπ (2n + 1)yπ
fmn cos
cos
, 0 ≤ x, y ≤ 7
16
16
m=0 n=0
Ck =
� 1
√2 wenn k = 0
1 sonst
Dabei beschreibt fmn den Pixelwert an der Stelle (m, n). Am Ende stehen 64
DCT-Koeffizienten Fxy, die die einzelnen Frequenzanteile am Gesamtbild darstellen.
Abbildung 3 visualisiert die einzelnen Frequenzanteile: Das originale Bild setzt sich aus
einer Linearkombination dieser Blöcke zusammen mit den DCT-Koeffizienten als Gewichtung.
Der Block oben links gibt den gleichförmigen Grundton des Blocks an, weshalb
er als DC-Komponente bezeichnet wird. Die restlichen Koeffizienten, bezeichnet als
AC, beschreiben nach unten rechts immmer feiner werdende Strukturen wie Kanten und
Muster.
Das menschliche Auge ist empfindlich gegenüber groben Strukturen, wohingegen feine
Details nicht so deutlich wahrgenommen werden. Nach unten rechts nehmen die Komponenten
der DCT-Matrix in ihrer Bedeutung für den Gesamteindruck des Bildes also
ab.
Quantisierung Die Quantisierung zielt genau auf diesen Sachverhalt ab, indem die
hochfrequenten Koeffizienten in ihrer Genauigkeit beschnitten werden. Dazu wird die
DCT-Matrix F elementweise durch die Quantisierungmatrix Q geteilt und gerundet:
F Q � �
F (x, y)
(x, y) =
Q(x, y)
Je größer die einzelnen Elemente in der Quantisierungsmatrix sind, desto kleiner sind also
die Werte der resultierenden Matrix F Q . Wandelt man jene in ganzzahlige Werte um, so
22
Bd

Abbildung 3: Die Frequenzanteile, aus denen sich jeder 8×8-Pixel-Block zusammensetzt.
Jeder Block stellt eine von 64 Frequenzen dar [Wik08e].
erhält man einen Datenblock, dessen Entropie direkt abhängig ist von der verwendeten
Matrix Q. Im Allgemeinen wird die Quantisierungsmatrix so gewählt, dass die Werte
nach unten rechts größer werden, um besagter Frequenzmaskierung Rechnung zu tragen.
23

Man siehe dazu folgende Beispielrechnung:
⎡
10 15 25 37 51 66 82
⎤
100
⎢
15
⎢
25
⎢
Q = ⎢ 37
⎢ 51
⎢ 66
⎣ 82
19
28
39
52
67
83
28
35
45
58
72
88
39
45
54
66
79
94
52
58
66
76
89
103
67
72
79
89
101
114
83
88
94
103
114
127
101 ⎥
105 ⎥
111 ⎥
119 ⎥
130 ⎥
142⎦
100 101
⎡
782,91
105 111 119
44,93 172,52
130 142 156
−35,28 −20,58 35,93 2,88
⎤
−3,85
⎢
−122,35
⎢
−2,99
⎢
F = ⎢ −7,98
⎢ 3,87
⎢ −3,77
⎣ 1,78
−75,46
−32,77
0,66
7,07
0,80
3,28
−7,52
−57,18
2,41
0,56
−1,46
4,63
55,00
−30,07
−21,28
5,13
−3,50
3,27
30,72
1,76
−31,07
−2,47
1,48
2,39
−17,73
17,63
−17,20
−15,09
4,13
−2,31
8,29
12,23
−9,68
−17,70
−6,32
5,21
1,97 ⎥
−13,57 ⎥
16,94 ⎥
−3,76 ⎥
−18,47 ⎥
11,77 ⎦
−1,75 0,43 −2,72 −3,05 3,95 −1,83 1,98 3,87
F Q ⎡
78 3 7 −1 0 1 0
⎤
0
⎢
−8
⎢
0
⎢
= ⎢ 0
⎢ 0
⎢ 0
⎣ 0
−4
−1
0
0
0
0
0
−2
0
0
0
0
1
−1
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 ⎥
0 ⎥
0 ⎥
0 ⎥
0 ⎥
0⎦
0 0 0 0 0 0 0 0
Zick-Zack-Sortierung Vor der eigentlichen Entropiekodierung werden noch zwei andere
Komprimierungstechniken angewendet. Zunächst findet eine Zick-Zack-Umsortierung
aller AC-Komponenten eines Blocks statt. Abbildung 4 verdeutlicht diese Technik: Da
die Werte Richtung unten rechts nahe Null sind, wird auf diese neue Reihenfolge nun
eine verlustfreie Lauflängenkodierung angewandt.
Die DC-Komponenten werden gesondert behandelt, indem hier eine Differenzkodierung,
auch als prädiktive Kodierung bezeichnet, durchgeführt wird. Hierbei werden blockübergeifend
nur die Differenzen der Koeffizienten untereinander gespeichert.
Entropiekodierung Die abschließende verlustfreie Entropiekodierung profitiert direkt
von der oben beschriebenen Quantisierung der DCT-Koeffizienten. Je größer die Werte
in der Quantisierungsmatrix Q sind, desto niedriger ist die Entropie der gerundeten
Matrix F Q . Dies wiederum hat eine höhere Kompressionsrate zur Folge. Der Kompressionsgrad
wird bei JPEG also ausschließlich über die Werte in der Quantisierungsmatrix
Q gesteuert.
Im Standard sind zwei Verfahren vorgesehen:
24

Abbildung 4: Zick-Zack-Umsortierung der AC-Koeffizienten [Bol07].
• Huffman-Kodierung [Wik08c]
• Arithmetische Kodierung [Wik08a]
Die Arithmetische Kodierung ist hinsichtlich des Kompressionsgrades sehr effizient, erfordert
aber eine hohe Rechenleistung und ist patentgeschützt. Die Huffman-Kodierung
ist lizenzfrei und performant, erzielt aber schlechtere Kompressionsraten. Genau wie
die im JPEG-Standard vorgesehene Möglichkeit der 12-Bit-Kanalgenauigkeit spielt die
arithmetische Kodierung keine praktische Rolle; nahezu alle Dateien sind mit Huffman
kodiert.
Dekodierung Um aus einer JPEG-Datei wieder das ursprüngliche RGB-Bild zu gewinnen,
müssen die Schritte des Komprimierungsvrogangs in umgekehrter Reihenfolge
rückgängig gemacht werden. Dazu dekodiert man die Daten zunächst mit Huffman und
bringt alle Koeffizienten von ihrer Zick-Zack-Reihenfolge in ihre natürliche Position innerhalb
der Koeffizienten-Matrix F Q . Um aus jener die DCT-Matrix F zurückzugwinnnen,
multipliziert man sie anschließend elementweise mit der Quantisierungsmatrix Q,
die in der JPEG-Datei immer mitgespeichert werden muss.
Inverse diskrete Kosinus-Transformation Die IDCT wandelt die 64 Koeffizienten Fmn
eines Blocks wieder um in die ursprünglichen Pixeldaten fxy:
fxy = 1
4
7� 7�
� � � �
(2x + 1)mπ (2y + 1)nπ
CmCnFmn cos
cos
, 0 ≤ x, y ≤ 7
16
16
m=0 n=0
Durch die Quantisierung und die damit entstandene Ungenauigkeit sind diese Pixelwerte
verschieden von denen des Originalbildes. Das verlustbehaftete Ergebnis ist also nur noch
eine Näherung der ursprünglichen Daten.
25

Transformierung in das RGB-Modell Normalerweise findet als letzter Schritt eine Umwandlung
nach RGB statt, um die Datei auf dem Bildschirm anzeigen zu können:
⎡ ⎤
R
⎡
1 0 1,402
⎤ ⎡
Y
⎣G⎦
= ⎣1
−0,344136 −0,714136⎦
· ⎣
B 1 1,772 0
′
⎤
P b⎦
P r
wobei vorher die Korrektur
⎡ ⎤
Y
⎡ ⎤
Y
⎡ ⎤
0
⎣P
b⎦
= ⎣Cb⎦
− ⎣128⎦
P r Cr 128
durchgeführt wird, entsprechend der Formel (3).
JPEG-2000 JPEG-2000 ist eine konsequente Weiterentwicklung des originalen JPEG-
Standards von 1992. Statt der diskreten Kosinus-Transformation werden Wavelet-
Transformationen [Bra94] verwendet. Die Komplexität letzterer liegt bei O(N) im Gegensatz
zu O(N log N) bei der DCT, wobei N für die Anzahl der Pixel steht. Dadurch
entfällt die Notwendigkeit, das Bild in 8×8-Pixel-Blöcke zu unterteilen. Dies und der lokale
Charakter der diskreten Wavelet-Transformation, kurz DWT, verhindern die bei hoher
Kompressionsrate auftauchende Klötzchenbildung in JPEG-Bildern, siehe dazu Abbildung
5. Beim JPEG-Bild links wird die Einteilung in grobe Blöcke sichtbar, während
Abbildung 5: Vergleich von JPEG, links, zu JPEG-2000 bei 66-facher Kompressionsrate
[Wik08f].
das JPEG-2000-Bild rechts lediglich unscharf wird.
Die zweite wichtige Neuerung betrifft die Entropie-Kompression, die ausschließlich mittels
arithmetischer Kodierung durchgeführt wird.
Dateiformat
JPEG File Interchange Format – JFIF JFIF in seiner neuesten Version 1.02 von 1992
ist das einzige bedeutende Bildformat, das den JPEG-Standard von 1992 implementiert.
26

Die Endung .jpg ist die gebräuchlichste, weniger verbreitet sind .jpe, .jpeg oder .jfif. Das
Farbmodell ist auf YCbCr beschränkt und die maximale Auflösung beträgt 65536×65536
Pixel. Es ist keine Definition des Farbraums vorgesehen. Es wird jedoch das Seitenverhältnis,
englisch: ” aspect ratio“, mitgespeichert. Der Mime-Typ lautet ” image/jpeg“.
Eine progressive Speicherung der Bilddaten erlaubt es, eine grobe Bildvorschau zu erhalten,
bevor die Datei, beispielsweise über eine langsame Verbindung ins Internet, komplett
übertragen ist. Für eine Bildergalerie bietet JFIF außerdem die Möglichkeit, ein
unkomprimiertes RGB-Vorschaubild einzubetten. Im optionalen EXIF-Bereich können
Metadaten, wie beispielsweise GPS-Koordinaten, eingetragen werden.
JFIF ist in Segmente aufgeteilt. Diese entsprechen dem, was in anderen Formaten als
Tags bezeichnet wird. Das eigentliche Datensegment beginnt nach dem optionalen Header
mit einem Start-Of-Image-Marker. Dieser SOI-Marker besteht aus den zwei Bytes
0xFF und 0xD8.
Ein Tag-Header besteht immer aus vier Bytes: 0xFF XX SizeUB und SizeLB. Dabei gibt
XX gibt den Typ des Segments an; Tabelle 1 listet die Möglichkeiten dazu auf.
Die Länge des Datensegments errechnet sich aus SizeUB · 256 + SizeLB, und enthält
immer die zwei Bytes SizeUb und SizeLB selbst, womit ein leeres Datensegment die
Größe von zwei Bytes hat.
Der konkrete Aufbau einer JFIF-Datei sieht wie folgt aus:
1. SOI-Marker: 0xFF 0xD8
2. JFIF-Tag: FF E0 00 10 4A 46 49 46
4A 46 49 46 ist die ASCII-Codierung für JFIF
3. . . . weitere Tags
• unkomprimiertes Vorschaubild (optional)
• Quantisierungstabelle(n)
• . . .
4. SOS Start of Scan: enthält entropiekodierte Pixeldaten
5. EOI End of Image
JP2 JP2 ist das, im Gegensatz zu JFIF, ISO-standardisierte Dateiformat für JPEG-
2000. Es wurde in Teil 1 der Spezifikation definiert [ISO00].
Neben der Farbraum-Definition, nicht zu verwechseln mit dem Farbmodell, bietet es
einen optionalen Transparenzkanal und die Möglichkeit, palettenbasiert zu speichern.
Die Dateiendung ist festgelegt auf .jp2. Der MIME-Typ lautet ” image/jp2“.
Einsatzgebiet Die JPEG-Kompression lässt sich überall dort einsetzen, wo visuelle
Verluste in Kauf genommen werden können. Das Verfahren ist nicht nur auf statische
Bilder beschränkt, sondern kann auch auf bewegte Bilder angewandt werden.
27

FF xx Symbol Bezeichnung
FF D8 SOI Start Of Image
FF E0 APP0 JFIF tag
FF Cn SOFn Start of Frame Marker, legt Art der Kompression fest:
FF C0 SOF0 Baseline DCT
FF C1 SOF1 Extended sequential DCT
FF C2 SOF2 Progressive DCT
FF C3 SOF3 Lossless (sequential)
FF C5 SOF5 Differential sequential DCT
FF C6 SOF6 Differential progressive DCT
FF C7 SOF7 Differential lossless (sequential)
FF C8 JPG reserviert für JPEG extensions
FF C9 SOF9 Extended sequential DCT
FF CA SOF10 Progressive DCT
FF CB SOF11 Lossless (sequential)
FF CD SOF13 Differential sequential DCT
FF CE SOF14 Differential progressive DCT
FF CF SOF15 Differential lossless (sequential)
FF C4 DHT Definition der Huffman Tabellen
FF CC DAC Definition der arithmetischen Codierung
FF DB DQT Definition der Quantisierungstabellen
FF E1 APP1 EXIF Daten
FF EE APP14 Oft für Copyright Einträge
FF En APPn n = 2 . . . F allg. Zeiger
FF FE COM Kommentare
FF DA SOS Start of Scan
FF D9 EOI End of Image
Tabelle 1: Mögliche Tag-Typen innerhalb einer JFIF-Datei [Wik08d]
28

Bilder Das Format JFIF wird in vielen Bereichen der PC-Welt verwendet:
• Internet-Browser
• Java
• Bildverarbeitungssoftware: Paint, Gimp, Photoshop . . .
• Spiele
Im Internet ist es neben GIF immer noch das beherrschende Format, da es aufgrund der
kleinen Dateien schneller übertragen werden kann.
Die Java-VM unterstützt das Speichern und Laden von JPEG-Dateien, ohne dass der
Entwickler auf externe Bibliotheken angewiesen ist. Selbst Spiele, die auf DVDs ausgeliefert
werden, greifen auf das platzsparende Format zurück, um Texturen zu speichern.
Digitale Fotoapparate im semiprofessionellen Bereich speichern die Megapixel-Bilder
im JFIF-Format, wobei gelegentlich Spezialprozessoren eingesetzt werden, die hardwaremäßige
JPEG-Kompression sehr schnell durchführen können. Für Profi-Fotografen
hingegen eignet sich JFIF nur bedingt, weshalb es in diesem Bereich nur sehr selten anzufinden
ist. Artefaktbildung, mangelnde Kanalauflösung, die bei JFIF nur 8 Bit beträgt,
und fehlende Farbraumdefinition sind hier KO-Kriterien.
Video Die einfachste Möglichkeit, JPEG in Videos einzusetzen, ist Motion-JPEG, kurz
M-JPEG. Hierbei werden die einzelnen Frames unabhängig voneinander mittels JPEG
komprimiert und nacheinander abgespeichert. Da dieses Verfahren wenig Rechenleistung
erfordert und trotzdem zufriedenstellende Qualität liefert, wird es gerne auf mobilen
Geräten wie digitalen Videokameras eingesetzt. M-JPEG ist kein offiziell verabschiedeter
ISO-Standard, sondern nur eine Aneinanderreihung von JFIF-Bildern, weshalb die
Speicherung der zum Video gehörigen Tonspur nicht klar definiert ist.
Die Position der Tonspur ist hingegen bei MPEG, das von der Expertengruppe mit der
Bzeichnung ” ISO/IEC JTC1/SC29/WG11“ entwickelt wurde, im Standard verankert.
Das JPEG-Kompressionsverfahren wird hier noch mit anderen Techniken kombiniert,
wie beispielsweise Block-Motion-Compensation. Diese frameübergeifende Kompression
ermöglicht kleinere Dateien bei gleicher Qualität, erfordert jedoch höhere Rechenleistung.
MPEG wird unter anderem auf Video-DVDs und im Bereich digitaler Fernsehübertragung,
Digital Video Broadcasting (DVB), eingesetzt.
JPEG-2000 JPEG-2000 konnte trotz seiner Überlegenheit bis heute keine große Verbreitung
erlangen. Der einzige Browser, der dieses Format nativ unterstützt, ist die Mac
OS X-Version von Safari, weshalb solche Dateien im Internet auch nur selten anzutreffen
sind.
Dennoch gibt es Spezialanwendungen, die vom neuen Standard Gebrauch machen: der
medizinische DICOM-Standard erlaubt die Einbettung von JPEG-2000 in seine Datensegmente.
Die Texturen im Online-Rollenspiel ” Second Life“ werden platzsparend damit
komprimiert. Neuere PC-Spiele werden diese Möglichkeit wohl auch bald nutzen. Die
29

neuen deutschen Reisepässe speichern elektronisch Fingerabdrücke und Passbilder im
JPEG-2000-Format.
4.3 PNG
Zusammenfassung PNG ist ein standardisiertes freies Bildformat, das ursprünglich
als Ersatz für das GIF-Format geplant war, weil jenes den patentierten LZW-
Kompressionsalgorithmus verwendet. PNG unterstützt
• Palettengrafiken mit bis zu 256 Farben,
• Graustufenbilder mit 1, 2, 4, 8 oder 16 Bit Graustufentiefe pro Pixel,
• Rastergrafiken im Farbraum RGB mit 24 oder 48 Bit Farbtiefe pro Pixel
• sowie Alphakanäle mit 8 oder 16 Bit.
Dabei tritt besonders die Möglichkeit in den Vordergrund, einzelne Pixel mit 256 oder
65536 Abstufungen von Transparenz darzustellen, wohingegen das GIF-Format nur
volle Transparenz unterstützt.
Für Animationen, für die das GIF-Format berühmt ist, wurde als spezieller Nebenzweig
der Entwicklung von PNG das Format MNG (Multiple-Images Network Graphics)
entwickelt, das sich aber nicht durchsetzte.
PNG wird mittlerweile von allen gängigen Programmen zur Anzeige von Grafiken
unterstützt, allen voran die Webbrowser. Nachzügler war hier der von Microsoft
entwickelte Internet Explorer, der erst ab Release 7 PNG-Grafiken in vollem Umfang
unterstützte.
Kompression wird in PNG durch den Deflate-Algorithmus bereitgestellt, der sich aus
dem LZ77-Algorithmus, einem Vorgänger des LZW-Algorithmus, mit dem es keine
patentrechtlichen Probleme gab, und Huffman-Codes zusammensetzt. Obwohl der
Kompressionsalgorithmus mit LZ77 insgesamt nicht so effizient ist wie LZW, ist die
Kompression von PNG-Dateien ingesamt besser als die von GIF-Dateien, weil Vorfilter
verwendet werden [MA99] [Roe].
Standards, Dokumente Das PNG-Dateiformat wird zur Zeit in aktueller Version vom
W3C in einer sogenannten W3C-Recommendation, also einer Empfehlung, sowie dem
ISO-PNG-Standard beschrieben.
Aufbau von PNG-Dateien PNG war, wie die meisten freien Projekte, von Beginn an in
Hinblick auf Modularität und Übersichtlichkeit konzipiert. Nach einem Dateiheader folgt
eine Reihe von sogenannten Chunks (Brocken, Stück), die von unterschiedlichen, festgelegten
und frei gewählten Typen sein können und alle Daten des Bildes speichern. Dazu
gehören neben den Pixeldaten oder Palettendaten selbst zum Beispiel auch Metainformationen
über das Bild oder Chunks für spezielle Arten von Transparenz. Im folgenden
30

werden die elementaren Chunks des Formates vorgestellt, die für die Darstellung von
PNG-Bildern notwendig sind.
Aufbau des Formates Datei-Header
Der Header einer PNG-Datei enthält in den ersten acht Bytes der Datei die grundlegenden
Daten, die Darstellungs- oder Bearbeitungsprogramme benötigen:
Byte 1 2 3 4 5 6 7 8
HEX-Darstellung 89 50 4e 47 0d 0a 1a 0a
ASCII-Darstellung \211 P N G \r \n \032 \n
Die einzelnen Bytes haben die folgende Bedeutung:
1: Ein Startzeichen zur Identifikation des Dateiformats, da einige ältere Betriebssysteme
allein anhand des ersten Bytes eine Datei identifizieren. Das Zeichen wurde
absichtlich so gewählt, dass es nicht als ASCII-Zeichen interpretierbar ist, damit die
Datei nicht fälschlicherweise als gewöhnliche ASCII-Textdatei interpretiert werden
kann.
2, 3, 4: Der Name des Dateiformats in ASCII-Codierung.
5, 6: Unter den von Microsoft produzierten Betriebssystemen DOS und Windows wird
für das Einleiten einer neuen Zeile neben dem Standard \n, das für Linefeed steht,
auch \r verwendet. Dies simuliert die noch aus Zeiten der Schreibmaschine bekannte
Folge von Linefeed und Carriage Return (genannt CR-LF-Verfahren), wobei
Linefeed das Hinunterschieben des Druckkopfes auf eine neue Zeile und Carriage
Return das Zurückschieben des Druckkopfes an den Begin der Zeile bezeichnet.
Diese Kombination dient der Überprüfung auf Übertragungsfehler beim Transport
der Daten über ein Netzwerk.
7: Da das DOS-Betriebssystem von Microsoft nicht mit Dateien vom Typ PNG umgehen
kann, wurde hier das DOS-Standard-Stoppzeichen eingeführt, so dass das
Auslesen einer PNG-Datei an diesem Punkt abbricht.
8: Wie bereits die Bytes fünf und sechs dient auch dieses Zeichen dem Integritätstest.
In dieser Variante wird nur der Befehl Linefeed verwendet, der auf Unix-Systemen
Standardbefehl für einen Zeilenumbruch ist.
Da das PNG-Format, wie bereits erwähnt, auf Modularität ausgelegt ist, reicht es
aus, im Datei-Header das Dateiformat eindeutig zu beschrieben und Integritätstests
durchzuführen [MA99].
31

Chunks In PNG-Grafiken werden außer dem Datei-Header alle Daten in Chunks
gehalten. Hier können sowohl die eigentlichen Bilddaten wie Palette oder Pixeldaten,
als auch Metainformationen in Text-Chunks oder zusätzliche Informationen wie Transparenz
einzelner Pixel gespeichert werden.
Aufbau von Chunks Alle Chunks haben den gleichen Aufbau: Die ersten vier Bytes
geben die Länge des Chunks an, darauf folgen vier weitere Bytes, die vier ASCII-Zeichen
für die Beschreibung des Typs des Chunks, anschließend die eigentlichen Daten des
Chunks, die beliebig groß sein können, und zuletzt die CRC-Checksumme des Typ- und
des Datenfeldes. PNG verwendet eine Prüfsumme mit Cyclic Redundancy Check mit
dem standardmäßig verwendeten Polynom 32. Grades.
Anzeige- oder Bearbeitungsprogramme können durch diese Konvention rasch die ersten
acht Bytes auslesen, anhand des Typ-Feldes entscheiden, ob die enthaltenen Daten für
die Anzeige oder Bearbeitung wichtig sein könnten, und gegebenenfalls zum nächsten
Chunk springen.
Eine PNG-Grafik muss immer mindestens einen Header-Chunk (IHDR), dann mindestens
einen Daten-Chunk (IDAT) und letztlich einen End-Chunk (IEND) enthalten.
Der Header-Chunk muss der erste Chunk nach dem eigentlichen Datei-Header sein und
der End-Chunk muss der letzte Chunk in der Datei sein. Für Palettengrafiken wird
außerdem ein Paletten-Chunk (PLTE) benötigt. Die eigentlichen Bilddaten können
in mehrere Daten-Chunks aufgeteilt sein. Die Größe dieser Chunks ist meist von den
Puffergrößen der verwendeten Bildbearbeitungsprogramme abhängig.
Neben den in der PNG-Spezifikation angegebenen Chunks können Chunks auch selbst
definiert werden. Einige Programme zur Bildverarbeitung oder Bildindizierung verwenden
diese zum Speichern zusätzlicher Informationen, die für die jeweiligen Programme
wichtig sind.
Namenskonventionen für Typbeschreibungen von Chunks Die Benennung von
Chunks erfolgt nicht willkürlich. Die Groß- und Kleinschreibung der einzelnen Buchstaben
im Typ-Feld wird durch das fünfte Bit im Byte induziert. Der Buchstabe wird
groß geschrieben, wenn das Bit auf Null gesetzt ist, und klein geschrieben, wenn das Bit
auf Eins gesetzt ist. Im folgenden sind die jeweils fünften Bits jedes Bytes aufgeführt:
Byte 1: Ancillary Bit (Hilfsbit)
• Wird der Buchstabe groß geschrieben, ist der Chunk zur Darstellung des Bildes
notwendig. Programme, die diesen Chunk nicht verstehen, können demnach
das Bild nicht anzeigen.
• Wird der Buchstabe klein geschrieben, kann der Chunk von Bearbeitungsoder
Anzeigeprogrammen ignoriert werden.
Byte 2: Private Bit (privates Bit)
32

• Wird der Buchstabe groß geschrieben, gehört der Chunk zu den offiziell in
der PNG-Spezifikation genannten Chunks.
• Wird der Buchstabe klein geschrieben, stammt er von einem Programm, das
ihn zu speziellen Zwecken benutzt.
Byte 3: Reserved Bit (reserviertes Bit)
• Dieser Buchstabe muss zur Zeit immer groß geschrieben werden. Das Byte ist
reserviert, zur Zeit gibt es aber noch keine offizielle Bedeutung dafür.
Byte 4: Safe-to-copy Bit (sicher-zu-kopieren-Bit)
• Wird dieser Buchstabe groß geschrieben, ist der Chunk gewissermaßen
schreibgeschützt. Dies bedeutet, dass ein Programm, das den Chunk nicht
versteht, ihn nicht löschen oder Änderungen daran vornehmen darf.
• Wird dieser Buchstabe klein geschrieben, darf der Chunk geändert oder
gelöscht werden, auch wenn das bearbeitende Programm den Chunk nicht
versteht.
Die PNG-Spezifikation visualisiert diese Namenskonvention anhand des Beispiels
” bLOb“ [MA99]:
b klein geschrieben Ancillary Bit ist 1
L groß geschrieben Private Bit ist 0
O groß geschrieben Reserved Bit ist 0
b klein geschrieben Safe-to-copy Bit ist 1
IHDR-Chunk Nachdem der eigentliche Header der Datei dazu dient, nur die elementaren
Informationen über die Datei zu speichern, werden im darauf folgenden Header-
Chunk die grundlegenden Informationen über das Bild genannt:
• 4 Bytes speichern die Breite des Bildes.
• 4 Bytes speichern die Höhe des Bildes.
• 1 Byte speichert die Farbtiefe des Bildes.
• 1 Byte speichert den Farbtyp.
• 1 Byte speichert die Kompressionsmethode. Zur Zeit wird nur der Deflate-
Algorithmus unterstützt.
• 1 Byte speichert die Methode zum Vorfiltern. Vorfilter werden zur Zeit von den
meisten Programmen nicht standardmäßig angeboten.
• 1 Byte speichert die Interlace-Methode (Zeilensprung-Methode). Interlacing beschreibt
den Bildaufbau nicht von oben links nach unten rechts, sondern beispielsweise
zunächst mit jeder vierten Zeile.
33

In diesem Chunk können nicht beliebige Kombinationen von Bytes gespeichert werden.
Offensichtlich stehen der Farbtyp und die Farbtiefe in Korrelation, da nicht in jedem
unterstützten Farbtyp alle Farbtiefen verwendet werden können. Folgende Kombinationen
sind erlaubt:
Farbtiefe Erlaubte Bittiefe Bedeutung
0 1, 2, 4, 8, 16 Pixel beschreibt Grauwert
2 8, 16 Pixel beschreibt RGB-Tripel
3 1, 2, 4, 8 Pixel beschreibt Palettenindex
4 8, 16 Pixel beschreibt Grauwert und Transparenzwert
6 8, 16 Pixel beschreibt RGB-Tripel und Transparenzwert
PLTE-Chunk Sofern im Feld für den Farbtyp gespeichert wurde, dass es sich um eine
Palettengrafik handelt, muss der PLTE-Chunk im Bild genau einmal vorhanden sein,
und zwar direkt nach dem IHDR-Chunk. Da jeder Chunk seine Länge selbst speichert,
kann eine Farbpalette bei PNG-Grafiken zwischen 1 und 256 Farben beliebig lang sein,
wobei jede Farbe durch drei Bytes, je für Rot, Grün- und Blau-Anteil, gespeichert wird.
Dies ist ein Vorteil gegenüber GIF-Grafiken, bei denen eine Palette immer die Länge
derjenigen Zweierpotenz hat, die mindestens alle verwendeten Farben halten kann, und
damit in den meisten Fällen unnötige Einträge speichert.
IDAT-Chunk Eine PNG-Grafik muss immer mindestens einen IDAT-Chunk enthalten,
es kann aber auch, unter der Auflage, dass alle zusammenhängen, eine beliebig lange
Folge von IDAT-Chunks verwendet werden. Hier gibt meist die Puffergröße der verwendeten
Bearbeitungsprogramme den Ausschlag.
Die Daten in den IDAT-Chunks beschreiben die Farb- oder Graustufenwerte sowie
gegebenenfalls die Transparenzwerte, wenn es sich um eine Rastergrafik handelt, oder
die Palettenindizes, wenn es sich um eine Palettengrafik handelt. Der Chunk speichert
nur fertig komprimierte Daten; es läuft also gegebenenfalls ein Vorfilter über die
Bilddaten und anschließend komprimiert der Deflate-Algorithmus diese Daten, bevor
sie in die IDAT-Chunks geschrieben werden.
IEND-Chunk Ein IEND-Chunk muss als letztes Chunk jeder PNG-Grafik vorhanden
sein. Es enthält außer dem Namen und einer Länge von null keine weiteren Daten. Beim
Auslesen einer PNG-Grafik wird dieses Chunk lediglich verwendet, damit klar ist, dass
das Bild vollständig vorliegt und keine weiteren Daten von Anzeigeprogrammen mehr
ausgelesen werden müssen.
Text-Chunks Zum Speichern zusätzlicher Informationen ist das System mit Chunks
beliebig erweiterbar, solange es noch unbenutzte Typ-Namen für Chunks gibt. Trotzdem
34

gibt es drei Arten von Text-Chunks, die zum Standard gehören und dazu vorgesehen
sind, alle für Anzeigeprogramme eventuell wichtigen Metadaten zu speichern:
tEXt: Dieser Chunk wird für kurzen Text verwendet, der nicht komprimiert werden
muss oder soll. Die Kodierung der einzelnen Textinhalte erfolgt in Latin1 nach
ISO Standard 8859-1. Das bedeutet, dass keine Buchstaben gespeichert werden, die
nicht zum Standardzeichensatz gehören. Einzige Ausnahme ist das Zeilenumbruch-
Zeichen. Das Datenfeld dieses Chunks speichert lediglich ein Schlüsselwort, das
maximal 79 Bytes lang ist, ein Null-Byte zum Trennen und die Textnachricht.
zTXt: Für den Fall, dass größere Textinhalte im Bild gespeichert werden sollen, sieht
der Standard diesen Chunk vor, der neben dem Schlüsselwort und dem Text noch
ein Feld für die Kompressionsmethode speichert. Laut aktuellem Standard wird
zur Kompression von Text-Chunks wie auch den eigentlichen Bilddaten nur der
Deflate-Algorithmus unterstützt. Damit das Schlüsselwort jedes Chunks schnell
ausgelesen werden und bei Bedarf der dahinterstehende Text dekomprimiert werden
kann, wird nur der Text selbst, nicht aber das maximal 79 Bytes lange
Schlüsselwort komprimiert. Der Buchstabe z im Chunk-Namen steht für zlib, eine
Bibliothek, die den Deflate-Algorithmus implementiert.
iTXt: Dieser Chunk ermöglicht internationale Metadaten. Ein Feld speichert die nach
RFC 3066 definierten Abkürzungen für menschliche Sprachen. Das Feld für das
Schlüsselwort bleibt erhalten, es wird allerdings ein Feld für die Übersetzung des
Schlüsselwortes mit angehängt. Des Weiteren enthält auch dieser Chunk ein Feld
für die Kompressionsmethode, wobei auch hier nur der eigentliche Textteil komprimiert
werden kann.
Die Besonderheit des internationalen Text-Chunks ist, dass als Zeichensatz zum
Speichern der Metadaten der UTF-8-Zeichensatz verwendet wird. Dies gewährleistet,
dass auch Sonderzeichen aller möglichen Sprachen, wie sie im UTF-Standard
in ISO/IEC 10646-1 definiert sind, gespeichert werden können.
hIST-Chunk Für Palettengrafiken unterstützt das PNG-Format die Möglichkeit,
ein Histogramm, also eine Statistik über die Häufigkeit des Vorkommens einzelner
Paletteneinträge im Bild, zu speichern. Im Datenteil dieses hIST-Chunks wird eine
Reihe von 16 Bit langen Ganzzahlen vom Typ ” unsigned int“ gespeichert, die für jeden
Eintrag der Farbpalette jeweils die ungefähre Häufigkeit des Vorkommens dieser Farbe
im Bild speichert. Nachdem Histogramm-Einträge stets näherungsweise erfolgen, hat
nur der exakte Null-Wert eine spezielle Bedeutung, nämlich, dass die angegebene Farbe
im gesamten Bild überhaupt nicht vorkommt.
Verfahren zur Kompression Zur Kompression der Bilddaten wird der sogenannte
Deflate-Algorithmus verwendet, ein gerade in der OpenSource-Gemeinde sehr berühmter
und oft verwendeter Algorithmus, der zum Beispiel auch bei gzip Verwendung findet.
Die Kompression erfolgt bei PNG üblicherweise in drei Schritten, nämlich ” Vorfiltern“,
35

” LZ77-Kompression“ und Huffman-Codierung“, wobei zur Zeit leider viele Programme
”
standardmäßig keine Vorfilter verwenden, durch die eine erhebliche Ersparnis erreicht
würde. Außerdem kann eine Interlacing-Methode angegeben werden, die eventuell eine
schnellere Erkennbarkeit der Grafik bei niedrigeren Bandbreiten in Netzwerken erlaubt
[Deu96].
Vorfilter Grafiken vom Typ PNG können deutlich platzsparender sein als andere Grafiken,
insbesondere als solche vom Typ GIF. Ein großer Vorteil von PNG ist der in der
Kompressionsphase gegebenenfalls angewandte Vorfilter. Ein solcher Vorfilter kann z. B.
eine eingelesene Bildzeile mit der vorigen Bildzeile vergleichen und Verbindungen zwischen
gleichen Farben hergestellen.
Vorfilter werden immer byteweise ausgeführt und stehen deshalb nicht in direkter
Abhängigkeit vom Farbtyp oder der Farbtiefe der Grafik. Nichtsdestotrotz ist es für
Grafiken mit weniger als 256 Farben besser, unkomprimiert in einer Palettengrafik gespeichert
zu werden. Truecolor-Bilder sind meist sehr groß und eignen sich in den meisten
Fällen für effizientes Vorfiltern. Der PNG-Standard kennt die folgenden Vorfilter:
0 (None): Es wird kein Vorfilter angewendet. Dies ist leider die Standardeinstellung der
meisten Bildbearbeitungsprogramme.
1 (Sub): Es wird nicht der eigentliche Bytewert sondern die Differenz zum vorigen links
liegenden Pixelwert gespeichert.
2 (Up): Es wird nicht der eigentliche Bytewert sondern die Differenz zum Wert des
Pixels in der darüber liegenden Zeile gespeichert.
3 (Average): Es wird die Differenz aus dem eigentlichen Wert und dem Mittelwert des
links und darüber liegenden Pixels gespeichert.
4 (Paeth): Dieser Filter liest für ein Pixel den links daneben liegenden, den darüber
liegenden und den links darüber liegenden Pixelwert aus, addiert den links und
darüber liegenden Wert und zieht den links darüber liegenden Pixelwert von der
Summe ab. Anschließend wird für jeden der drei ausgelesenen Pixelwerte die Differenz
zum errechneten Vergleichswert bestimmt und letztlich derjenige Pixelwert
gespeichert, der am nächsten am Vergleichswert liegt [MA99].
4.4 WAV
Zusammenfassung In einer WAV-Datei werden Audiodaten in digitaler Form gespeichert.
Die Audiodaten sind Abtastwerte, die die Amplitude zu einem bestimmten
Zeitpunkt digital darstellen. Diese Abtastwerte, auch Samples genannt, werden in
einer WAV-Datei fortlaufend abgelegt und ergeben somit den zeitlichen Verlauf einer
Schwingung. Die Genauigkeit dieser digitalen Repräsentation, auch Qualität genannt,
hängt von der Anzahl der Abtastwerte pro Zeiteinheit (üblich sind 44100 Mal in der
36

Sekunde) und der Quantisierungsrate (beispielsweise 16 Bit pro Sample) ab.
Das WAV-Containerformat setzt auf dem Resource Interchange File Format (RIFF)
auf [wpw08]. RIFF ist ein Containerformat zur Speicherung von Multimedia-Daten,
das 1991 von Microsoft und IBM entwickelt worden ist. Als Grundlage für das RIFF-
Dateiformat diente das von der Firma Electronic Arts 1985 eingeführte Interchange
File Format (IFF). In RIFF-Dateien können unterschiedliche Multimedia-Ressourcen
gespeichert werden. Dabei wird nach dem Prinzip vom tagged File Format im Header
der Datentyp angegeben. Als mögliche Datentypen kommen BMP, WAV, AVI oder
RTF in Frage.
Zwar können in einer WAV-Datei auch komprimierte Daten abgespeichert werden, für
die dann ein bestimmter Wert im Header gesetzt werden muss, jedoch liegt der Inhalt
der WAV-Dateien in der Regel unkomprimiert vor. Aus diesem Grund wird im Folgenden
ausschließlich auf PCM-Rohdaten eingegangen. Ein Beispiel hierfür ist in Abbildung 6
auf Seite 39 zu sehen.
Aufbau des Formates Da eine WAV-Datei immer in einem RIFF-Container enthalten
ist, beginnt sie stets mit dem RIFF-Chunk, in dem dann der Datentyp festgelegt wird.
Bits Feldname Beschreibung
4 ChunkID Enthält die Buchstaben RIFF in ASCII-Form
(5216491646164616 als big-endian).
4 ChunkSize Hier wird die Gesamtgröße der Datei angegeben.
Dabei werden die 8 Bytes der Felder ChunkID
und ChunkSize nicht berücksichtigt.
4 Format Enthält den Formattypen. In diesem Fall die
Buchstaben WAVE
(5716411656164516 als big-endian).
Dem RIFF-Chunk folgt stets der Format-Chunk, in dem das Format und die Art der
Darstellung der Audiodaten angegeben ist.
37

Bits Feldname Beschreibung
4 Subchunk1ID Enthält die Buchstaben fmt
(66166d1674162016 big-endian form).
4 Subchunk1Size Dies ist die Größe des folgenden Format-Chunks
in Bytes. Bei PCM folgen stets 16 Bytes.
2 AudioFormat Besagt, in welcher Form die Audiodaten vorliegen.
Da wir von PCM ausgehen ist dieser Wert
1.
2 NumChannels Die Anzahl der Kanäle:
Mono = 1, Stereo = 2, . . .
4 SampleRate Abtastwerte pro Sekunde:
z. B.: 8000, 22050, 44100
4 ByteRate Bytes pro Sekunde. Die Byterate ergibt sich aus
der Anzahl der Kanäle und der Anzahl der Abtastwerte
pro Sekunde.
2 BlockAlign Bytes pro Abtastwert.
2 BitsPerSample Bits pro Zeiteinheit für einen Kanal.
8 bits = 8, 16 bits = 16, . . .
Der Data-Chunk enthält die Audiodaten und somit den Teil der Datei, der für
steganographische Zwecke interessant ist. Der RIFF-Chunk und der Format-Chunk
sollten bei einer Dateneinbettung nicht verändert werden.
Bits Feldname Beschreibung
4 Subchunk2ID Enthält die Buchstaben data
(6416611674166116 als big-endian).
4 Subchunk2Size Die Anzahl der Bytes der folgenden
Audiodaten in diesem
Chunk.
* Data Die Audiodaten. Dabei werden
die Audioinformationen
aller Kanäle chronologisch abgelegt.
Das ist in Abbildung 6
gut zu erkennen.
4.5 PDF
Zusammenfassung Bei dem Portable Document Format (PDF) handelt es sich um
ein Dateiformat für Dokumente, die mit Einschränkungen nicht mehr verändert werden
sollen. PDF wurde von der Firma Adobe Systems [ado08a] entwickelt. Die Spezifikationen
sind zwar offen und von der ISO genormt, Adobe behält sich aber das Copyright an diesen
vor.
38

Abbildung 6: Beispiel für eine unkomprimierte WAV-Datei. [pcm08]
Eine PDF-Datei hat den Vorteil, auf allen betrachtenden oder verarbeitenden Systemen
unabhängig von der Konfiguration (verwendetes Betrachtungsprogramm, installierte
Schriften, Art des Druckers) gleich auszusehen. Dies mag ein Grund sein, warum PDF
sehr weit verbreitet ist und als wichtiges Format für die Archivierung, den Austausch
oder den Druck von Dokumenten gilt.
Neben fast allen gängigen Office-Paketen und dem Textsatzsystem L ATEXexistieren
viele Programme und Konverter, die PDF-Dateien beispielsweise aus Postscript- oder
HTML-Dateien erzeugen können [wp08].
Aufbau des Formates PDF ist ein vektorbasiertes Seitenbeschreibungsformat, welches
die freie Skalierung des Inhalts ermöglicht. Ein PDF-Dokument ist aus vielen so genannten
Objekten aufgebaut, welche Teile des Inhalts repräsentieren. Eine einzelne Seite kann
dabei aus hunderten Objekten bestehen. Objekte können verschiedenster Art sein.
Ein Textobjekt besteht aus einem oder mehrerer Glyphen die Zeichen repräsentieren.
Das Aussehen dieser Glyphen wird in einer separaten Datenstruktur, einer so genannten
Font als Vektorgrafik definiert.
Ein Pfadobjekt definiert eine Menge von verbundenen und nicht verbundenen Punkten,
Linien und Flächen, die so eine Vektorgrafik bilden.
Ein Bildobjekt ist eine rechteckige Rastergrafik, die beispielsweise ein Bild in das
39

Dokument integriert. Diese Bildobjekte können bei Bedarf mittels JPEG, JPEG2000
oder LZW komprimiert werden.
Dies sind die wichtigsten Objekte, jedoch gibt es noch eine Vielzahl weiterer. Die Reihenfolge
der Objekte in der Datei ist nicht festgelegt, hat keine semantische Bedeutung
und kann somit vom Ersteller frei definiert werden. Um dies zu ermöglichen enthält
ein PDF-Dokument am Dateiende eine Referenztabelle, die die Position jedes Objektes
innerhalb der Datei enthält.
Die Geometrie einer einzelnen Seite wird durch verschiedene Arten von Boxen, also
rechteckigen Rahmen, definiert. Die MediaBox beschreibt die Größe des Ausgabemediums.
Alle anderen Boxen müssen sich innerhalb dieser befinden.
Die CropBox beschreibt den Bereich der Seite, der auf der Ausgabe ausgegeben werden
soll. Meist ist diese nicht kleiner als die MediaBox.
Die BleedBox und die TrimBox beinhalten den Platz auf der Seite, der letztendlich nur
bedruckt wird. Die BleedBox ist etwas größer, da sie noch einen Rahmen, den Beschnitt,
beinhaltet, der für die Drucktechnik wichtig ist.
Letztendlich bildet eine ArtBox den Rahmen für ein Objekt. Bis auf die MediaBox
sind alle Boxen optional [Ado06].
4.6 SVG
Zusammenfassung Scalable Vector Graphics, kurz SVG, sind Vektorgrafiken, welche
in einem standardisierten XML-Format gespeichert werden. Es ist möglich, dass der
Dateiinhalt mittels gzip komprimiert wurde, dann muss die Datei vor der Bearbeitung
zunächst dekomprimiert werden. Ein derart komprimiertes SVG hat die Dateiendung
’.svgz’, unkomprimierte SVG-Bilder, deren Inhalt im Klartext vorliegt, haben die Dateiendung
’.svg’.
Aufbau des Formates Die Datei beginnt üblicherweise mit einer XML-Deklaration:
Die eigentlichen SVG-Daten befinden sich zwischen einem einleitenden - und
einem abschließenden -Tag. Dazwischen befinden sich die Beschreibungen der
verschiedenen Elemente der Vektorgrafik.
Eine kleine Übersicht der verschiedenen Tags:
• beschreibt einen Pfad.
• beschreibt einen Kreis.
• beschreibt eine Linie.
• ... beschreibt und definiert einen Text.
40

Über die einzelnen grafischen Elemente hinaus gibt es Tags, welche zur Beschreibung
von Animationen genutzt werden können. Darüber hinaus ist Scripting mit einem
JavaScript-Dialekt und das Einfügen von grafischen Effekten und Filtern möglich.
Ein Tag dient nur der Einordnung eines grafischen Elements, es fehlt die genaue Beschreibung
der Eigenschaften (Höhe, Breite, Liniendicke, etc.). Dies wird durch die Attribute
eines Tags erreicht, welche innerhalb des einleitenden Tags in der Form von
Name=”Wert” angegeben werden [Wik08g].
4.7 CSS
Zusammenfassung Cascading Style Sheets sind eine Ergänzung zu HTML, mit der
sich die Struktur eines HTML-Dokuments vom Layout trennen lässt.
CSS wurde mit HTML 4.0 im Jahr 1997 vom W3C offiziell als Standard verabschiedet.
Ein sauberes HTML 4.0+ Dokument verwendet keine Formatierungsangaben wie beispielsweise
Farbe und Schriftart, sondern gibt lediglich die Struktur für den Inhalt vor.
Ein Stylesheet, ins Deutsche übersetzt ” Formatvorlage“, enthält zentral die eigentlichen
Layoutangaben. Dadurch werden zum einen Redundanzen vermieden und zum anderen
wird ein schnelles Umgestalten des Webseiten-Layouts vereinfacht.
Aufbau des Formates Ein CSS kann innerhalb eines HTML-Dokuments definiert werden:
. kommentar { font −s t y l e : i t a l i c ;
c o l o r : red ;
font −s i z e : 12 pt }
Die gängigere Methode ist jedoch, einen Link auf eine CSS-Datei anzugeben, der gleichzeitig
von verschiedenen HTML-Dateien genutzt werden kann [Bol08]:
Die Datei-Endung für eine Stylesheet-Datei ist .css.
CSS besteht aus Regeln. Eine Regel definiert durch Kommata abgetrennte Selektoren.
Jene stehen vor geschweiften Klammern und innerhalb eines solchen Klammerblocks
befinden sich durch Semikolons getrennt Eigenschaft-Werte-Paare: jeder Eigenschaft
folgt nach einen Doppelpunkt ein oder mehrere Werte. Auch mehrere durch Blanks
getrennte Worte sind erlaubt.
/∗ CSS−Regel ∗/
S e l e k t o r [ , S elektor2 , . . . ] {
Eigenschaft −A: Wert−A;
Eigenschaft −B: Wert−B
}
41

Eine Übersicht aller Selektoren ist hier zu finden: [W3C08b].
Ein konkretes CSS-Beispiel sieht so aus:
p . note {
p o s i t i o n : r e l a t i v e ;
l e f t : 15%;
width : 80%;
padding : 30px ;
padding−bottom : 45px ;
border : 1px s o l i d black ;
l i n e −h e i g h t : 1 . 5em ;
c o l o r : black ;
font −weight : bold ;
text −a l i g n : j u s t i f y ;
background−c o l o r : #e e e e e e
}
Auf folgende Weise wird diese Regel in HTML benutzt:
Dies i s t e i n k l e i n e r Testabsatz . Dies i s t e i n k l e i n e r Testabsatz .
. . .
Abbildung 7 zeigt die Ausgabe des Web-Browsers [Wik08b]. Eine Auflistung und Be-
Abbildung 7: Browser-Interpretation von CSS und HTML
schreibung aller möglichen Werte gibt es hier [Blo08]. Weitere Informationen gibt es
direkt auf der CSS-Homepage des W3C [W3C08a].
42

5 Vorhandene steganographische Algorithmen
5.1 Grundlagen
Die nachfolgenden Algorithmen dienen der steganographischen Einbettung in Dateien
unterschiedlicher Formate. Damit geht einher, dass die Funktionsweise sich von Algorithmus
zu Algorithmus unterscheidet, gerade in Abhängigkeit zum verwendeten Dateiformat.
Die grundlegenden Begriffe und Vorgänge, die alle Algorithmen gemeinsam haben,
werden hier kurz vorgestellt. Formatspezifische Begriffe können den vorangegangen Beschreibungen
der einzelnen Dateiformate entnommen werden.
Ein steganographischer Algorithmus verwendet als Eingabe eine Datei, das so genannte
Cover. Ein Cover kann zum Beispiel eine Bild-Datei oder eine Audio-Datei sein, die
steganographische Einbettung funktioniert aber auch mit Textdateien oder beinahe beliebigen
anderen Dateien. Grundlegend kann ein Cover demnach als Vektor von Bits
aufgefasst werden. Nach Anwendung des Algorithmus wird aus dem Cover ein Steganogramm,
auch Stego-Datei genannt, also eine Datei, die dem eingegebenen Cover
möglichst gleicht. Dies bedeutet, dass das Aussehen oder der Klang als für den Menschen
wahrnehmbare Eigenschaften, als auch die binäre Repräsentation der Datei, wie sie auf
dem Rechensystem gespeichert oder über ein Netzwerk verschickt wird, möglichst geringfügig
vom eingegebenen Cover abweicht. Weiterhin enthält das Steganogramm nach
Anwendung des Algorithmus die Geheimnachricht. Diese kann eine beliebige Kette
von Bits sein, also eine gewöhnliche Text-Nachricht in beispielsweise ASCII- oder UTF-
8-Formatierung, oder eine binäre Nachricht in Form einer anderen Datei. Die Anwendung
des Algorithmus auf ein Cover nennen wir Einbettung.
Um die Geheimnachricht in das Cover einzubetten, wird die Binärrepräsentation des
Covers, also die darin enthaltenen Bits, die nur die Werte Eins oder Null annehmen
können, geändert. Ein niederwertigstes Bit, auch Least Significant Bit genannt,
beschreibt dabei dasjenige Bit einer Binärzahl, dessen Wertigkeit am geringsten ist, das
höherwertigste Bit oder Most Significant Bit hingegen das Bit mit der höchsten
Wertigkeit. Für die Schreibweise verwenden wir das sogenannte Little Endian-Format,
das zum Beispiel von Prozessoren der Firma Intel verwendet wird. Dies bedeutet, dass
eine Binärzahl von links nach rechts beginnend mit dem höherwertigsten Bit geschrieben
und auf gleiche Art und Weise im Arbeitsspeicher eines Rechensystems abgelegt
wird. Dabei steht das niederwertigste Bit in der kleinsten Speicheradresse, nachfolgende
höherwertigere Bits stehen in Speicherzellen mit größeren Adressen.
Ein Bit vorn oder links anzuhängen heißt demnach, ein noch höherwertigeres Bit als
das bisher höherwertigste Bit der Binärzahl hinzuzufügen, ein Bit hinten oder links
anzuhängen bedeutet analog, dass alle vorhandenen Bits in ihrer Wertigkeit um eine
Zweierpotenz aufsteigen und ein neues niederwertigstes Bit hinzugefügt wird, also eine
Eins oder eine Null. Selbiges gilt für die Geheimnachricht, die ebenfalls als Vektor aus
Bits aufzufassen ist.
Die Entscheidung, welche Teile des Covers vom Algorithmus geändert werden, um die
Geheimnachricht einzubetten, wird bei einigen Algorithmen von einem Pseudozufalls-
43

zahlengenerator, kurz PRNG für Pseudo Random Number Generator, übernommen.
Dieser verwendet einen eigenen Algorithmus, um – ausgehend von einem Startwert, dem
Random Seed oder Stego-Key, zum Beispiel einem Passwort – Zahlen pseudozufällig
zu generieren. So kann die gleiche Zahlenfolge unter Verwendung des gleichen Algorithmus
und Passwortes auf Seiten des Senders wie des Empfängers eines Steganogramms
hergestellt werden. Die Steganographie ist zum versteckten Übertragen von Informationen
gedacht, daher betrachten wie Sender und Empfänger eines Steganogramms als
zwei Klienten in einem großen, offenen Netzwerk von Rechensystemen, wie dem Internet.
Alle Beschreibungen der Sicherheit von Algorithmen oder Angriffen auf diese verwenden
das Prinzip von Kerckhoff, das heißt, die beschriebenen Algorithmen sind öffentlich
und können von jedermann frei studiert oder verwendet werden. Die Sicherheit der steganographischen
Algorithmen wird also daran bemessen, wie hoch die Wahrscheinlichkeit
ist, in dem Steganogramm enthaltene Daten zu finden. Bereits das Finden von solchen
Datenmustern, nicht erst das Auslesen der Geheimnachricht, gilt als erfolgreicher Angriff
auf die steganographischen Algorithmen. Gleichzeitig soll, wie bereits erwähnt, ein
menschlicher Betrachter nicht imstande sein, mit seinen eigenen Sinnen zu erkennen, ob
es sich um eine gewöhnliche Datei oder ein Steganogramm handelt.
Die Ausbettung einer Geheimnachricht beschreibt die Anwendung des Algorithmus,
welche die zuvor in der Einbettung veränderten Bits findet und daraus die Geheimnachricht
zusammensetzt. Dieser Vorgang basiert zunächst einmal auf der Funktionsweise
des Algorithmus selbst, das Auslesen der Geheimnachricht kann bei einigen Algorithmen
aber auch erst durch die Eingabe eines Passwortes oder das Setzen von Parametern
möglich werden. Parameter sind dabei besondere Einstellungen von Algorithmen, um
beispielsweise festzulegen, wie groß ein Block von Daten sein soll, der bei der Ein- und
Ausbettung bearbeitet wird. In solchen Fällen kann die Geheimnachricht nur dann ohne
Fehlversuche ausgebettet werden, wenn dem Empfänger des Steganogramms das Passwort
und/ oder die Parameter bekannt sind, die vom Sender eingegeben wurden.
5.2 Einbettung in GIF-Dateien
5.2.1 GIFShuffle
Zusammenfassung GIFShuffle wurde im Januar 1998 von Matthew Kwan veröffentlicht.
Im Januar 2003 folgte GIFShuffle 2.0.
Der Algorithmus kodiert Geheimnachrichten über die Reihenfolge der Farbeinträge in
der Farbpalette.[?]
Algorithmus Zunächst wird der Binärrepräsentation der Geheimnachricht eine Eins
vorn angestellt, um die Zahl eindeutig zu machen für den Fall, dass sie mit einer oder
mehreren Nullen beginnen sollte. Danach werden die einzigartigen Farben im Cover, also
die Farben, die in der Farbpalette nur einmal vorkommen, gezählt. Da die Nachricht
über die Permutation der Farben eingebettet wird, kann nun bereits getestet werden, ob
die Nachricht überhaupt eingebettet werden kann. Gilt m > n! − 1, wobei m die Nachrichtenlänge
und n die Anzahl einzigartiger Farben im unveränderten Bild beschreibt,
44

so ist die Nachricht zu groß, um eingebettet zu werden.
Wenn die Nachricht eingebettet werden kann, werden die einzigartigen Farben der Farbpalette
des Covers in natürliche Ordnung gebracht, indem die Werte für Rot mit 256 2 ,
die für Grün mit 256 1 und die für Blau mit 256 0 multipliziert und anschließend diese
Werte addiert werden (r · 65536 + g · 256 + b). Im Anschluss wird in einer Iteration jede
einzigartige Farbe der Palette auf Position m mod i gesetzt, wobei i die Iterationsvariable
(1...n) beschreibt. Sollte dabei ein Index bereits belegt sein, werden alle bereits
eingefügten Farben inkrementiert, also in der Palette um einen Index nach oben verschoben.
Schließlich werden die nicht eindeutigen Farben hinten an die Farbpalette angehängt
und die Pixeldaten, welche die Farben in der Farbpalette indizieren, so angepasst, dass
sie die gleiche Farbe wie vor der Einbettung indizieren.
Der Empfänger des Stego-Bildes kann nun aus der Reihenfolge der Paletteneinträge
auf die Geheimnachricht schließen. Der Algorithmus stellt die natürliche Ordnung der
einzigartigen Farben her, iteriert durch diese Farben und berechnet bei jeder Iteration
m = m · (n − i) + p, wobei m die Nachricht, n die Anzahl einzigartiger Farben in der
Farbpalette, i die Iterationsvariable (1...n) und p der Index der Farbe in der Farbpalette
in natürlicher Ordnung ist.
Bei n Farben können log2(n!) Bits eingebettet werden. Da die meisten Farbpaletten
gemäß der Helligkeit oder den Vorkommen im Bild geordnet sind, gilt ein Algorithmus,
der Paletteneinträge umsortiert, generell als sehr unsicher. Des weiteren ist eine Permutation,
die aus der natürlichen Ordnung der Farbpalette abgeleitet ist, als äußerst unsicher
zu bewerten, weil ein jeder die mit der natürlichen Ordnung vorgegebene anfängliche
Permutation der Einträge kennt.
5.2.2 FriRui
Zusammenfassung Der Algorithmus stammt aus einer Veröffentlichung von Jessica
Fridrich und Du Rui, mit dem Titel ” Secure Steganographic Methods for Palette
Images“([Jir01]) Mit dem Algorithmus lassen sich Daten in palettenbasierten Bildern
verstecken. Die Funktionsweise des Algorithmus wird für GIF Bilder im Folgenden
erläutert.
Algorithmus Anhand folgender Formel berechnet man die Distanzen aller Farben in
der Farbpalette.
dij = (Ri − Rj) + (Gi − Gj) + (Bi − Bj) (4)
dij ist die Distanz zweier Farben i und j. R, G und B stehen für die einzelnen Farbwerte:
Rot, Grün und Blau. Nun kann man Tripel folgender Form erstellen.
((Ri, Gi, Bi), (Rj, Gj, Bj), dij) (5)
Diese Tripel lassen sich nun anhand der Distanz aufsteigend sortieren. Die Farben in
dieser geordnete Menge von Tripeln trägt man nun in eine gesonderte Tabelle ein und
verändert dabei eventuell die Parität. Die Parität jeder Farbe berechnet man, indem
45

man die einzelnen RGB-Farbwerte addiert. Ist das Ergebnis dieser Addition gerade, so
ist die Parität null, ist es ungerade, so ist die Parität eins. Beim Eintragen der Farben
aus den einzelnen Tupeln der geordneten Tupelmenge geht man folgendermaßen vor:
Ist keine der betrachteten Farben in der neuen Tabelle, verändert man die Paritäten der
Farben so, dass sie sich unterscheiden. Ist eine der betrachteten Farben in der Tabelle, so
verändert man die andere Farbe, so dass sich die Paritäten unterscheiden. Diesen Vorgang
wiederholt man, bis man alle Farben in die neue Tabelle eingetragen hat. Abbildung 8
verdeutlicht diesen Vorgang.
Möchte man nun ein Nachrichtenbit mit Wert Null einbetten und ist die Parität der
Originalfarbe im Bild gleich Eins, so verwendet man die Farbe mit geringster Distanz zum
Original, welche die Parität Null hat. Entsprechend verfährt man für den umgekehrten
Fall.
Einbettung in mehrere Pixel Das Bild wird in Pixelketten aufgeteilt. Die Parität über
alle Pixel in dieser Kette wird gebildet. Es muss nur ein Farbwert in der Kette geändert
werden. Hierzu kann man das Unauffälligste auswählen.
Aus der Veröffentlichung geht hervor, dass eine Kettenlänge von 2 die Anzahl an
Änderungen um 30% verringert.
• Vorteil: Je weniger Änderungen, desto schwerer durch Analyseverfahren aufzuspüren.
• Nachteil: Je mehr Pixel in einer Kette, desto niedriger die Einbettungsrate.
Einbettung nach vorheriger Analyse Berücksichtigt die Anordnung der Bits im Cover.
Einfarbige Bereiche werden beispielsweise ausgelassen. Nur Pixel in deren Umgebung sich
x verschiedene Farben befinden, werden berücksichtigt.
Einbettung während Farbreduktion Man nutzt die Effekte der Farbreduktion um Daten
einzubetten. Bei diesem Verfahren wird nicht die Originalfarbe verwendet die der
Farbreduktionsalgorithmus ermittelt, sondern die nächstgelegene Farbe mit der passenden
Parität. Bei statistischen Analysen fällt dies nicht so sehr auf, da nur Pixel verändert
werden, die sich schon durch die Farbreduktion hervorheben.
Methode 1 Man teilt das Bild in Blöcke zu 3x3 Pixeln. Man bildet die Parität über den
ganzen Block. Nun bestimmt man eine Funktion anhand derer man Werte für die MSBs
berechnen kann. Man bestimmt einen Schwellwert, der zur Einbettung genutzt wird.
Wird dieser Schwellwert nach der Einbettung in einen Block überschritten, so wird die
Einbettung zwar durchgeführt, das Nachrichtenbit wird jedoch erneut in den nächsten
Block eingebunden. Der Empfänger betrachtet nun nur die Blöcke, die den Schwellwert
nicht überschreiten.
46

Palette (Farbwerte als int)
Paritäten der Farbwerte
Pixeldaten (Indizes auf Palette)
Cover
1 | 3 | 3 | 4
1 | 1 | 1 | 0
0 | 1 | 2 | 3
D = { (1,2,0) , (1,3,1), (2,3,1), (0,1,2) , (0,2,2), (0,3,3) }
-- wobei Tripel:= (Farbindex1, Farbindex2, Distanz)
Indizes der Paletteneinträge
Paritäten (NEU) der Einträge
Pixeldaten vor Einbettung:
Neue Paritäten der Einträge:
Geheimnachricht:
Pixeldaten nach Einbettung:
C (Datenstruktur des Algorithmus)
1 | 2 | 3 | 0
1 | 0 | 0 | 0
Cover -> Stego-Bild
0 | 1 | 2 | 3
0 | 1 | 0 | 0
1 | 0 | 0 | 1
1 | 2 | 2 | 1
Abbildung 8: Ein Beispiel zum FriRui Algorithmus
47
Distanzen bestimmen
Optimale Paritäten
bestimmen
Nachricht einbetten

Methode 2 Man teilt das Bild in Blöcke zu 2x2 Pixeln. Enthält ein Block mehr als 2
verschiedene Farben, so wird für gut befunden. Eine Farbe wird für gut befunden, wenn
alle 2x2-Blöcke, in denen sie enthalten ist, für gut befunden wurden. Aus der Menge der
Pixel mit guten Farben, wählt man diejenigen, die zur Einbettung der Geheimnachricht
genutzt werden sollen, aus. Der Block muss nach der Einbettung immer noch als gut
deklariert werden, ähnlich wie in Methode 1.
5.2.3 Sortieren/Umsortieren
Zusammenfassung Der Algorithmus von Corinna John, von uns ” Sortieren und Umsortieren“
genannt, versteckt eine Nachricht durch Umsortieren der Einträge der Farbpalette.
Die Funktionsweise ist demnach analog zu der von GIFShuffle [Joh].
Algorithmus Der Algorithmus stützt sich auf die Tatsache, dass die Einträge der Farbpalette
in GIF-Bildern, zumindest in der Theorie, willkürlich sortiert sein können. Die
Einträge werden gemäß einer zuvor festgelegten Ordnung (z. B. aufsteigend nach Helligkeit)
sortiert. Auch völlig unsortiert aussehende Paletten sind dabei erlaubt, so lange der
Empfänger des Stego-Bildes diese kennt und damit die Nachricht reproduzieren kann.
Dies ist ein eklatanter Vorteil gegenüber GIFShuffle, bei dem die Palette immer gemäß
der natürlichen Ordnung der Farben sortiert wird und eine Einbettung demnach leicht
reproduziert werden kann.
Die Geheimnachricht wird eingebettet, indem man, wenn man eine Eins ausdrücken
möchte, den Paletteneintrag in der sortierten Palette auf seiner aktuellen Position
belässt, und, wenn man eine Null ausdrücken möchte, den Paletteneintrag um einen
Index nach unten verschiebt. Sollte dabei der untere Index nicht frei sein, werden alle
Farben mit einem unteren Index um eine Stelle weiter nach unten verschoben. An den
Rändern der Palette wird zyklisch verschoben, das letzte Element kann also zum ersten
Element werden.
Der Empfänger des Stego-Bildes kann den gleichen Algorithmus noch einmal anwenden,
wobei wiederum die festgelegte Ordnung hergestellt und anschließend die Indizes miteinander
verglichen werden: Abweichnungen beschreiben eine Null, sonst Eins.
Die Einbettungsrate liegt bei einem GIF-Bild mit 256 Farben bei 256 − 1 Bit, was 31
ASCII-Zeichen entspricht. Nachdem aber die Mehrzahl aller GIF-Bilder zumindest irgendeine
Sortierung enthält (z. B. nach Helligkeit oder Vorkommen der Farben im Bild),
ist die Entdeckungswahrscheinlichkeit des Algorithmus hoch und dieser damit als unsicher
einzustufen.
5.3 Einbettung in JPEG-Dateien
5.3.1 F5
Zusammenfassung
F5 wurde 2001 von Andreas Westfeld [Wes01] entwickelt und soll die statistischen Eigenschaften
eines Trägers erhalten. Im Gegensatz zu den meisten LSB-Verfahren werden
die einzelnen Frequenzkoeffizienten nicht überschrieben, sondern ihr absoluter Wert
48

dekrementiert. Zudem werden Frequenzkoeffizienten mit Wert 1 genutzt, lediglich Koeffizienten
mit Wert 0 werden nicht für dir Einbettung genutzt.
F5 bedient sich der Matrixkodierung von Ron Crandall [Cra98], wodurch die Einbettungseffizienz
gesteigert wird.
Permutative Spreizung
Bei F5 wird eine steganographische Nachricht nicht von oben nach unten in den Träger
eingebettet, sondern mit Hilfe einer Permutation der Frequenzkoeffizienten in dem Träger
verteilt. Die Permutation ist abhängig von einem Schlüssel, den sowohl Sender als auch
Empfänger besitzen müssen.
Matrixkodierung
Bei der Matrixkodierung werden n änderbare Stellen eines Trägers zu einem Block (Kodewort)
zusammengefasst. Um eine Nachricht x, bestehend aus k Stellen, in den Träger
einzubetten wird geprüft, ob eine Hashfunktion f aus dem Kodewort bereits die Nachricht
extrahieren kann: x = f(a), wobei a das Kodewort ist. Ansonsten muss das Kodewort
so geändert werden, dass gilt x = f(a ′ ), wobei a ′ das veränderte Kodewort ist.
Dabei darf die Anzahl der Änderungen (Hammingdistanz) d, obwohl die Matrixkodierung
auch andere Modi erlaubt, bei denen 2, 3 oder mehr Stellen verändert werden
müssen, bei F5 nicht größer als 1 sein: d(a, a ′ ) ≤ 1. Die Kodewortlänge ergibt sich bei
einer Nachrichtenlänge k somit zu n = 2 k − 1
Das folgende Beispiel verdeutlicht die Einbettung einer Nachricht, die aus zwei Bits x1,
x2 besteht, in ein Kodewort a der Länge n = 3.
x1 = a1 ⊕ a3, x2 = a2 ⊕ a3 ⇒ nichts ändern
x1 �= a1 ⊕ a3, x2 = a2 ⊕ a3
x1 = a1 ⊕ a3, x2 �= a2 ⊕ a3
x1 �= a1 ⊕ a3, x2 �= a2 ⊕ a3
⇒ a1 ändern
⇒ a2 ändern
⇒ a3 ändern
Algorithmus
Zu Beginn des F5-Algorithmus wird die Permutation der Frequenzkoeffizienten mittels
eines Schlüssels initialisiert. Zudem wird mit Hilfe der maximalen Kapazität des Trägers
und der Nachrichtengröße der Parameter k sowie die Kodewortlänge n bestimmt.
Die Einbettung selbst ist in Abb.9 beschrieben.
Die Bildung des Hashwerts in Zeile 3 wird nach folgendem Schema berechnet:
hash(a) = ⊕ n i=1ai ∗ i
Eigenschaften
Beim Vergleich des eigentlichen JPEG Histogramms (Abb.10) und des Histogramms
nach der Einbettung mittels F5 (Abb.11) fällt auf, dass die Häufigkeit der Frequenzkoeffizienten
mit Wert 0 leicht ansteigt. Dieses ist auf die Schrumpfung zurückzuführen,
49

C = JPEG-Frequenzkoeffizienten
buffer[n] = n-stelliger Einbettungspuffer
1 do
2 buffer mit n Indiezes der Koeffizienten, die nicht 0 sind, füllen
3 hash = k − -stelliger Hashwert
4 msg = k Bits der Nachricht
5 position = hash ⊕ msg
6 if position �= 0 then
7 Dekrementiere Betrag von C[buffer[position − 1]] um 1
8 while C[buffer[position]] = 0
Abbildung 9: F5 Algorithmus
die entsteht, wenn bei der Einbettung ein Koeffizient mit einem Absolutwert von 1 zu 0
dekrementiert wird und ein neuer Block zur Einbettung ausgewählt werden muss.
Häufigkeit
-4 -3 -2 -1 0 1 2 3 4
JPEG-Koeffizienten
Abbildung 10: JPEG-Histogramm
Häufigkeit
-4 -3 -2 -1 0 1 2 3 4
Abbildung 11: F5-Histogramm
JPEG-Koeffizienten
Durch die Matrixkodierung bietet F5, in Abhängigkeit von der Einbettungsrate, eine
relativ hohe Einbettungseffizienz wie in Abb.12 zu sehen.
Dabei ergeben sich die einzelnen Kurven für die Einbettungsrate R, die Änderungsdichte
D und die Einbettungseffizienz E aus den folgenden Formeln:
Einbettungsrate (Nachrichtenlänge pro Kodewort):
R(k) = k
2 k − 1
50

E(k)
10
9
8
7
6
5
4
3
Abbildung 12: F5-Einbettungsrate
2
1 2 3 4 5 6 7 8 9 10
k
Änderungsdichte (Änderungen pro Nachrichtenbit):
D(k) = 1
2k
Einbettungseffizienz (Eingebettete Bits pro Änderung):
E(k) = R(k)
D(k)
Allerdings muss hierbei noch die Schrumpfung berücksichtigt werden, wodurch F5 eine
Einbettungseffizienz von 1,5 bei maximaler Einbettungrate erreicht.
Angriff
In [FGH03] wird beschrieben, dass es möglich ist, Einbettungen mit F5 zu entdecken und
sogar die Länge der eingebetteten Nachricht zu ermitteln. Dazu wird das JPEG-Bild erst
dekomprimiert und vier Zeilen abgeschnitten, wie in Abb. 13 gezeigt.
Abbildung 13: Crop-Angriff
51
E(k)

Daraufhin wird ein Tiefpassfilter verwendet um Blockartefakte zu entfernen. Eine erneute
Komprimierung mit der Quantisierungsmatrix des Trägers und ein darauf folgender
Vergleich der Histogrammdaten der Frequenzkoeffizienten kann einen erhöhten Anteil an
0-Koeffizienten aufdecken.
5.3.2 MB2
Zusammenfassung
Bei der modellbasierten Steganographie liegt die Idee des perfekten Komprimierers zugrunde.
Unter einem perfekten Komprimierer versteht man einen Komprimierer, der alle
Eigenschaften der realen Welt kennt, also intern ein perfektes Modell der realen Welt
besitzt. Somit sind komprimierte Bilder lediglich eine willkürliche Aneinanderreihung
von Bits.
Darauf aufbauend kann man davon ausgehen, dass ein perfekter Dekomprimierer aus
willkürlichen Daten immer ein ursprüngliches Bild erstellen kann, da er ebenfalls ein
perfektes Modell der realen Welt besitzt.
Da es allerdings keinen perfekten Komprimierer gibt, versucht die modellbasierte Stegonographie,
ein nahezu perfektes Modell P zu nutzen, um eine steganographische Nachricht
in einen Träger einzubetten.
Dabei werden für einen Menschen oder eine Maschine wahrnehmbare Eigenschaften des
Trägers Xdet 1 genutzt um das Modell zu initialisieren. Vernachlässigbare Eigenschaften
des Trägers Xindet werden bei MBS unter Berücksichtigung des Modells mit Hilfe
eines arithmetischen Dekodierers so verändert, dass sie die Nachricht enthalten. Ein
Empfänger kann somit wieder das Modell mit Hilfe von Xdet initialisieren und die eingebettete
Nachricht extrahieren.
Die genaue Arbeitsweise von MBS ist in Abb.14 dargestellt.
Algorithmus
Im Hinblick auf JPEG-komprimierte Grafiken bedeutet dies, dass es eine Aufteilung von
wahrnehmbaren und vernachlässigbaren Eigenschaften gibt, wobei die vernachlässigbaren
Eigenschaften einer JPEG-komprimierten Grafik die Positionen der Frequenzkoeffizienten
im Bild darstellen. Im folgenden werden die Häufigkeit eines bestimmten Frequenzkoeffizienten
c als hochpräzise Behälter hc bezeichnet.
Dagegen stellen die wahrnehmbaren Eigenschaften eine Gruppe lc von im Histogramm
benachbarter hochpräziser Behälter dar.
⎧
⎪⎨ h2c+1 + h2c wenn c < 0
lc = h0
⎪⎩
h2c−1 + h2c
wenn c = 0
wenn c > 0
1 In dem Artikel von Rainer Böhme und Andreas Westfeld [BW04] werden die Bezeichnung Xdet und
Xindet statt wie bei Phil Sallee [Sal05] α und β verwendet. Da diese Ausarbeitung sich öfter auf
Andreas Westfeld beruft, sollen diese Bezeichnung das weitere Lesen vereinfachen
52

Cover
X
X X
det
X X ’
det
X’
indet
indet
Abbildung 14: MBS-Aufbau
Model
P
X i ndet | X det
Entropy
Decoder
Message
M
Diese Gruppe wird im Folgenden ” Behälter mit niedriger Präzision “genannt.
Behälter mit niedriger Präzision sind somit Teil von Xdet und dürfen bei der Einbettung
nicht verändert werden. Dagegen stellen hochpräzise Behälter Elemente von Xindet
dar, die unter Berücksichtigung eines Models P verändert werden dürfen. Dabei muss
der Algorithmus beachten, dass die Häufigkeit innerhalb eines Behälters mit niedriger
Präzision unverändert bleibt und die Änderung weiterhin kohärent zum Modell sind.
Modell
Als Modell für die Häufigkeitsverteilung wird eine Cauchy Verteilung genutzt, die wie
folgt definiert ist:
p − 1
P (c) = (|c/s| + 1)−p
2s
mit den Parametern p > 1 und s > 0 zum Anpassen des Modells an das Histogramm.
Die zugehörige Dichtefunktion ist:
�
1
D(c) = 2 (1 + |c/s|)1−p wenn c ≤ 0
1 − 1
2 (1 + |c/s|)1−p wenn c ≥ 0
Dabei ist c jeweils der Index eines Behälters mit niedriger Präzision.
Abb.17 zeigt das Histogramm einer mit JPEG komprimierten Grafik mit den jeweiligen
hochpräzisen und niedriger präzisen Behältern (l−2 . . . l2). Die rote Linie beschreibt dabei
das Modell, das über die Parameter p und s an die Behälter mit niedriger Präzision
angepasst wurde.
53

Häufigkeit
l
-2
l
-1
l
1
-4 -3 -2 -1 0 1 2 3 4 JPEG Koeffizienten
l
2
Abbildung 15: MBS-Modell
Nach dem Anpassen des Modells wird die Wahrscheinlichkeit von jedem Koeffizienten
innerhalb des Modells über die Dichtefunktion berechnet. Diese Wahrscheinlichkeiten
werden mit der Nachricht und den Häufigkeiten der Koeffizienten an einen arithmetischen
Dekodierer übergeben. Die Ausgabe des arithmetischen Dekodierers zusammen mit dem
jeweiligen Behälter mit niedriger Präzision entspricht dem Wert des neuen Koeffizienten.
Ein möglicher Dekodierer wird nach Sallee [Sal05] in [IHWC87] beschrieben.
Blockreduzierung
MB2 besitzt zudem einen Blockreduzierungsalgorithmus, der nur dann eine Einbettung
zuläßt, wenn an den Rändern eines 8 × 8-Pixel-Blocks die Abhängigkeiten zu einem
Nachbarblock nicht verletzt werden. Dadurch reduziert sich aber die Kapazität von MB2
im Gegensatz zu MB1 um fast 50%.
Eigenschaften
Bei MBS ergibt sich die Einbettungsrate R, die Änderungsdichte D und die Einbettungseffizienz
E aus der Wahrscheinlichkeit p einer von zwei Koeffizienten aus einem Behälter
mit niedriger Präzision lc.
Einbettungsrate (Durchschnittliche Anzahl von Bits die kodiert werden):
R(p)c = −(p log 2(p) + (1 − p) log 2(1 − p))
Änderungsdichte (Änderungen pro Nachrichtenbit):
D(p)c = 2p(1 − p)
Einbettungseffizienz (Eingebettete Bits pro Änderung):
E(p)c = R(p)
D(p)
54

E(p)
4
3.5
3
2.5
Abbildung 16: MBS-Einbettungsrate
2
0 0.1 0.2 0.3 0.4 0.5
p
0.6 0.7 0.8 0.9 1
Wie in Abb. 16 zu sehen ist, sinkt die Einbettungseffizienz E(p)c nie unter 2 für
0 < p < 1.
Angriff
Bisher wurde immer davon ausgegangen, dass die Häufigkeit von Frequenzkoeffizienten
kontinuierlich mit steigender Frequenz abnimmt.
Dies ist aber nicht immer der Fall, je nach Art des Bildes und je nach Aufnahmegerät
kann ein Träger eine erhöhte Häufigkeit von Frequenzen in äußeren Bereichen
aufzeigen. Diese Besonderheit wird von dem verwendeten Modell nicht abgedeckt wie
in Abb. 17 ersichtlich. Bei der Einbettung durch MBS würde diese Besonderheit unter
Umständen entfernt werden, da Änderungen kohärent zum zugrunde liegenden Modell
bleiben müssen.
Bei genügend statistischen Daten kann diese Veränderung der Frequenzkoeffizienten daher
durch einen Vergleich der erwarteten und der vorhandenen Koeffizienten aufgedeckt
werden. Nach [BW04] ist die Wahrscheinlichkeit schon bei 50%, dass eine steganographische
Nachricht entdeckt werden kann, wenn mehr als 40% der möglichen Kapazitat
eines Trägers genutzt werden.
5.3.3 Perturbed Quantization – PQ
Zusammenfassung In [Fri05b] beschreiben Jessica Fridrich und weitere Autoren eine
Möglichkeit, Nachrichten mittels Wet Paper Codes, kurz WPC, in JPEG-Koeffizienten
zu verstecken.
55
E(p)

Häufigkeit
-4 -3 -2 -1 0 1 2 3 4 JPEG Koeffizienten
Abbildung 17: JPEG-Histogramm mit erhöhter Häufigkeit von hohen Frequenzkoeffizienten
Wet-Paper-Codes – WPC Grob übersetzt bedeutet WPC ” Schreiben auf nassem Papier“
[Fri05a]. Der Sender kennt die nassen Stellen auf dem Papierstück, und meidet
beim Beschreiben diese Regionen, da die Tinte dort micht haften bleibt. Ein weiterer
Vergleich, der dem Problem etwas näher kommt, ist das Beschreiben eines Speichers mit
defekten Zellen. Dabei gibt es insgesamt n Speicherzellen, von denen n − k fest auf Null
oder Eins stehen. Der Sender, dem die defekten Stellen bekannt sind, muss die funktionierenden
derartig beschreiben, dass der Empfänger, der keine Orts-Kenntnis über die
defekten Bits besitzt, die ursprüngliche Nachricht wiederherstellen kann.
Einbettung Die Shannon-Kapazität des Speichers, also die maximale Grösse der zu
übermittelnden Nachricht, ist genau k. Folgende Definitionen werden zur Lösung des
Problems benutzt:
• xi ∈ J, wobei J = {0 . . . 255} und i ∈ {0, . . . , n}
• S(x) sei eine Abbildung (hier einfacherweise von x auf das LSB von x) auf die
Cover-Symbole
• bx= (S(x1), S(x2) . . . , S(xn)) Bit-Vektor der Cover-Symbole
Die nicht-defekten Symbole des Speichers bzw. des Trägermediums xi könnten nun
verändert werden nach yi, und by= (S(y1), S(y2) . . . , S(yn)) ist dann der Vektor mit
der eingebetteten Nachricht. Der Empfänger sieht nur nur by. Letzteres stellt also die
LSBs unseres modifizierten Trägermediums dar.
Die als Bit-Vektor dargestellte Nachricht s= (s1, s2, . . . , sm) mit der Länge m soll nun
vom Sender eingebettet werden. Für by muss gelten:Dby = s.
Dabei ist D eine binäre m×n-Matrix, die sowohl dem Sender als auch dem Empfänger
bekannt sein muss. Sie wird pseudorandomisiert aus dem Stego-Key erzeugt. Das lineare
Gleichungssystem aus Formel (??) lässt sich nicht für beliebige Matrizen D lösen; die
Unveränderlichkeit der n − k Elemente des Vektors y erschwert die Problemstellung
56

k Gauß[sec] LT[sec] P
1000 0.023 0.008 43%
10000 17.4 0.177 75%
30000 302 0.705 82%
100000 9320 3.10 90%
Tabelle 2: Laufzeitvergleich zwischen Gauß-Elimination und Matrix LT Prozess in
Abhängigkeit von der Nachrichtenlänge k, wobei P die Wahrscheinlichkeit
ist, dass die Nachricht erfolgreich eingebettet werden kann.
zusätzlich. Daher ist eine erfolgreiche Einbettung nicht garantiert. Kann jedoch eine
Lösung gefunden werden, so ist es dem Empfänger möglich, mittels Gleichung (??),
seiner Kenntnis über D und den Daten des veränderten Trägermediums by die Nachricht
s auszurechnen.
Um die defekten Stellen mit einzubeziehen, wird die Gleichung nun umgeschrieben:
Dby = s ⇔ Dv = s − Dbx , mit v = by − bx
Alle defekten Stellen in v sind Nullen, da sie nicht verändert werden können. Durch Entfernung
dieser Zeilen wird v zu einem k ×1-Vektor transformiert, wobei die Bezeichnung
erhalten bleibt. Dadurch schreibt sich (??) so:
Hv = z , (6)
wobei H eine m × k Matrix darstellt, die durch Entfernen derselben Zeilen aus D
gewonnen wird, und z = s − Dbx ist. Die Lösung v dieser Gleichung ergibt die Bits,
welche verändert werden müssen.
Matrix-LT-Prozess Gleichung (6) kann durch Gauß- Elimination gelöst werden. Durch
die hohe Komplexität von O(n 3 ) hätte dies allerdings sehr lange Laufzeiten für große
Datenmengen zur Folge.
LT Codes wurden 2005 von Michael Luby vorgeschlagen, daher steht die Abkürzung LT
für Luby Transform. Der hier beschriebene Matrix-LT-Prozess mit einer Komplexität
von O(n ln(k/σ)) ist signifikant schneller, wie in Tabelle 2 zu sehen ist.
LT-Codes Die grundlegende Idee dahinter ist es, die Matrix H aus Formel (6) so zu
erzeugen, dass sich das Gleichungssystem einfach lösen lässt.
Abbildung 18 zeigt einen zweigeteilten Graphen, dessen Adjazenzmatrix dem Robust
Soliton Distribution Schema, kurz RSD, genügt. Im linken Teil des Graphen befinden
sich die Nachrichtenbits Mx, rechts die Bits des veränderten Trägermediums Ex. Um die
Nachricht zurückzugewinnen geht man folgendermaßen vor:
1. Finde eine Stelle mit nur einer Kante (E7)
57

Abbildung 18: LT Veranschaulichung
2. Setze das zugehörige Nachrichtenbit M3 gleich dem von E7
3. Setze alle mit M3 verbundenen Stellen x auf x ⊕ M3 (E1 und E4)
4. Streiche die zugehörigen Kanten
5. Weiter mit Punkt 1., falls noch nicht alle Bits von M bestimmt sind
Die Wiederherstellung der Nachricht ist in diesem Fall so einfach, weil sich durch die
RSD-Beschaffenheit der Adjazenzmatrix nach Schritt 4. immer eine weitere Stelle mit nur
einer Kante finden lässt, solange die Nachricht noch nicht vollständig wiederhergestellt
ist.
Matrix-LT-Codes Zur Lösung von Gleichung (6) wird das LT-Codes-Verfahren auf die
Matrix H angewandt, um das System zu lösen. Statt eine beliebige pseudorandomisierte
Matrix zu erzeugen, benutzt man eine RSD-Matrix, um damit den Rechenaufwand zu
verringern.
Sei wj = w(rj, rj+1, . . . , rn) das Hamming-Gewicht einer Zeile in A, dann kann A wie
folgt zu einer Dreiecksmatrix umgewandelt werden:
1. Setze j = 0
2. Finde eine Zeile i mit wj = 1
3. Setze k gleich dem Index dieser Eins im Vektor w
4. Tausche Zeilen von Position i zu Position j
5. Tausche Spalten von Position k zu Position j
6. Setze j = j + 1
7. Falls j kleiner als Zeilenanzahl von A, gehe zu Punkt 2
58

Lösen der Gleichung Wendet man diese Methode auf H T in Gleichung (6) an, so ergibt
sich eine neue Matrix [U, H ′ ], wobei U eine obere Dreiecks m × m Matrix mit
Einsen auf der Diagonale und H ′ eine m × (k − m)-Matrix ist. Durch diese neu gewonnene
Darstellungsform kann v und damit auch by durch rekursives Einsetzen berechnet
werden.
Einschätzung Der Kapazitätsverlust durch das Matrix-LT-Verfahren beträgt bis zu
10%. Problematisch gestaltet sich die pseudorandomisierte Erzeugung einer RSD-Matrix
aus dem Stego-Key [Lub02]
Von Vorteil hingegen ist der niedrige Komplexitätsgrad, um das Gleichungssystem zu
lösen.
Perturbed Quantization (PQ) konkret Das bis hierhin beschriebene Verfahren ist allgemein
gültig für beliebige Trägermedien. Perturbed Quantization im Speziellen spezifiziert
als nicht defekte Zellen alle JPEG-DCT-Koeffizienten, für deren Nachkommastellen
c gilt:
c ∈ [0, 5 − ε; 0, 5 + ε] , ε ≤ 0, 1 .
Je kleiner ε gewählt wird, desto weniger Nachrichtenbits können eingebettet werden und
desto geringer ist die Entdeckungswahrscheinlichkeit. PQ stört also die Quantisierung
und erzeugt künstliche aber schwer zu identifizierende Rundungsfehler.
Liegt das Ursprungsbild unkomprimiert vor, so kann das Verfahren direkt bei der Konvertierung
in ein JPEG-Bild angewandt werden. Möchte man als Quelle ein bereits quantisiertes
JPEG-Bild verwenden, so können durch Requantisierung mit einer größeren
Quantiserungsmatrix künstlich Nachkommastellen erzeugt werden. Das requantisierte
Bild besitzt allerdings höhere Kompressionsartefakte als das ursprüngliche.
5.4 Einbettung in Rastergrafiken
5.4.1 BattleSteg
Zusammenfassung BattleSteg wurde von der Neuseeländerin Kathryn Hempstalk 2005
entwickelt [Kat07]. Der Algorithmus ist eine Kombination aus den beiden Algorithmen
HideSeek und FilterFirst, die ebenfalls von dieser Autorin stammen. HideSeek basiert
auf dem Programm Hide and Seek für Windows 95 und schreibt die Bits der Geheimnachricht
in die LSBs von durch einen Pseudozufallsgenerator ausgewählte Pixel.
FilterFirst verfolgt den Ansatz, dass Daten am besten an Kanten im Bild eingebettet
werden, da hier Variationen im Farbwert nicht so auffallen wie an gleichfarbigen Flächen.
Dazu wird beispielsweise ein Laplace-Filter auf das Bild angewendet. Dieser Filter berechnet
für jeden Pixel einen Wert, der den Farbwertunterschied zu seinen Nachbarpixlen
repräsentiert. Die Daten werden nun in Pixeln eingebettet, an denen der Filterwert hoch
ist, also an dieser Stelle vermutlich eine Kante ist.
BattleSteg vereint beide Ideen: Es wird ein Kantenfilter über das Bild gelegt und dann
werden zufällige Kantenpixel zur Einbettung ausgewählt. Wurde ein Bit in einem Pixel
eingebettet, wird, in Analogie zum Spiel Schiffe versenken, im näheren Umfeld dieses
59

Pixels versucht, weitere Bits einzubetten. Nach einer Weile wählt der Algorithmus eine
neue Stelle aus.
Der Algorithmus ist in dem Programm Digital Invisible Ink Toolkit implementiert,
welches eine Beispiel-Implementierung der Autorin ist [Kat07].
Algorithmus Der Algorithmus wendet standardmäßig auf das Trägerbild einen Laplace-
Filter an. Alternativ sieht das Digital Invisible Ink Toolkit auch andere Kantenfilter wie
Sobel- oder Prewitt-Filter vor, welche ähnlich wie Laplace funktionieren. Als Resultat
erhält man ein Kantenbild, also ein Graustufenbild, auf dem der Farbwert eines Pixels
umso heller ist, je mehr er sich im Originalbild von seinen Nachbarn unterscheidet. Die
Pixel dieses Filterbildes werden nun in einer Liste nach ihren Helligkeitswerten sortiert.
Sind zwei Werte gleich, wird zusätzlich die x- und y-Koordinate mit einbezogen. Nun
wird der Median dieser Liste gespeichert und die obersten 10% der Pixel, also die mit
der stärksten Kantenausprägung, betrachtet. Diese Pixel werden als Engines bezeichnet.
Nun werden die Ships gesucht. Hierzu werden die vier Nachbarpixel jeder Engine
betrachtet und der Filterwert mit dem Median verglichen. Ist er grösser, wird das jeweilige
Pixel als Ship markiert. Ist mindestens eins der vier Pixel ein Ship, wird auch das
Engine-Pixel zu einem solchen.
Listing 1: Beispielcode
1 // D e f i n i e r e o b e r s t e 10% F i l t e r p i x e l
2 int topten = ( int ) f i l t e r e d P i x e l A r r a y . l ength / 1 0 ;
3
4 // D e f i n i e r e Engines
5 F i l t e r e d P i x e l e n g i n e s [ ] = new F i l t e r e d P i x e l [ topten ] ;
6
7 // D e f i n i e r e Median
8 int median = f p a r r a y [ f i l t e r e d P i x e l A r r a y . l ength / 2 ] . g e t F i l t e r V a l u e ( ) ;
9
10 // D e f i n i e r e Ships
11 s h i p s = new boolean [ image . getWidth ( ) ] [ image . getHeight ( ) ] ;
12 for ( int i = 0 ; i < e n g i n e s . length ; i ++){
13 int x = e n g i n e s [ i ] . getX ( ) ;
14 int y = e n g i n e s [ i ] . getY ( ) ;
15 i f (Math . abs ( f i l t e r . getValue ( x , y ) ) >= median ){
16 // D e f i n i e r e P i x e l xy a l s Ship
17 s h i p s [ x , y ] = true ;
18 }
19 }
Ein Pseudozufallsgenerator, der das verwendete Passwort als Seed verwendet, wählt
ein Pixel, einen Farbkanal und in diesem ein Least-Significant-Bit, welches je nach vorgegebenen
Einstellungen nicht zwingend das niedrigste Bit sein muss. Diese drei Informationen,
Pixel-Koordinate, Farbkanal und Bit werden zusammengenommen als Shot be-
60

zeichnet. Ist das verwendete Pixel ein Ship, wird dieser Shot, also das zuvor ausgewählte
Bit des Pixelfarbkanals, mit einem Bit der Geheimnachricht überschrieben.
1 // Durchlaufe Nachricht
Listing 2: Beispielcode
2 for ( int i = 0 ; i < message . length ; i++) {
3
4 // Finde z u f a e l l i g e x− und y−Koordinate
5 int shotx = Math . abs (Random . nextInt ( imageWidth ) ) ;
6 int shoty = Math . abs (Random . nextInt ( imageHeight ) ) ;
7
10
8 // Waehle Farbkanal
9 int chanal = Math . abs (Random . nextInt ( numChanals ) ) ;
11 // Waehle LSB
12 int b i t p o s = mStart + Math . abs (RandomG . nextInt ( (mEnd − mStart ) + 1 ) ) ;
13
14 // Bette Geheimbit ein
15 i f ( s h i p s [ shotx , shoty ] == true ) {
16 image . s e t P i x e l B i t ( shotx , shoty , chanal , bitpos , message [ i ] ) ;
17 }
18 }
Jetzt wendet der Algorithmus eine Technik des Spiels Schiffe versenken an, welches
Namensgeber für den Algorithmus ist: Er sucht in der direkten Umgebung des eingebetteten
Bits nach weiteren Stellen, an denen sich gut Daten einbetten lassen, indem
er soganannte Ranged Shots zufällig plaziert, die einen vorher festgelegten Maximalabstand
vom letzten Shot haben und hier weitere Bits einbettet, sollte es sich um ein Ship
handeln. Nach einer ebenfalls vorher festgelegten Anzahl an Ranged Shots wird wieder
ein normaler Shot durchgeführt.
Um die Daten auch sicher wieder ausbetten zu können, ohne dass das erzeugte Filterbild
durch das Einbetten verändert wird, wird vorher festgelegt, welche Bits eines
Farbwertes der Filter betrachten soll und welche zum Einbetten benutzt werden sollen.
So kann der Filter beispielsweise die ersten sechs Bit jedes Farbkanals benutzen und die
letzten beiden (LS-)Bits werden zum Einbetten von Daten vorgehalten.
Damit der Algorithmus beim Ausbetten weiß, wann er abbrechen muss, wird die Länge
der Nachricht an deren Anfang geschrieben und mit eingebettet [Kat07].
Verbesserungen Der BattleSteg-Algorithmus bietet einige Möglichkeiten zur Verbesserung.
So sollte in erster Linie überprüft werden, inwiefern die sogenannten Ranged Shots
überhaupt sinnvoll sind, da dadurch die eingebetteten Bits im Bild gesammelt auftreten
und so möglicherweise leichter zu entdecken sind. Dies wäre beispielsweise möglich durch
statische Angriffe auf Steganogramme, die mit und ohne Ranged Shots erstellt wurden.
Desweiteren könnte das Finden der Ships verbessert werden. Bisher werden dafür die
vier Pixel ober- und unterhalb sowie links und rechts jeder Engine in Betracht gezogen.
61

1 2 3 4
5 6 7 1
2 3 4 5
6 7 1 2
Abbildung 19: Beispiel für eine 4 × 4 Gewichtsmatrix für den CPT-Algorithmus
Vorstellbar wäre, alle acht angrenzenden Pixel oder sogar Pixel in einem größeren Radius
in Betracht zu ziehen. Vielleicht könnte man sich so auch an Kanten ” entlanghangeln“.
Zuletzt könnte die Definition der Engines verbessert werden. Statt nur die 10% hellsten
Filterpixel zu verwenden könnte dieser Wert je nach Bild dynamisch festgelegt werden.
5.4.2 CPT
Zusammenfassung Der CPT-Algorithmus basiert auf einem im Jahre 2001 veröffentlichten
Algorithmus von Y-Y.Chen, H-K. Pan und Y-C. Tseng. [YYCT01] Dieser Algorithmus
wurde für die Einbettung von Daten in Schwarz-Weiß Rasterbildern, also Bildern
mit 1-Bit Farbtiefe entwickelt, jedoch funktioniert er auch sehr gut auf der LSB-Ebene
von mehrfarbigen Bildern.
Zur Einbettung wird das Bild in Blöcke einer vorher festgelegten Größe zerlegt. Mittels
einer Schlüsselmatrix und einer Gewichtsmatrix, die Sender und Empfänger des Steganogramms
vorher austauschen müssen, wird in jeden Bildblock eine bestimmte Menge an
Bits eingebettet. Hierbei werden allerdings immer maximal 2 Pixel pro Block verändert.
Algorithmus In der folgenden Beschreibung des Verfahrens ist F das Trägerbild, m und
n die Dimensionen eines Bildblocks, K eine binäre Schlüsselmatrix, W eine Gewichtsmatrix.
Die beiden Matrizen sind jeweils so groß wie ein Bildblock. Der Wertebereich
für die Elemente der Gewichtsmatrix ist [1, 2 r − 1]. Jeder dieser Werte muss mindestens
einmal vorkommen. Abbildung 19 zeigt ein Beispiel für eine solche Matrix. Es ist
r ≤ ⌊log 2(mn−1)⌋ die Anzahl der Bits, die in einem Block eingebettet werden sollen und
Bl eine einzubettende binäre Zeichenfolge der Länge l.Der ⊕-Operator ist die elementweise
XOR-Verknüpfung zweier Matrizen gleicher Größe. Mit dem ⊗-Operator werden
zwei gleich große Matrizen elementweise multipliziert. Mit SUM(M) wird die Summe
aller Elemente der übergebenen Matrix M berechnet.
Vor dem Einbettungsvorgang wird das Bild in k Blöcke der Größe m × n aufgeteilt. In
jeden Block werden r Bits eingebettet, indem mit der Vorschrift SUM((Fi⊕K)⊗W ) das
Gewicht des Blockes berechnet wird und dieses dann durch Kippen von maximal zwei
62

Bits innerhalb des jeweiligen Blockes an die jeweiligen Nachrichtenbits angpasst wird.
Die Nachrichtenbits werden hierbei als r-stellige Binärzahl angesehen. Die zu kippenden
Bits werden ermittelt, indem man die Pixel des Blockes in Mengen Sω aufteilt, deren
Elemente diejenigen Pixel sind, deren Kippen das Gewicht des Blockes jeweils um ω
verändert.
Sω = {k, l|(Fi ⊕ K) |k,l| = 0 ∧ W |k,l| = ω ∨
(Fi ⊕ K) |k,l| = 1 ∧ W |k,l| = ⌊log 2(mn − 1)⌋ − ω}
Die Aufteilung in die Mengen erfolgt nach obenstehender Formel. Zusätzlich wird die
Menge S0 = {∅} definiert. Mit der Differenz zwischen dem Blockgewicht und den betrachteten
Nachrichtenbits d werden dann zwei Mengen Sω anhand folgender Vorschrift
ausgewählt:
Wähle ein h ∈ {0, 1, . . . , 2 r − 1}, so dass Sh∗d �= ∅ und S −(h−1)∗d �= ∅.
Aus den beiden Mengen wird dann jeweils ein Bit ausgewählt und im Bildblock gekippt.
Ist eine von den gewählten Mengen S0 hat dies zur Folge, dass nur ein Bit gekippt
werden muss, um das gewünschte Blockgewicht zu erzielen.
Der Vorteil dieses Verfahrens ist die konstante Einbettungsrate von ⌊log 2(m ∗ n −
1)⌋ Bits pro Block und der durch die zwei Matritzen gegebene große Schlüsselraum.
Außerdem ist die Änderungsrate im Vergleich zum LSB-Verfahren wesentlich geringer,
da unabhängig von der Blockgröße und der Anzahl der Nachrichtenbits pro Block jeweils
nur maximal zwei Bits pro Bildblock im Trägermedium verändert werden. Allerdings
bettet das Verfahren die Daten sequentiell in jeden Bildblock des Trägerbildes ein. Es
werden, im Gegensatz zu z.B. BattleSteg keinerlei Überprüfungen vorgenommen, ob ein
bestimmter Bildblock für die Einbettung geeignet ist, oder ob diese sehr auffällig wäre,
wie es z.B. bei Bildern mit größeren einfarbigen Flächen der Fall wäre. An diesem Punkt
lässt sich das CPT Verfahren noch verbessern.
5.5 Einbettung in Audio-Dateien
5.5.1 Echo-Hiding
Zusammenfassung Echo-Hiding bettet Geheiminformationen durch Einfügen eines
Echos ins Audiosignale ein. Die Daten werden dabei durch den Offset (Abstand zum
originalen Signal) des Echos kodiert. Wenn dieses einen sehr kleinen Abstand zum Original
hat, ist es für das menschliche Ohr nicht zu erkennen. Diese Verschmelzung vom
Original mit dem Echo ist vom Hörer und der Art des Trägers abhängig. Sie befindet
sich bei ungefähr drei Millisekunden [FAPP99]. Das Echo fügt dem Originalton dann
zusätzliche Resonanz hinzu, was allenfalls zu einem volleren Klang, im Vergleich zum
Träger, führen kann.
Algorithmus
63

Einbettung Beim Einbetten werden von dem Träger zwei Kopien erstellt, die jeweils
um ein Echo des gesamten Originalsignals angereichert werden. Die Echos der beiden
Varianten haben unterschiedliche Verzögerungszeiten. Wie man in Abbildung 20 sehen
kann, hat das 1-Signal einen größeren Abstand zwischen dem Original und dem Echo
als das 0-Signal. Beide Verzögerungszeiten sind so gewählt, dass sie beim Hören nicht
als ein Echo zu identifizieren sind.
Die entstandenen Signale werden jetzt mit weich überblendenden Mischern, an-
Abbildung 20: Einbettungsvorgang: 0-Signal und 1-Signal werden erstellt und den Geheimbits
entsprechend gemischt.
hand der zu kodierenden Geheimbits, ineinander übergeblendet. Die Mischer müssen
sich an eine festgelegte Blocklänge halten, die ausreichend groß ist, um ein Echo
beinhalten zu können. Diese Blocklänge legt die Einbettungsrate fest. Wie die Mischer
aus den Geheimbits hervorgehen, ist auf der rechten Seite der Abbildung 20 angedeutet.
Um das Signal des Steganogramms zu erhalten wird das 1-Signal mit dem 1-Mischer
multipliziert und das 0-Signal mit dem 0-Mischer multipliziert. Die beiden Ergebnisse
werden anschließend addiert.
Extrahierung Beim Extrahieren der Geheiminformation wird das Steganogramm mittels
einer Autokorrelation mit sich selbst verglichen, wodurch das Echo gefunden werden
kann [auk08]. Jetzt wird durch den Abstand zwischen dem Original und dem Echo entschieden,
ob das Geheimbit Null oder Eins ist.
Anmerkungen Es ist nicht sichergestellt, dass durch dieses Verfahren die Geheiminformation
komplett extrahiert werden kann. Je nach Eigenschaft des Trägermaterials
können zum Beispiel natürliche Echos zum Problem beim Extrahieren werden. Ein
64

zusätzlicher Faktor, dessen Veränderung die erfolgreiche Extrahierung verbessern kann,
ist die Amplitude des Echos. Eine besonders große Amplitude des Echos führt zu einer
starken Resonanzerweiterung des Steganogramms und kann, abhängig vom Audioinhalt
des Trägers, auffällig sein. Als ungefährer Richtwert für eine geeignete Einbettungsrate
kann 16 Bits pro Sekunde gesehen werden [DG].
Da eine Extrahierung der Geheimnachrichten hier nicht gewährleistet werden kann,
bietet es sich an, redundante Daten und fehlerkorrigierende Kodierung zu benutzen.
5.5.2 Phase-Coding
Phase-Coding bettet Geheiminformationen durch das Verschieben von Phasen der Frequenzen
eines in Audiosignals ein.
Zusammenfassung Bei Phase-Coding werden die Anfangsphasen des ersten Audiosegments
so gesetzt, dass diese die Geheimbits repräsentieren [Ben99]. Da die Phasen aller
folgenden Segmente um diesen gesetzten Wert mitverschoben werden, entstehen keine
Phasensprünge innerhalb des Audiosignals. Auf Phasensprünge reagiert das menschliche
Ohr empfindlich, aber mit welcher Phase eine Frequenz beginnt, ist schwer wahrzunehmen,
was beim Phase-Coding ausgenutzt wird.
Algorithmus
Einbettung Im Folgenden ist ω die Phase einer Frequenz.
1. Der Träger wird in N Segmente unterteilt, die jeweils K Abtastwerte enthalten.
2. Für jeden Index n eines Segments, wobei 0 ≤ n ≤ N − 1, wird eine diskrete
Fourier-Transformation der K Abtastwerte durchgeführt. Man erhält dadurch eine
Phasenmatrix Ωn(ωk) für jeden Index k einer Frequenz mit 0 ≤ k ≤ K − 1 und
eine Matrix Θn(θk) mit den Einträgen für die Amplitude der Frequenzen.
3. Für jedes k bildet man die Phasendifferenz zweier aufeinander folgender Segmente
mit den Indizes n und n + 1:
∆Ωn+1(ωk) = Ωn+1(ωk) − Ωn(ωk).
4. Die Geheimnachricht wird kodiert, indem man im Segment mit dem Index n = 0
die Werte in der Phasenmatrix auf π
π
, um eine 1 zu repräsentieren, oder − , um
2 2
eine 0 zu repräsentieren, setzt. Man erhält also eine veränderte Phasenmatrix, die
wir Φ ′ 0 nennen.
5. Anhand von Ω ′ 0 können jetzt die veränderten Phasen Ω′ n für alle folgenden Segmentindizes
n mit 0 < n ≤ N − 1 wie folgt berechnet werden:
Ω ′ n(ωk) = ∆Ωn(ωk) + Ω ′ n−1(ωk).
65

6. Mit den dadurch veränderten Phasenmatrizen Ω ′ n(ωk) und den originalen Amplitudenmatritzen
Θn(θk) wird das Audiosignal durch die inverse diskrete Fourier-
Transformation wieder hergestellt.
Extrahierung Um die Geheimnachricht zu extrahieren, muss der Empfänger die Segmentlänge
kennen und wissen, wie Geheimbits durch die Phasen repräsentiert werden.
Nach einer diskreten Fourier-Transformation des Steganogramms mit der richtigen Segmentlänge
kann der Empfänger anhand der Phasenmatrix des ersten Segments die Geheimnachricht
ablesen.
Anmerkungen Im Gegensatz zum Echo-Hiding kann die Geheimnachricht immer extrahiert
werden. Phase-Coding erzeugt kein Rauschen, aber wenn zu viele Frequenzen
signifikant in der Phase verschoben werden, kann es zu unerwünschten Resonanzen kommen.
Daher müssen die Frequenzen und die Anzahl der Verschiebungen sinnvoll gewählt
werden. Laut [Ben99] können durch dieses Verfahren 8 bis 32 Bits pro Sekunde versteckt
werden, je nach Segmentlänge.
5.5.3 LSB – Least Significant Bits
Zusammenfassung Die Methode, Daten in den am wenigsten wichtigen Bits (Least Significant
Bits, LSB) zu verstecken, ist eine der ältesten und am häufigsten anzutreffenden
in der digitalen Steganographie.
Algorithmus Beim LSB-Verfahren werden die Bits einer geheimen Nachricht in den
untersten Bits des Covers versteckt, welche dabei überschrieben werden. Die Einbettungsrate
ist zumindest theoretisch nur durch die Anzahl der überschriebenen Bits eines
Coverbytes beschränkt. Werden alle Bits des Covers überschrieben, so ist das Resultat
mit der Geheimnachricht identisch, und die steganographische Verarbeitung somit
sinnlos.
Obwohl der Ansatz, eine Nachricht in den LSBs einzubetten, vielen Algorithmen zu
Grunde liegt, unterscheiden sie sich doch durch die Auswahl der zu verändernden Bytes
des Covers. Der einfachste Ansatz, vom Anfang des Covers an das unterste Bit eines
jeden Bytes zu überschreiben, bis entweder die Nachricht komplett untergebracht wurde
oder das Cover zu Ende ist, ist relativ leicht zu entdecken. Daher wurden und werden
immer neue Methoden zur Auswahl der Trägerbytes erdacht.
Die Sicherheit des verwendeten LSB-Algorithmus ist von dieser Auswahl abhängig.
Wird ein sehr einfaches Schema gewählt, so ist die geheime Nachricht nicht nur einfach
nachweisbar, sondern kann unter Umständen auch in der Länge abgeschätzt oder sogar
extrahiert werden. Aber selbst ein sehr komplexes Einbettungsschema, wie es zum Beispiel
BattleSteg (siehe Abschnitt 5.4.1) verwendet, ist nur dann vergleichsweise sicher,
wenn die Einbettungsrate niedrig gehalten wird.
Der große Vorteil der LSB-Methode ist der geringe Aufwand, den die Einbettung verursacht.
Wählt man ein simples Einbettungsschema, ist auch der Aufwand zur Auswahl
der Coverbytes sehr gering.
66

Auf Audiodaten angewendet, bietet sich das WAVE-Format an, da dieses, abgesehen
von einem kurzen Header am Anfang der Datei, aus einer Sammlung von 16-Bit-Zahlen
besteht. Verändert man einen solchen Messwert, ein sogenanntes ”Sample”, im untersten
Bit, so ändert sich die Amplitude an dieser Stelle um ein Fünfundsechzigtausendstel. Dies
ist nur dann hörbar, wenn jeder Messwert genutzt wird, und auch leise Stellen in der
Audiodatei überschrieben werden. Auch hier hängen die Sicherheit und der Aufwand des
Algorithmus direkt vom Einbettungsschema ab.
6 Verbesserungen bestehender und neue Algorithmen
6.1 Einbettung in Bild-Dateien
6.1.1 T
Zusammenfassung
Im Gegensatz zu anderen Algorithmen wird keine Nachricht eingebettet, sondern davon
ausgegangen, dass die Nachricht bereits in einem Träger ist. Einem Empfänger muß nur
noch mitgeteilt werden, wo die Nachricht ist.
Algorithmus
Zunächst folgt eine kleine Einführung in Neuronale Netze
Neuronale Netze
Ein neuronales Netz besteht im allgemeinen aus folgenden Komponenten:
• Neuronen:
– Aktivierungszustand a.
Dieser Zustand gibt die Aktivierung des Neurons an
– Aktivierungsfunktion fact.
Die Aktivierungsfunktion gibt den Aktivierungszustand aj zum Zeitpunkt t+1
eines Neurons j aus dem alten Aktivierungszustand aj(t) und der Netzeingabe
netj(t) an.
aj(t + 1) = fact(aj(t), netj(t), θj)
Wobei θj der Schwellenwert des Neurons j und fact die Aktivierungsfunktion
ist.
– Ausgabefunktion fout
Die Ausgabe eines Neurons j, die durch eine Ausgabefunktion aus der Aktivierung
des Neurons bestimmt.
oj = fout(aj)
• Verbindungsnetzwerk der Neuronen
Ein Neuronales Netz kann als gerichteter, gewichteter Graph angesehen werden.
67

Wobei die Kanten die gewichteten Verbindungen zwischen den Neuronen darstellen.
Das Gewicht der Verbindung von Neuron i nach Neuron j wird als wij bezeichnet.
Die Gewichtsmatrix der Verbindungen aller Neuronen wird als W bezeichnet.
• Propagierungsfunktion
Diese Funktion gibt an, wie sich die Netzeingabe eines Neurons aus den Ausgaben
der anderen Neuronen und den Verbindungsgewichten berechnet. Die Netzeingabe
netj(t) von Neuron j berechnet sich nach
netj(t) = �
oi(t) ∗ wij
i
aus der Summe der Ausgaben oi(t) der Vorgängerneuronen multipliziert mit den
jeweiligen Gewichten wij der Verbindungen von Neuron i nach Neuron j.
• Lernregel: Die Lernregel ist ein Algorithmus, durch die ein neuronales Netz lernt,
für eine vorgegebene Eingabe eine gewünschte Ausgabe zu produzieren.
BAM
Ein BAM ist eine spezielle Klasse von neuronalen Netzwerken und wurde von Bart Kosko
[Bar88] bekanntgemacht. Es handelt sich beim BAM um ein heteroassoziatives Netzwerk.
Es akzeptiert einen Eingabevektor in einer Schicht von Neuronen und produziert einen
passenden Ausgabevektor in einer anderen Schicht von Neuronen.
Das BAM Netzwerk besteht aus zwei Ebenen von Neuronen, B und C. Diese zwei
Schichten werden durch eine Gewichtsmatrix W von B nach C und durch eine transponierte
Matrix W T von C nach B verbunden.
Normalerweise wird die logistische Aktivierungsfunktion verwendet:
1
oi =
1 + e−λ∗neti wobei oi die Ausgabe des Neurons i ist und neti die gewichtete Summe der Eingaben in
Neuron i. λ ist eine Konstante, welche die Steigung der logistischen Aktivierungsfunktion
bestimmt.
Um das BAM für diesen Algorithmus nutzen zu können, wird eine binäre Version mit
den folgenden Eigenschaften verwendet:
• λ hat einen sehr großen Wert, so dass eine binäre Schwellenwertfunktion angenähert
wird.
• Die Neuronen können sich ihren alten Aktivierungszustand merken
• Alle Ausgaben ändern sich gleichzeitig und bleiben konstant
Damit ergibt sich:
⎧
⎪⎨ 1 wenn neti(t) > 0
oi(t + 1) = 0
⎪⎩
oi(t)
wenn neti(t) < 0
wenn neti(t) = 0
68

Der Schwellenwert aller Neuronen ist in diesem Modell gleich Null.
Die Assoziationen des Netzwerks werden in den Gewichtsmatrizen W und W T gespeichert.
Dabei wird ein Vektor X mit einem Vektor Y assoziiert und umgekehrt. Die
Vektoren können dabei verschieden viele Elemente enthalten.
Um nun eine gespeicherte Assoziation in einem BAM zu finden, wird wie folgt vorgegangen:
• Der Vektor X wird an die Ausgabe von der Ebene B angelegt.
• Daraufhin wird er wieder entfernt und das Netzwerk läuft frei mit dieser Ausgabe,
wobei es durch W die assoziierte Ausgabe Y bei Ebene C erzeugt.
• Diese Ausgabe erzeugt über W T in Schicht B eine zum Vektor X ähnliche Ausgabe.
Dieser Prozess wird solange wiederholt bis sich das Netzwerk stabilisiert. Mit jeder Iteration
werden die Ausgaben von Ebene B und C der gespeicherten Information ähnlicher.
(Mathematisch betrachtet minimiert das Netzwerk eine Liapunow-Energiefunktion)
Die benötigte Gewichtsmatrix für zwei Vektoren X und Y kann über
W = �
p
X T p Yp
direkt berechnet werden. W ist die Summe der äußeren Produkte der Transponierten
des entsprechenden Vektors Xp mit dem Vektor Yp. Dabei gibt p jeweils ein Muster an.
Um die Leistung des BAMs zu steigern werden zudem Bipolarvektoren benutzt und
folgende bipolare binäre Schwellenwertfunktion:
⎧
⎪⎨ 1 wenn neti(t) > 0
oi(t + 1) = −1
⎪⎩
oi(t)
wenn neti(t) < 0
wenn neti(t) = 0
JPEG
Mit Hilfe eines BAM soll nun versucht werden eine geheime binäre Nachricht N in einer
JPEG Grafik zu verstecken. Dazu sei angenommen, es existiert ein öffentlicher binärer
Schlüssel K.
Dieser Schlüssel soll nun eine Liste von Eingabevektoren mit je n Elementen darstellen.
Diese Eingabevektoren Kp sollen nun mit Hilfe einer Gewichtsmatrix W mit Teilen der
geheimen Nachricht Np assoziiert werden. Wobei gelten soll, dass das erste Element von
K mit dem ersten Element von N usw. assoziiert wird.
Die Gewichtsmatrix läßt sich nun wie folgt berechnen:
W = �
p
K T p Np
Als Beispiel sei folgender öffentlicher Schlüssel K, sowie eine geheime Nachricht N
gegeben:
K = (1, 0, 0, 0, 1, 0, 0, 0, 1)
69

N = (0, 0, 1, 0, 1, 0, 1, 0, 0)
Der Einfachheit halber sei n = 3 und die Anzahl der Elemente in Kp und Np gleich.
Somit folgt:
K0 = (1, 0, 0)K1 = (0, 1, 0)K2 = (0, 0, 1)K3 = (0, 1, 1)
N0 = (0, 0, 1)N1 = (0, 1, 0)N2 = (1, 0, 0)N3 = (1, 0, 0)
Als Bipolarvektoren dargestellt:
K0 = (1, −1, −1)K1 = (−1, 1, −1)K2 = (−1, −1, 1)K3 = (−1, 1, 1)
N0 = (−1, −1, 1)N1 = (−1, 1, −1)N2 = (1, −1, −1)N3 = (1, −1, −1)
Die resultierende Gewichtsmatrix W ist somit:
⎛ ⎞
1
⎛ ⎞
−1
⎛ ⎞
−1
⎛ ⎞
−1
W = ⎝−1⎠
∗ (−1 − 11) + ⎝ 1 ⎠ ∗ (−11 − 1) + ⎝−1⎠
∗ (1 − 1 − 1) + ⎝ 1 ⎠ ∗ (1 − 1 − 1)
−1
−1
1
1
⎛
−1 −1
⎞
1
⎛
1 −1
⎞
1
⎛
−1 1
⎞
1
⎛
−1 1
⎞
1
= ⎝ 1 1 −1⎠
+ ⎝−1
1 −1⎠
+ ⎝−1
1 1 ⎠ + ⎝ 1 −1 −1⎠
1 1 −1 1 −1 1 1 −1 −1 1 −1 −1
⎛
−2 0
⎞
4
= ⎝ 0 2 −2⎠
4 −2 −2
Die Gewichtsmatrix besteht nur aus ganzen Zahlen, wobei das größte Element kleiner
gleich p und das kleinste Element größer gleich −p ist.
Wenn man sich nun einen JPEG Block, also die quantisierten Frequenzkoeffizienten
eines 8x8 Pixel Blocks, als eine Matrix V vorstellt, dann ergibt sich folgendes Bild:
⎛
⎞
DC AC1 AC2 AC3 AC4 AC5 AC6 AC7
⎜ AC8 AC9 AC10 AC11 AC12 AC13 AC14 AC15⎟
⎜
⎟
⎜AC16
AC17 AC18 AC19 AC20 AC21 AC22 AC23⎟
⎜
⎟
⎜AC24
AC25 AC26 AC27 AC28 AC29 AC30 AC31⎟
⎜
⎟
⎜
⎜AC32
AC33 AC34 AC35 AC36 AC37 AC38 AC39
⎟
⎜
⎜AC40
AC41 AC42 AC43 AC44 AC45 AC46 AC47
⎟
⎝
⎠
AC48 AC49 AC50 AC51 AC52 AC53 AC54 AC55
AC56 AC57 AC58 AC59 AC60 AC61 AC62 AC63
Wobei die Häufigkeit von Koeffizienten mit einer niedrigen Frequenz höher ist, als
die mit einer hohen Frequenz. Somit ist die Wahrscheinlichkeit hoch, dass man alle
Elemente einer Gewichtsmatrix in einem JPEG Block finden kann. Um eine geheime
Nachricht zu übertragen, reicht es somit wenn man lediglich die Indizes der JPEG-
Frequenzkoeffizienten, die für die Gewichtsmatrix notwendig sind überträgt.
70

Wenn nun ein Sender die JPEG komprimierte Datei erhält und zudem die Indizes
für die Gewichtsmatrix, kann er mit dem öffentlichen Schlüssel die Nachricht wieder
reproduzieren:
N0 = Fact(K0W )
⎛
−2 0
⎞
3
N0 = Fact((1, −1, −1) ⎝ 0 2 −2⎠)
4 −2 −2
= Fact((−5, 0, 8)) = (−1, −1, 1)
N0 = Fact(K0W T )
⎛
−2 0
⎞
4
K0 = Fact((−1, −1, 1) ⎝ 0 2 −2⎠)
3 −2 −2
= Fact((6, −4, −3)) = (1, −1, −1)
⎛
−2 0
⎞
3
N1 = Fact((1, −1, −1) ⎝ 0 2 −2⎠)
4 −2 −2
= Fact((−5, 0, 8)) = (−1, −1, 1)
Der Zustand ist stabil, die Ausgabe, also ein Teil der Nachricht, ist (−1, −1, 1) bzw.
(0, 0, 1)
GIF
Um nun die Indizes für die einzelnen Elemente der Gewichtsmatrix zu übertragen, sei
angenommen es gibt einen öffentlichen Schlüssel K, der durchaus der selbe Schlüssel,
wie für den Eingabevektor sein kann und eine GIF Grafik mit einer Farbtabelle F .
⎛
⎞
#0000F F
⎜ #F F F F 00 ⎟
F = ⎜ . . . ⎟
⎝ #000000 ⎠
#F F F F F F
Die Idee ist nun diese Farbtabelle zunächst nach Farben zu sortieren:
⎛
⎞
#F F F F F F
⎜ #F F F F 00 ⎟
⎜ . . . ⎟
⎝ #0000F F ⎠
#000000
71

Nun wird bei diesem Vektor jede Zeile ausgeblendet, deren Index in dem binären Vektor
des Schlüssels K eine 0 hat.
⎛ ⎞
1
⎜ 0 ⎟
⎜
⎜.
. . ⎟
⎝ 1 ⎠
1
∗
⎛
⎞
#F F F F F F
⎜ #F F F F 00 ⎟
⎜ . . . ⎟
⎝ #0000F F ⎠
#000000
=
⎛
⎞
#F F F F F F (0)
⎜ . . . ⎟
⎝ #0000F F (62) ⎠
#000000(63)
Jetzt wird jede Farbe in diesem Vektor von 0 bis 63 durchnumeriert und die Farbtabelle
des GIFs wieder so aufgebaut, daß im oberen Teil der Farbtabelle jeweils die Farben
stehen, die in einem JPEG Block ein Gewichtselement darstellen. Dabei ist der Index
der Farbe das Element aus dem JPEG-Block, welches in der Gewichtsmatrix an Position
0 steht, das zweite an Position 2 usw. Diese Nummerierung wird dann mit einem
Farbwert abgeschlossen, welches keinen Index darstellt. Da für die Gewichtsmatrix nicht
alle 64 Farbeinträge benötigt werden, kann der Rest wieder für einen neuen JPEG Block
genutzt werden. Ein Empfänger kann wieder diesen Algorithmus nutzen um die Indizes
zu extrahieren.
Kapazität
Die Kapazität des Algorithmus ist durch zwei Faktoren begrenzt. Zum einen müssen die
Elemente der Gewichtsmatrix in einem JPEG-Block vorhanden sein, ansonsten muß die
Anzahl der Neuronen im BAM reduziert werden. Zum Anderen ist die Kapazität eines
BAMs, also die Anzahl L der Vektoren die assoziiert werden können durch die folgende
Formel gegeben:
L < n/(2 ∗ log n)
Wobei diese Grenze nur aussagt, wieviele Muster bei einer (verrauschten) Eingabe zu
98% sicher erkannt werden. Da für diesen Algorithmus die Eingabe aber nicht verrauscht
ist, kann diese Kapazitätsgrenze leicht überschritten werden. Somit müßte die Anzahl
der Vektoren bzw. die Anzahl der Teile aus dem Schlüssel, die mit Teilen der Nachricht
assoziiert werden, immer abhängig von der Eingabe gewählt werden. Bei einer Eingabe,
deren Elemente (als Vektor betrachtet) einen hohen Winkel bilden, können mehr Teile
aus Schlüssel und Nachricht assoziiert werden als bei Elementen mit kleinem Winkel.
Angriff
Ein Angriff auf JPEG ist nicht möglich, da hier keine Veränderung stattfindet
Nur ein Angriff auf die Eigenschaften der GIF-Grafik wäre denkbar. Allerdings, unter
der Annahme, dass die Farbtabelle einer GIF-Grafik willkürlich ist, sollte hier auch kein
Angriff möglich sein.
72

6.2 GIF
6.2.1 Fortgeschrittener GIFShuffle
Motivation Der GIFShuffle-Algorithmus hat eine offensichtliche Schwachstelle: Durch
die stets gleiche initiale Ordnung, die sich für jedes Bild berechnen lässt, kann ein Angreifer
ein durch den GIFShuffle-Algorithmus mit Informationen angereichertes Bild abfangen,
die initiale Ordnung berechnen und auf die Geheimnachricht schließen.
Grundlegende Funktionsweise Der GIFShuffle Algorithmus wird zweimal angewandt:
Zunächst wird die initiale RGB-Ordnung hergestellt, anschließend wird diese Ordnung
durch ein Passwort, das nur dem Sender und Empfänger bekannt ist, durch den
GIFShuffle-Algorithmus permutiert. Die resultierende Ordnung ist nur dem Sender und
Empfänger bekannt und wird nun als initiale Ordnung für den GIFShuffle-Algorithmus
verwendet, der die eigentliche Nachricht einbettet.
Ein Angreifer kann demnach aus dem Stego-Bild nicht auf die initiale Ordnung der
Nachrichteneinbettung schließen und damit die Nachricht nicht rekonstruieren, so lange
er das Passwort nicht kennt.
schwierig in
Verbindung
zu bringen
RGB-Ordnung
permutiere mit PW
Permutation mit Passwort
(nicht von Dritten abfangbar)
permutiere mit Nachricht
Permutation mit Nachricht
Abbildung 21: Doppelte Permutation mit GIFShuffle
73
einfach in
Verbindung
zu bringen
einfach in
Verbindung
zu bringen

6.3 Einbettung in Audio-Dateien
6.3.1 WPC-Audio
Zusammenfassung Die Wet-Paper-Codes aus Abschnitt 5.3.3 werden auf Audio-
Dateien angewandt.
Segmentierung Audio-Dateien, insbesondere unkomprimierte WAVs, sind im Allgemeinen
erheblich größer als Bilder. Selbst nachdem die Komplexität des WPC-Verfahrens
mittels LT-Codes reduziert worden ist, hängt der Berechnungsaufwand nicht linear von
der Dateigröße. Um WPC auf Audio-Dateien anwenden zu können, müssen die Daten
daher in kleinere Blöcke unterteilt werden. Die Größe dieser Blöcke kann frei gewählt
werden, wobei die Geduld des Benutzers und die zu Verfügung stehende Rechenleistung
die zu beachtenden Faktoren sind. Zum Wiederherstellen der versteckten Nachricht muss
die gewählte Blockgröße bekannt sein.
Perturbed MP3 Die Idee, die hinter Perturbed Quantization steht, kann auf
MP3-Dateien übertragen werden, indem die eindimensionalen MDCT-Koeffizienten
” gestört“werden. Auch bei MP3 findet vor der Huffman-Kodierung der Koeffizienten
eine Quantisierung statt. Die künstlich eingefügten Rundungsfehler können hier genauso
statistisch nur schwer nachgewiesen werden.
Verglichen mit einem JPEG-Bild gibt es in einem durchschnittlichen MP3 wesentlich
mehr Koeffizienten. Daher lassen sich entweder größere Nachrichten verstecken, oder
man verkleinert das Auswahlfenster für die Koeffizienten, um statistisch unauffäligere
Daten zu erzeugen.
WPC-WAV
Perturbed WAV Sind sowohl Quell- und Zielformat WAVs , so findet im Allgemeinen
keine Quantisierung statt. Daher kann man diese auch nicht mit der obigen Methode
verändern. Ein Lösungsansatz ist es, künstlich eine Rundungsoperation einzuführen,
um diese dann gezielt zu stören, siehe 5.3.3. Dafür bietet sich die Umwandlung von
16-Bit-PCM-Daten nach 8-Bit an. Man betrachtet dabei die unteren acht Bits als Nachkommastellen
und trifft aufgrund dieser Werte eine Entscheidung, ob das betrachtete
Sample modifizierbar ist oder nicht.
Randomized WAV Eine einfache Veränderung der LSBs von WAV-Dateien mit pseudorandomiserten
Daten, wie sie ein Verschlüsselungsalgorithmus aus der zu versteckenden
Nachricht erzeugt, ist statistisch auffällig. Um die Entdeckungswahrscheinlichkeit
zu verringern, kann man Wet-Paper-Codes verwenden, um die Anzahl der Samples zu
reduzieren, in denen das LSB verändert wird; einfacherweise könnte diese Anzahl der
Nachrichtenlänge in Bits entsprechen.
Anstatt nach einem rekonstruierbaren Muster veränderbare Samples auszuwählen, kann
der Sender dies zufällig tun. Ein spezieller Stego-Angriff kann also auch bei Kenntnis
74

des Algorithmus die veränderten Samples nicht vorselektieren, um nur für diese die Statistik
zu betrachten. Und ein allgemeiner Angriff kann aufgrund der geringen Änderung
am Trägermedium keine eindeutige Entscheidung darüber treffen, ob eine Nachricht versteckt
wurde oder nicht.
Der gleiche Effekt kann effizienter ohne WPC erreicht werden, indem statt randomisiert
pseudorandomisiert in Abhängigkeit vom Stego-Key ausgewählt wird. Dieses Verfahren
wird daher nicht implementiert.
6.4 Einbettung in SVG-Dateien
6.4.1 SVG-Winkel
Zusammenfassung Die geheime Nachricht soll in den XML-Daten eines Vektorbildes
im SVG-Standard eingebettet werden. Wir vermuten, dass die Winkelangaben, wie sie
bei der Beschreibung von Farbverläufen verwendet werden, sich am besten zum Einbetten
von Geheimbits mittels eines LSB-Verfahrens eignen.
Algorithmus Da uns kein Algorithmus bekannt ist, der die Einbettung in SVGs beherrscht,
werden wir selbst einen entwickeln.
Funtionsweise Die Nachkommastellen der Winkelangaben werden genutzt, um in den
niedrigstwertigen Bits (den LSBs) Daten einzubetten. Da in unserem Projekt auch generische
LSB-Verfahren entwickelt werden sollen, besteht die Aufgabe des konkreten SVG-
Algorithmus lediglich darin, eine SVG-Datei zu lesen, die Winkeldaten (falls vorhanden)
zu extrahieren und an einen der generischen LSB-Algorithmen weiter zu reichen.
Ein Zwischenschritt könnte die Analyse der Winkeldaten sein, ob sie vor der Einbettung
eine genügend große Zufälligkeit aufweisen. Dadurch wird verhindert, dass bei
gleichmäßigen Winkeln (z.B. exakt 45 ◦ im Gegensatz zu 44, 256678371 ◦ ) die eingebetteten
Daten zu stark herausstechen. In wiefern sich eine solche Analyse aber realisieren
lässt, muss noch untersucht werden.
Für eine Übersicht über den Aufbau eines SVGs siehe Abschnitt 4.6.
Für uns von Interesse sind nicht direkt die Tags des XML-Formats, sondern das optionale
Attribut transform, welches beschreibt, wie ein grafisches Element verändert wird,
bevor es dargestellt wird. Dabei gibt es eine Menge verschiedener Operationen, welche
innerhalb des Attributs beschrieben werden, unter anderem Rotation, Verschiebung,
Verzerrung, etc. Interessant ist für uns nur die Matrix-Transformation. Eine Transformationsmatrix
wird durch sechs Fließkommazahlen beschrieben, welche vergleichsweise
viele Nachkommastellen und in den meisten Fällen eine hohe Entropie aufweisen.
Das transform-Attribut zur Matrixbeschreibung kommt in einem SVG nicht
sehr häufig zum Einsatz. Dafür wird aber umso häufiger das gradientTransform-
Attribut genutzt, um die Transformation eines Farbverlaufs ( oder
) anzugeben.
75

Aufwand, Einbettungsrate und Sicherheit Von dem reinen Extrahieren und der
eventuellen Analyse der Winkeldaten einmal abgesehen, entsprechen Aufwand, Einbettungsrate
und Sicherheit des Algorithmus denen des verwendeten generischen LSB-
Algorithmus.
Die Herausforderung beim Extrahieren der Coverbytes wird es sein, die Fließkommazahlen
auf eine ähnliche Art zu behandeln wie die ganzzahligen Werte der bisherigen
LSB-Anwendungsfälle.
6.5 Einbettung in PDF-Dateien
6.5.1 PDFShuffle
Zusammenfassung
Ähnlich wie bei der Umsortierung der Farbtabelle von GIF Grafiken, können auch die
einzelnen Objekte eines PDF Dokuments umsortiert werden.
Algorithmus
Vor der allgemeinen Beschreibung des PDF Formats, soll kurz auf die innere Struktur
eingegangen werden. Ein PDF Dokument besteht aus einzelnen Objekten. Diese werden
über einen Katalog bzw. XREF Tabelle referenziert. Durch diese baumartige Struktur
Abb.22 kann ein PDF-Reader schnell eine bestimmte Seite in einem Dokument anzeigen,
ohne dieses erst ganz einlesen zu müssen. Besonders interessant für diesen Algorithmus,
Lesezeichen
Catalog
Seite 1
Seite 2
Seite 3
Abbildung 22: PDF-Struktur
Artikel
ist die XREF Tabelle und die Anordnung der Objekte. Ein XREF Eintrag ist 20 Bytes
lang, die ersten 10 Bytes geben den Offset innerhalb des PDF-Stroms an. Daraufhin folgt
ein Leerzeichen und die 5 Bytes lange Generationsnummer. Den Abschluß bildet wieder
ein Leerzeichen gefolgt von der Kennzeichnung des Objekts. Diese besteht entweder
aus dem Buchstaben n für inuse entry (vorhandene Objekte) oder f für free entry
(gelöschte Objekte). Die letzten 2 Bytes können entweder ein CRLF Zeilenumbruch
76

oder ein Leerzeichen gefolgt von CR oder LF sein.
Das folgende Beispiel zeigt ein einfaches PDF Dokument:
%PDF-1.2
1 0 obj
>
stream
60 5 m
110 5 l
85 45 l
.5 .6 1 rg
f
21 5 m
44 32 87 37 115 17 c
3 w
0 G
S
.707 .707 -.707 .707 0 0 cm
BT
/F1 9 Tf
10 -5 Td
.9 .3 .3 rg
(Hello World!) Tj
ET
endstream
endobj
2 0 obj
>
endobj
3 0 obj
>
/Contents 1 0 R
>>
endobj
77

4 0 obj
>
endobj
5 0 obj
>
endobj
xref
0 6
0000000000 65535 f
0000000009 00000 n
0000000215 00000 n
0000000296 00000 n
0000000467 00000 n
0000000530 00000 n
trailer
< /Size 6 /Root 5 0 R >>
startxref
582
%%EOF
Im unteren Teil befindet sich die XREF Tabelle, die den Offset für jedes Objekt innerhalb
des Dokuments enthält. Bei kleinen Dokumenten ist diese Tabelle meist aufsteigend
sortiert, da das erste Objekt meist auch die erste Seite darstellt. Allerdings können nach
[Ado08b] beliebige Objekte eingefügt bzw. auch gelöscht werden. Beim löschen werden
allerdings die Objekte nicht aus dem Dokument entfernt, sondern nur die Kennzeichnung
von n auf f geändert. Somit kann davon ausgegangen werden, dass bei großen Dokumenten
keine Sortierung der XREF Tabelle mehr herrscht. In einem solchen Fall kann
der GIF Shuffle Algorithmus auf die Objekte eines PDF Dokuments angewendet werden.
Wobei die einzelnen Objekte die Rolle der Farbtabelle einer GIF-Grafik übernehmen.
Analyse von Format und Algorithmus
Damit PDFShuffle effizient eingesetzt werden kann, muss sichergestellt werden, dass eine
Vielzahl von PDF-Dokumenten genügend Objekte bietet, um eine hohe Einbettungsrate
zu erreichen, als auch, dass die Entdeckungswahrscheinlichkeit nicht höher ist als die von
GIFShuffle.
Es wurde daher ein Programm entwickelt, das mit Hilfe der Yahoo-Search-Engine
PDF-Dateien herunterlädt und analysiert, um eben genannte Anforderungen empirisch
zu testen. Es wurden in drei Durchläufen jeweils 5000 unterschiedliche PDF-Dateien
78

getestet:
Test 1:
• Objekte insgesamt: 1492059
• nicht linear angeordnet insgesamt: 115223
• nicht linear angeordnet und dabei als gelöscht markiert: 493964
• linear angeordnet und dabei als gelöscht markiert: 1906
• Im Schnitt 298.4118 Klassen pro Datei
• Im Schnitt 121.8374 nicht sortierte Klassen pro Datei (40.8286133457 %)
• davon als geloescht markierte: 98.7928 nichtsortierte Klassen pro Datei
(81.0857749755 %)
• Im Schnitt 0.3812 als geloescht markierte aber sortierte Klassen pro Datei
Test 2:
• Objekte insgesamt: 1720354
• nicht linear angeordnet insgesamt: 213347
• nicht linear angeordnet und dabei als gelöscht markiert: 522780
• linear angeordnet und dabei als gelöscht markiert: 10045
• Im Schnitt 344.0708 Klassen pro Datei
• Im Schnitt 147.2254 nicht sortierte Klassen pro Datei (42.7892747655 %)
• davon als geloescht markierte: 104.556 nichtsortierte Klassen pro Datei
(71.0176369023 %)
• Im Schnitt 2.009 als geloescht markierte aber sortierte Klassen pro Datei
Test 3:
• Objekte insgesamt: 242597
• nicht linear angeordnet insgesamt: 13712
• nicht linear angeordnet und dabei als gelöscht markiert: 6783
• linear angeordnet und dabei als gelöscht markiert: 357
• Im Schnitt 48.5194 Klassen pro Datei
• Im Schnitt 4.099 nicht sortierte Klassen pro Datei (8.4481671249 %)
79

• davon als geloescht markierte: 1.3566 nichtsortierte Klassen pro Datei
(33.0958770432 %)
• Im Schnitt 0.0714 als geloescht markierte aber sortierte Klassen pro Datei
Die Tests zeigen, dass die allermeisten Objekte, die nicht linear angeordnet sind, als
gelöscht markiert sind. Eine Einbettung in alle Objekte würde daher im Gegensatz zu
GIFShuffle zwar eine bessere Einbettungsrate aber auch eine deutlich höhere Entdeckungswahrscheinlichkeit
bedeuten. Eine Einbettung in die als gelöscht markierten Objekte
einer PDF-Datei wäre beinahe eben so sicher wie die Einbettung in GIF-Dateien,
die Einbettungsrate würde aber im Schnitt auf log2(100!) sinken.
Der letzte Test zeigt weiterhin, dass im Internet viele PDF-Dateien zu finden sind, die
sich für eine Einbettung wegen ihre Größe nicht eignen würden, da zu wenige Objekte
vorhanden sind.
Die Projektgruppe hat sich deshalb dagegen entschieden, den Algorithmus PDFShuffle
in die Softwarebibliothek aufzunehmen.
6.6 Einbettung in CSS-Dateien
6.6.1 CSS-Steganographie
Zusammenfassung CSS bietet die Möglichkeit, Informationen sowohl durch Permutation
von Eigenschaft-Werte-Paaren als auch mittels Leerzeichen zu verstecken.
Algorithmus Analog zu GIF-Shuffle wird für alle Eigenschaften eine natürliche Ordnung,
beispielsweise die alphabetische, definiert. Innerhalb eines Selektors können durch
Permutation dieser Reihenfolge ca log 2 n! Bits versteckt werden.
Um die Kapazität des Trägermediums zu erhöhen, werden durch Hinzufügen oder Weglassen
von Leerzeichen Nullen und Einsen codiert.
CSS eignet sich für diese beiden Verfahren gut, da ein solches Stylesheet normalerweise
’natürlich wächst’; vom Autor einer Website werden hier Informationen ohne
erkennbares System hinzugefügt oder entfernt, weshalb die zufällige Reihenfolge der
Eigenschaft/Werte-Paare statistisch nicht auffällig ist.
Analyse von Format und Algorithmus Die Untersuchung von 13000 im Internet verwendeten
CSS-Dateien zeigte, dass eine Implementierung dieses Algorithmus nicht lohnenswert
ist. Im Schnitt enthielten die Dateien 62 Klassen. Wird der Shuffle-Algorithmus
angewendet auf die Klassen einer CSS-Datei so ergibt sich eine Einbettungsrate von
log 2 62! = 284 Bits.
Eine Einbettung durch Verwendung von Leerzeichen erwies sich als sehr auffällig,
wodurch die erwartete Einbettungsrate von log 2 n!) + n nicht erreicht werden kann. Um
die Einbettungsrate anzuheben könnte zusätzlich in die Attribute eingebettet werden. Da
eine Klasse durchschnittlich nur zwei Attribute enthält, könnte man hier gerade einmal
62 Bits einbetten. Damit läge die zu erwartende Einbettungsrate bei 346 Bits.
Unter diesen Umständen wird eine Implementierung nicht in Betracht gezogen.
80

7 Die Bibliothek libstego
Die hier vorgestellten Algorithmen und Mechanismen der Steganographie sind bisher
häufig nur als einzelne Implementierungen zu finden. Steganographische Software ist
nicht weit verbreitet, und es fehlt eine gemeinsame Grundlage für die erhältliche Software.
Ziel dieser Projektgruppe ist es, eine Bibliothek zu entwickeln, welche die Entwicklung
von steganographischen Programmen ermöglicht, ohne dass jeder Entwickler die Algorithmen
neu implementieren muss. Die genauen Funktionen der Bibliothek werden in
späteren Dokumenten vorgestellt, hier wird zunächst nur unsere Motivation dargelegt
und ein grober Überblick über den geplanten Aufbau geliefert.
7.1 Aufbau der Bibliothek
Während der Planung der Bibliothek haben wir uns entschieden, Funktionen zum Einlesen
und Schreiben bestimmter Dateiformate in eine gesonderte Bibliothek zu verschieben,
um uns in der Kernbibliothek auf die Algorithmen konzentrieren zu können. Beide Bibliotheken
kommunizieren über noch festzulegende Datenstrukturen miteinander. Durch
die Trennung von Datei-Ein- und -Ausgabe von den eigentlichen Berechnungen können
Anwender unserer Bibliothek auch eigene Dateiformate verwenden, die sie direkt an die
Algorithmen übergeben können.
7.2 Implementierungsdetails
Als Programmiersprache wurde C gewählt, da es als der kleinste gemeinsame Nenner
für die Entwicklung von Bibliotheken angesehen wurde. Eine in C implementierte Bibliothek
kann in einer Vielzahl von anderen Programmiersprachen verwendet werden,
der umgekehrte Fall ist weniger häufig. Außerdem gilt C als performant und bietet gute
Möglichkeiten zur direkten Manipulation von Bits, was für viele der Algorithmen wichtig
ist.
Für die Ein- und Ausgabe der verschiedenen Dateitypen werden wir bereits vorhandene
Bibliotheken verwenden, soweit dies möglich ist. Ebenfalls werden wir spezielle
mathematische Bibliotheken verwenden, um den Implementierungsaufwand im Rahmen
und den Fokus auf den steganographischen Algorithmen zu halten.
81

Glossar
Alphakanal Ein zusätzlicher Farbkanal, der jedoch nicht eine Farbe aus RGB, sondern
den Transparenzwert eines Pixels beschreibt.
big-endian Bezeichnet die Reihenfolge in der Bytes für das Speichern von Zahlen abgelegt
werden. Diese Reihenfolge ist wichtig, wenn mehr als ein Byte nötig ist, um
einen Zahlenwert zu repräsentieren. Bei der big-endian Reihenfolge wird das Byte
mit den höchstwertigen Bits zuerst gespeichert..
Containerformat Als Containerformat bezeichnet man ein Dateiformat, das verschiedenartige
Datenformate enthalten kann. Das Containerformat legt dabei nur die
Art und Struktur fest, wie der Inhalt abgelegt wird..
Cover Ein Medium, in das eine Geheimnachricht eingefügt werden soll.
DCT Abkurzung fur ” Diskrete Kosinus Transformation “.
Dichtefunktion Die Wahrscheinlichkeitsdichte ist ein Hilfsmittel, mit dem sich die Wahrscheinlichkeit
berechnen lässt, dass eine stetige Zufallsvariable zwischen zwei reellen
Zahlen a und b liegt..
Entropie Mittlerer Informationsgehalt eines Zeichens.
Entropiekodierung Kompressionsverfahren, in dem haufig vorkommende Zeichen mit
weniger Bits kodiert werden als seltene. Bekannteste Vertreter sind Huffman-
Kodierung und Arithmetische Kodierung.
F5 Steganographischer Algorithmus von Andreas Westfeld.
Gamma Mittels Gammakorrektur wird die Helligkeit von Bildern an verschiedene Ausgabegerate
angepasst..
Hamming-Gewicht ist die Anzahl an Einsen in einem binaren Vektor..
Hammingdistanz Maß für die Unterschiedlichkeit von zwei Zeichenketten.
Huffman-Codes Kompressionsverfahren, das unter anderem im Grafikformat PNG verwendet
wird.
ISO International Organization for Standardization, eine internationale Organisation
zum Definieren von Standards.
JFIF Konkretes Dateiformat, das JPEG benutzt.
JPEG Verfahren zur verlustbehafteten Kompression von Bildern.
82

JPEG-2000 Weiterentwicklung des JPEG-Standards von 1992.
Laplace-Filter Bildfilter zum Auffinden von Kanten in einem Bild.
LSB Das LSB ist das niederwertigste Bit eines binären Strings.
LZW-Algorithmus Lempel-Ziv-Welch-Algorithmus zur Kompression, der im Bildformat
GIF verwendet wird.
Matrixkodierung Verfahren zur Einbettung von Nachrichtenbits in Kodewörtern.
MBS Modellbasierte Steganographie.
Palettengrafik Grafik, in der die Farbwerte in einer Palette gespeichert sind und die
Pixeldaten lediglich Indizes der Palette speichern.
PCM Die Puls-Code-Modulation ist ein Verfahren, das genutzt wird, um ein analoges
Signal in ein digitales Signal umzuwandeln..
Permutative Spreizung Einbettungskoeffizienten werden mit Hilfe einer Permutation
ausgewählt.
PQ Perturbed Quantization ist ein Verfahren, um Nachrichten in JPEGs zu verstecken..
Prewitt-Filter Bildfilter zum Auffinden von Kanten in einem Bild, ahnlich LaPlace.
Random Seed Eine Bytefolge, die einen Zufallsgenerator speist, so dass die generierten
Werte auf Sender- und Empfängerseite gleich sind.
Rastergrafik Grafik, in der jedes Pixel mit einer bestimmten, formatabhängigen Anzahl
Bits den Farbwert und ggf. Transparenzwert beschreibt.
RSD Eine Matrix, die dem Robust Soliton Distribution Schema genugt, kann leicht in
eine Dreiecksform gebracht werden.
Sample Einzelner Messwert, im Zusammenhang mit dem WAVE-Audiodateiformat ein
Messwert, der die Amplitude des Signals zu einem bestimmten Zeitpunkt angibt..
Sobel-Filter Bildfilter zum Auffinden von Kanten in einem Bild, ahnlich LaPlace.
Stego-Bild Ein Bild, in das eine Geheimnachricht eingebettet worden ist.
Stego-Key Ein Schlüssel oder Passwort, der/das als Random Seed verwendet wird.
SVG Scalable Vector Graphic, ein XML-basiertes Format zum Speichern von Vektorbildern..
Tag Ein Tag erweitert die Daten in einer Datei um Zusatzinformation, beispielsweise
deren Ursprung oder wie die Daten interpretiert werden sollen..
83

Tagged File Format Ein Dateiformat, dass über standardisierte Tags angibt in welcher
Form und Länge die Daten vorliegen..
W3C World Wide Web Consortium, eine internationale Organisation für Web-
Standards.
WPC Wet-Paper-Codes sind eine Methode, um Nachrichten effizient zu verstecken.
XML Extensible Markup Language, ”[. . . ]eine Auszeichnungssprache zur Darstellung
hierarchisch strukturierter Daten in Form von Textdateien.”??.
XOR Binäre Operation, die nur dann wahr wird, wenn genau einer der beiden Operanden
wahr ist..
YCbCr Farbmodell, welches Farben in einen Helligkeitsanteil (Luminanz Y) und zwei
Farbarten (Chrominanz Cb und Cr) aufteilt.
84

Literatur
[Ado06] Adobe Systems Incorporated. PDF Reference, sixth edition. http://www.
adobe.com/devnet/pdf/pdf_reference.html, November 2006.
[ado08a] Adobe.com. http://www.adobe.com, Juni 2008.
[Ado08b] Adobe. PDF Reference and Related Documentation. http://www.adobe.
com/devnet/acrobat/pdfs/pdf_reference.pdf, Juni 2008.
[auk08] Autokorrelation. http://de.wikipedia.org/wiki/Autokorrelation, Juni
2008.
[Bar88] Bart Kosko. Bidirectional Associative Memories. IEEE Transactions on
Systems, Man and Cybernetics,, 18(1):49–60, 1988.
[Ben99] Walter Bender. Techniques for data hiding. http://www.research.ibm.
com/journal/sj/353/sectiona/bender.html, Juli 1999.
[Blo08] Blooberry. CSS Properties. http://www.blooberry.com/indexdot/css/
propindex/all.htm, August 2008.
[Bol07] Boll, Susanne. Vorlesung Medienverarbeitung, Mai 2007.
[Bol08] Boll, Susanne. Vorlesung Internet Technologien, Januar 2008.
[Bra94] Brani Vidakovic, Peter Mueller. Wavelets For Kids. http://www2.isye.
gatech.edu/~brani/wp/kidsA.pdf, December 1994.
[BW04] Rainer Böhme and Andreas Westfeld. Breaking Cauchy Model-Based JPEG
Steganography with First Order Statistics. 2004.
[Cra98] Ron Crandall. Some Notes on Steganography. Gesendet an die Steganography
Mailing List. 1998.
[Deu96] Peter Deutsch. Deflate compressed data format specification version 1.3.
http://tools.ietf.org/html/rfc1951, 1996.
[DG] Walter Bender Daniel Gruhl, Anthony Lu. Echo Hiding. http://www.media.
mit.eduzSzDataHidingzSzedh2.pdf/gruhl96echo.pdf.
[FAPP99] Markus G. Kuhn Fabien A. P. Petitcolas, Ross J. Anderson. Information
Hiding—A Survey. http://www.cl.cam.ac.uk/~rja14/Papers/
ieee99-infohiding.pdf, Juli 1999.
[FGH03] Jessica J. Fridrich, Miroslav Goljan, and Dorin Hogea. Steganalysis of JPEG
Images: Breaking the F5 Algorithm. In IH ’02: Revised Papers from the 5th
International Workshop on Information Hiding, pages 310–323, London, UK,
2003. Springer-Verlag.
85

[Fou08] FourCC Org. Video Codes and Pixelformat Definitions. http://www.
fourcc.org, Mai 2008.
[Fri05a] Fridrich J., Goljan M., Soukal D. Efficient Wet Paper Codes, 2005.
[Fri05b] Fridrich J., Goljan M., Soukal D. Perturbed Quantization Steganography,
2005.
[GIFa] http://www.gnu.org/philosophy/gif.html.
[GIFb] http://progfree.org/Patents/Gif/origCompuServe.html.
[GIFc] http://www.w3.org/Graphics/GIF/spec-gif89a.txt.
[IHWC87] Radford M. Neal Ian H. Witten and John G. Cleary. Arithmetic coding for
data compression. Commun. ACM, 30(6):520–540, 1987.
[ISO92a] ISO , ITU. JPEG Specification. http://www.iso.org/iso/iso_catalogue/
catalogue_tc/catalogue_detail.htm?csnumber=18902, 1992.
[ISO92b] ISO , ITU. JPEG Specification. http://www.itu.int/rec/T-REC-T.
81-199209-I/en, 1992.
[ISO00] ISO , ITU. JPEG-2000 Part 1. http://www.jpeg.org/public/
15444-1annexi.pdf, 2000.
[Jir01] Jiri Fridrich, Du Rui. Secure Steganographic Methods for Palette Imagages.
Proceedings ACM, Workshop on Multimedia & Security, 2001.
[Joh] Corinna John. Steganography 14 - what text lists, gif images, and
html pages have in common. http://www.codeproject.com/KB/security/
steganodotnet14.aspx.
[Kat07] Kathryn Hempstalk. Digital Invisible Ink Toolkit. http://diit.
sourceforge.net/, September 2007.
[Lub02] Luby Michael. LT Codes. In Proc. The 43rd Annual IEEE Symposium on
Foundations of Computer Science, pages 271–282, November 2002.
[MA99] Thomas Boutell et alii Mark Adler. Portable network graphics (png) specification,
version 1.2. http://png.unicast.org/pub/png/spec/1.2/, Juli
1999.
[pcm08] WAVE PCM soundfile format. http://ccrma.stanford.edu/CCRMA/
Courses/422/projects/WaveFormat/, Juni 2008.
[Roe] Greg Roelofs. Portable network graphics. http://www.libpng.org/pub/
png/.
86

[Sal05] Phil Sallee. Model-Based Methods For Steganography And Steganalysis. Int.
J. Image Graphics, 5(1):167–190, 2005.
[Ter84] Terry A. Welch. A Technique for High-Performance Data Compression.
http://www.cs.duke.edu/courses/spring03/cps296.5/papers/
welch_1984_technique_for.pdf, 1984.
[W3C08a] W3C. CSS. http://www.w3.org/Style/CSS/, August 2008.
[W3C08b] W3C. CSS Selektoren. http://www.w3.org/TR/css3-selectors/
#selectors, August 2008.
[Wes01] Andreas Westfeld. F5-A Steganographic Algorithm. In IHW ’01: Proceedings
of the 4th International Workshop on Information Hiding, pages 289–302,
London, UK, 2001. Springer-Verlag.
[Wik08a] Wikipedia. Arithmetisches Kodieren. http://de.wikipedia.org/wiki/
Arithmetisches_Kodieren, Mai 2008.
[Wik08b] Wikipedia. Cascading Style Sheets. http://de.wikipedia.org/wiki/
Cascading_Style_Sheets, Juni 2008.
[Wik08c] Wikipedia. Huffman-Code. http://de.wikipedia.org/wiki/
Huffman-Kodierung#Huffman-Code, Mai 2008.
[Wik08d] Wikipedia. JFIF. http://de.wikipedia.org/wiki/JFIF, Mai 2008.
[Wik08e] Wikipedia. JPEG. http://de.wikipedia.org/wiki/JPEG, Mai 2008.
[Wik08f] Wikipedia. JPEG-2000. http://de.wikipedia.org/wiki/JPEG-2000, Mai
2008.
[Wik08g] Wikipedia. Scalable Vector Graphics. http://de.wikipedia.org/wiki/
SVG, Juni 2008.
[Wik08h] Wikipedia. YCbCr-Farbmodell. http://de.wikipedia.org/wiki/
YCbCr-Farbmodell, Mai 2008.
[wp08] Wikipedia Artikel: Portable Document Format. http://de.wikipedia.org/
wiki/Pdf, Juni 2008.
[wpw08] Wikipedia Artikel: RIFF WAVE. http://de.wikipedia.org/wiki/RIFF_
WAVE, Juni 2008.
[YYCT01] H-K. Pan Y-Y. Chen and Y-C. Tseng. A secure data hiding scheme for
two-color images. IEEE Symposium on Computers and Communication
(ISSC2000), 2001.
87