Zitat:
Sag mir lieber mal um welches Programm es sich handelt, oder upp die exe etc. Dann crack ich dir das eben. Geht wahrscheinlich schneller wenn ich mir den assembler code anschaue als wenn hagen von input und output daten den algo zurückverfolgen will
Das wäre in der Tat einfacher in diesem Falle. Allerdings zeigt schon die bloße Analyse das es zumindest teilweise knackbar ist, bzw. das der Aufwand dafür ungleich geringer sein wird als bei einer guten Implementierung.
Ich hatte aber nicht vor nun von Anfang bis Ende das Ding zu analysieren, immerhin will der OP das wissen und muß sich demzufolge auch damit selber befassen. Ich werde nur Ansätze und Hinweise geben.
Auf alle Fälle ist das Design anfällig. Ich vermute das die zusätzlichen Bytes entweder
a.) Prüfsummen sind
b.) Block-Identifikatoren sein könnten
c.) zusätzliche Informationen aus dem internen Registern des Ciphers sind, dh. Redundanz zu den Inputdaten oder dem Passwort
In jedem Falle ist es für uns zusätzliche Information die wir benutzen können um das Ding zu knacken. Normalerweise versucht man strengsten zu verhindern das sowas passiert.
Zb. Fall c.) bedeutet das der Programmierer nach/vor jeden Datenblock zusätzliche Infos abspeichert die das Passwort kontinuierlich verändert. Also jeder Datenblock arbeitet mit einer veränderten Kopie des originalen Passwortes. Die zusätzlichen Bytes könnte benutzt worden sein um eben diese Passwort zu verändern. Das wären natürlich wertvolle Informationen für uns um das Passwort zu knacken. Dazu müssen wir aber herausfinden ob nun die Expansion der Datenmenge konstant zu Nachrichtengröße ist oder konstant zu der Datenlänge (Blöcken) der Nachricht ist. Sprich, werden nur Bytes am Ende der gesammten Nachricht drangehangen oder alle 16 Bytes ein par Bytes in den Ciphertext eingebaut.
Sind aber alles Hypothesen die man erst noch verifizieren müsste.
Gruß Hagen
[edit]
Quatsch erzähle ich da. Wir wissen ja schon das die gleichen Daten an unterschiedlicher Blockposition immer fast identisch verschlüsselt werden. Das widerlegt die Hypothese das das Passwort kontinuierlich Block für Block verändert wird. Nein, das Passwort ist immer gleich lang. Das spräche dafür das der Programmierer eine einfache XOR-Verschlüsslung mit dem Passwort gemacht hat, immer reihum sequentiell. Das würde auch erklären warum die Blockröße si unklar ist, also 14 Bytes statt 16 Bytes. Das Passwort könnte also durchaus exakt 14 Bytes o.ä. groß sein.
Der Test auf diese Hypothese müsste so aussehen das man mit zb. folgenden Daten experimentiert
Code:
123123123
112233112233112233112233
111222333111222333111222333111222333
111122223333111122223333111122223333111122223333
usw.
Falls das Paswort zb. 14 Zeichen lang ist und der Algo. wirklich nur per XOR oä. verschlüsselt und dabei einfach das Passwort rotiert, dann müssten wie mit obigen Testdaten ein Set finden bei dem die 1111 und 2222 und 3333 Blöcke identisch verschlüsselt wurden. Sollte dies der Fall sein wissen wir wie lang dieses Passwort ist. In diesem Falle wäre es KEIN Blockcipher mehr eher ein Streamcipher dessen kleinste Dateneinheit so lang wie das Passwort ist.
[/edit]