Hallo erstmal an alle Leser, habe aus Sommerferien-Langeweile versucht, einen Algorithmus zu entwerfen, welcher einen Text verschlüsselt, alles sehr einfach und primitiv gehalten :-] Zurzeit bin ich mit dem Erzeugen der "Rohdaten" fertig, aber jetzt habe ich ein Problem: Wie kann ich testen, ob mein Algorithmus etwas taugt, einigermaßen sicher ist? Ist hier jemand, der sich auf dem Gebiet auskennt und mir sagen kann, ob und wie sicher er ist? Kann ja mal zum Ausprobieren ein kurzes Beispiel posten: Aus einem Text mit dem Inhalt "Hallo" wird »632E2C0300D002« Dagegen aus "HAllo" -> »631A9C0300D002« Könnt euch ja mal wenn ihr Lust und Zeit habt, daran probieren :-] Danke
Jeromyo Hochgesang schrieb: > Aus einem Text mit dem Inhalt "Hallo" wird »632E2C0300D002« > Dagegen aus "HAllo" -> »631A9C0300D002« > Könnt euch ja mal wenn ihr Lust und Zeit habt, daran probieren :-] Kurze Texte sind sowieso mehr oder weniger unknackbar. Eine Verschlüsselung zu knacken beruht entweder immer irgendwie auf Statistik oder auf Glück. Und Statistik beginnt erst bei großen Zahlen zu wirken.
Danke für die schnelle Antwort! Also längeren Text hernehmen?
Hallo, man sieht bereits jetzt, dass der Algorithmus nicht sicher ist. Grund: Bei einer geringfügigen Änderung der Eingabe unterscheiden sich auch nur die Ausgaben geringfügig, das ist sehr schlecht. Warum? Nun, wenn ich jetzt den Text "63????0300D002" empfange, ist die Wahrscheinlichkeit sehr hoch, dass der Klartext "H?llo" lautet, d.h. ich kann einige Zeichen des Klartextes bestimmen. Es gibt verschiedene Sicherheitsbegriffe für Kryptographie. Einer ist zum Beispiel: Wenn ich einen Chiffretext sehe, darf ich daraus keine Informationen über den Klartext erhalten (abgesehen von der ungefähren Länge). Weil das in der Praxis aber nicht umsetzbar ist, gibt es einen abgeschwächten Begriff: Die Ausgabe des Algorithmus darf nicht von einem Zufallsgenerator unterscheidbar sein. Um deinen Algorithmus zu prüfen, kannst du folgendes Spiel spielen: Du bekommst eine Funktion vorgelegt, der du einen Wert übergeben kannst, z.B. den String "Hallo". Nun wird zufällig bestimmt, ob der Wert deinem Algorithmus oder einem Zufallsgenerator übergeben wird. Wenn du nun erraten kannst, ob der Zufallsgenerator oder dein Algorithmus dahinter steckt, ist dein Algorithmus schlecht. Bei deinem Algorithmus würde ich "Hallo" als Eingabe nehmen und schaue, ob das Ergebnis z.B. auf D002 endet. Wenn ja, ist es dein Algorithmus, ansonsten der Zufallsgenerator. Falls das in mehr als 50% der Durchläufe stimmt, ist der Algorithmus schlecht. Daraus folgt: Der Algorithmus muss definitiv Zufall beinhalten, denn sonst kann man das Spiel einfach zweimal spielen - einmal "Hallo" verschlüsseln, Ergebnis merken, nochmal spielen und schauen, ob das gleiche rauskommt. Es kann sein, dass in deinem Algorithmus gute Ideen stecken - wenn das Ergebnis aber trotzdem ist, dass "H" am Anfang immer zu "63" am Anfang der Ausgabe steht oder ähnliches, könntest du den ganzen Algorithmus auch durch eine einfache Tabelle ersetzen, das wäre sehr schlecht. In der Praxis nimmt man deshalb zusätzlich einen Betriebsmodus für den Algorithmus hinzu: http://de.wikipedia.org/wiki/Betriebsmodus_%28Kryptographie%29 Übrigens kann man auch kurze Texte knacken, hier hat das mal ein Teilnehmer gemacht und ich hab mir die Mühe gemacht, das zu knacken: Beitrag "Kryptographie Rätsel" Das gelang, obwohl es der RSA-Algorithmus war (der übrigens den obigen Sicherheitsbegriff nicht besteht, weshalb man ihn in der Praxis nur verwendet darf, wenn die Eingaben zufällig sind!). Man sollte deshalb in der Praxis nur fertige Lösungen nehmen und nichts selbst implementieren, denn es gibt so viele Fallstricke, dass es mit Sicherheit immer ein Sicherheitsproblem gibt, wenn man nicht viel Ahnung von der Materie hat.
Sehr ausführliche Antwort, danke Rüdiger! Ich denke, ich habe die Problematik erkannt, kann relativ einfach entschlüsselt werden, es war auch nur der Rohcode :-] Ich denke ich werde noch einen Schlüssel hinzufügen müssen, da damn, wie schon oben erklärt, zu einfach auf den ursprünglichen Klartext schließen kann...
Wenn ein Schlüssel im Spiel ist, kann man folgendes Experiment durchführen: Du gibst uns den Quelltext der Verschlüsselungsfunktion. Dann geben wir dir 10 Klartexte, die du mit einem von dir einmalig zufällig gewählten Schlüssel verschlüsselst - und dazu 10 Ausgaben deines Algorithmus mit dem gleichen Schlüssel, aber 10 zufällig von dir bestimmten Eingaben. Du gibst uns also 2 mal 10 Ausgaben deines Algorithmus. Wenn wir trotz Kenntnis des Quelltexts dann nicht entscheiden können, welche der beiden Gruppen mit den 10 Ausgaben die zufälligen Eingaben und welches unsere gewählten Eingaben waren, dann hängt die Sicherheit nur vom Schlüssel ab und der Algorithmus kann als gut betrachtet werden (oder wir als schlecht :-) Die Sicherheit darf also nur vom Schlüssel abhängen, selbst wenn das ganze Verfahren offen und bekannt ist.
Ein netter Test von längeren Verschlüsselungsergebnissen ist das Anhören (einfach als 8Bit signed/unsigned mono laden) mit verschiedenen Eingabedaten (Konstant, Aufsteigend, Raster, ...). Wenn im Ausgangssignal (ausser dem Loopen) irgendeine Struktur hörbar ist (Rattern, Pfeiffen, etc.) taugt es nicht ;) Es muss einfach nur Rauschen.
Wow, richtige Resonanz da! Den Quelltext kann ich im Moment noch nicht rausgeben, da unvollständig ;) Aber ich habe einmal einen Schlüssel auf den Text "Hallo" angewendet, statt »632E2C0300D002« bekomme ich als Ausgabe »^@aØo(^[«. Und die Anzahl der Möglichkeiten der Verschlüsselung ist "AnzahlZeichenUsrpungstext"!, also bei diesem kurzen Text "nur" 120 Möglichkeiten für den Schlüssel, bei einem Text mit 20 Zeichen allerdings schon 2.4x10^18 Möglichkeiten :-] Ich habe mit »632..« ja nur die Rohdaten herausgegeben, der Schlüssel vertauscht die Positionen der bytegroßen "Pakete, durch Entschlüsseln mit Wechseln von verschiedenen Zahlensystem(z.B. von 8Bit auf 5, es könnte 63.2E in 632.E umgewandelt und mit diesem Wert weitergerechnet werden, dadurch kommt es absolut auf die Position der Pakete an) kommt zwar bei jeder Eingabe etwas heraus, allerdings nur Schwachsinn, siehe oben :-]
Ok, kurz zur Erklärung: Ursprünglich war der Rohcode 63.2E... Der Schlüssel vertauscht die Position der Pakete auf eine bestimmte Art&Weise: 2E.63... Jetzt wird der "Punkt" verschoben, also 12 Bit statt 8 Bit verwendet: (Ursprünglich wäre es jetzt 632.E2C...) Nach dem Vertauschen der Positionen: 2E6.32?... Da jedes der 12 Bit Pakete individuell behandelt wird, kommt es sehr auf die Position der Pakete in den Rohcode an, und es gibt ja unglaublich viele Möglichkeiten (außer bei sehr kurzen Texten), die Pakete anzuordnen
Dann kann man dem verschlüsselten Text ansehen, wie viele 1-Bits der Klartext hat, oder? Und 0 wird immer auf 0 abgebildet. Beides wäre eine Schwäche im Rahmen der oben erklärten Sicherheit, denn ein Zufallsgenerator würde bei 0 als Eingabe nur mit sehr kleiner Wahrscheinlichkeit 0 als Ausgabe liefern, dein Verfahren jedoch immer. Du brauchst also zusätzlich noch etwas, das die Bits "kippt", um die Anzahl der 1- und 0-Bits zu verändern. Edit: Achso, das ist nur ein zusätzliches Verfahren nach dem Anwenden der eigentlichen Verschlüsselung - OK.
@Rüdiger, du bist ja echt ein Profi! Kannst du mir einen Tipp geben, wie ich das "0-Eigabe Problem" lösen kann? Eine Pseudozahl zufälliger Länge an jeden Code anhängen und ihn mit verschlüsseln?
Rüdiger Meinhard schrieb: > Übrigens kann man auch kurze Texte knacken, hier hat das mal ein > Teilnehmer gemacht und ich hab mir die Mühe gemacht, das zu knacken: > Beitrag "Kryptographie Rätsel" Du hattest da aber auch Hilfe. Durch die 'Form' Der Schlüssel hast du auf RSA-Verschlüsselung getippt und das ist schon mal ganz schön viel. Ist die Art des Verschlüsselungsverfahrens nicht bekannt, dann wird das ganze gleich ein paar Nummern schwieriger. So gibt es einige verschlüsselte Texte in der Weltgeschichte, die sich bis heute einer erfolgreichern Entschlüsselung hartnäckig widersetzen, obwohl anzunehmen ist, dass die Verschlüsselung bei weitem nicht so raffiniert bzw. mathematisch aufwändig wie eine RSA-Verschlüsselung ist. Einige interessante Fälle zeigt Klaus Schmeh zb hier http://scienceblogs.de/klausis-krypto-kolumne/
Die meisten Algorithmen haben dazu eine feste Substitutionstabelle, d.h. die Datenblöcke werden fest auf andere Datenblöcke abgebildet. Also bei dir könnte jedes 8-Bit-Wort vor dem eigentlichen Verfahren erstmal auf andere 8-Bit-Worte abgebildet werden. Also ungefähr so: Verschlüsselung(Eingabe, Schlüssel): - teile Eingabe in 8-Bit-Blöcke - bilde den ersten 8-Bit-Block mit Tabelle auf anderen Wert ab - vertausche die Positionen der Blöcke oder der Bits darin nach deinem Verfahren - addiere den Schlüssel per XOR - berechne aus dem Schlüssel einen neuen Schlüssel (damit das XOR nicht für jeden Block gleich ist) - wiederhole das ganze mehrfach, z.B. 32 Runden
Jeromyo Hochgesang schrieb: > Ich habe mit »632..« ja nur die Rohdaten herausgegeben, der Schlüssel > vertauscht die Positionen der bytegroßen "Pakete Vielleicht solltest du dir doch mal ansehen, wie DES, oder AES das machen. So ins Blaue hinein einen Verschlüsselungsalgorithmus zu basteln, ist keine gute Idee, wenn es was Ernsthaftes werden soll.
Karl Heinz: Das stimmt natürlich :-) Falls jemand solche Rätsel mag, aber gerne lösbare haben möchte - in unserem Institut werden ab und zu mal Geheimschriften angeliefert, die Leute beim Anschauen geerbter Sachen finden. Das sind dann ganz reale Geheimschriften, die zusätzliche Spannung beim Entziffern bieten, weil die Anwender Fehler machen können usw. Im Anhang mal eine alte Postkarte und alle Details, die wir rausgefunden haben. Wir nehmen sowas einfach als Übungsaufgabe für die Kryptographie-Vorlesung, in diesem Fall haben einige Studenten den Text entziffert, es ist also machbar :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.