Dateien verschlüsseln - aber wie?

[Luckie]

Ich will, die datei auch entschlüsseln könne, wenn sie mit einem anderen Algo des DEC verschlüsselt wurde, entschlüsseln können. dann bin ich abwärts kompatible, wenn ich den Verschlüsselungsalgo ändere.

Verschlüsseln geht schon mit Header schreiben, auch den Hash habe ich schon drin.

[negaH]

Ok, ihr habt mich soweit gebracht :)

Ich werde nachher euch beiden meine inoffizielle Version von DEC per PN schicken, und dazu noch einen Source der macht was ihr wollte. Sprich Header + Random + Prüfsumme + Prüfsumme über Daten.

Zugegeben, ich habe eigentlich keine Lust mit der älteren DEC Version zu arbeiten, und alle die Features die ich ansprach sind in eurer Version noch nicht enthalten.

Gruß Hagen

[Luckie]

Aber nur zur Anschaung, sonst kann ich ja gleich

Zitat:

Copyright by Hagen Reddmann

drunterschreiben.

[negaH]

Zitat:

Aber nur zur Anschaung, sonst kann ich ja gleich

Copyright by Hagen Reddmann

drunterschreiben.

Ja und ? ich dachte dieser Name bürgt für Qualität und Sicherheit :)

Es kann noch ein bischen dauern, da ich mich auch entschlossen habe meine DEC Sourcen von allem "Übel" zu befreien und viel Experimentalcode rauszuschmeißen.
Dafür habt ihr dann aber auch einige Fehler draussen. Rijndeal zB. hatte einen klitzekleinen aber entscheidenden Bug.

Gruß Hagen

[daniel-volk]

Hi Hagen,

das ist echt nett!!! :bounce2:

Was ist, wenn ich mein Prog dann fertig habe? Bist du damit einverstanden, wenn ich in die Versionsinfo meines Progs (mach ich immer mittels Message) - "© Verschlüsselungs- und Hash-Source: Hagen Reddmann" einfüge? Zusätzlich dazu kommt in die Lizenz natürlich noch dein englischer Lizenztext.

MfG,
Daniel. :coder:

[Luckie]

So, hab's. Allerdings ohne Random und die Prüfsumme prüft nur, ob die entschlüsselte Datei in Ordnung ist. In einen Thread habe ich es auch noch nicht, da muß ich mal kucken, wie ich das mache. Ich hänge es mal an.

[Luckie]

Verflixed, wie kann ich denn den Verschlüssel- bzw Entschlüsselvorgang abbrechen? Wenn ich den Thread einfach kille, wird die Datei nicht geschlossen. Muss ich die Datei stückchenweise in einer Schleife bearbeiten?

[daniel-volk]

Ach, lass das mit dem Abbrechen doch einfach. Das kannst du bei Steganos auch nicht. Blockier das Prog einfach so lange und bau 'ne Fortschrittsanzeige ein. Dann ist das schon OK.

Und solange du nicht grad 100MB oder so verschlüsselst, dauert das ja auch nicht lange.

Sonst versuch doch mal, die Datei nachträglich zu schließen. Das könnte doch eventuell geh'n.
Wenn nicht, dann musst du wohl alles stückweise verschlüsseln...und das ist auch nicht grad toll...

MfG,
Daniel.

[Luckie]

http://www.luckie-online.de/files/beta-area/ da gibt es die Version mit Threads.

Nein, wenn dann will ich es schon richtig machen. Es muß ja nicht jeder meine Porno Videos auf meienm Rechner ankucken. Und warum sollte man es nicht stücchenweise machen? Ist doch auch kein Problem. Es gibt doch EncodeBuffer und DecodeBuffer und in einer Schleife den SourceStream zu durchlaufen ist doch auch kein Problem. Sind doch nur 5 Zeilen mehr Code oder so. mache ich die Nacht wohl noch.

[Luckie]

So geht es:

Delphi-Quellcode:

GetMem(SrcBuffer, 1024);
GetMem(DestBuffer, 1024);
try
  while (SrcStream.Position < SrcStream.Size) and (Terminated = False) do
  begin
    if SrcStream.Size - SrcStream.Position > 1024 then
      Len := 1024
    else
      Len := SrcStream.Size - SrcStream.Position;
    SrcStream.ReadBuffer(SrcBuffer^, Len);
    EncodeBuffer(SrcBuffer^, DestBuffer^, len);
    DestStream.WriteBuffer(DestBuffer^, Len);
  end;
finally
  FreeMem(SrcBuffer);
  FreeMem(DestBuffer);

SrcBuffer, DestBuffer sind Pointer und Len ist vom Typ Integer.

[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:

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. :mrgreen: 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. :thuimb:

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??? :idea:

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* :mrgreen:

[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 :)

[daniel-volk]

So,
ich hab hier mal die erste Beta meines Verschlüsselungsprogs CryptMaster.
Bis jetzt kann man nur Texte ver- und entschlüsseln, dafür aber - hoffentlich - sehr sicher!
Ich arbeite mit folgenden Mitteln:
DEC von Hagen (öffentliche Version)
Cipher: Rijndael
Hash: SHA1
Mode: CTS

Bevor der Klartext verschlüsselt wird, wird erst noch ein Zufallsstring der Länge "BufSize" vorne angehängt.
Anschließend wird beides verschlüsselt.
Nachdem alles verschlüsselt ist, wird noch der Original-Hashwert des Klartextes vorne angehängt und fertig.

Die Entschlüsselung geht genau umgekehrt.

Testet also bitte alle mal den CryptMaster und sagt mir, wie ihr das GUI etc findet!

@Hagen:
So, nun mal an den Experten:
Mein vorläufig verwendeter Code sieht so aus. Meiner Meinung nach sollte das zu einer maximalen Sicherheit führen, aber ich bin eben nur Amateur in Sachen Verschlüsselung.

Delphi-Quellcode:

const
  EXTENSION = '.cryptmaster';
  APPNAME = 'CryptMaster';
  APPVER = 'Beta 1';
  DefCipherClass : TCipherClass = TCipher_Rijndael;
  DefHashClass : THashClass = THash_SHA1;
  DefStringFormat = fmtMIME64;
  DefCipherMode = cmCTS;

implementation

{$R *.dfm}

// Function zum Generieren der Zufallswerte
function TFrmCipher.RandomString(Len: Integer): String;
begin 
  SetLength(Result, Len); 
  Rnd.Buffer(Result[1], Len);
end;

// function zum Verschlüsseln von Text
function TFrmCipher.EncodeString(Klartext, Passwort : string) : string;
var
  Hashstring : string;
begin
  with DefHashClass.Create(nil)
  do begin
      try
       HashString := CalcString(Klartext,nil,DefStringFormat);
      finally
       Free;
      end;
     end;
  with DefCipherClass.Create('',nil)
  do begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Result := CodeString(RandomString(BufSize)+Klartext,paEncode,DefStringFormat);
       Result := HashString+Result;
      finally
       Free;
      end;
     end;
end;

// String dekodieren | Result[1] (0,1) gibt an, ob es einen Fehler gab
function TFrmCipher.DecodeString(Ciphertext,Passwort : string):string;
var
  Hashlength : word;
  OldHash, NewHash : string;
begin
  with DefHashClass.Create(nil)
  do begin
       try
         Hashlength := length(CalcString(Ciphertext,nil,DefStringFormat));
       finally
         Free;
       end;
     end;
  OldHash := Copy(Ciphertext,1,Hashlength);
  Delete(Ciphertext,1,Hashlength);
  with DefCipherClass.Create('',nil)
  do begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Result := CodeString(Ciphertext,paDecode,DefStringFormat);
       Delete(Result,1,BufSize);
      finally
       Free;
      end;
     end;
  with DefHashClass.Create(nil)
  do begin
       try
         NewHash := CalcString(Result,nil,DefStringFormat);
       finally
         Free;
       end;
     end;
  If OldHash = NewHash
  then Result := '1'+Result
  else Result := '0'+Result;
end;

Wie bewertest du diesen Code?

Thx,
Daniel.

PS: @Hagen:
Würde es dir etwas ausmachen, wenn ich dir meinen fertigen Sourcecode (sofern er denn mal irgendwann fertig ist) demnächst zur Kontrolle zuschicke? Bevor ich das Ding mit der Definition "sehr sicher" - möchte nämlich mit die sicherste Freeware-Verschlüsselungssoftware schreiben - auf die Leute loslasse, hätte ich das schon gerne nochmal überprüft. :zwinker:

[negaH]

Zitat:

Nachdem alles verschlüsselt ist, wird noch der Original-Hashwert des Klartextes vorne angehängt und fertig.

Wie bewertest du diesen Code?

Nun diese Frage hätte ich so nicht gestellt an deiner Stelle, nun antworte ich auch offen.

1.) deine Einrückungen im Source sind Mist
2.) deine Zeilenumbrüche bei den "with do", "if thens" usw. sind Mist, die Befehle gehören in eine Zeile, nur ein "Begin end" Block wird ZWEI Zeichen eingerückt. Dafür gibt es die "Begin end" Blöcke.

3.) das Protokoll deiner Verschlüssung erlaubt Angriffe die nicht sein müssten.

In einem der vorherigen Postings nahm ich an das du die Message vorne mit Zufallsbytes expandierst, dann einen Hash darüber erzeugst in vor die Message hängst und dann alles verschlüsslst. Diese Annahme war ja bekanntlich falsch, hatte aber ihre Gründe.

Denn in deinem Verfahren ist der Hash unverschlüsselt und wird somit für den Angreifer lesbar.
Dieser macht nun folgendes bei zb. 8 Bytes kurzen Messages. Er erzeugt alle möglichen Zufallsbytes = 2^64 Kombinationen. Nun erzeugt er alle 2^64 möglichen Message Kombinationen und hat nun die Möglichkeit ein Dictionary zu allen Kurzen Passwörtern anzulegen. Nur anhand deines Hashes besteht nun die Möglichkeit die Message aus der Datenbank zu finden und das dazugehörige Passwort.

Die Kombinationsvielfalt von 2^64 ist viel zu gering. Erst ab 2^128 wird es unpraktikabel.
Du solltest tatsächlich den Hash mitveerschlüsseln da er sowieso erst relevant wird wenn die Message wieder entschlüsselt wird. Da der Hash aber in jedem Falle eine "Verknüpfung" zu den Daten hat, heist das auch wenn er sicher ist er denoch bestimmte Dictionary Angriffe ermöglicht wenn er nicht geschützt wird. Also: Hash + 128 Bit Zufall + Message verschlüsseln. Wäre der Hash eine verkürzte Prüfsumme, zB. 32 Bit, so könnte man diese auch unverschlüsselt speichern, warum ??
Das besondere eines Hashes ist es das die durch ihn erzeugten "Prüfsummen" mit enorm hoher Wahrscheinlichkeit exakt eine Nachricht identifizieren. (stimmt nur praktisch aber nicht theoretisch, aber egal). Eine 32 Bit Prüfsumme im Vergleich zu einem 128 Bit hash, würde demnach 2^(128 -32) = 2^96 mal mehr Prüfsummen erzeugen die zu jeweils verschiedenen Nachrichten trotzdem gleich wären. D.h. bei 2^128 verschiedenen Nachrichten a 128 Bit, erzeugt eine Hashfunktion exakt 2^128 verschiedne Prüfsummen, eine 32 Bit Prüfsumme würde aber für jede der 2^32 möglichen Prüfsummen jeweils 2^96 verschiedene Messages zulassen. Ein kurze Prüfsumme wäre demnach NICHT mehr eindeutigt und ein Angreifer hat nicht mehr die Chance auf grund der Prüfsumme eine eindeutige Nachricht zuzuordnen. Kryptographisch gesehen verkehrt sich das Verhältnis von BitSize zu Sicherheit aus ins Gegenteil.

Ich hoffe mal das man diesen komplizierten Ausführungen noch folgen konnte.

Gruß Hagen

[daniel-volk]

Doch doch,
ich konnte dir sehr gut folgen. Dann werde ich den Code mal so umstellen, dass der Hash-Wert mitverschlüsselt wird. Hier war das ja mit dem Random nicht schwer, aber wie mace ich das mit dem Random bei Files? Luckie hat ja schon seinen Code veröffentlicht, bei dem in den Files dann noch die Hash-Werte gespeichert werden. Aber eben auch im Header und somit inverschlüsselt! Ist das akzeptabel?
Files sind ja meist so lang, dass ein Hashwert nicht mehr viel Aufschluss geben kann, oder?

Und welche Funktion muss ich nutzen, um meinen Files vor dem Verschlüsseln noch Zufallsbytes hinzuzufügen? Ich werde als Grundlage für die Verschlüsselung wohl Luckies erste Veröffnetlichung nehmen.

Noch etwas zu AES-Verfahren im DEC:
1) Du sagtest mal, dass da ein Fehler sei. Beeinträchtigt der die Sicherheit oder wozu führt der?
2) Mit wieviel Bit arbeitet die AES-Verschlüsselung im DEC?

THX,
Daniel.

[daniel-volk]

Ein Mann, ein Wort...

Hier ist der veränderte Code:

Delphi-Quellcode:

const
  EXTENSION = '.cryptmaster';
  APPNAME = 'CryptMaster';
  APPVER = 'Beta 1';
  DefCipherClass : TCipherClass = TCipher_Rijndael;
  DefHashClass : THashClass = THash_SHA1;
  DefStringFormat = fmtMIME64;
  DefCipherMode = cmCTS;
  CipherTextBegin = '[BEGIN-CryptMaster-Message]';
  CipherTextEnd = '[CryptMaster-Message-END]';

implementation

{$R *.dfm}

// Function zum Generieren der Zufallswerte
function TFrmCipher.RandomString(Len: Integer): String;
begin
  SetLength(Result, Len);
  Rnd.Buffer(Result[1], Len);
end;

// function zum Verschlüsseln von Text
function TFrmCipher.EncodeString(Klartext, Passwort : string) : string;
var
  Hashstring : string;
begin
  with DefCipherClass.Create('',nil) do
    begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Klartext := RandomString(BufSize)+Klartext;
       with DefHashClass.Create(nil) do
         begin
           try
             Hashstring := CalcString(Klartext,nil,DefStringFormat);
           finally
             Free;
           end;
         end;
       Klartext := Hashstring+Klartext;
       Result := CodeString(Klartext,paEncode,DefStringFormat);
     finally
       Free;
     end;
   end;
  // Marker für den Ciphertext setzen
  Result := CipherTextBegin+Result+CipherTextEnd;
end;

// String dekodieren | Result[1] (0,1) gibt an, ob es einen Fehler gab
function TFrmCipher.DecodeString(Ciphertext,Passwort : string):string;
var
  Hashlength : word;
  OldHash, NewHash : string;
  RemBufSize : Int64;
begin
  // Marker für den Ciphertext entfernen
  Delete(Ciphertext,1,pos(CipherTextBegin,Ciphertext)+length(CipherTextBegin)-1);
  Delete(Ciphertext,pos(CipherTextEnd,Ciphertext),length(Ciphertext)-pos(CipherTextEnd,Ciphertext)+1);
  with DefHashClass.Create(nil) do
    begin
       try
         Hashlength := length(CalcString(Ciphertext,nil,DefStringFormat));
       finally
         Free;
       end;
     end;
  with DefCipherClass.Create('',nil) do
    begin
      try
       Mode := DefCipherMode;
       HashClass := DefHashClass;
       InitKey(Passwort,nil);
       Result := CodeString(Ciphertext,paDecode,DefStringFormat);
       RemBufSize := BufSize;
      finally
       Free;
      end;
     end;
  OldHash := Copy(Result,1,Hashlength);
  Delete(Result,1,Hashlength);
  with DefHashClass.Create(nil) do
    begin
       try
         NewHash := CalcString(Result,nil,DefStringFormat);
       finally
         Free;
       end;
     end;
  Delete(Result,1,RemBufSize);
  If OldHash = NewHash then Result := '1'+Result else Result := '0'+Result;
end;

MfG,
Daniel. :bounce2:

[daniel-volk]

Hi Hagen,

mir ist gerade etwas aufgefallen:
Auch Steganos 5 arbeitet mit AES und SHA1! Hab ich wohl 'ne gute Wahl getroffen. :mrgreen:

Aber mal was Anderes dazu: Steganos verwendet doch Live-Encryption. Dabei werden die Daten immer nur beim Lesen entschlüsselt, was dann voraussetzt, dass auch immer nur einzelne Dateiteile gelesen werden.
Und das wiederum bedeutet doch, dass Steganos wahrscheinlich mit ECB oder so arbeitet, nicht aber mit CTS! Sie werden also auch keine Zufallsbytes anhängen, weil das dann nichts mehr bringt.

Wenn ich somit ohne Random arbeite (bei den Files) aber mit CTS, dann müssten Known-Plaintext-Angriffe bei mir doch immer noch schlechter durchzuführen sein, als bei Steganos, oder? Und das wiederum würde bedeuten, dass ich ruhig auf Random verzichten kann, denn Steganos wird ja wohl schon sicher genug sein!
Wenn ich jetzt ECB (oder wie das auch immer heißt) verwenden würde (ohne Random), würde das weniger Sicherheit bieten als CTS?

Wie kann ich eigentlich mit den DEC eine Datei wipen? Geht das mit dem Code:

Delphi-Quellcode:

with DefCipherClass.Create('',nil) do
begin
  Mode := mdCTS;
  HashClass := DefHashClass;
  InitKey('',nil);
  CodeFile(Filename,paWipe,nil);
  DeleteFile(Filename);
end;

Oder muss ich das irgendwie anders machen?

MfG,
Daniel. :firejump:

[negaH]

Zitat:

Wenn ich somit ohne Random arbeite (bei den Files) aber mit CTS, dann müssten Known-Plaintext-Angriffe bei mir doch immer noch schlechter durchzuführen sein, als bei Steganos, oder? Und das wiederum würde bedeuten, dass ich ruhig auf Random verzichten kann, denn Steganos wird ja wohl schon sicher genug sein!
Wenn ich jetzt ECB (oder wie das auch immer heißt) verwenden würde (ohne Random), würde das weniger Sicherheit bieten als CTS?

Ich weiß nicht ob Steganos mit ECB arbeitet, kann es mir nur schwer vorstellen. Sollte es so sein dann hätten die Designer einen groben Fehler gemacht.
Der Zufallswert expandiert nur die Nachricht, es können also auch andere Ciphermodes angewendet werden die "seekable" sind. Ich glaube aber nicht das Steganos "wahlfreien" Zugriff bei der Entschlüsselung ermöglicht. So gut ist Steganos nun auch wieder nicht.

Es gibt Ciphermodes die genauso sicher wie CTS/CBC sind und dennoch wahlfreien Zugriff auf die Daten während der Entschlüsselung bieten. Z.b. der CTR=Counter Modus. Dabei wird jeder Block der Verschlüsselung durchnummeriert. Intern wird ein zB. 64/128 Bit Zähler mitgeführt, als IV sozusagen, und die Nummer des Blockes draufaddiert. Nun hat man den IV berechnet der zu dem Block gehört. Da der Counter sich so von Block zu Block immer erhöht hat jeder Block seinen eigenen Counter, ist aber NICHT abhänig von vorherigen Blöcken. Dieser CTR Mode ist ein Vorschlag bei der AES Auswahl der zukünftigen Standard Ciphermodes. Der Startcounter beim CTR sollte nur einmal verwendet werden !

Ich persönlich würde dennoch mit CTS arbeiten, da er durch seine Eigenschaften eine Alles oder Nichts Entschlüsselung ermöglicht. Dies ist das algorithmisch gesehen höchste Maß an Sicherheit.
Auch der CTS ermöglicht eine Live-Ver-/Entschlüsselung, aber eben nur sequentiell vom ersten Block zum letzten Block der Message.

Allerdings ist CTS in keinster Weise ein Standardmodus, sondern ein von mir entwickelter "Doppel-Feedback" Modus. D.h. meine Änderungen sind so gemacht das sie einen CBC Modus erweitern um einen "Doppelt-CBC-Modus" zu bekommen. Wenn also der CBC Modus als sicher gilt so muß es auch der CTS Modus sein. CBC ist ein sehr anerkannter Standardmodus. Diese "Design" Philosophie musste ich benutzen damit CTS sicher bleibt/wird, denn ich selber habe nicht die Resourcen um effektiv zu beweisen das CTS wirklich sicher ist.

Was macht CTS ?
CBC verknüpft per XOR das Feedbackregister mit den Datenblock der verschlüsselt werden soll. Danach wird der Datenblock verschlüsselt und ins Feedbackregister kopiert.
CTS macht das gleiche, aber statt Kopieren wird das Feedbackregister wiederum XOR verknüpft mit dem nun verschlüsselten Datenblock.
Das Feedbackregister enthält am Schluß im CTS Modus die XOR Verknüpfungen der Daten vor Verschlüsseung mit der XOR Verknüpfung der Daten nach der Verschlüsselung ALLER Datenblöcke.
Im CBC Modus enthält das Feedbackregister am Schluß den letzten verschlüsselten Datenblock.

Hier erkennt man die Eigenschaft der "Error-Propagation" des CTS Modus, denn das letzte Feedbackregister ist sozusagen die XOR Summe aller Blöcke + deren Verschlüsseltes Produkt in verschlüsselter Form. Eine einzigste Fehlerbit-Änderung würde damit vollständig die nachfolgenden Blöcke zerstören.

Die Gegenüebrstellung der Modis sieht so aus:

Zitat:

IV = initialization Vector
c() = verschlüsslungsfunktion eines Blockes
Cx = Ciphertext des x. Blockes, die verschl. Message besteht aus C1...Cx
Dx = Plaintext des x. Datenblockes, die Message besteht aus D1..Dx
F = Feedbackregister

CBC-Modus

C0 = IV
C1 = c(C0 xor D1)
C2 = c(C1 xor D2)
C3 = c(C2 xor D3)
C4 = c(C3 xor D4)

CTS-Modus

C0 = IV
C1 = c(C0 xor D1)
C2 = c(C0 xor C1 xor D2)
C3 = c(C0 xor C1 xor C2 xor D3)
C4 = c(C0 xor C1 xor C2 xor C3 xor D4)

verkürzt und intern in meinen Ciphern benutzt siehts so aus:

F = IV
C1 = c(F xor D1); F = F xor C1; // F == C0 xor C1
C2 = c(F xor D2); F = F xor C2; // F == C0 xor C1 xor C2
C3 = c(F xor D3); F = F xor C3; // F == C0 xor C1 xor C2 xor C3
C4 = c(F xor D4); F = F xor C4; // F == C0 xor C1 xor C2 xor C3 xor C4

F = Cipher-Message-Authentication-Code

CBC-Mode

F = IV
C1 = c(F xor D1); F = C1;
C2 = c(F xor D2); F = C2;
C3 = c(F xor D3); F = C3;
C4 = c(F xor D4); F = C4;

F = letzter verschlüsselter Block

vollständige Formel für C3 ist:

CTS-Mode

C3 = c(IV xor D3 xor c(IV xor D2 xor c(IV xor D1)) xor c(IV xor D1))

CBC-Mode

C3 = c(c(c(IV xor D1) xor D2) xor D3)

Man sieht sehr schön um wie vieles stärker der CTS Modus sein muß, obwohl nur eine einzigste Operation verändert wurde. Statt F = Cx, eben F = F xor Cx !

Im CBC Mode wird nur der 1. Datenblock mit dem Zufalls-IV verknüpft.
Im CTS Mode werden ALLE Datenblöcke mit dem IV verknüpft.
Im CBC Mode wird nur der vorherige verschlüsselte Block mit dem aktuellen Block verknüpft.
Im CTS Mode werden ALLE vorherigen verschlüsselten Blöcke mit dem aktuellen Block verknüpft.

Wie gesagt ich meine das ich NICHT der absolute Kryptoguru bin und nicht die Fähigkeiten besitze um sagen zu können das meine Analysen was taugen. Jeder sollte sich selber ein Bild über CTS machen, und darüber selber nachdenken ob CTS nun besser als CBC ist. Ich persönlich bin davon überzeugt das er um vielfaches besser ist als CBC.

Gruß Hagen

[daniel-volk]

@ Hagen:

Erst einmal danke für deine sehr anschaulichen Formeln!
Aber meine (eigentlich recht guten da Mathe-Leistungskurs und Informatik) mathematischen Kenntnisse lassen mich doch etwas an CTS zweifeln.
Ich CBC wird jeweils auch der Cipherblock des vorherigen Datenblockes "mitgenommen".
Dieser enthält nun wiederum Infos über den davor usw.
Es ist somit klar, dass auch bei CBC die Infos des ersten Blockes bis zum Schluss - wenn auch nur geringfügig - mitgetragen werden.

Im CTS-Modus erfolgt dieses Mittragen sehr viel intensiver, und gerade dass führt zu meinem Zweifel:
Erst einmal ein kurzes Beispiel dazu:

Wenn ich 13 xor 55 xor 255 xor 3 xor 54 rechne, dann kommt da 240 raus.
Rechne ich jetzt 240 xor 13, dann gibt das 253 und das ist wiederum = 55 xor 255 xor 3 xor 54 .

Soll heißen:
Wenn ich bei einer noch so langen XOR-Rechnung einen Wert zweimal einbeziehe, dann wird er eliminiert. Wird auch hierdurch klar: Y xor Y = 0 bzw: Y xor Y xor X = X

Der Random-Block, der ja nun der erste ist, befindet sich nun im Feedbackregister und wird somit auf den Block 2 angewendet. Das Ergebnis davon gelangt jetzt wieder in abgewandelter Form in das Feedbackregister: ==> Im Feedbackregister befindet sich indirekt der Random-Block 0 zweimal!
Somit hat er eventuell auf Block 3 keine Auswirkung mehr! Lediglich in Block 4 wäre wieder eine Auswirkung gegeben, da hier der Random-Block 0 dreimal vorkäme.

Diese Problematik solltest du mal genauer untersuchen.
Ich will jetzt nicht unbedingt behaupten, dass CTS unsicherer ist als CBC, aber auch beim Gegenteil bin ich skeptisch!
Denk immer dran: Bei der Modifikation von Ciphern etc kann sehr schnell etwas schief gehen! Ein XOR zu viel und alles ist kaputt - obwohl es im ersten Moment sicher aussieht...

Was für ein Fehler ist eigentlich in Rijndael im DEC?
Kann ich den irgendwie manuell beheben? Das sind doch sicher nur ein oder zwei Zeilen?!
THX,
Daniel.

[negaH]

Zitat:

Im CTS-Modus erfolgt dieses Mittragen sehr viel intensiver, und gerade dass führt zu meinem Zweifel:
Erst einmal ein kurzes Beispiel dazu:

Wenn ich 13 xor 55 xor 255 xor 3 xor 54 rechne, dann kommt da 240 raus.
Rechne ich jetzt 240 xor 13, dann gibt das 253 und das ist wiederum = 55 xor 255 xor 3 xor 54 .

Soll heißen:
Wenn ich bei einer noch so langen XOR-Rechnung einen Wert zweimal einbeziehe, dann wird er eliminiert. Wird auch hierdurch klar: Y xor Y = 0 bzw: Y xor Y xor X = X

Der Random-Block, der ja nun der erste ist, befindet sich nun im Feedbackregister und wird somit auf den Block 2 angewendet. Das Ergebnis davon gelangt jetzt wieder in abgewandelter Form in das Feedbackregister: ==> Im Feedbackregister befindet sich indirekt der Random-Block 0 zweimal!
Somit hat er eventuell auf Block 3 keine Auswirkung mehr! Lediglich in Block 4 wäre wieder eine Auswirkung gegeben, da hier der Random-Block 0 dreimal vorkäme.

Schau dir's nochmal genauer an, denn deine Annahmen stimmen so nicht.
Beim CTS Modus wird ja immer nur mit den Verschlüsselten Vorgängerblöcken XOR verknüpft. Wäre c(), der Verschlüsslungscode, eine einfache XOR Verschlüsselung dann würde deine Annahme stimmen. Aber im gleichem Maße wäre dann CBC erst recht unsicher. Da aber c() bei heutigen Blockverschlüsslungen eben nur durch e(), dem Entschlüsslungscode, invertierbar ist, können deine Annahmen nicht stimmen.

Beim CBC Modus wird nur der 1. Block verknüpft mit dem IV. Da dieser IV natürlich Einfluß auf den nächsten Wert im Feedback-register hat, wird er indirekt mit durchgeschliffen. Allerdings im CTS Modus passiert das Gleiche plus das der IV mit jedem Block verknüpft wird.

Deshalb meinte ich ja das der CTS Modus sozusagen ein "doppelter" CBC Modus ist. Genau genommen ist er ein "x Block facher" CBC Modus. Je mehr Blöcke verschlüsselt werden im CTS Modus destomehr ist der nachfolgende Block abhänig von allen Vorgängerblöcken. Der letzte Block ist das Produkt aller Vorgängerblöcke + IV's + Passwort + Verschlüsselungsfuntion c(). Der letzte Wert im Feedbackregister ist somit absolut abhängig vom IV + Palintext + CipherText + Passwort + c().
Wie gesagt, schau dir die Formeln ganz genau an, und analysiere sie erstmal richtig. Dann wirst du sehen was ich meine. Der CTS Modus wurde mit vielen Cryptogurus in sci.crypt besprochen und analysiert.

Zitat:

Was für ein Fehler ist eigentlich in Rijndael im DEC?
Kann ich den irgendwie manuell beheben? Das sind doch sicher nur ein oder zwei Zeilen?!

Sorry, nicht in Rijndael ist der Fehler sondern in Twofish.

Gruß Hagen

[daniel-volk]

Zitat:

Der CTS Modus wurde mit vielen Cryptogurus in sci.crypt besprochen und analysiert.

Achso, na dann ist ja alles OK.

Frage mich nur immer noch, warum er dann nicht längst öffentlich anerkannt ist wie CBC. Auf diese Möglichkeit hätte doch schon viel früher jemand kommen können. :roll:
Egal. Mal sehen, welchen Mode ich verwende. Entweder CTS oder CBC. CBC hätte wahrscheinlich den Vorteil, dass er von der Öffentlichkeit eher anerkannt wird und die Leuts somit mehr Vertrauen in mein Prog hätten - auch wenn CTS im Endeffekt vielleicht sicherer wäre. :?

Mal seh'n, werd schon 'ne Lösung finden. :-D

MfG,
Daniel.

PS: Meine Zweifel rührten nicht daher, dass ich dir nicht zutraue sowas zu erfinden, sondern eher daher, dass ich CTS für recht ungeprüft hielt und slbst schon oft darüber verwundert war (bei meinen eigenen Kryptversuchen) welche "Wunder der Mathematik" da plötzlich auftauchen. :mrgreen:

[negaH]

Zitat:

Frage mich nur immer noch, warum er dann nicht längst öffentlich anerkannt ist wie CBC. Auf diese Möglichkeit hätte doch schon viel früher jemand kommen können.

Oh, ein ähnlicher CTS als solches wurde vor einem Jahr in den AES Auswahlprozess für Standard Ciphermodes aufgenommen. Betrachtet man CTS mal auf Byte-Ebene so stellt man fest das es CFB Modis gibt die wie CTS arbeiten. Es ist also nicht unbekannt im eigentlichen Sinne, sondern es wurden anderen Ciphermodis den Vorrang gegeben weil sie meistens effizienter sind. Erst seit 1-2 Jahren bemüht man sich auch die Ciphermodis der Blockcipher genauer und gezielter zu entwickeln. Bis dato wurden die Ciphermodis im allgemeinen NICHT als Sicherheitsrelevant eingestuft. Diese Annahme hat sich als falsch erwiesen, weil eben die Sicherheitanforderungen gestiegen sind.

Ich persönlich habe CTS so entwickelt weil der Austausch der Feedback-Zuweiseung Operation so enorm einfach durch eine XOR Operation möglich war. Statt Move() eben XOR(). Es gibt mittlerweile noch einen Counter-CTS Modus.

Zitat:

PS: Meine Zweifel rührten nicht daher, dass ich dir nicht zutraue sowas zu erfinden, sondern eher daher, dass ich CTS für recht ungeprüft hielt und slbst schon oft darüber verwundert war (bei meinen eigenen Kryptversuchen) welche "Wunder der Mathematik" da plötzlich auftauchen

Diese Herangehensweise ist absolut korrekt und richtig. Aber Neuentwicklungen werden gemacht damit sie ältere Fehler beseitigen. Würde man nur an altem hängen so würden sich bessere Neuentwicklungen nicht durchsetzen. Zudem, es gibt genügend Beispiele bei denen die heutigen Cryptogurus selber Fehler eingestehen, und trotzdem sind deren Verfahren Standards geworden. Um es mal anders auszudrücken: Krypto-Standards sind Mittel in einem elektronischen Krieg der zwischen den beteiligten und Patenthaltenden Firmen geführt wird. Die Entwickler/Professoren/Doktoren und Experten dieser Firmen/Universitäten sind nur Mittel zum Zweck. Deshalb setzen sich auch immer wieder Standard's durch die eben nicht gut sind.

Gruß Hagen

[daniel-volk]

Ich glaub ich spinne:
Warum wollen diese Streams nicht so wie ich will?
Ich hab Luckie's Art die Files zu ver- und entschlüsseln mal etwas abgewandelt. Und zwar habe ich als Random-Ersatz den Hash-Wert mit in der Datei gespeichert.
Aber das führt nur zu Fehlern:
Die Version des Quelltextes, die ich euch jetzt vorlege, die führt gleich zu einem Fehler. Ich hatte schon einige Sachen geändert, die dann bewirkt haben, dass es keine Fehlermeldung mehr gab (beum Verschlüsseln). Aber es ging trotzdem nie richtig! Es wurden dann halt völlig falsche Daten gespeichert. :(
Zugegeben: Das sind meine ersten Versuche mit Streams zu arbeiten. Hab auch schon bei Delphi-Source ein Tutorial gelesen, aber mein Hauptproblem, dass ich nicht von einem Stream zu anderen kopieren kann (CopyFrom geht nicht), das kriege ich auch nicht behoben.

@ Luckie:
Ich weiß ja, dass du mit Streams ganz gut umgehen kannst. Kannst du mir an dieser Stelle vielleicht helfen? Das ist (hoffentlich) die letzte Hürde, die mir vor der Fertgstellung noch bevorsteht. :)

Danke!!!!!!!!

So, hier der Code:

Delphi-Quellcode:

// Datei entschlüsseln
function TFrmCipher.DecodeFile(Input, Output, Passwd: String; hWnd: THandle): Boolean;
var
  SrcStream: TStreamProgressAdapter;
  DestStream: TFileStream;
  TempStream : TMemoryStream;
  NewHeader, OldHeader : TFileHeader;
begin
  result := False;
  SrcStream := TStreamProgressAdapter.Create(TFileStream.Create(Input, fmOpenRead), hWnd);
  if Assigned(SrcStream) then
  begin
    try
      DestStream := TFileStream.Create(Output, fmCreate);
      if Assigned(DestStream) then
      begin
        try
        TempStream := TMemoryStream.Create;
      if Assigned(DestStream) then
      begin
        try
          SrcStream.Seek(sizeof(TFileHeader), soFromBeginning);
          with DefCipherClass.Create('', nil) do
          begin
            Mode := DefCipherMode;
            HashClass := DefHashClass;
            InitKey(Passwd, nil);
            DecodeStream(SrcStream, TempStream, SrcStream.Size);
          end;
          TempStream.Position := 0;
          TempStream.Read(OldHeader,SizeOf(TFileHeader));
          TempStream.Seek(SizeOf(TFileHeader),0);
          DestStream.Write(TempStream,DestStream.Size);
          NewHeader.HashString := DefHashClass.CalcStream(DestStream, DestStream.Size);
          finally
          FreeAndNil(TempStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
        finally
          FreeAndNil(DestStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
      finally
        FreeAndNil(SrcStream);
      end;
  end
  else
  begin
    RaiseLastOSError();
    exit;
  end;
  If NewHeader.HashString = OldHeader.HashString then
  result := true else
  result := false;
end;

// Datei verschlüsseln
function TFrmCipher.EncodeFile(Input, Output, Passwd: String; hWnd: THandle): Boolean;
var
  SrcStream: TStreamProgressAdapter;
  DestStream: TFileStream;
  TempStream: TMemoryStream;
  FileHeader : TFileHeader;
  len : Int64;
  rem : string;
begin
  result := False;
  SrcStream := TStreamProgressAdapter.Create(TFileStream.Create(Input, fmOpenRead or fmShareDenyNone), hWnd);
  if Assigned(SrcStream) then
  begin
    try
      DestStream := TFileStream.Create(Output, fmCreate);
      if Assigned(DestStream) then
      begin
        try
          TempStream := TMemoryStream.Create;
          if Assigned(TempStream) then
          begin
          try
          FileHeader.HashString := DefHashClass.CalcStream(SrcStream, SrcStream.Size);
          TempStream.Write(FileHeader, sizeof(TFileHeader));
          TempStream.Write(SrcStream, SrcStream.Size);
          with DefCipherClass.Create('', nil) do
          begin
            Mode := DefCipherMode;
            HashClass := DefHashClass;
            InitKey(Passwd, nil);
            EncodeStream(TempStream, DestStream, SrcStream.Size);
          end;
        finally
          FreeAndNil(DestStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
        finally
          FreeAndNil(TempStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
    finally
      FreeAndNil(SrcStream);
    end;
  end
  else
  begin
    RaiseLastOSError();
    exit;
  end;
  result := True;
end;

Ich möchte möglichst mit nur einer Quelldatei und einer Ausgabedatei arbeiten, damit nicht so viel auf dem Datenträger geschrieben wird.
Das Teil soll nämlich so sein, dass man es auch auf'm USB-Stick verwenden kann, ohne dass es zu viele Schreibzyklen benötigt. Deshalb arbeite ich auch mit dem Memory-Stream.

Und bevor ich von Hagen wieder einen drauf kriege:
Ich hab den Code noch nicht groß formatiert. Sieht also so durchwühlt aus, wie es halt beim Experimentieren ist. :wink:

MfG,
Daniel. :bounce2:

[Luckie]

Und ich soll jetzt aus dem "durchwühlten" Code den Fehler raus machen oder wie? Dazu hab eich leider im Moment nicht den Nerv. Ich liege mit einer Erkältung im Bett.

[daniel-volk]

Hi.

1) Mit durchwühlt meinte ich nur, dass die Formatierung nicht immer 100%ig ist (hat Hagen mal kritisiert), ansonsten passt die Formatierung aber - vor Allem in dem Teil, der im Endeffekt wirklich wichtig ist.

2) Nach Bett sieht das nicht gerade aus. Oder du hast ein Notebook mit WLAN. :)

3) Ich hatte dich auch nur als Beispiel genannt, weil du dich auch mit der Materie des DEC auskennst und mit nicht mein ganzen Konzept zerstören würdest.
Aber natürlich kann mir auch jede(r) Andere helfen. Fakt ist nur, dass ich alleine hier nicht mehr weiter komme. Und das ist ja dann nicht gerade gut. :(

Danke euch allen!

MfG,
Daniel.

[Luckie]

Man muß auch mal aufstehen.

[negaH]

Delphi-Quellcode:

  FileHeader.HashString := DefHashClass.CalcStream(SrcStream, SrcStream.Size); 
  if SrcStream.Position <> SrcStream.Size then
 // Hash.CalcStream() hat nicht den Stream.Zeiger verändert und arbeitet somit falsch !!
  else
 // Hash.CalcStream() hat wie erwartet den Stream gelesen und somit ist der Streamzweiger amd
 // Ende des Stream. Der Programmier hat nun darauf zu achten das er per SrcStream.Position := 0;
 // wieder an den Anfang positionert FALLS er mit SrcStream weiter arbeiten muß. Da der Programmier
 // eigentlich die VCL kennen sollte müsste er auch wissen das dieses Verhalten immer so ist.
 // Denn er ist der jenige der denken kann und der VCL sagen muß was er will.

:) oder in kurz: SrcStream.Position = ScrcStream.Size nach Aufruf von Hash.CalcStream() usw. Du musst damit .EncodeStream() funktioniert also SrcStream.POsition := 0; vorher aufrufen. Alle Stream Funktionen sollten niemals Stream.Position selbständig verändern, sondern immer ausgehen von der akteuellen Position arbeiten. Damit wird es möglich in einen Stream z.B. per Bitmap.SaveToStream() mehrere Bitmaps hintereinander zu speichern.

Gruß Hagen

[daniel-volk]

Hi,

hab Hagen's Rat mal befolgt, aber immer noch ohne Erfolg.
Ich kriege zwar keine Fehlermeldung mehr, aber ansonsten geht es immer noch nicht:
Die Ausgabedatei ist nicht mehr das, was sie mal war. :(

Ok, muss jetzt weg. Guckt euch den Code mal an.
Eigentlich fehlt mir doch nur eine Funktion zum Löschen eines Streamstücks. Und die hab ich nicht.
Vielleicht sind da aber auch noch andere Fehler?!

MfG,
Daniel.

Danke!!!

Delphi-Quellcode:

// Datei verschlüsseln
function TFrmCipher.EncodeFile(Input, Output, Passwd: String; hWnd: THandle): Boolean;
var
  SrcStream: TStreamProgressAdapter;
  DestStream: TFileStream;
  TempStream: TMemoryStream;
  FileHeader : TFileHeader;
begin
  result := False;
  SrcStream := TStreamProgressAdapter.Create(TFileStream.Create(Input, fmOpenRead or fmShareDenyNone), hWnd);
  if Assigned(SrcStream) then
  begin
    try
      DestStream := TFileStream.Create(Output, fmCreate);
      if Assigned(DestStream) then
      begin
        try
          TempStream := TMemoryStream.Create;
          if Assigned(TempStream) then
          begin
          try
          SrcStream.Seek(0,sofrombeginning);
          // Anhand von SrcStream soll der FileHash berechnet werden...
          FileHeader.HashString := DefHashClass.CalcStream(SrcStream, SrcStream.Size, nil, DefFileStringFormat);
          // TempStream übernimmt die Rolle von SrcStream
          TempStream.LoadFromStream(SrcStream);
          TempStream.Seek(0,sofrombeginning);
          // Der FileHeader wird in TempStream vor die eigentlichen Daten geschrieben (geht das so???)
          TempStream.Write(FileHeader, sizeof(TFileHeader));
          TempStream.Seek(0,sofrombeginning);
          DestStream.Seek(0,sofrombeginning);
          with DefCipherClass.Create('', nil) do
          begin
            Mode := DefCipherMode;
            HashClass := DefHashClass;
            InitKey(Passwd, nil);
            EncodeStream(TempStream, DestStream, TempStream.Size);
          end;
        finally
          FreeAndNil(TempStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
        finally
          FreeAndNil(DestStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
    finally
      FreeAndNil(SrcStream);
    end;
  end
  else
  begin
    RaiseLastOSError();
    exit;
  end;
  result := True;
end;

// Datei entschlüsseln
function TFrmCipher.DecodeFile(Input, Output, Passwd: String; hWnd: THandle): Boolean;
var
  SrcStream: TStreamProgressAdapter;
  DestStream: TFileStream;
  TempStream : TMemoryStream;
  NewHeader, OldHeader : TFileHeader;
begin
  result := False;
  SrcStream := TStreamProgressAdapter.Create(TFileStream.Create(Input, fmOpenRead or fmShareDenyNone), hWnd);
  if Assigned(SrcStream) then
  begin
    try
      DestStream := TFileStream.Create(Output, fmCreate);
      if Assigned(DestStream) then
      begin
        try
        TempStream := TMemoryStream.Create;
      if Assigned(TempStream) then
      begin
        try
          with DefCipherClass.Create('', nil) do
          begin
            Mode := DefCipherMode;
            HashClass := DefHashClass;
            InitKey(Passwd, nil);
            // Zuerst wird SrcStream Decodiert und in TempStream geschrieben
            DecodeStream(SrcStream, TempStream, SrcStream.Size);
            // jetzt befindet sich am Anfang von TempStream der FileHeader
            Free;
          end;
          TempStream.Seek(0,sofrombeginning);
          // Der FileHeader wird gelesen
          TempStream.Read(OldHeader,SizeOf(TFileHeader));
          // Problem: Der Rest der Datei hinter dem Header muss in DestStream geschrieben werden!!!
          // Habe auch schon Write() versucht
          DestStream.CopyFrom(TempStream,TempStream.Size-TempStream.Position);
          DestStream.Seek(0,sofrombeginning);
          NewHeader.HashString := DefHashClass.CalcStream(DestStream, DestStream.Size, nil, DefFileStringFormat);
          finally
          FreeAndNil(TempStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
        finally
          FreeAndNil(DestStream);
        end;
      end
      else
      begin
        RaiseLastOSError();
        exit;
      end;
      finally
        FreeAndNil(SrcStream);
      end;
  end
  else
  begin
    RaiseLastOSError();
    exit;
  end;
  If NewHeader.HashString = OldHeader.HashString then
  result := true else
  result := false;
end;

[edit=Daniel B]Tags korrigiert. Mfg, Daniel B[/edit]

[daniel-volk]

Hallo,

inzwischen hab ich durch weitere Experimente herausgefunden, dass der Fehler nicht in der Verschlüsselung sondern lediglich in der Entschlüsselung liegt. Beim Verschlüsseln geht alles 100 pro.

Mal sehen, ob ich die Entschlüsselung noch weiter analysieren kann...

MfG,
Daniel.

[daniel-volk]

JJJJuuuuuhhhhuuuuu!!!!!!!!!!! :angle:

Hab's endlich geschafft!
Man, da hab ich vor lauter Bäumen den Wald nicht mehr gesehen! :oops:
Es lag so nahe...

Mein Problem war: Da ich mit CopyFrom() nicht klar kam, hab ich erst LoadFromStream verwendet und anschließend dann den HashWert vorne eingefügt. Zumindest hatte ich es so vor... Delphi hat das etwas anders verstanden und mir dadurch den vorderen Teil der Datei überschreiben.

Jetzt hab ich den Zeiger einfach vor der CopyFrom Operation in der Quelldatei auf SrcStream.Size gesetzt und schon konnte ich erst den Hash einfügen und anschließend mit CopyFrom die Quelldatei!!!

Gemerkt hab ich das Ganze, indem ich mit Textfiles experimentiert hab und den Cipher abgeschaltet hatte. Da bin ich dann stutzig geworden, weil ich unterschiedliche Hash-Werte bekam und weil mir der Anfang der Datei fehlte.

Egal,
jetzt geht's jedenfalls!!! :firejump:

Danke euch Allen, die ihr mich so tatkräftig unterstützt habt!!! :cheers:

MfG,
Daniel.

PS:
@Hagen:
Wenn es dir nichts ausmacht, darf ich dir dann - nach erneuter Überarbeitung - meinen Source mal zuschicken? Ich möchte nur sichergehen, dass ich nicht irgendeinen groben Unsinn gemacht habe, der dann die ganze Sicherheit flöten gehen lässt... :wink:

[Luckie]

Ich warte, ehrlich gesagt, immer noch darauf, wie ich an die CipherID / HashID rankomme, bzw. wie ich sie dann nutzen kann. :roll:

[daniel-volk]

Das weiß ich ehrlich gesagt auch nicht.

Aber mach es doch so:
Deklarier dir die Variable DefCipherClass vom Typ TCipherClass, die dann automatisch die Werte TCipher_Rijndael, TCipher_Blowfish etc enthalten kann.
Die speicherst du im Stream und kannst nach dem Laden dann sagen:

Delphi-Quellcode:

with DefCipherClass.Create('',nil) do
begin
  HashClass := DefHashClass;
  InitKey(PW,nil);
  CodeStream();
  Free;
end;

MfG,
Daniel.