Wie funktioniert Verschluesselung bzw. sichere Datenuebertragung

[Lude]

Hi,

wenn ich sowas wie den SSL implementieren wuerde, wuerde ich (ganz laienhaft ;-):
 - einen Sicherheitsserver ins Web stellen, der Sicherheit bereitstellt, also die Leistung verkauft, dass nicht alle alles duerfen
 - ein sicherer http-Request wuerde implementiert werden indem der Browserclient dem Sicherheitsserver meldet, dass er einer dem Sicherheitsserver bekannten Site Daten senden moechte
 - die Antwort des Sicherheitsservers wuerde darin bestehen, dass er dem Browserclient eine Eindeutigkeit (IP des Browserclients?) mitgibt und einen temporaer gueltigen Schluessel zurueckgibt
 - der Browserclient verschluesselt dann seinen Request und sendet die Daten
 - der sichere Webserver erhaelt die Daten, wendet sich an den Sicherheitsserver, holt sich den temporaer gueltigen Schluessel und entschluesselt

Wahrscheinlich scheitert das o.g. Konzept irgendwie. - Kann mir jemand ein paar Zeilen schreiben warum und wie man's ggf. besser macht? - Allerdings scheint mir, dass aus Gruenden der Logik ausser dem Webbrowserclient und dem Webserver eine Instanz benoetigt wird, die Sicherheit bereitstellt, oder?

Gruss,
Lude

[Sven Rautenberg]

Moin!

Wahrscheinlich scheitert das o.g. Konzept irgendwie. - Kann mir jemand ein paar Zeilen schreiben warum und wie man's ggf. besser macht? - Allerdings scheint mir, dass aus Gruenden der Logik ausser dem Webbrowserclient und dem Webserver eine Instanz benoetigt wird, die Sicherheit bereitstellt, oder?

Allein schon eine Formulierung wie "Server, der Sicherheit bereitstellt" ist ziemlich abstrus, wirr und haarsträubend.

Sicherheit ist kein Produkt, was man verkaufen, austauschen oder irgendwie von A nach B transportieren (oder digital auch kopieren) kann.

Sicherheit ist ein Konzept, gewisse Dinge zuzulassen, und andere Dinge nicht.

Bei SSL bestand die Aufgabe darin, zwei Stationen so miteinander kommunizieren zu lassen, dass Dritte diese Kommunikation nicht abhören können. Der Aspekt "dass nicht jeder alles darf" ist von SSL nicht im Geringsten erfaßt.

Realisiert wird SSL durch ein Public-Key-Verfahren, welches es ermöglicht, dass die zwei Stationen trotz abgehörter Leitung Schlüsseldaten austauschen können, um einen sicheren, verschlüsselten Kanal auf der abgehörten Leitung aufzubauen.

Alle anderen Überlegungen zu "Sicherheit" sind davon abhängig, was denn überhaupt passieren soll.

Dinge wie zentral organisierte und geprüfte Authentifizierung von Benutzern beispielsweise führt zu Stichworten wie LDAP.

- Sven Rautenberg

[Erwin]

Moin!

Realisiert wird SSL durch ein Public-Key-Verfahren, welches es ermöglicht, dass die zwei Stationen trotz abgehörter Leitung Schlüsseldaten austauschen können, um einen sicheren, verschlüsselten Kanal auf der abgehörten Leitung aufzubauen.

Nähres ist bei netscape zu finden...

Gruss, Erwin

[Lude]

Hi,

Realisiert wird SSL durch ein Public-Key-Verfahren, welches es ermöglicht, dass die zwei Stationen trotz abgehörter Leitung Schlüsseldaten austauschen können, um einen sicheren, verschlüsselten Kanal auf der abgehörten Leitung aufzubauen.

war also gar nicht mal so doof, was ich da geschrieben habe. - Da ich nicht fragen moechte, wie das o.g. "Public-Key-Verfahren" funktioniert (zu vermutetende Antwort: "RTFM"), frage ich nur, ob das von mir vorgeschlagene Verfahren tauglich ist. Ist es das?

Alle anderen Überlegungen zu "Sicherheit" sind davon abhängig, was denn überhaupt passieren soll.

Dinge wie zentral organisierte und geprüfte Authentifizierung von Benutzern beispielsweise führt zu Stichworten wie LDAP.

Es scheint mir durchaus auch um Sicherheit zu gehen; Authentifizierungskonzepte (DT 'Sesssions', 'User', 'Rights') kuemmern sich um andere Aspekte von Sicherheit.

Gruss,
Lude

[Erwin]

Hi Lude,

Realisiert wird SSL durch ein Public-Key-Verfahren, welches es ermöglicht, dass die zwei Stationen trotz abgehörter Leitung Schlüsseldaten austauschen können, um einen sicheren, verschlüsselten Kanal auf der abgehörten Leitung aufzubauen.

war also gar nicht mal so doof, was ich da geschrieben habe. - Da ich nicht fragen moechte, wie das o.g. "Public-Key-Verfahren" funktioniert (zu vermutetende Antwort: "RTFM"), frage ich nur, ob das von mir vorgeschlagene Verfahren tauglich ist. Ist es das?

Bei einer SSL Verbindung werden auch die Passworte verschlüsselt übertragen, zb. für status 403.

Dasselbe gilt auch wenn eine UserAuth nicht über 403 abgewickelt wird sondern zb. über ein eigenes LoginScript auf dem HTTPS Server (zum aufbau einer Session).

Wenn dahinter (LoginScript) ein LDAP Server liegt, ists empfohlen, dass die Verbindung zwischen dem HTTPS~ und dem LDAPServer ebenfalls encrypted wird, zb. LDAPS.

Erwin

[Lude]

Hi,

Bei einer SSL Verbindung werden auch die Passworte verschlüsselt übertragen, zb. für status 403.

wo kommt die Verschluesselung (der Schluessel) fuer die "Passworte" her? Und, zweitens, funktioniert's halbwegs so, wie von mir spekuliert (und beschrieben)? (Oder koennte es so funktionieren? ;-)

Gruss,
Lude

[Sven Rautenberg]

Moin!

war also gar nicht mal so doof, was ich da geschrieben habe. - Da ich nicht fragen moechte, wie das o.g. "Public-Key-Verfahren" funktioniert (zu vermutetende Antwort: "RTFM"), frage ich nur, ob das von mir vorgeschlagene Verfahren tauglich ist. Ist es das?

Du hast geschrieben, dass du sowas wie SSL implementieren wolltest. SSL arbeite mit zwei Stationen, nicht mit dreien. Dein Konzept taugt nichts, weil du dich von einer dritten Station abhängig machst, die laut deinem Konzept nicht zwingend deiner Kontrolle untersteht.

Es scheint mir durchaus auch um Sicherheit zu gehen; Authentifizierungskonzepte (DT 'Sesssions', 'User', 'Rights') kuemmern sich um andere Aspekte von Sicherheit.

"Scheint"? Werd' mal konkret.

- Sven Rautenberg

[Lude]

Hi,

Du hast geschrieben, dass du sowas wie SSL implementieren wolltest. SSL arbeite mit zwei Stationen, nicht mit dreien. Dein Konzept taugt nichts, weil du dich von einer dritten Station abhängig machst, die laut deinem Konzept nicht zwingend deiner Kontrolle untersteht.

was ist mit der Zertifizierungsstelle beim SSL? Koennte das vielleicht auf die Existenz eines dritten Geraets hindeuten? - Und wie will man logisch ueberhaupt im Web Sicherheit implementieren ohne einer dritten Instanz?

Es scheint mir durchaus auch um Sicherheit zu gehen; Authentifizierungskonzepte (DT 'Sesssions', 'User', 'Rights') kuemmern sich um andere Aspekte von Sicherheit.

"Scheint"? Werd' mal konkret.

War doch konkret. Oder geht's bei SSL nicht um Sicherheit? - Gewisse rhetorische Spaesschen und auch Fehler erbitte ich moeglichst wohlwollend aufzunehmen und zu bearbeiten.

Gruss,
Lude

[Sven Rautenberg]

Moin!

was ist mit der Zertifizierungsstelle beim SSL? Koennte das vielleicht auf die Existenz eines dritten Geraets hindeuten? - Und wie will man logisch ueberhaupt im Web Sicherheit implementieren ohne einer dritten Instanz?

Die dritte Instanz ist für SSL nicht zwingend notwendig.

Sie ist deswegen vorhanden, um SSL-Zertifikate auf den Webservern digital zu unterschreiben. Zusammen mit den in eigentlich allen Browsern installierten Zertifikaten dieser Stellen kann der Browser nicht nur die Verschlüsselung aktivieren, sondern automatisch auch die Authentizität des Servers feststellen. Denn nur der Server, der ist, wofür er sich ausgibt, wird eine gültige Unterschrift haben.

Definitiv wird aber zum Schlüsselaustausch keine dritte Stelle kontaktiert.

Und es ist auch problemlos möglich, ohne eine dritte Stelle eine eigene Unterschrift zu benutzen. Dann macht man damit eben seine eigene Zertifizierungsstelle auf. Das kann sich für den kleinen Anwenderkreis lohnen (dann installiert jeder der drei Zugriffsberechtigten das Zertifikat und weiß künftig, dass SSL-Kommunikation mit dem Server immer mit dem _echten_ Server stattfindet), oder auch für einen größeren Anwenderkreis (beispielsweise alle Mitarbeiter einer Firma). Es ist unpraktisch für die Weltbevölkerung als Großes. :)

War doch konkret. Oder geht's bei SSL nicht um Sicherheit? - Gewisse rhetorische Spaesschen und auch Fehler erbitte ich moeglichst wohlwollend aufzunehmen und zu bearbeiten.

SSL verschlüsselt und authentifiziert die zwei Kommunikationsteilnehmer. Denn auch auf Client-Seite kann ein Zertifikat bescheinigen, dass der Client der ist, für den er sich ausgibt. Der Server kann schon allein deswegen Zugriffe freigeben, ganz ohne Passwort.

Aber du bist in der Hinsicht unkonkret, als dass du immer wieder von "Sicherheit" sprichst, aber nicht deutlich machst, gegen welches Risiko du dich absichern willst. Sicherheit - wovor?

Du hast irgendwas von "SSL selber implementieren" gefaselt, obwohl die Notwendigkeit dazu nicht besteht. Warum selber machen? Welchen Vorteil hat das? Wärst du so schlau, wie tausende Kryptographie-Experten, die das System entworfen und getestet haben, um es besser zu machen? Vermutlich nicht. Warum also diese akademische Diskussion ohne Ziel? Die schwimmt nämlich in meinen Augen sehr ziellos im freien Raum umher und kommt nicht voran.

- Sven Rautenberg

[Lude]

Hi,

was ist mit der Zertifizierungsstelle beim SSL? Koennte das vielleicht auf die Existenz eines dritten Geraets hindeuten? - Und wie will man logisch ueberhaupt im Web Sicherheit implementieren ohne einer dritten Instanz?

Die dritte Instanz ist für SSL nicht zwingend notwendig.

sagen wir mal ich moechte Dir z.B. ein XML-Dokument per http zukommen lassen und moechte dieses Verschluesseln. Wie lasse ich Dir den Schluessel zum Entschluesseln zukommen?

Sie ist deswegen vorhanden, um SSL-Zertifikate auf den Webservern digital zu unterschreiben. Zusammen mit den in eigentlich allen Browsern installierten Zertifikaten dieser Stellen kann der Browser nicht nur die Verschlüsselung aktivieren, sondern automatisch auch die Authentizität des Servers feststellen. Denn nur der Server, der ist, wofür er sich ausgibt, wird eine gültige Unterschrift haben.

Das interesiert mich. Habe ich die o.g. Funktionalitaet in meinem Ausgangsposting treffend beschrieben?

Und es ist auch problemlos möglich, ohne eine dritte Stelle eine eigene Unterschrift zu benutzen.

Zurzeit bezweifle ich diese Aussage stark.

Du hast irgendwas von "SSL selber implementieren" gefaselt, obwohl die Notwendigkeit dazu nicht besteht. Warum selber machen? Welchen Vorteil hat das? Wärst du so schlau, wie tausende Kryptographie-Experten, die das System entworfen und getestet haben, um es besser zu machen? Vermutlich nicht. Warum also diese akademische Diskussion ohne Ziel? Die schwimmt nämlich in meinen Augen sehr ziellos im freien Raum umher und kommt nicht voran.

Nun, ich habe gute Erfahrung damit gemacht bestimmte Konzept-Implementation, ja ich traue mich sogar, bestimmte Produkte zu schreiben, nachzubauen. - Z.B. DB-Replikationen oder das gute alte Sitzungskonzept. Das ist gut fuer's Verstaendnis, glaub's mir einfach mal.

Gruss,
Lude

[Peter Kaufmann]

Hallo Lude,

sagen wir mal ich moechte Dir z.B. ein XML-Dokument per http zukommen lassen und moechte dieses Verschluesseln. Wie lasse ich Dir den Schluessel zum Entschluesseln zukommen?

am besten gar nicht! Du verwendest den öffentlichen Schlüssel von Sven (http://wwwkeys.de.pgp.net:11371/pks/lookup?search=sven%40rtbg.de&op=vindex)  und verschlüsselst dann dein Dokument mit dem Schlüssel so, daß nur noch Sven mit seinen privaten Schlüssel das ganze decodieren kann [1].

Und es ist auch problemlos möglich, ohne eine dritte Stelle eine eigene Unterschrift zu benutzen.

Zurzeit bezweifle ich diese Aussage stark.

Doch das geht: Wenn ich z.B. irgendwann mal Sven IRL treffen sollte gebe ich ihn ein Stück Papier mit dem Fingerprint meines Public Keys und er gibt mir sein Fingerprint. Wir überprüfen dann gegenseitig unsere öffentlich verfürbaren Public Keys und unterschreiben geg. Falls digital die selbigen. Jeder der meinen Urteilsvermögen vertraut weiß dann, daß der Public Key auch wirklich zu Sven gehört.

Vielleicht solltest du dir mal ein gutes Buch ausleihen und dir die Grundlagen anlesen. Ich finde "Abenteuer Kryptologie" von Reinhard Wobst ganz nett. Das Buch ist ohne jegliche Grundkentnisse weitesgehend gut zu verstehen und unterhaltsam geschrieben.

Grüße,

Peter

[1] Das ist in der Praxis meist geringfügig komplizierter: Mit dem Public Key wird nämlich normalerweise nur ein symetrischer Schlüssel verschlüsselt mit dem dann die eigentliche Nachricht codiert wird. Das ändert aber nichts an der zu Grunde liegenden Idee.

[Lude]

Hi,

sagen wir mal ich moechte Dir z.B. ein XML-Dokument per http zukommen lassen und moechte dieses Verschluesseln. Wie lasse ich Dir den Schluessel zum Entschluesseln zukommen?

am besten gar nicht! Du verwendest den öffentlichen Schlüssel von Sven (http://wwwkeys.de.pgp.net:11371/pks/lookup?search=sven%40rtbg.de&op=vindex)  und verschlüsselst dann dein Dokument mit dem Schlüssel so, daß nur noch Sven mit seinen privaten Schlüssel das ganze decodieren kann [1].

was ist, wenn ich 'Sven Rautenberg' nicht kenne?

Gruss,
Lude

[Peter Kaufmann]

Hallo Lude,

was ist, wenn ich 'Sven Rautenberg' nicht kenne?

dann musst du jemanden finden der Sven kennt und die Echtheit seines Public Keys bestätigt. Oder du vertraust jemanden (oder besser du überprüfst gleich verschiedene Quellen) der jemanden vertraut der Svens Schlüssel signiert hat.

Im Fall von Sven wäre das z.B. die Zeitschrift ct. Den Fingerprint der ct findest du in jeder Ausgabe der Zeitschrift im Impressum und kannst somit leicht die Korrektheit ihres eigenen Schlüssels nachprüfen. Wenn du dann noch den Beauftragten der ct zutraust, daß sie Sven richtig überprüft haben (die ct macht das immer auf diversen Messen mit Hilfe des Persos) kannst du Sven dein vertrauliches Dokument schicken.

Grüße,

Peter

[Sven Rautenberg]

Moin!

sagen wir mal ich moechte Dir z.B. ein XML-Dokument per http zukommen lassen und moechte dieses Verschluesseln. Wie lasse ich Dir den Schluessel zum Entschluesseln zukommen?

Die Möglichkeit, per PGP zu verschlüsseln, hat Peter Kaufmann bereits erwähnt.

Die grundsätzliche Frage ist: Woher weißt du, an wen du das schicken mußt? Wie kannst du sicher sein, dass der Ort, an dem du die Daten wie-auch-immer ablieferst, unter meiner Kontrolle steht, bzw. nur mir Einsicht gewährt.

Antwort: Du kannst es nicht wissen, ohne dass es dir jemand sagt. Beispielsweise ich. Oder jemand anderes. Aber gerade weil jemand anderes ja auch sagen könnte: "Schick das per Mail an [e-mail], das kommt immer an!", mußt du diese Angaben irgendwie verifizieren.

Ich sehe bei SSL in der Tat ein Problem. Machst du Online-Banking? Deine Bank hat für den Kontozugang ein signiertes SSL-Zertifikat. Das war nicht billig, und die Bank hat dafür alle möglichen Nachweise bringen müssen, dass die zu zertifizierende Domain auch wirklich ihr gehört bzw. dass das alles mit rechten Dingen zugeht.

Wenn jetzt ein böser Angreifer einen "bankserver2" eröffnet und dafür ein Zertifikat einer anderen Stelle kriegen würde, würde kein Browser der Welt Alarm schlagen. Und wenn er es schafft, für das gesamte Internet, oder zumindest für einen kleineren Teil diesen "bankserver2" anstelle des Originals zu platzieren, würde niemand Verdacht schöpfen.

Die Zertifizierungsstellen sind also wirklich ziemlich wichtige Institutionen, welchen alle Welt gezwungenermaßen gehöriges Vertrauen entgegenbringt, ohne dass sie davon weiß.

Das ist aber auch nur deswegen der Fall, weil SSL eben nicht nur zum Verschlüsseln, sondern auch zum Authentifizieren benutzt werden kann.

Wenn du hingegen SSH (Secure Shell) benutzt, wird der Datenverkehr zwar verschlüsselt, aber irgendwelche obskuren Zertifizierungsstellen sind nicht involviert. Der Server hat sich bei der Installation des SSH-Servers einen möglichst eindeutigen Fingerprint zugelegt, und beim ersten Kontakt (bei dem man selbst sicherstellen muß, dass dieser zum richtigen Server erfolgt - indem man beispielsweise den per Papierpost übermittelten Fingerprint vergleicht) wird man gebeten, den Fingerprint zu bestätigen, damit der Server in die Liste bekannter Server aufgenommen wird. Auch ohne die Aufnahme ist der Datenverkehr verschlüsselt - dieser Mechanismus soll einfach verhindern, dass man arglos einen ausgetauschten und untergeschobenen Server kontaktiert und dem das Passwort mitteilt.

Sie ist deswegen vorhanden, um SSL-Zertifikate auf den Webservern digital zu unterschreiben. Zusammen mit den in eigentlich allen Browsern installierten Zertifikaten dieser Stellen kann der Browser nicht nur die Verschlüsselung aktivieren, sondern automatisch auch die Authentizität des Servers feststellen. Denn nur der Server, der ist, wofür er sich ausgibt, wird eine gültige Unterschrift haben.

Das interesiert mich. Habe ich die o.g. Funktionalitaet in meinem Ausgangsposting treffend beschrieben?

Nein, weil der Browser und der Server nicht in Kontakt mit einer dritten Stelle stehen.

Und es ist auch problemlos möglich, ohne eine dritte Stelle eine eigene Unterschrift zu benutzen.

Zurzeit bezweifle ich diese Aussage stark.

Ganz einfach: Du kannst deine eigene Zertifizierungsstelle eröffnen. Dann spielst du beispielsweise "Thawte" oder "Verisign" in klein. Und kannst deinen eigenen SSL-Serverschlüssel unterschreiben.

Dein Zertifikat installierst du dann noch auf deinem benutzten Browser, und künftig meckert der nicht mehr darüber, dass er das Zertifikat des HTTPS-Servers seltsam findet.

Wenn du die Sicherheit aller Übermittlungskanäle sicherstellen kannst, auf denen die Zertifikate etc. übermittelt werden, dann kann dir mit sehr hoher Wahrscheinlichkeit niemand falsche Daten unterschieben.

Nun, ich habe gute Erfahrung damit gemacht bestimmte Konzept-Implementation, ja ich traue mich sogar, bestimmte Produkte zu schreiben, nachzubauen. - Z.B. DB-Replikationen oder das gute alte Sitzungskonzept. Das ist gut fuer's Verstaendnis, glaub's mir einfach mal.

Das sei dir unbenommen. Aber so, wie es sich für mich zur Zeit darstellt, willst du das Rad ein zweites Mal erfinden. Was hälst du davon, stattdessen erstmal die traditionellen Anwendungen zum Laufen zu kriegen? Also Apache mit mod_ssl (welches seinerseits OpenSSL benötigt), dann die ganze Geschichte mit den Schlüsseln und Zertifikaten etc. - da ist zum Lernen wirklich reichlich Potential, auch ohne Neuerfindungen. :) Und zum Verzweifeln, weil irgendwas nicht geht, vermutlich auch.

- Sven Rautenberg

[Lude]

Hi,

vielen Dank fuer Deine Erlaeuterungen. Dank auch an 'Peter Kaufmann'. - Mir ist die Sache etwas klarer geworden; insbesonders auch Deine Ausfuehrungen ueber SSL-Zertifikate waren fuer mich wichtig.

Das sei dir unbenommen. Aber so, wie es sich für mich zur Zeit darstellt, willst du das Rad ein zweites Mal erfinden.

Es ist natuerlich falsch das Rad immer wieder neu zu erfinden, aber die Funktionsweise des Rades zu verstehen, beispielsweise indem man dieses Tool ganz grob selbst entwickelt (besser skizziert), ist hilfreich.

Noch eine kleine Bonusfrage:
Wenn man eine Datenmenge hat, die einen fuer den Menschen sinnvollen Inhalt repraesentiert, also beispielsweise Zahlen und Woerter, und diese liegt verschluesselt vor (sagen wir mal ein 64Bit-Schluessel). Kann man mit "Brute Force" den Inhalt ermitteln? - Wie soll das gehen? - Ein Mensch kann ja bei diesem Vorhaben nicht mitwirken und man wuerde beispielsweise irgendwann "Ein Hund geht ueber die Strasse" mithilfe seines Lexikons ermitteln waehrend in Wirklichkeit "Praesident W.Bush kommt am 24.12.2003 nach Karlsruhe" gemeint war.

Gruss,
Lude

[Sven Rautenberg]

Moin!

Noch eine kleine Bonusfrage:
Wenn man eine Datenmenge hat, die einen fuer den Menschen sinnvollen Inhalt repraesentiert, also beispielsweise Zahlen und Woerter, und diese liegt verschluesselt vor (sagen wir mal ein 64Bit-Schluessel). Kann man mit "Brute Force" den Inhalt ermitteln? - Wie soll das gehen? - Ein Mensch kann ja bei diesem Vorhaben nicht mitwirken und man wuerde beispielsweise irgendwann "Ein Hund geht ueber die Strasse" mithilfe seines Lexikons ermitteln waehrend in Wirklichkeit "Praesident W.Bush kommt am 24.12.2003 nach Karlsruhe" gemeint war.

Verschlüsselungsverfahren haben in der Tat das Problem, dass ein verschlüsselter Code mit jedem angewandten Schlüssel ein Ergebnis bringen - nur ist das in den allermeisten Fällen eben eher sinnlos.

Ich wage zu behaupten, dass es, da nur eine endliche Zahl von Schlüsseln existiert, nur eine einzige entschlüsselte Version gibt, die Sinn macht.

Das kann man an einigen Merkmalen festmachen, die auch automatisiert feststellbar sind.

Text beispielsweise weist typischerweise eine charakteristische Byteverteilung auf. Beispielsweise keine 0-Bytes, wenig Bytes im Bereich 1 bis 31 (das sind alles seltene Steuerzeichen), viele Bytes im Bereich der normalen Schriftzeichen. Mit einer statistischen Analyse kriegt man schnell raus, ob das Ergebnis "Text" ist oder nicht.

Verschlüsselte Dateiformate sind auch einfach herausfindbar. Ein JPG-Bild hat eben einen gewissen Datei-Header, der aufs Byte genau stimmen muß.

Das Problem ist natürlich, dass eine verschlüsselte Bytefolge im Prinzip alles sein kann: ASCII-Text, Bild, PDF,... Das Prinzip dürfte also sein, jedes mit einem Schlüssel dekodierte Ergebnis auf bekannte Merkmale zu prüfen, und im Zweifel Alarm zu schlagen, damit ein Mensch das Resultat auf Sinnhaftigkeit prüft. Kann ja sein, dass aus einem verschlüsselten Text dekodiert tatsächlich ein gültiges, aber sinnloses JPG-Bild wird.

- Sven Rautenberg