Codebrecher gesucht...
- Ersteller CyberOp
- Erstellt am
Hallo zusammen,
hab vor einiger Zeit ein Programm geschrieben (in Java) mit dem man einen Text verschlüsseln kann.
Ich geh nicht davon aus, das es unschlag bar ist, dennoch würde mich es interessieren
wie sicher es ist.
Würde mich freuen, wenn sich der eine oder andere es sich mal anschaut
und mir etwas dazu sagen kann. Das Proggy ist keineswegs auf Geschwindigkeit
ausgelegt
Es ist mehr gedacht gewesen zu zeigen, das man einen Text verschlüsseln kann und der Crypt-Text immer anders aussieht.
Viel Spaß bei hacken
hab vor einiger Zeit ein Programm geschrieben (in Java) mit dem man einen Text verschlüsseln kann.
Ich geh nicht davon aus, das es unschlag bar ist, dennoch würde mich es interessieren
wie sicher es ist.
Würde mich freuen, wenn sich der eine oder andere es sich mal anschaut
und mir etwas dazu sagen kann. Das Proggy ist keineswegs auf Geschwindigkeit
ausgelegt
Es ist mehr gedacht gewesen zu zeigen, das man einen Text verschlüsseln kann und der Crypt-Text immer anders aussieht.Viel Spaß bei hacken
Also gut... 
Aus dem Passwort wird ein HASH-Wert erzeugt. Dieser Wert besteht aus Zahlen.
(Ich nehme an, das das schon die erste Schwachstelle ist. Könnte man aber in einer neueren Version auch aus was anderem generieren.)
Dann gibt es 10x256 Zeichen. Soll bedeuten, das für jede Zahl 0 bis 9 eine eigene Tabelle existiert. In jeder dieser Tabellen wird jeder Buchstabe einer 7stelligen Binärzahl zugewiesen. Diese Zuordnung geschah völlig zufällig und ist aber immer gleich.
Jetzt wird es etwas kompliziert:
Man nimmt den ersten Buchstaben des Klartextes und die erste Zahl des HASH-Wertes.
Geht in die Tabelle mit der Nummer des HASH-Wertes und gibt den 7stelligen Binärcode des entsprechenden Buchstaben zurück. usw. Wenn HASH-Wert am ende, fange von vorne an...
Nun hat man ein schönes buntes Durcheinander von einsen und nullen.
Nun wird per Zufallsgenerator alles andere, was nicht 1 oder 0 ist zur "verwirrung" reingestreut.
Jetzt sieht es ja schon recht gut aus. Reicht aber noch nicht.
Nun wiederholt sich das ganze, je nach stärke der verschlüsselung (im Programm angebbar). Ausgangstext ist nun der Pseudo-Crypttext. Da der nun Zufällig generierte Buchstaben enthält und an immer wieder anderen Stellen (Die für das entschlüsseln aber keine Rolle spielen) entsteht daraus auch wieder ein völlig anderer Pseudo-Crypttext.
usw.
2 Anmerkungen:
1. Entschlüsseln funktioniert so:
Nimm Crypttext und schmeiss erst mal alles weg, was nicht 1 oder 0 ist.
Dann mittels Passwort den HASH-Wert erzeugen und entschlüsseln. Diesen Crypttext wieder "säubern" und wieder entschlüsseln. usw, je nach stärke.
2. Es können mehrere unterschiedliche Passwörter für einen Text verwendet werden.
Soll bedeuten, das man angeben kann, das beim ersten verschlüsseln Passwort 1 benutzt, bei zweiten verschlüsseln Passwort 2, usw.
Somit muss man beim Entschlüsseln nicht nur die Passwörter kennen, sondern auch deren Reihenfolge, wie sie beim Verschlüsseln angegeben wurden.
Ach ja. Noch was. Ich glaube das Programm hat ein Speicherleck. Wenn ich mich recht erinnere, braucht es bei einer sehr starken Verschlüsselnung unheimlich viel Zeit und Speicher![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Wer den Fehler Findet darf ihn behalten und gerne optimieren.
Aus dem Passwort wird ein HASH-Wert erzeugt. Dieser Wert besteht aus Zahlen.
(Ich nehme an, das das schon die erste Schwachstelle ist. Könnte man aber in einer neueren Version auch aus was anderem generieren.)
Dann gibt es 10x256 Zeichen. Soll bedeuten, das für jede Zahl 0 bis 9 eine eigene Tabelle existiert. In jeder dieser Tabellen wird jeder Buchstabe einer 7stelligen Binärzahl zugewiesen. Diese Zuordnung geschah völlig zufällig und ist aber immer gleich.
Jetzt wird es etwas kompliziert:
Man nimmt den ersten Buchstaben des Klartextes und die erste Zahl des HASH-Wertes.
Geht in die Tabelle mit der Nummer des HASH-Wertes und gibt den 7stelligen Binärcode des entsprechenden Buchstaben zurück. usw. Wenn HASH-Wert am ende, fange von vorne an...
Nun hat man ein schönes buntes Durcheinander von einsen und nullen.
Nun wird per Zufallsgenerator alles andere, was nicht 1 oder 0 ist zur "verwirrung" reingestreut.
Jetzt sieht es ja schon recht gut aus. Reicht aber noch nicht.
Nun wiederholt sich das ganze, je nach stärke der verschlüsselung (im Programm angebbar). Ausgangstext ist nun der Pseudo-Crypttext. Da der nun Zufällig generierte Buchstaben enthält und an immer wieder anderen Stellen (Die für das entschlüsseln aber keine Rolle spielen) entsteht daraus auch wieder ein völlig anderer Pseudo-Crypttext.
usw.
2 Anmerkungen:
1. Entschlüsseln funktioniert so:
Nimm Crypttext und schmeiss erst mal alles weg, was nicht 1 oder 0 ist.
Dann mittels Passwort den HASH-Wert erzeugen und entschlüsseln. Diesen Crypttext wieder "säubern" und wieder entschlüsseln. usw, je nach stärke.
2. Es können mehrere unterschiedliche Passwörter für einen Text verwendet werden.
Soll bedeuten, das man angeben kann, das beim ersten verschlüsseln Passwort 1 benutzt, bei zweiten verschlüsseln Passwort 2, usw.
Somit muss man beim Entschlüsseln nicht nur die Passwörter kennen, sondern auch deren Reihenfolge, wie sie beim Verschlüsseln angegeben wurden.
Ach ja. Noch was. Ich glaube das Programm hat ein Speicherleck. Wenn ich mich recht erinnere, braucht es bei einer sehr starken Verschlüsselnung unheimlich viel Zeit und Speicher
Wer den Fehler Findet darf ihn behalten und gerne optimieren.
Hmm. Schreib mal dazu, auf welche Basis du dich jeweils beziehst (hex, dez, bin).
Wenn du 256 Zeichen auf 7Bit Zahlen mappst bekommst du doch da nicht mehr die 256 Zeichen zurück, weil die 7Bit nur 128 verschiedene Möglichkeiten darstellen können.
Wieviel Bit hat dein Hash eigentlich? Ich würd da der Sicherheit wegen eine der üblichen Hash-Routinen nehmen, also zB. SHA256 oder sowas.
Hmm ich denk ich hab's verstanden. Der Alg setzt unter dem Aspekt natürlich ziemlich stark darauf, dass der Angreifer ihn eben nicht kennt. Dein Prog kannst du ja aber net verschlüsseln, denn das brauchst du ja eben um die Sachen zu entschlüsseln
.
Bei einer 1fachen Verschlüsselung dürfte eine Plaintext-Attacke recht schnell zum Schlüssel führen. Plaintext heist, dass du eine gewisse Anzahl an Bytes des entschlüsselten Textes kennst. Also wenn du da zB. eine ext2 Partition durchjagst, dann sieht der 1. Sektor fast immer gleich aus - bei einer Hashlänge von x Bytes würden x Bytes zusammenhängender Klartext reichen, um den Schlüssel zu rekonstruieren (wenn die Tabellen bekannt sind, aber die gehören ja zum Alg).
Eine Häufigkeitsanalyse ist nicht ganz so einfach, weil du ja 10 Tabellen hast, und es demnach 10 sich überlagernde Verteilungsmuster gibt. Andererseits kann man, wenn die Hash-Länge bekannt ist, zB. nur jedes 20. Zeichen (wenn Hash-Länge = 20) in die Analyse einbeziehen, weil da jeweils die selbe Tabelle zum Tragen kommt.
Den Hash könnte man auch über den Vergleich der Häufigkeitsanalysen herausfinden. Die Tabellen selbst sind ja bekannt, also wenn bei jedem Hashlänge*n+0 Zeichen meinentwegen der Zeichencode 0xa8 besonders oft auftritt und bei jedem Hashlänge*n+1 Zeichen zB. 0x12, dann werden dahinter die selben Ausgangszeichen stehen. Also durchsucht man die Tabellen, hat man 2 gefunden wo 0xa8 bei der einen und 0x12 der anderen auf das selbe Zeichen zeigen werden das wohl die vom Hash benutzten Tabellen sein.
Das ist eine ziemliche Schwachstelle, die eben gerade erst durch die Tabellen zustande kommt.
Naja... war ja doch etwas ausführlicher. Ich denke ab ~160kb Größe des zu
verschlüsselnden Textes reicht eine einfache Häufigkeitsanalyse, um auf den Hash zu kommen.
Morgen guck ich mir mal eine mehrfache Verschlüsselung an.
Wenn du 256 Zeichen auf 7Bit Zahlen mappst bekommst du doch da nicht mehr die 256 Zeichen zurück, weil die 7Bit nur 128 verschiedene Möglichkeiten darstellen können.
Wieviel Bit hat dein Hash eigentlich? Ich würd da der Sicherheit wegen eine der üblichen Hash-Routinen nehmen, also zB. SHA256 oder sowas.
Hmm ich denk ich hab's verstanden. Der Alg setzt unter dem Aspekt natürlich ziemlich stark darauf, dass der Angreifer ihn eben nicht kennt. Dein Prog kannst du ja aber net verschlüsseln, denn das brauchst du ja eben um die Sachen zu entschlüsseln
. Bei einer 1fachen Verschlüsselung dürfte eine Plaintext-Attacke recht schnell zum Schlüssel führen. Plaintext heist, dass du eine gewisse Anzahl an Bytes des entschlüsselten Textes kennst. Also wenn du da zB. eine ext2 Partition durchjagst, dann sieht der 1. Sektor fast immer gleich aus - bei einer Hashlänge von x Bytes würden x Bytes zusammenhängender Klartext reichen, um den Schlüssel zu rekonstruieren (wenn die Tabellen bekannt sind, aber die gehören ja zum Alg).
Eine Häufigkeitsanalyse ist nicht ganz so einfach, weil du ja 10 Tabellen hast, und es demnach 10 sich überlagernde Verteilungsmuster gibt. Andererseits kann man, wenn die Hash-Länge bekannt ist, zB. nur jedes 20. Zeichen (wenn Hash-Länge = 20) in die Analyse einbeziehen, weil da jeweils die selbe Tabelle zum Tragen kommt.
Den Hash könnte man auch über den Vergleich der Häufigkeitsanalysen herausfinden. Die Tabellen selbst sind ja bekannt, also wenn bei jedem Hashlänge*n+0 Zeichen meinentwegen der Zeichencode 0xa8 besonders oft auftritt und bei jedem Hashlänge*n+1 Zeichen zB. 0x12, dann werden dahinter die selben Ausgangszeichen stehen. Also durchsucht man die Tabellen, hat man 2 gefunden wo 0xa8 bei der einen und 0x12 der anderen auf das selbe Zeichen zeigen werden das wohl die vom Hash benutzten Tabellen sein.
Das ist eine ziemliche Schwachstelle, die eben gerade erst durch die Tabellen zustande kommt.
Naja... war ja doch etwas ausführlicher
. Ich denke ab ~160kb Größe des zu verschlüsselnden Textes reicht eine einfache Häufigkeitsanalyse, um auf den Hash zu kommen.
Morgen guck ich mir mal eine mehrfache Verschlüsselung an.
Hi,
Sorry, das ich mich so lange nicht gemeldet habe, aber ich hatte unheimlich zu tun...
Ja, OK. Danke für die Tipps. Das die einfache Verschlüsselung leicht zu knacken ist habe ich mir schon gedacht.
Ich denke aber das gerade die mehrfache Verschlüsselung etwas sicherer ist.
Bin auf deine Analyse gespannt
Sorry, das ich mich so lange nicht gemeldet habe, aber ich hatte unheimlich zu tun...
Ja, OK. Danke für die Tipps. Das die einfache Verschlüsselung leicht zu knacken ist habe ich mir schon gedacht.
Ich denke aber das gerade die mehrfache Verschlüsselung etwas sicherer ist.
Bin auf deine Analyse gespannt
dge
Cadet
- Mitglied seit
- 13.06.2005
- Beiträge
- 8
- Renomée
- 0
CyberOp schrieb:
Mehrfaches Substitutions-Chiffre. Das Knacken des solchen wurde schon erfolgreich im alten Rom durchgeführt
. Somit hast du auch mit den typischen Mängeln dieser zu kämpfen. Bei der mehrfachen Verschlüsselung ziehst du deinen Text durch das Einfügen der Buchstaben nur weiter auseinander, die Häufigkeiten bleiben aber erhalten. Z.B.: Esel -> Exxsxexl -> yEyxxsxyyexl -> ...
Und du kannst ja nicht einfach ein "e" (z.B. 1010101) einstreuen, da das deinen Algorithmus kaputt machen würde bzw. der Klartext nicht wiedergewonnen werden kann.
Desweiteren dürfen die eingefügten Zeichen NICHT 0 oder 1 sein. Das ist das Hauptproblem bei der erneuten Verschlüsselung. Dort werden gültige Zeichen {0,1} in deiner Mapping Tabelle nur auf die Spalten der Zeichen 0 und 1 "gemapped". Alles andere ist per Definition beim zweiten Durchgang "eingestreut".
Wie schon von i_hasser erläutert: Bei einem entsprechend langen Text dürfte das Knacken recht schnell gehen. Bei einem zu kurzen Text musst du zu viele nicht benötigte Zeichen einstreuen.
Das Hash-Generieren zu Anfang kannst du Dir IMO sparen. Der Hash wird nur verwendet um das Mapping zu erstellen was ebenso durch das Passwort geschehen könnte (ok, nicht jeder will vielleicht 160 Bit eingeben).
Der Hash ist gut für Algorithmen, wo man eine bestimmte Länge des Keywords braucht. AES ist zB. gängig mit 128 Bit, 192 Bit und 256 Bit. Eine 23 Zeichen Passphrase mit ihren 184 Bit passt da zB. schlecht rein.
Wenn man den Hash manuell vorgeben kann, ist das auch noch eine Möglichkeit die Sache schwieriger zu machen (vor allem Dictionary Attacks). Niemand ist so blöd und versucht was direkt über den Key zu entschlüsseln, wenn das vorher gehashed wurde. Wenn man sich über ein Dictionary an der Passphrase versucht, muss man aber wissen welcher Hash Algorithmus zum Einsatz kam. Oft wird auch mehrmals hintereinander gehashed.
Wie so oft ist das aber nix, was sich nicht herausbekommen ließe - ein sicheres Passwort ist das A und O.
Wenn man den Hash manuell vorgeben kann, ist das auch noch eine Möglichkeit die Sache schwieriger zu machen (vor allem Dictionary Attacks). Niemand ist so blöd und versucht was direkt über den Key zu entschlüsseln, wenn das vorher gehashed wurde. Wenn man sich über ein Dictionary an der Passphrase versucht, muss man aber wissen welcher Hash Algorithmus zum Einsatz kam. Oft wird auch mehrmals hintereinander gehashed.
Wie so oft ist das aber nix, was sich nicht herausbekommen ließe - ein sicheres Passwort ist das A und O.
CyberOp schrieb:
Wenn ich deine Beschreibung richtig verstanden habe, ist das hier deine eigentliche Verschlüsselung.
Du hast zehn Tabellen, welche jeweils eine andere Zuordnung deiner Klartextzeichen enthalten. Zu den Werten aus diesen Tabellen kommst du mit der aktuellen Ziffer des Hashwertes und ersetzt dann einfach dein Kalrtextzeichen durch eine siebenstellige Folge von "0" und "1".
Gratulation - du hast gerade die Vigenère-Verschlüsselung neu erfunden.
Zum knacken von Vigenère gibt es genügend erfolgreiche und auch effiziente Methoden.
Wo ist hier etwas kompliziert?CyberOp schrieb:
Hä, 'abcd...' sollen zwischen den Informationsträgern "0" und "1" Verwirrung stiftenCyberOp schrieb:
Ist letztenendes nutzlos und vergößert nur dein Chiffrat (siehe dge). Mit etwas Motivation ist es höchstens eine Fleißfrage, den Text soweit zu entschlüsseln bis nicht mehr überproportional "0" und "1" auftaucht.CyberOp schrieb:
Wenn ich jetzt nicht alles verpeilt habe (nehme wohlgemeinte "Kritik" in dem Fall zurück), solltest du diese Eigenentwicklung schnellstens in der virtuellen Schublade verschwinden lassen und dir etwas Paperware zu Gemüte führen (Singh ließt sich sehr angenehm und auch für Nichtmathematiker verständlich).
Ziemlich einfach müsste sich sowas implementieren lassen: Der Klartext wird in xyz Byte Blöcke unterteilt, und innerhalb ieser Blöcke findet auch eine Neupositionierung statt. Die Blöcke werden nacheinander verschlüsselt, und der Schlüssel für einen Block ergibt sich unter anderem aus dem Hash des vorherigen Blocks (meinentwegen macht man das in einer Kette von 64 Blöcken, dann wird wieder der Hash des Passworts verwendet).
Macht Plaintext Attacken fast unmöglich (man weis idR nicht wo der verschlüsselte Text steht, man weis nicht mit welchen Hash er verschlüsselt wurde, da man die vorherigen Blöcke nicht kennt), und dürfte auch sonst relativ schwer zu knacken sein.
Wenn man noch Zeit und Lust hat, kann man die Hashberechnung innerhalb einer 64 Blöcke Kette nicht einfach der Reihe nach durch machen, sondern sagen wir abhängig von der letzten 64 Blöcken abhängig machen. Selbst wenn man bei 512Byte Blöcken 32kB Plaintext am Stück hat, ließe sich die Verschlüsselung damit nicht knacken (man kennt den Hash der vorherigen 64 Blöcke nicht).
Macht Plaintext Attacken fast unmöglich (man weis idR nicht wo der verschlüsselte Text steht, man weis nicht mit welchen Hash er verschlüsselt wurde, da man die vorherigen Blöcke nicht kennt), und dürfte auch sonst relativ schwer zu knacken sein.
Wenn man noch Zeit und Lust hat, kann man die Hashberechnung innerhalb einer 64 Blöcke Kette nicht einfach der Reihe nach durch machen, sondern sagen wir abhängig von der letzten 64 Blöcken abhängig machen. Selbst wenn man bei 512Byte Blöcken 32kB Plaintext am Stück hat, ließe sich die Verschlüsselung damit nicht knacken (man kennt den Hash der vorherigen 64 Blöcke nicht).
Ähnliche Themen
