Text entschlüsseln, Algorithmus nur teilweise bekannt

[Björn Ole]

Zu so später Stunde noch tippen, na mal schauen ob das was wird...


Ich versuche mich daran, einen Text zu entschlüsseln, welcher mit Hilfe des Programms "Encryption and Decrpytion 3.0" verschlüsselt wurde. Folgende Infos gibt die Webseite preis: AES 256 zur Datenver/entschlüsselung, SHA 256 als Hash-Algorithmus für das Passwort. Mehrfaches verschlüsseln ein und desselben Textes mit dem gleichen Passwort bringt komplett unterschiedliche Ergebnisse.

Nun, hier ein Beispiel:

Zu verschlüsselnder Text: Test
Passwort: GEHEIM
Resultat: FC343FC9164CE283FC08C9A12EEEBB26A3E0E31C5C4909A130 BD075A730F6BD2336C6F329BAA84E8F9AE531EC2CF8B75E882 420BC792CB351860CD7276FF149E4080*5590*1*28*tBuSGDvX7y5+3vorzrFiK1rAU8rO1X2Jg6Do8Q0mwMo=

Die Sterne sind anscheinend Trennzeichen, das Ergebnis besteht also aus folgenden Teilen:

1. FC343...4080 - UpperCase HEX, höchstwahrscheinlich die verschlüsselten Hauptdaten
2. 5590 - bin ich ratlos, scheint eine zufällige Zahl zu sein, allerdings immer 4- oder 5-stellig
3. 1 - Anzahl an Verschlüsselungen. Wird dreimal hintereinander verschlüsselt, steht hier also eine 3
4. 28 - diese Zahl ergibt sich aus der Länge des Textes, der verschlüsselt werden soll: 31 - ((Textlänge-1) mod 32), hier also 31 - ((4-1) mod 32) = 31 - (3 mod 32) = 31 - 3 = 28
5. tBu...Mo= - anscheinend Base64 kodiert, ebenfalls ratlos

Mit dem DEC hab ich schon ein wenig rumgebastelt, vielleicht bekomme ich morgen einen postbaren Versuch hin.

Gibt es hier allgemein Hoffnung, darauf zu kommen und den Algorithmus nachzubauen, oder soll ich es lieber gleich sein lassen? Ich bin nicht so der Experte auf dem Gebiet, darum hoffe ich auf ein paar Meinungen von euch.


Gruß und gute Nacht, Björn.

[cookie22]

Zitat:

Mehrfaches verschlüsseln ein und desselben Textes mit dem gleichen Passwort bringt komplett unterschiedliche Ergebnisse.

Ja, weil das Programm offensichtlich Random Salts und/oder Ivs benutzt. Die werden wohl im Header der Datei stehen. Deine 2. wird eins davon sein. Deine 5. könnte die Hashsumme des Passwortes sein.

Hast du denn das Passwort? Wenn ja dann benutz doch einfach das besagte Programm, das ist doch Freeware. Welchen Sinn macht es das nachzubauen.

[himitsu]

Das erinnert mich irgendwie an die berühmte Vollbitverschlüsselung. :stupid:

- Sicherheit durch Unwissenheit :shock:
> unser Hagen würde wohl sowas sagen "Sicher ist das was man kennt und es dennoch beweisbar nicht/nur schwer knacken kann"

- Mehrfachverschlüsselung bringt auch keinen Mehrgewinn an Sicherheit.
> wenn ich Hagen richtig verstanden hab, dann könnte das teilweise sogar Gegenteilig ausfallen.
> abgesehn davon, daß hier eh nur die selbe Verschlüsselung wiederholt wird und das Wieoft sogar erkenntlich ist ... also vollkommen nutzlos



Die erste große Frage bleibt also erstmal im Raum stehen:
Warum unbedingt diese Art der Verschlüsselung und wenn ja, warum nicht direkt mit diesem Programm?

[Deep-Sea]

Zitat:

Zitat von cookie22 (Beitrag 1083375)

Deine 5. könnte die Hashsumme des Passwortes sein.

Aber wieso sollte man die da rein packen? I.d.R. läuft es doch so: Über das Passwort und den Salt wird der Hash berechnet, der als Schlüssel für die Verschlüsselung dient. Den Hash also mit rein zu packen ist nicht nur sinnlos, sondern würde sogar den Schlüssel verraten :stupid:

[cookie22]

Zitat:

Zitat von Deep-Sea (Beitrag 1083385)

Zitat:

Zitat von cookie22 (Beitrag 1083375)

Deine 5. könnte die Hashsumme des Passwortes sein.

Aber wieso sollte man die da rein packen? I.d.R. läuft es doch so: Über das Passwort und den Salt wird der Hash berechnet, der als Schlüssel für die Verschlüsselung dient. Den Hash also mit rein zu packen ist nicht nur sinnlos, sondern würde sogar den Schlüssel verraten :stupid:

Nein würde er nicht, denn Sha-256 ist kryptographisch sicher und durch die Hashsumme kann nicht auf das Passwort geschlossen werden. Schreibst du den Hash nicht, bzw. einen aussagekräftigen teil davon, in den Header, hast du keine Möglichkeit das Passwort auf Richtigkeit zu überprüfen. Du musst dann die Datei vollständig mit dem falschen Passwort entschlüsseln, um festzustellen ob es richtig ist oder nicht. Bei großen Dateien ist das wohl kaum praktikabel. :wink:

[Deep-Sea]

Sofern man DEN Hash auch als Schlüssel nutzt, würde man es schon.
Um schnell prüfen zu können, ob das Entschlüsselte stimmt, kann man ja einen ebenfalls mitverschlüsselten Header vor die Daten schreiben.
Viele Archivformate arbeiten aber trotzdem nach dieser "kaum praktikabel" Methode - man erhält oft erst am Ende den Fehler "Prüfsumme falsch", wenn man das Passwort falsch angegeben hat. So hat man auch gleich den Schutz vor Bruteforce-Attacken erhöht ^^
Im Endeffekt ist es aber trotzdem nur rumgerate, da wir ja nicht wissen wie die besagte Software arbeitet.

[himitsu]

Wenn man den Hash des Passwortes kennt, dann kann man den Angriff erstmal auf diesen kleinen Hash auslegen
und muß dann nur noch wenige Male die großen Daten versuchen zu entschlüsseln.

veschlüsselte Daten und den Passworthash könnte man auch noch in Beziehung setzen und hätte somit ein leichteres Angriffsziel, da man diese Daten gegeneinander verifizieren könnte.

[cookie22]

Zitat:

Zitat von Deep-Sea (Beitrag 1083401)

Sofern man DEN Hash auch als Schlüssel nutzt, würde man es schon.
Um schnell prüfen zu können, ob das Entschlüsselte stimmt, kann man ja einen ebenfalls mitverschlüsselten Header vor die Daten schreiben.
Viele Archivformate arbeiten aber trotzdem nach dieser "kaum praktikabel" Methode - man erhält oft erst am Ende den Fehler "Prüfsumme falsch", wenn man das Passwort falsch angegeben hat. So hat man auch gleich den Schutz vor Bruteforce-Attacken erhöht ^^
Im Endeffekt ist es aber trotzdem nur rumgerate, da wir ja nicht wissen wie die besagte Software arbeitet.

Wenn dieser Header immer gleich ist, lieferst du damit bekannten Text. Das ist ein gutes Ziel für einen Angriff. Man nennt diesen Angriff, "Known Plaintext Attack". Wenn man davon ausgeht, dass der Header klein ist, ist das sicher nicht sonderlich schlimm, aber gut ist das auch nicht. Wenn dein Schlüssel mittels Zufalls Salt und Key Derivation Funktion erzeugt wurde, spricht nichts dagegen den Hash in den Header zu schreiben. Allerdings reicht es ja schon ihn nur teilweise dort rein zuschreiben.

[Deep-Sea]

Zitat:

Zitat von cookie22 (Beitrag 1083449)

Man nennt diesen Angriff, "Known Plaintext Attack".

Kann es sein, dass du mich für total dumm hältst? So komm ich mir zumindest gerade vor.
Der Header muss ja nicht aus fixen Daten bestehen. Denn das hinzufügen des Passwortes als Hash bringt eben weitere Probleme mit sich, wie himitsu bereits sagte. Und man muss eben zwei verschiedene Key derivation functions haben - einmal für die Verschlüsselung und einmal für den Passwort-Hash ...
Und wie gesagt, kann es ja gewollt sein, dass man erst am Ende der Entschlüsselung merkt, dass etwas nicht stimmt - das verlangsamt auf natürliche Weise Bruteforce-Angriffe (sofern natürlich kein known plaintext am Anfang vorliegt. Aber so ziemlich jedes komplexere Format als eine Textdatei hat einen Header mit einem oft fixen Wert - der nennt sich "magic number" :P).

[cookie22]

Zitat:

Zitat von Deep-Sea (Beitrag 1083457)

Kann es sein, dass du mich für total dumm hältst?

Wenn ich dich für dumm halten würde, würde ich hier nichts posten. ;)

Zitat:

Zitat von Deep-Sea (Beitrag 1083457)

Und man muss eben zwei verschiedene Key derivation functions haben.

Nein, muss man nicht. Man muss eine Hash-Funktion und eine KDF haben. Das sind zwei völlig verschiedene Dinge.

Zitat:

Zitat von Deep-Sea (Beitrag 1083457)

Aber so ziemlich jedes komplexere Format als eine Textdatei hat einen Header mit einem oft fixen Wert - der nennt sich "magic number"

Ein Grund mehr den Header nicht zu verschlüsseln und dort nur kryptographisch nicht relevante Daten zu speichern.