Dateien verschlüsseln - aber wie?

[Luckie]

So, in der Beta-Area (http://www.luckie-online.de/files/beta-area/) liegt erstmal die Beta Version. Ich warte jetzt noch darauf, wie man die CipherIdentites bekommt und wie man einen Cipher an Hand derer zuweist. Vorbereitet ist schon alles, soll heißen, wird im Header schon berücksichtigt. Und ich warte noch darauf, was Hagen mit diesem RANDOM will.

Ansonsten, ver- und entschlüsseln in Threads, kann auch abgebrochen werden, Fenster kann AlwaysOnTop gemacht werden, Programm läßt sich mit einer Datei als Parameter starten ("Senden an") und Drag and Drop vom Explorer ist möglich, verifizieren der entschlüsselten Datei über einen MD4 Hash.

[daniel-volk]

Hört sich schon ganz gut an.
Aber ich würde dennoch alles zusammen verschlüsseln, weil das ansonsten bei einigen Algos zu (meines Wissens nach) die Sicherheit beeinträchtigt:
Einige Algos verschlüsseln Byte für Byte - was ich wür unzureichend halte.
Andere nehmen Teile aus dem vorherigen Byte mit in das nächste. Und das ist besser. 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.
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.
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:

n8ksxVwGygUzRCYbHHp7UkV3BGM=nUaZc9n0d7lULRs7EoOrCC ieJYOTOhoIQRzDYy0=

/UjzH7VldipFxu00fxw0dxK/ot4=WS0U7DjHcKqePIbB/FIBquPH6IgW3yIlxW4xmZs=

Na, merkst du was?
Das Passwort ist in beiden Fällen Luckie. Kannst die Texte zur eigenen Kontrolle ja mal entschlüsseln. Nutz dafür dann einfach das Prog im Anhang.

MfG,
Daniel.

[Luckie]

Abwarten, was der Experte dazu sagt.

[mirage228]

Hi,

irgendwie kann ich deinen Text mit meinem Programm nicht entschlüsseln.

Delphi-Quellcode:

var
  s: string;
begin
  Rijndael1.InitialiseString('Luckie');
  Rijndael1.LoadIVString('Luckie');
  Rijndael1.DecryptString('UaZc9n0d7lULRs7EoOrCCieJYOTOhoIQRzDYy0=', s);
  Showmessage(S);
  Rijndael1.Burn;
end;

da kommt nie was gescheites bei raus.
hast du vllt ne andere schlüssellänge bei Rijndael?
Bei deinem Programm klappts.

mfG
mirage228

[negaH]

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

[Luckie]

Sprich EnccodeBuffer ist genauso sicher, wie Encode(Stream)?

In diesem Zusammenhang und auch wegen deiner PN an mich: Gibt es irgendwo im Netzt Seiten zum Thema Kryptologie für Einsteiger? Denn mit meinem momentanen Wissen über das Thema bin ich wohl eher nutzlos für dich.

Noch was, wie sicher ist denn meine Lösung zur zeit. Also anwendung eines Algorithmusses ohne irgendwelchen Firlefanz? Siehe das zu das programm in meiner Ablage / Beta-Area.

[negaH]

Zitat:

Sprich EnccodeBuffer ist genauso sicher, wie Encode(Stream)?

Encode(Stream) benutzt intern EncodeBuffer().

Zitat:

In diesem Zusammenhang und auch wegen deiner PN an mich: Gibt es irgendwo im Netzt Seiten zum Thema Kryptologie für Einsteiger?

Schwierige Frage, denn meine Links wurden von der SyGate Firewall zerstört
Ich empfehle immer wieder Bruce Schneiers Werk "Angewendete Kryptographie". Eine bessere Einführung wird man auch im WEB nicht finden. Meisten sind diese sogenannten "Krypto-WEB-Seiten" eh nur Zitate aus Schneiers Buch. Wenn man einmal die wichtigsten Krypto-Bücher gelesen hat und dann auf Suche im WEB geht wird man schnell feststellen das es zwar enorm viele WEB Sites gibt aber alle nur das gleiche wiederkauen. Sprich es ist wenig glaubwürdig das die Leute dann wirklich Ahnung haben, und es erscheint meistens so das sie sich nur profilieren wollen.

Zitat:

Noch was, wie sicher ist denn meine Lösung zur zeit. Also anwendung eines Algorithmusses ohne irgendwelchen Firlefanz? Siehe das zu das programm in meiner Ablage / Beta-Area.

Weit sicherer als viele Verfahren die Eigenentwicklungen sind. Sprich z.B. die vielen Postings hier im Forum die mit random() oder igendwelchen Cäsar Ciphern arbeiten.
Aber bei weitem NICHT so sicher wie sie es sein könnten. Wie du oben lesen kannst sind besonders bei Blockciphern einige Aspekte zu beachten. Da aber deren Umsetzung absolut Protokollabhänig ist konnte ich sie nicht im DEC implementieren. Naja, du kennst meine Meinung über Tutorials/Dokumentationen zum DEC und warum ich keine mache. Eben weil DEC nur eine Sammlung der Algorithmen ist und nicht weiter geht zu den Protokollen. Beides bestimmt aber die Sicherheit des Endproduktes.

Gruß Hagen

[Luckie]

Zitat von negaH:

Zitat:

Sprich EnccodeBuffer ist genauso sicher, wie Encode(Stream)?

Encode(Stream) benutzt intern EncodeBuffer().

Gut zu wissen.

Zitat:

Zitat:

In diesem Zusammenhang und auch wegen deiner PN an mich: Gibt es irgendwo im Netzt Seiten zum Thema Kryptologie für Einsteiger?

Schwierige Frage, denn meine Links wurden von der SyGate Firewall zerstört
Ich empfehle immer wieder Bruce Schneiers Werk "Angewendete Kryptographie". Eine bessere Einführung wird man auch im WEB nicht finden. Meisten sind diese sogenannten "Krypto-WEB-Seiten" eh nur Zitate aus Schneiers Buch.

Dem Smily nach zu urteilen hat unser IT-Profi auch kein intaktes Backup. Ich werde mich dann mal auf die Suche begeben.

Zitat:

Zitat:

Noch was, wie sicher ist denn meine Lösung zur zeit. Also anwendung eines Algorithmusses ohne irgendwelchen Firlefanz? Siehe das zu das programm in meiner Ablage / Beta-Area.

Weit sicherer als viele Verfahren die Eigenentwicklungen sind. Sprich z.B. die vielen Postings hier im Forum die mit random() oder igendwelchen Cäsar Ciphern arbeiten.
Aber bei weitem NICHT so sicher wie sie es sein könnten.

Gut, für den privat Gebrauch und nicht so relevate Daten, also für Liebesbriefe, die nicht jeder lesen soll, sollte es also reichen? Wenn ich das veröffentliche, wie beschreibt man da am besten den Grad der Sicherheit? Zur Zeit nutze ich BlowFish. Mal sehen ob ich was finde, wo die Vor- und Nachteile der Algos erörtert werden und deren Einsatzgebiete.

Und besten Dank für die ganze Mühe, die du dir hier für uns machst.

Allerding wäre nett von dir, wenn du mal eben sagst, wie man an die CipherIdentity dran kommt und wie man sie einsetzt. dann kann man eben noch schnell verschiedene Algos implementieren.

[daniel-volk]

Hi.
Lest ihr alle nicht richtig?

@ negaH:

Zitat:

Zitat:

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.

Erst sagst du mir, dass das falsch sein und dann sagst du wieder genau das, was ich auch schon sagte. Guck doch mal, was ich bei Luckie kritisiert habe: Nicht, dass er alles zusammen verschlüsseln will, sondern dass er die Streams einzeln verschlüsseln will. Und dann müsste er immer wieder neue Zufallsblöcke einbauen! Und genau auf diese einzelnen Verschlüsselungen bezieht sich mein Zitat oben. Du solltest also eher "Absolut richtig" oder so schreiben. Du hast mich ja quasi bestätigt.

Zitat:

Zitat:

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.

@ Hagen und @ mirage228:
Auch nicht richtig:
Ich hab den Originaltext mit Rijndael mit Mode CTS und Hash SHA1 verschlüsselt und das Ganze dann im MIME Base 64-Format ausgegeben.
Anschließend hab ich vor den verschlüsselten Text noch den SHA1-Hashwert des Originaltextes geschrieben, der im MIME Base 64-Format genau 28 Zeichen lang ist.
Beim Entschlüsseln wird also erst der Original-Hash-Wert (der nicht verschlüsselt ist) entfernt und gespeichert und anschließend der Rest entschlüsselt! So kann dann festgestellt werden, ob das Passwort richtig war. Und auch bei einer Brute-Force-Attack musst du den Text erst komplett entschlüsseln, bevor du den Hash-Wert zum Vergleich berechnen kannst.
Und mein Beispiel war dazu gedacht, um euch (besonders Luckie) zu zeigen, dass ein einziges anderes Bit (nicht einmal ein komplettes Byte) ganz am Anfang des Klartextes, den gesamten Ciphertext anders aussehen lässt. Und das, obwohl nicht einmal etwas verschoben ist.
Hiermit wollte ich klarmachen, dass es wichtig ist, dass du - beim einzelnen Verschlüsseln der Streams - vor jeden Stream neue Random-Bytes hängst.

Jetzt verstanden???

Wie weit bist du mit deiner Version des DEC? Hab mein GUI so gut wie fertig und werde dann mal anfangen den Cipher zu integrieren.
Lohnt es sich, dass ich dabei auf die neue Version über PN warte?

MfG,
Daniel.

PS:
*HEUTE SAMSTAG - SAMSTAG NICHT FEIERTAG IST*

[negaH]

@Daniel-volk:

Zitat:

Lest ihr alle nicht richtig?

Tja, scheint mir wohl so zu gehen Es ist aber auch schwierig immer den Gedanken anderer Leute korrekt zu folgen.

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 .......

Diese einseitige Aussage ist zu hart von mir, stimmt.
Was ich damit meinte war das auch wenn man Zufallsbytes vorn anhängt, es abhängig vom Ciphermode ist ob sie überhaupt Einfluß auf die nachfolgenden Daten haben. Im ECB Mode zB. wären solche Zufallsbytes eben sinnlos.

Somit hätte ich besser sagen müssen "nur bedingt richtig". Stellt man sich aber die Frage: "Ist diese Aussage richtig oder falsch, eg. JA oder NEIN" dann müsste man sie absolutistisch gesehen mit NEIN beantworten. Ich bezog also mein "absolut falsch" nicht darauf das du dich "absolut" geirrt hast, sondern darauf das wenn man es vereinfacht beantwortet mit "falsch" antworten müsste.

Zitat:

Und mein Beispiel war dazu gedacht, um euch (besonders Luckie) zu zeigen, dass ein einziges anderes Bit (nicht einmal ein komplettes Byte) ganz am Anfang des Klartextes, den gesamten Ciphertext anders aussehen lässt. Und das, obwohl nicht einmal etwas verschoben ist.

Schön, denn dies demonstriert die "Error-Propagation" des CTS Modus. Exakt aus diesen Gründen habe ich ja den CTS Modus so entwickelt. Das hat Vorteile wie auch Nachteile, je nach Zielsetzung. Will man eine "Autom. Selbstsynchronization bei Fehlern", heist will man erreichen das bei Bitfehlern nicht die komplette Nachricht zerstört wird, so wäre CTS eben die falsche Wahl. Besser wäre dann der CBC Mode.

Es beweist auch warum Zufallsbits am Anfang der Message wichtig sind, und welche Auswirkungen sie
haben. Auch im CBC Modus würden diese Zufallsbits das komplette Verschlüselungsprodukt verändern, aber denoch existiert ein enormer Unterschied zwischen CTS und CBC Mode. Der CBC Mode benutzt diese Zufallsbits nur "oberflächlich" denn selbst wenn man einen Bitfehler entschlüsselt so werden die übernächsten Blöcke wieder richtig entschlüsselt. Somit haben die Zufallsbits keine direkten Auswirkungen auf alle nachfolgenden Blöcke im gesammten. Im CTS Mode ist dies aber so.

Somit stimmen wir beide eigentlich überein

Gruß Hagen

PS: es ist wirklich schwierg ohne Formeln solche Sachverhalts zu erklären bzw. so zu verstehen das man sich nicht mißversteht