Ich am arbeiten noch bin, Feiertage es ja eigentlich
(Zitat: Joda)
Zitat:
Einige Algos verschlüsseln Byte für Byte - was ich für unzureichend halte.
Das sind StreamCipher und tatsächlich gelten sie als unsicherer als BlockCipher, wenn der Zufallsgenerator nicht enorm gut ist.
Zitat:
Andere nehmen Teile aus dem vorherigen Byte mit in das nächste. Und das ist besser.
Dies sind BlockCipher. Allerdings verschlüsseln sie Blockweise, meistens >= 8 bytes auf einmal.
Blockcipher OHNE richtigen Cipher Mode gelten als unsicherer. D.h. NIEMALS einen BlockCipher im ECB Modus verwenden es sei den die Messages besteht aus Zufall.
Der Cipher Mode verknüpft dann den vorherigen Datenblock mit dem nachfolgenden Datenblock bevor dieser verschlüsselt wird. Dis ist Aufgabe des Ciphermodes und nicht des Cipheralgorithmus !
Da nun die Message immer ein mehrfaches der Blockgröße sein müsste entsteht das Problem des Paddings. Den nur vollständig verschlüsselte Blöcke gelten als sicher und können wieder korrekt entschlüsselt werden. Man lösst dieses mit dem Cipher Text Stealing Verfahren, das im
DEC verwendet wird. Dieses Verfahren ist solange sehr sicher wie man mehr als einen Block verschlüsselt. Hängt man also vor der Messages nun Blocksize Bytes Zufallsdaten dran so ist dieser Modus absolut sicher.
Blockcipher sollte man sich wie Schindeln eines Daches vorstellen, jede nachfolgende Schindel wird von der vorherigen überdeckt. Eine Schindel ist ein Block.
Zitat:
Im letzten Byte deiner Datei findest du dann eventuell noch "Spuren" des ersten Bytes. Wenn du die Datei zerstückelst, dann musst du zudem auch noch an jedes Stück ein Random-Zeug anhängen, weil die Datei später ja schließlich aus mehreren Einzelverschlüsselungen mit nur einem Passwort besteht.
Diese Aussage ist nicht ganz richtig. Wird die Message in Stücken zu Blocksize Bytes zerhackt und dann verschlüsselt so ist dies identisch mit einer sequentiell korrekten Verschlüsselung eines einizigen zusammenhängenden Datenblockes.
Zitat:
Soll heißen:
Selbst wenn du am Anfang Zufallsbits anhängst sind diese in der Mitte nicht mehr, da sie ja nicht durchgängig vom Anfang her mitgetragen werden! Du kannst also, beginnend mit dem zweiten Stream, später einen Known-Plaintext-Angriff durchführen. Und das geht eben nicht, wenn die Verschlüsselung durchgängig ist.
Absolut falsch, denn es hängt vom Ciphrmode ab. Wird mit ECB verschlüsselt, also OHNE Feedback der Blöcke untereinander, dann würde deine Aussage zutreffen. Denn nun wäre der Zufallsdatenblock am Anfang absolut eigenständig und hätte keinen Einfluß auf die nachfolgenden Blöcke.
Wird aber ein Feedback Modus benutzt so pflanzt sich der Zufall vom ersten Block bis zum letzten Block weiter. Besonders in dem von mir entwickelte CTS Modus, ein Doppel-Feedback-Modus, sind alle Blöcke von allen Vorgängerblöcken abhänig. Wird ein Block verändert und falsch entschlüsselt so hat das Einfluß auf alle nachfolgenden Blöcke. Diese Eigenschaft nennt man "Error-Propagation" und ist abhängig vom Einsatzzweck erwünscht oder nicht erwünscht. Für sehr sichere Verschlüsselungen ist dies erwünscht. Den nun kann man einen Datenblock über die Message hinaus weiter verschlüssln. Dieser Datenblock dient dann als C-MAC = Cipher Message Authentication Code, sprich sichere Prüfsumme. Sie erspart also die doppelte Anwendung einer Hashfunktion, oder wird sogar als Hashfunktion selber benutzt.
Zitat:
Hier ein Beispiel:
Ich habe den Text oben mit Rijndael (Hash: SHA1) verschlüsselt. Einmal hab ich vorne ein x Angehäng und einmal ein y. Obwohl die Textlänge stets gleich ist, findest du einen komplett anderen Ciphertext vor! (Die ersten 28 Zeichen darfst du nicht beachten, weil diese nur den Hash-Wert des Originaltextes darstellen:
Weil du eben den Hashwert mit verschlüsselst. Dies bedeutet aber das
1.) bei gleicher Message der gleiche Hashwert erzeugt wird, und somit die verschlüsselte Nachricht mit gleichem Passwort immer gleich ist. Genau dies ermöglicht "known plain text" attacks, denn nun wird für alle kurzen Messages eine Datenbank erzeugt mit allen kurzen Passwörtern. Über diese Datenbank kann man nun zu einer verschl. Nachricht das Passwort raussuchen.
2.) Wird eine "Brute Force Attack" gemacht so ermöglicht der Hashwert die Überprüfung der entschlüsselten Message. Der Angreifer hat also eine auswertbare automatisierbare Funktion mit der er das Test-Passwort überprüfen kann.
Also eigentlich keine gute Idee, es sei denn die Nachricht wird am Anfang durch ca. 16 Bytes Zufall expandiert. Denn dann würde der Hashwert auch über diese Zufallsbytes gehen und somit bei der gleichen Nachticht aber immer andere Hashwerte erzeugen.
Um die Zufallsbytes kommt man nie herum, egal ob man:
1.) den Zufall als Passwort Salt benutzt, also das Passwort per Zufall expandiert und darüber per Hashfunktion den Sessionkey erzeugt
2.) den Cipher per Zufalls-IV initialisiert und somit den 0. Block der Message = Feedbackregister per Zufall initialisiert. Vorrausgesetzt man benutzt den entsprechenden Ciphermodus.
3.) die Message selber mit Zufallsdaten versieht und verschlüsselt.
Bei 1. und 2. muß der Zufallswert lesbar mit abgespeichert werden. D.h. der Angreifer kann diesen sofort extrahieren und seine Berechnungen durchführen. Nur bei Methode 3. ist auch dieser Zufall geschützt und hat trotzdem die gleichen Auswirkungen wie die Methoden 1. und 2. Es ist klar das ich Methode 3. bevorzuge und wenn dann nur noch zusätzlich Methode 1. anwende.
Man sieht nun auch den Unterschied zwischen Stream- und Blockciphern.
Stremcipher arbeiten vollkommen unabhänig und sind vollständige Verschlüsselungen.
Blockcipher bestehen aus dem Verschlüsselungsalgorithmus und einem äußeren Frame-Algorithmus der die Messageblöcke untereinander verknüpft. Damit Blockcipher sicher sind muß also
1.) der Algo. sicher sein
2.) ein Feedback-Ciphermodus benutzt werden
3.) der 0. Block des Feedback-Ciphermodus auf sichere Weise erzeugt werden, am besten echter Zufall.
Wird die Message selber um einen Block Zufall am Anfang erweitert so könnte man diesen Block als 0. Block betrachten, aber mit dem Unterschied das er nun mitverschlüsselt wird.
Da die Blocksize meisten 8 oder 16 bytes groß ist, sollte man mit einem solchen Verfahren arbeiten, aber der Zufallsblock sollte immer >= 16 bytes sein. 16 bytes sind 2^128 verschiedene Kombinationen von Zufallsbits, und dies reicht aus um eine Brute Force Attacke auf diese Zufallsbits unmöglich zu machen. Ein normaler IV wäre zwar auch zufällig, er wäre aber lesbar und meistens nur 8 Bytes groß.
Gruß Hagen