Zitat:
Der Algo soll wohl auch nicht sehr sicher sein, da er nur auf Geschwindigkeit optimiert ist und eigentlich nur dazu dienen soll das nicht jeder direkt sehen kann was drin steht.
Woher weist du das ? Hast du noch wichtige Informationen di du uns nicht veraten hast ? Ich möchte mich nur sehr ungern mißbrauchen lassen, nur weil ein Freund von dir einen primitiven Cipher entwickelt hat und nicht selber in der Lage ist das zu kryptoanalysieren. Immerhin ist es schon ein bischen Arbeit.
Nungut, es gibt ein par Auffälligkeiten die untypisch für eine sicherer Verchlüsselung sind.
1.) Die Blockgröße ist nicht klar definiert
2.) die Nachricht wird vor oder durch die Verschlüsselung um par Bytes expandiert, zb. eine Prüfsumme oder igendwelche andere Daten wie Recordtype oder so werden mit in den Datenblock eingerechnet. Das erkennt man an den letzten par Bytes, sie sind immer gleich.
3.) es gibt keine Abhängigkeit der Blöcke untereinander
Mal ein Beispiel, ich habe die MIME64 Strings in HEX umgewandelt.
Code:
11111111111111112222222222222222 -> 1003067C555F56586A48445F5355 4556 1807 1300057F565C555B694B475C5056 3332 02
22222222222222221111111111111111 -> 1300057F565C555B694B475C5056 4655 1B04 1003067C555F56586A48445F5355 3332 02
11111111111111111111111111111111 -> 1003067C555F56586A48445F5355 4556 1B04 1003067C555F56586A48445F5355 3332 02
Schau dir mal ganz genau die Daten an. Du wirst erkennen das die 11111'en der 1. Zeile am Anfang identisch kodiert werden in der 2. Zeile im 2. Block. Das Gleiche gilt für die 2222'er. So ein Block coiert aber nur 14 Ziffern identisch, danach folgen 2 Bytes die sich von der Blockposition her unterscheiden und danach nochmal par Bytes, bei denen ich annehme das sie im Algo. nur Füller sind.
Nungut es ist also zumindestens schonmal ein Angriff möglich. Wir können ganz gezielt aus einem langen 1111'er String wie in der 3. Zeile einen String wie in der 1. oder 2. Zeile zusammen bauen.
Stelle dir das so vor:
Wir wissen das das Program eine Banküberweisung mit dem Algo. verschlüsselt. Wir wissen auch das in den ersten 16 Bytes die Summe und Bankdaten kodiert sind und im 2. Datenblock der Empfänger dieser Summe. Angenommen unser Empfänger wäre die Kontonummer 2222222222222222. Unsere eigene Kontonummer ist die 1111111111111111. Wir können also die Banküberweisung (1. Zeile) so fälschen und abändern das aus der Kontonummer 22222222222 die Kontonummer 11111111111111 wird. Das Geld geht also auf unser Konto.
Der Algo. ist damit defakto unsicher.
Jetzt musst du härter analysieren. Du musst rauskriegen was es mit den zusätzlichen Datenbytes auf sich hat, sind es Prüfsummen oder zus. Recordfelder ?
Am besten du fängst an eine größere Menge an Daten zu sammeln. Zb. indem du das verschl. und analysierst
Code:
1
11
111
1111
11111
111111
1111111
usw. bis du 64 Einsen codiert hast.
2
22
222
2222
usw.
3
33
333
usw.
und den MIME64 String in einen binären umwandelst und diesen in HEX konvertierst. MIM64 ist für die Analyse ein schlechtes Format.
Dann zählst du ab ob die Nachricht Blockweise oder nur einmalig um einen feste Anzahl von Bytes expandiert wurde. D.h.
a.) sind es immer +X Bytes mehr in den verschl. Daten unabhängig von deren Datenmenge ?
b.) sind es DataLength div BlockSize *X Bytes an verschl. Daten mehr, also werrden zb. nach 16 Bytes pro Block noch 2 zusätzlich eingefügt ?
Wenn du das raushast, weist du ob eine Prüfsumme Blockweise oder Nachrichtenweise angehängt wird. Auf alle Fälle ist es auffällig das am Ende der verschl. Nachricht immer die gleichen Bytes stehen.
Es ist aber jetzt schon mit hoher Sicherheit ersichtlich das es sich um keinen guten bzw. sicheren Algo. handlen kann. Dazu hat der Programmierer zu viele gravierende Fehler gemacht. Wenn man es richtig macht würde man nicht durch die Analyse von so wenigen Testdaten die Informationen herausbekommen die wir jetzt schon rausgefunden haben. Ich meine nach 30 Minuten effektiv.
Gruß Hagen
Gruß Hagen