Zitat:

---

Original geschrieben von MarkusJ
Wenn man sich von jedem Byte das niedrigste Bit (oder die beiden niedrigsten ...) nimmt und eigene Daten hineinkodiert, besteht die Möglichkeit, Daten auf diese Art und Weise zu verschlüsseln.

---

Bis jetzt hast Du nur Steganographie beschrieben, noch keine Verschlüsselung.

Zitat:

---

Es wird bei meinem Programm nicht einfach nur diese Bitebene mit Daten gefüllt, sondern man kann die Reihenfolge der Daten verändern und schon hat man eine Datei nicht nur unsichtbar, sondern auch noch verschlüsselt gemacht.

---

Naja, nur die Reihenfolge der Bits veraendern ist vielleicht nicht so eine gute Idee. Dieses Verfahren leckt bereits Information über den Klartext: das Verhältnis von 1-bits zu 0-bits wird dadurch nicht verborgen. Ausserdem: ein wichtige statische Eigenschaft guter Verschlüssler ist, dass ein 1-bit Änderung viele Bits beeinflusst, diese Eigenschaft erfüllt Dein Verfahren offensichtlich nicht. Entsprechend ist Dein Verfahren mit einer chosen plain text attack fast trivial einfach zu knacken: wenn man dem Verfahren einen Klartext mit genau einem gesetzten Bit gibt, verrät es sofort, wo dieses Bit hinpermutiert wurde. Dein Verfahren ist also mit genau so vielen gewählten Klartexten vollständig zu knacken, wie es Bits verschlüsseln kann. Man könnte dies als ein ganz primitves Beispiel differentieller Kryptanalyse ansehen, bei der man aus den Chiffrat-Unterschieden bei leicht verschiedenen Klartexten Rückschlüsse auf den Schlüssel ziehen kann. Allgemeiner: wenn man Deinem Verfahren zwei Klartexte mit genau einem unterschiedlichen Bit gibt, verrät es, wo der Unterschied hinpermutiert wird.

Zitat:

---

Wenn man CharlyMais Avatar-Bild nimmt, als BMP Speichert und darin dann Daten verschlüsselt, sind ~8,7 KB Daten (-Overhead) zu verstecken und so verschlüsslen, dass die Anzahl der Möglichen Key-Kombinationen bei 2,4388835175505556138491954862648e+21448 liegt ...

---

Wahrscheinlich hast Du diese Megazahl erhalten, indem Du die Anzahl der Permutationen 8.7k * 8 bits berechnet hast. So gewaltige Zahlen bekommt man immer, wenn man mit Permutationen arbeitet. Das Problem ist nur: wie spezifiziert man die Permutation? Die Anzahl möglicher Permutationen auf den Bytes eines 1MB grossen Files ist auch gewaltig (ich will das gar nicht erst ausrechnen), aber eine beliebige Permutation zu beschreiben ist eigentlich nur möglich, indem man sie vollständig aufschreibt. Der Schlüssel wird damit noch viel länger als der Klartext, meist ist das nicht praktikabel. Und sobald Du die Permutation kürzer beschreiben kannst, hast Du auch eine kürzere Schlüssellänge. Ausserdem: der Angriff mit gewählten Klartexten funktioniert auch hier: das Verfahren liefert den Schlüssel nach einer Million Versuchen, das entspricht einer praktischen Schlüssellänge von nur 20bit. Bei CharlyMais Avatar wären es dann noch etwa 16bit effektive Schlüssellänge.

Zitat:

---

Das schafft man mit keinem anderen Key so schnell und einfach ...

---

Das schaffst auch Du nicht so schnell und einfach

Zitat:

---

Und weil Reinhard gemeint hat, dass dieses Bildrauschen auffällig ist: Ich fülle vorher jede Ebene mit zufallsdaten, die ganze Ebene ist also voll mit Bildrauschen ... und davon dann die richtigen Bytes (man muss ja nicht jedes nutzen ...) und dann noch in der korrekten Reihenfolge ...

---

Du verlängerst damit den Schlüssel nur noch um die Information, welche Bytes genommen werden müssen. Wirklich praktikabler wird er dadurch nicht.

Auch der oben beschriebene Angriff mit gewählten Klartexten ist nicht wirklich erschwert worden. Man muss jeden 1-bit Klartext einfach mehrmals durch Dein Verfahren lassen, bis man erkennt, welche Bits zufällig sind, und welche Resultat einer Permutation des Klartextes sind.

Zitat:

---

Und vor dem Verschlüsseln wird alles noch komprimiert, was das ganze zusätzlich erschwert.

---

Was eigentlich immer beim Verschlüsseln ausser bei ganz geringen Datenmengen üblich sein sollte, um aus dem Klartext möglichst alle Redundanz zu entfernen, die im Chiffrat Rückschlüsse auf den Schlüssel geben könnte. Da man aber die Komprimierung kennt (davon sollte man immer ausgehen), kann man sich auch geeignete Klartexte basteln, die nach dem komprimieren für einen dem oben beschriebenen Angriff ähnlichen geeignet sind.

Geändert von Andreas Mueller am 30. Dezember 2005 um 00:18

Zitat:

---

Original geschrieben von Reinhard
Wenn jemand die Lösung posten möchte, dann bitte als Anhang, um nicht den anderen Threadlesern den Spaß zu verderben.

---

Im Usenet ist es üblich, in solchen Fällen rot13 zu verwenden, Cäsar-Verschlüsselung mit einer Verschiebung von 13 Zeichen. Sie hat den Vorteil, eine Involution zu sein, sie ist also ihr eigenes Entschlüsselungsverfahren. Hier ist der Unix-Befehl, mit dem man Reinhards Rätsel lösen kann, rot13 verschlüsselt:

Zitat:

---

frq -r l/NOPQRSTUVWXYZABCDEFGHIJKLM/MLKJUIHGPFEDCBONWTASQZVYXR/

---

Hallo nochmal!

@ Reinhard: Die Erklärung des Algorithmus kommt jetzt:
@ Andreas Mueller:
Entweder habe ich dich nicht verstanden, oder du mich nicht... ich erkläre nochmal meinen Algorithmus.

1. Die zu verschlüsselnde Datei wird in ihre einzelnen Bits zerlegt.
2. Der Key gibt X,Y,Farbe und Bitebene des Zielbytes an.
3. Die verwendeten Bitebenen im gesamten Bild werden mit Zufallsdaten gefüllt, damit sich hier kein Rauschen an benutzten Stellen abzeichnet.
4. An der im Key definierten Stelle wird das erste Bit aus dem Dateistream abgespeichert, die vorher vorhandene Information (Zufällig generiert), geht verloren.
5. Die nächste Stelle wird aus dem Key entnommen, dann wird das nächste Bit dort hin geschrieben.

--> Der Key ist die "Landkarte", die angibt, in welcher Reihenfolge die Bits geschrieben oder Ausgelesen werden.
Und ab diesem Augenblick ist es nich nur Stenographie, sondern auch Verschlüsselung.
Und die große Zahl an möglichen Kombinationen ergibt sich aus 2(Zustände) hoch (X*Y*GenutzteFarbe(n)*GenutzteBitEbene(n)).

mfG

Markus

PS: Wenn ich immer noch was falsches erzähle, erklärs mir bitte nochmal, danke

EDIT: Ein kleines Beispiel, welches Zeichen ist hier versteckt?

0110101011
1010101001
0101010010
0011101001
1010100010
0110110111
1000011100
0100100010
0111011101
0110111001

Lösung: 00111111=? Wie viele Möglichkeiten gibt es für dieses Zeichen? Mehr als genug!!!
Mein Key war: 7/6;3/3;2/3;10/10;5/6;7/4;2/9;10/6

Geändert von MarkusJ am 30. Dezember 2005 um 11:51

Zitat:

---

Original geschrieben von MarkusJ
2. Der Key gibt X,Y,Farbe und Bitebene des Zielbytes an.
3. Die verwendeten Bitebenen im gesamten Bild werden mit Zufallsdaten gefüllt, damit sich hier kein Rauschen an benutzten Stellen abzeichnet.
4. An der im Key definierten Stelle wird das erste Bit aus dem Dateistream abgespeichert, die vorher vorhandene Information (Zufällig generiert), geht verloren.
5. Die nächste Stelle wird aus dem Key entnommen, dann wird das nächste Bit dort hin geschrieben.

---

3. ist kein Schutz gegen Chosen Plaintext Attack oder differentielle Kryptanalyse, weil sich das Rauschen durch mehrmalige Anwendung des Algorithmus einfach wegmitteln lässt. Und selbst wenn man das nicht tut, leckt das Verfahren Information über den Klartext: das Rauschen hat statistisch gleich viele 1-Bits wie 0-bits, d.h. Dein Chiffrat hat statistisch genau so viele 1-Bits mehr/weniger wie Dein Klartext.
2., 4. und 5. beschreiben, wie Du bits permuttiert in den Output Datenstrom einsetzen willst. Da man dank der Schwäche von 3. schnell ermitteln kann, welche Bits Nutzdaten und welche Rauschen sind, bleibt nur noch die Permutation zu analysieren. Und das kann man wie vorher erklärt mit differentieller Kryptanalyse mit genauso vielen gewählten Klartexten wie Bits verschlüsselt werden sollen.
Insgesamt also ein sehr schwaches Verfahren.

HALT!
Ich habe einen wichtigen Faktor vergessen ... die statistische Annahme, dass der Anteil an 1en und 0en gleich ist, stimmt bei meinem Verfahren zum füllen der Ebene nicht.
Ich bestimme über zwei Zufallszahlen ein bestimmtes Verhältnis, welches die 1en zu den 0en haben.
Es werden dabei 10 Zufallsebenen erzeugt, bei denen ein ähnliches Verhältnis wiederum entscheidet, aus welcher der drei obigen Ebenen die Zufallsdaten entnommen werden. Wie sich das auf die Statistische Gesamtverteilung auswirkt, weis ich nicht, jedoch bin ich mir sicher, keine 50/50 zu erreichen.
Aber ich werden eine Test-Routine dafür schreiben, um das zu überprüfen

mfG

Markus

Hi,

Zitat:

---

Original geschrieben von CharlyMai

Für alle Interresierten der Verschlüsselungen von der Antike bis in die Neuzeit (PGP) kann ich nur das Buch "Geheime Botschaften" von "Simon Singh" empfehlen ....

---

Das Buch habe ich auch, kann ich nur empfehlen. Es widmet sich auch sehr viel den klassischen Verfahren. Die, und ihre Schwächen, sind viel einfacher zu durchschauen als die modernen Verfahren. Das macht die Lektüre viel interessanter.

Zitat:

---

Original geschrieben von MarkusJ

2. Der Key gibt X,Y,Farbe und Bitebene des Zielbytes an.

---

auch wenn das mit der Sicherheit nichts direkt zu tun hat: Du brauchst riesige Schlüssel um mit diesem Verfahren deine Daten zu Verschlüsseln.

Kleines Rechenbeispiel, bei dem wir wieder Pierres Avatar missbrauchen:
Wenn nur das LSB genutzt wird, ist dein Koordinatenraum schon sehr groß
X*Y*C=190*125*3=71250, d.h. du brauchst um ein einzelnes Bit zu Verschlüsseln 16,12bit + den Rechenaufwand um den Schlüssel entsprechend zu komprimieren, oder du entscheidest dich für die Performance und landest bei 32bit, was dann aber auch für Bilder im 2-3stelligen MPixel Bereich ausreicht. Du brauchst also mindestens 24bit um ein einziges bit zu Verstecken und zu Verschlüsseln.

Aber lass dich nicht entmutigen. Ein Team der deutschen Telekom (glaube ich) ist mit seinem Verfahren beim Wettbewerb der NIST zur Nachfolge des DES Algorithmus angetreten (Gewinner war dann Rijndael, jetzt bekannt als AES). Deren Vorschlag wurde auch in kurzer Zeit von den anderen Anwesenden Kryptologen "zerlegt".

Deine Chancen einen neuen (nach heutigen Maßstäben) konkurrenzfähigen Algorithmus zu entwickeln sind nun mal nicht so hoch. Aber das Bewusstsein, welche möglichen Schwächen ein Algorithmus haben kann, finde ich sehr wichtig. Es hat schon zu viele Fälle gegeben, in denen eine Eigenlösung versagt hat.

Gruß
Reinhard

Zitat:

---

Original geschrieben von MarkusJ

Wie sich das auf die Statistische Gesamtverteilung auswirkt, weis ich nicht, jedoch bin ich mir sicher, keine 50/50 zu erreichen.
Aber ich werden eine Test-Routine dafür schreiben, um das zu überprüfen

---

Das wird Dein Verfahren nicht retten. Die differentielle Kryptanalyse knackt Dein Verfahren immer, wenn Du nicht dafür sorgst, dass eine Einzelbitänderung sehr viele Chiffrat-Bits beeinflusst.
Tip: Buch von Bruce Schneier (Applied Cryptography) lesen, dann werden Dir wohl noch viele weitere Möglichkeiten aufgehen, wie man Dein Verfahren knacken kann.

Hallo Andreas

Ich habe mich zur differentiellen Krypt(o)analyse etwas schlau gelesen, mir ist aber nicht aufgegangen, inwiefern das mich betrifft.
Sowie ich es verstanden habe, wird bei diesem Verfahren ein selbstgewählter Text verschlüsselt und dann mit einem (mehren) weiteren Texten verglichen. Bei mir ist der Key aber nicht fest, d.h, wenn erwas durch mein Programm schicken will, muss er sich vorher selbst einen Key aussuchen ...
Könntest du mir den Gedanken bitte korrigieren, wenn ich daneben liegen sollte?
Danke!

mfG

Markus

EDIT: Ich hab noch ein Zitat ausm Netz:

Alle diese Verfahren einschließlich der linearen und der differenziellen Kryptoanalyse sind allerdings kaum konkret zum Brechen einer Chiffre im Sinne der klassischen Kryptoanalyse anwendbar. Sie setzen so viele bekannte Klartexte voraus, wie man in realistischen Situationen kaum je erhalten kann. Ihr Sinn liegt aber vor allem darin, sinnvolle Maße für die Sicherheit von Bitblock-Chiffren zu gewinnen. Ein solches Sicherheitsmaß ist z. B. die Anzahl bekannter Klartextblöcke, die man für einen Angriff benötigt. Chiffren, die selbst unter unrealistischen Annahmen über die Kenntnisse des Angreifers sicher sind, können als in der Praxis besonders sicher gelten.

Geändert von MarkusJ am 30. Dezember 2005 um 15:32

Zitat:

---

Original geschrieben von MarkusJ
Sowie ich es verstanden habe, wird bei diesem Verfahren ein selbstgewählter Text verschlüsselt und dann mit einem (mehren) weiteren Texten verglichen. Bei mir ist der Key aber nicht fest, d.h, wenn erwas durch mein Programm schicken will, muss er sich vorher selbst einen Key aussuchen ...

---

Fast alle Fileformate haben am Anfang irgend eine fest Magic Number, und oft folgt ein Header, in dem zum Beispiel das
Datum drin steht. Wenn man Dich also jeden Tag ein solches File übermitteln sieht, hat man gewählte Klartexte, die sich an sehr wenigen Stellen unterscheiden. Da Dein Schlüssel riesengross ist (viel grösser als die Bitzahl des Klartextes) wirst Du es Dir nicht leisten können, für jedes File einen neuen Schlüssel zu verwenden.

Zitat:

---

Alle diese Verfahren einschließlich der linearen und der differenziellen Kryptoanalyse sind allerdings kaum konkret zum Brechen einer Chiffre im Sinne der klassischen Kryptoanalyse anwendbar. Sie setzen so viele bekannte Klartexte voraus, wie man in realistischen Situationen kaum je erhalten kann. Ihr Sinn liegt aber vor allem darin, sinnvolle Maße für die Sicherheit von Bitblock-Chiffren zu gewinnen. Ein solches Sicherheitsmaß ist z. B. die Anzahl bekannter Klartextblöcke, die man für einen Angriff benötigt. Chiffren, die selbst unter unrealistischen Annahmen über die Kenntnisse des Angreifers sicher sind, können als in der Praxis besonders sicher gelten.

---

Das Zitat ist irreführend. Zum Beispiel hat man bei der Verschlüsselung von IP-Paketen genau die Situation, dass man sehr viele mehr oder weniger bekannte Klartexte mit sehr kleinen Unterschieden hat (die IP-Pakete eines TCP-Stromes unterscheiden sich eigentlich nur in der IP ID). Das Verfahren ist also sehr wohl praktikabel für die Kryptanalyse. Kommt noch dazu, dass in Deinem Fall nur sehr wenige Klartexte benötigt werden ...

Zitat:

---

Original geschrieben von Andreas Mueller

Fast alle Fileformate haben am Anfang irgend eine fest Magic Number, und oft folgt ein Header, in dem zum Beispiel das
Datum drin steht. Wenn man Dich also jeden Tag ein solches File übermitteln sieht, hat man gewählte Klartexte, die sich an sehr wenigen Stellen unterscheiden. Da Dein Schlüssel riesengross ist (viel grösser als die Bitzahl des Klartextes) wirst Du es Dir nicht leisten können, für jedes File einen neuen Schlüssel zu verwenden.

---

Das stimmt ja und ist schön und gut, aber erstens wird jede Datei erst einmal in einen Stream gepackt und dort komprimiert, was zufolge hat, dass soleche Magic Numbers schwer zu finden sein werden.
Zweitens, wie du bemerkt hast, wird der Key bei meinem Verfahren ohne optimierungen und kompressionen das 48-Fache der originaldatei groß sein.

Aber jetzt kommt der Punkt, an dem ich nicht mehr mitkomme ...
Nehmen wir mal an, ich sende zweimal eine Nachricht mit dem selben Schlüssel (der übrigens für jedes Bild und jede Datei verändert werden muss, da er nicht kleiner als die Datei sein darf ... und größer macht auch keinen Sinn, und der Schlüssel muss genau zum Bild passen ...), eine mit "Hallo" und eine mit "Salut"
Den Faktor Komprimierung lass ich jetzt mal weg ...
Dann bekommt der Empfänger einmal "Hallo", versteckt und mit Hintergrundrauschen umgeben, und einmal "Salut", ebenfalls so behandelt.
Nun ist das Hintergrundrauschen aber nicht identisch sondern wird jedesmal neu generiert.
Das heisst, der Empfänger kann jetzt versuchen, deise Datei zu entschlüsseln, ohne den Key zu kennen.
Die einzige möglichkeit, die ich sehe, ist mehrfach die selbe Datei mit dem selben Key zu verschlüsseln, dann lässt sich das Rauschen herausfiltern
Aber ansonsten ist dem Bild nichts zu entnehmen, da ich schließlich keine bekannten Klartexte mitverschicke.
Und selbst wenn ich weis, was ich Suche, so fält es mir doch schwer, die richtige Keyversion zu finden, weil ich die Bits in verschiedener Reihenfolge auslesen kann.
Mit der Anzahl der bekannten Texte fallen einige dieser Keys weg,
(Hey, hab ich jetzt das differentielle Kryptoanalyseverfahren verstanden?!),
aber es sind viele bekannten Texte nötig, um aussieben zu können ... und wenn man jeden Schlüssel nur ein- oder zweimal verwendet, sollte dieses Verfahren doch relativ sicher sein ...
Und btw: wenn man ein entsprechendes Verfahren entwickelt, einen Key aus einigen Daten zu bekommen und diese dann im Bild verschlüsselt, indiziert jedes Bild, jede verschlüsselte Datei einen neuen Key.

mfG

Markus