Selbstgeschriebenes Verschluesselungsprogramm

[eggy]

@Heinz: ich versuch das mit der Statistik mal ganz einfach an nem Beispiel zu zeigen, bitte nicht alles auf die Goldwaage werfen, die Details entnimmst Du lieber der Fachliteratur aber das fürs Grundverständnis reichts erstmal folgendes zu wissen:

Eines der einfachsten Verfahren ist Rot13, das ist zwar lächerlich unsicher, aber eignet sich sehr gut um strukturelle Probleme aufzuzeigen.

Nimm nen beliebigen (eigene Muttersprache ist hier erstmal am sinnvollsten) Text, schieb ihn durch rot13 aus bsdgames und tu die Ausgabe in ne crypto.txt.
Dann erzeugst Du Dir eine Zeichenhäufigkeitstabelle mit

Code: Alles auswählen

cat crypto.txt |  fold -w1 | tr '[:upper:]' '[:lower:]'  |sort |uniq -c |sort -n 

Als nächstes "errätst" Du die Sprache in der der Plaintext geschrieben wurde (hier solltest Du schummeln und gleich richtig raten, sonst wirds nur unnötig langwierig) und suchst aus dem schlauen Tabellenbuch der Linguisten (oder der Wikipedia) die Buchstabenhäufigkeiten für die geratene Sprache heraus. Wer als Kind viel Galgenmännchen gespielt oder zuviel Glücksrad gesehen hat kann sich den Blick ins Buch wahrscheinlich auch erstmal schenken. Dann schaust Du auf die Tabelle Deines Textes und setzt "e" bei deutschem Text überall dort an die Stelle des Buchstabens der am häufigsten im Cryptotext vorkommt (in der Tabelle die Zeile mit dem Leerzeichen ignorieren, die bleiben hier Leerzeichen), dann nimmst Du den zweithäufigsten Buchstaben und setzt da mal "n" ein, alles andere ersetzt Du durch "_", durch draufsehen wirst Du jetzt (falls der Text lang genug war) einige Stellen finden, die sich gut "erraten" lassen: "e_n" könnte "ein" sein, "nenne_" z.B. Nenner. Dann gehts wieder an die Tabelle, das dritthäufigste Vorkommen kannst Du nach Buch abarbeiten, oder einfach ausprobieren, oftmal passen (bei deutschen Texten) auf den nächsten Plätzen i a r s t - in irgendeiner Reihenfolge, da hilft ausprobieren. Einsetzen, Text versuchen zu lesen, wenns klappt hast Du wohl nen Treffer, sonst anders einsetzen und nochmal testen usw.

Warum i a r s t ? Statistik, die meisten deutschen Wörter enthalten einen oder mehrere dieser Buchstaben, je häufiger der jeweilige Buchstabe in dem Ursprungstext vorkommt, desto häufiger muss auch seine "Übersetzung" im Cryptotext auftauchen.

Jetzt kann man noch klüger raten, bestimmte Buchstabenkombinationen kommen in einigen Sprachen häufiger oder garnicht vor. Du findest wahrscheinlich kein deutsches Wort mit "jzj" oder "kkk". Oder wenn Du bereits "sc_n" gefunden hast, ist es sehr wahrscheinlich, dass der fehlende Buchstabe ein h ist. Solche "Regeln" hängen jedoch direkt von der verwendeten Sprache ab, während im Deutschen ein "th" eher selten anzutreffen ist, findest Du im Englischen sehr viele Vorkommen.

Nach nen paar Runden gezieltem Probieren wirst auch Du viel vom oder den ganzen restlichen Text raten können.

Und jetzt wirst Du wahrscheinlich fragen "und was hat das mit meinem Verfahren zu tun?".
Ganz einfach, Nichts
Wobei, stimmt nicht, das ist der Anfang, den man braucht um das Problem erstmal sehen zu können - glaub ich zumindest.
Dann kannst Du hingehen und anfangen das Onetimepad zu verstehen, warum es als sicher angesehen wird und warum die Gleichverteilung dabei wichtig ist. Und dann ist der nächste Schritt zu überlegen, warum bei mehrfacher Anwendung das Ganze unsicher wird - damit erzeugst Du nämlich über Umwege genau solche "Dopplungen" wie die, die Rot 13 so einfach angreifbar machen.
Aber das steht auch alles und viel besser erklärt in den entsprechenden Fachtexten, wünsche viel Spass beim Lesen.
Bis dahin zum nicht-einschlafen https://www.youtube.com/watch?v=yxx3Bkmv3ck
und wenn das noch nicht reicht https://www.youtube.com/watch?v=pCAKq0JCcdI
Der Kanal hat übrigens sehr viele interessante Videos, nicht nur zu Enigma und Co.

[uname]

Sehr schöne Erklärung.
Du solltest auf jeden Fall das oben von mir genannte Buch kaufen, da wird auch über Caesar-Verschlüsselung (ROT), Enigma usw. erzählt.
https://de.wikipedia.org/wiki/Geheime_Botschaften

Ich nutze im übrigen ROT26, welches doppelt so sicher wie ROT13 ist
https://www2.informatik.uni-hamburg.de/ ... .php/ROT26

Oder als Webanwendung: http://www.thomas-kuehn.de/geocaching/rot.php

[whisper]

Ich möchte hier mal kurz dem Heinz einen einfachen Tipp geben.
Um zu überprüfen, ob wohl eine selbstgeschriebene Verschlüsselung etwas taugt, kann man den codierten Text (mindestens ein paar 1000 Zeilen) mit gzip, zip oder ä. packen.
Das Ergebnis dürfte in der Größe nur unwesentlich kleiner sein, als unkomprimiert.
Warum? Weil Sinn einer Verschlüsselung ein scheinbar zufälliger Haufen von Zeichen ist.
Wenn das Komprimat kleiner ist, als der unkomprimierte Code, deutet das auf eine nicht perfekte Zufällige Verteilung hin.

Mal eben schnell verifiziert:

Code: Alles auswählen

# Zufällige Bytes in Datei schreiben
dd if=/dev/urandom count=100000 bs=512 of=./random.txt
# 
cp random.txt random2.txt
 
gzip random2.txt
# Ergibt
51200000 Mai 24 14:26 random.txt
51207840 Mai 24 14:27 random2.txt.gz
Das Komprimat ist sogar größer, durch den Overhead der Komprimierung, perfekt.

[eggy]

Weil Sinn einer Verschlüsselung ein scheinbar zufälliger Haufen von Zeichen ist.

Hast Du dafür eine Quellenangabe? Ich finde die Definition nicht sehr gelungen, Sinn einer Verschlüsselung sollte doch erstmal die Unkenntlichbarmachung des Plaintextes sein, oder so ähnlich

Das Komprimat ist sogar größer, durch den Overhead der Komprimierung, perfekt.

Ich befürchte, damit tut man sich keinen Gefallen. Ich kann problemlos aus Plaintext größeren Datenhaufen erzeugen, ohne dabei irgendwas zu verschlüsseln. Beispiel: meine (nicht-)Crypto-Funktion verdoppelt jeden Buchstaben, die Datei wird größer, der Inhalt aber nicht geheimer.

[heinz]

Bitte nicht sauer sein wenn ich nicht auf alle Kommentare eingehe aber es sind einfach zu viele...

@Heinz: ich versuch das mit der Statistik mal ganz einfach an nem Beispiel zu zeigen

Vielen Dank fuer Deine ausfuehrliche Erklaerung.
Ja, Haeufigkeitsanalyse ist eine gute Methode um verschluesselten Text zu untersuchen.
Aber wie Du ja auch schon selbst geschrieben hast ist es nicht auf eine Buchverschluesselung anwendbar.

Wenn das Komprimat kleiner ist, als der unkomprimierte Code, deutet das auf eine nicht perfekte Zufällige Verteilung hin.

Ich denke ich verstehe was Du meinst.
Wenn schon ein Komprimierungsprogramm in der Lage ist regelmaessigkeiten in der verschluesselten Datei zu finden, dann kann ein "Angreifer" das sicher auch.
Danke fuer die Anregung doch leider ist es wohl nicht so leicht auf eine Buchverschluesselung anwendbar.
Das Ergebnis bei dieser Art von verschluesselung ist eine lange Liste die nur aus den Ziffern 0-9 besteht und die duerfte relativ gut zu komprimieren sein.
Trotzdem eine gute Idee die Zufaelligkeit einer Datei zu testen...

Sinn einer Verschlüsselung sollte doch erstmal die Unkenntlichbarmachung des Plaintextes sein,

Wenn die Verschluesselte Datei ein scheinbar zufälliger Haufen von Zeichen ist, ist der Plaintext dann nicht Unkenntlich?

die Datei wird größer, der Inhalt aber nicht geheimer.

Ich denke Du hast whisper falsch verstanden.
Ihm ging es nicht darum die Verschluesselung sicherer zu machen sondern die "Qualitaet" der verschluesselten Datei zu testen.


Ich habe jetzt nochmal einen grossen "Haufen" von Texten im Netz ueber dieses Thema gelesen und kann einige der Kommentare von Euch allen etwas besser verstehen. Allerdings erschliesst sich mir immernochnicht das Argument warum eine Verschluesselung mit einer mp3-Datei unsicherer sein sollte als mit einer Liste von Zufallszahlen.
Klar hat eine mp3-Datei eine bestimmte Struktur die eine Zufallsliste nicht aufweist.
Aber ich halte es weiterhin fuer unmoeglich, aus einer Reihe von Zahlen die sich nicht wiederholen auf die Art der Schluesseldatei oder sogar den Plaintext zu schliessen.

Ja, bei einer One-Time-Pad Verschluesselung ist es absolut wichtig gleichverteilt zufällige Buchstabenfolgen zu verwenden aber eine Buchverschluesselung
funktioniert ein klein wenig anders. Auch wenn das hier einige bestreiten.

Leider bin ich nicht wohlhabend genug um einen angemessenen Preis auf einen Entschluesselungsversuch zu setzen sonst wuerde ich das tun.
Nicht um aller Welt zu zeigen wie Sicher das ist sondern um mitzubekommen wie es versucht/entschluesselt wurde.

Gruss, heinz

[eggy]

Aber wie Du ja auch schon selbst geschrieben hast ist es nicht auf eine Buchverschluesselung anwendbar.

Da hast Du mich falsch verstanden. Wenn am einen Ende der "kann man die Verschlüsselung brechen"-Skala das, als sicher eingestufte, perfekte One-Time-Pad sitzt und ROT13 ziemlich am anderen Ende, bewegt sich Deine Buchverschlüsselung von der einen Seite direkt auf die andere zu, und zwar in Abhängigkeit davon, ob der zugrunde liegende "Buchtext" random ist (echten Zufall gleichverteilt in ein Buch drucken, Auswahl der Textstellen ebenfalls komplett zufällig wählen und schon hast Du nen hübsches gebundenes Onetimepad ) und ob er mehrfach verwendet wird. Dann nämlich kommen wieder statistische Hässlichkeiten der Plaintexte ins Spiel, bestimmte Kombinationen "nutzen sich stärker ab" als andere. Und ganz fix landest Du auf der anderen Seite, dicht neben Rot13.
Und selbstverständlich sind Häufigkeitsanalysen bei jeder Art von Verschlüsselung möglich, nur halt selten so einfach und Erkenntnisbringend wie im Beispiel dargestellt. Manchmal muss man die direkten Abhängigkeiten betrachten, manchmal Abhängigkeiten unter Voraussetzungen und manchmal noch schlimmer um die Ecke denken. Das für andere verständlich aufzuschreiben überlass ich aber gerne jemand anderem. Es gibt nen paar gute Statistikbücher, einige nehmen sich auch den diversen Cryptofunktionen an, weil man Verteilungen sehr schön graphisch darstellen kann. Einfach mal in der Bib durchblättern was da im Regal steht.

Zu "mp3" schau Dir mal https://blog.filippo.io/the-ecb-penguin/ an, ähnliche Effekte sind (wenn auch weniger deutlich sichtbar) auch bei vielen anderen Verfahren zu finden. Es bleibt dabei, wenn Dein Zufall eine bestimmte Struktur hat, dann findet der sich später auch im Cryptotext. Und wenn Du raten kannst, welche Struktur das war, kannst Du versuchen ihn wieder rauszurechnen, was dich dem Plaintext schon sehr viel näher bringt.

Ich denke Du hast whisper falsch verstanden.
Ihm ging es nicht darum die Verschluesselung sicherer zu machen sondern die "Qualitaet" der verschluesselten Datei zu testen.

Ich hab ihn schon richtig verstanden, ich wollte mit dem Gegenbeispiel zeigen, warum das, was er da beobachtet hat, möglicherweise oftmals zutreffend ist, man aber auch sehr leicht beweisen kann, dass es nicht zwingend stimmen muss.
Korrelation und Koinzidenz https://de.wikipedia.org/wiki/Cum_hoc_ergo_propter_hoc
Das Problem und auch der Spass bei Verschlüsselung sind, dass einem hier sehr viele hinterhältige Dinge ganz böse auf die Füsse fallen können, ohne dass man es merkt. Ist so. War so. Wird so bleiben. Beispiele gibts dazu in der Cryptohistorie auch mehr als genug.

[eggy]

@heinz: grad beim Fahrplan lesen entdeckt, falls Du die Tage in der Nähe von Karlsruhe bist:
GPN19 Samstag 13:30h https://entropia.de/GPN19:Entzifferte_Geheimnisse

[heinz]

@eggy
Das ganze scheint meinen Horizont sehr zu uebersteigen...
Ich kapiere einfach nicht wie es moeglich sein soll, wenn ich aus mehreren 1000 "A"s zufaellig 10 herauspicke, eine Haeufigkeitsanalysa zu machen.

Samstag 13:30h https://entropia.de/GPN19:Entzifferte_Geheimnisse

Danke super Tipp!

Gruss, heinz