Dateien verschlüsseln - aber wie?

[daniel-volk]

Hello world!

Ich hab ja jetzt mein Programm so weit, dass es schon ganz vernünftig läuft.
Aber eine Sache gefällt mir noch nicht:
Bis 10MB ist das alles überhaupt kein Problem, 20MB dauern etwas - gehn aber immer noch schnell - und 40MB dauern ewig. Das Verschlüsseln geht dabei immer noch, aber das Entschlüsseln ist ein Katastrophe! Das dauert viel zu lange!
40MB dauern abgesehen davon mindesten 10mal so lange wie 10MB. Und das wird wohl daran liegen, dass ich mit dem MemoryStream arbeite und der den Arbeitsspeicher dann zu sehr ausfüllt. Und wenn Win dann erst anfängt in die Auslagerungsdatei zu schreiben, dann hab ich eh verloren...

Der aktuelle Code sieht jetzt so aus:

Delphi-Quellcode:

// Datei entschlüsseln
function TFrmCipher.DecodeFile(Input, Output, Passwd: String): Boolean;
var
  SrcStream, DestStream: TStreamProgressAdapter;
  TempStream: TMemoryStream;
  NewHeader, OldHeader: TFileHeader;
begin
  Button13.Show;
  ProgressBar1.Show;
  LbProgress.Show;
  FrmCipher.Refresh;
  result := False;
  SrcStream := TStreamProgressAdapter.Create(TFileStream.Create(Input, fmOpenRead or fmShareDenyNone),Handle);
  if Assigned(SrcStream) then
  begin
    try
      DestStream := TStreamProgressAdapter.Create(TFileStream.Create(Output, fmCreate),Handle);
      if Assigned(DestStream) then
      begin
        try
        TempStream := TMemoryStream.Create;
        if Assigned(TempStream) then
        begin
          try
            LbProgress.Caption := 'Die Datei wird entschlüsselt... (1/3)';
            FrmCipher.Refresh;
            with DefCipherClass.Create('', nil) do
              begin
                try
                  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
                finally
                  Free;
                end;
              end;
              TempStream.Seek(0,sofrombeginning);
              // Der FileHeader wird gelesen
              TempStream.ReadBuffer(OldHeader,SizeOf(TFileHeader));
              DestStream.FMax := TempStream.Size - TempStream.Position;
              LbProgress.Caption := 'Die entschlüsselte Datei wird aus dem Arbeitsspeicher in die Zieldatei geschrieben... (2/3)';
              FrmCipher.Refresh;
              DestStream.CopyFrom(TempStream,TempStream.Size-TempStream.Position);
              DestStream.Seek(0,sofrombeginning);
              LbProgress.Caption := 'Der Hash-Wert der entschlüsselten Datei wird berechnet... (3/3)';
              FrmCipher.Refresh;
              with DefHashClass.Create(nil) do
              begin
                try
                  NewHeader.HashString := CalcStream(DestStream,DestStream.Size,nil,DefFileStringFormat);
                finally
                  Free;
                end;
              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;
  If NewHeader.HashString = OldHeader.HashString then
  result := true else
  result := false;
  LbProgress.Caption := '';
  LbProgress.Hide;
  ProgressBar1.Hide;
  Button13.Hide;
end;

// Datei verschlüsseln
function TFrmCipher.EncodeFile(Input, Output, Passwd: String): Boolean;
var
  SrcStream: TStreamProgressAdapter;
  DestStream: TFileStream;
  TempStream: TStreamProgressAdapter;
  FileHeader : TFileHeader;
begin
  Button13.Show;
  ProgressBar1.Show;
  LbProgress.Show;
  FrmCipher.Refresh;
  result := False;
  SrcStream := TStreamProgressAdapter.Create(TFileStream.Create(Input, fmOpenRead or fmShareDenyNone),Handle);
  if Assigned(SrcStream) then
  begin
    try
      DestStream := TFileStream.Create(Output, fmCreate);
      if Assigned(DestStream) then
      begin
        try
          TempStream := TStreamProgressAdapter.Create(TMemoryStream.Create, Handle);
          if Assigned(TempStream) then
          begin
          try
          SrcStream.Seek(0,sofrombeginning);
          LbProgress.Caption := 'Der Original-Hash-Wert wird berechnet... (1/3)';
          FrmCipher.Refresh;;
          with DefHashClass.Create(nil) do
          begin
            try
              FileHeader.HashString := CalcStream(SrcStream,SrcStream.Size,nil,DefFileStringFormat);
            finally
              Free;
            end;
          end;
          TempStream.FMax := SizeOf(TFileHeader);
          TempStream.Seek(0,sofrombeginning);
          TempStream.Write(FileHeader, sizeof(TFileHeader));
          LbProgress.Caption := 'Die Originaldatei wird in den Arbeitsspeicher kopiert... (2/3)';
          FrmCipher.Refresh;
          SrcStream.Seek(0,sofrombeginning);
          TempStream.FMax := TempStream.Size + SrcStream.Size;
          TempStream.CopyFrom(SrcStream,SrcStream.Size);
          TempStream.Seek(0,sofrombeginning);
          DestStream.Seek(0,sofrombeginning);
          LbProgress.Caption := 'Die Datei wird verschlüsselt... (3/3)';
          FrmCipher.Update;
          with DefCipherClass.Create('', nil) do
          begin
            try
              Mode := DefCipherMode;
              HashClass := DefHashClass;
              InitKey(Passwd, nil);
              EncodeStream(TempStream, DestStream, TempStream.Size);
            finally
              Free;
            end;
          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;
  ProgressBar1.Hide;
  LbProgress.Caption := '';
  LbProgress.Hide;
  Button13.Hide;
end;

Wie ihr sehen könnt, gehe ich bei der Verschlüsselung nach folgender "Formel" vor:
Ziel := AES-Verschlüsselung([Header mit Hash-Wert]+Originaldatei);
(Ich hoffe mal das ist so verständlich.)

Das Problem bei der Geschichte ist halt nur, dass ich den Header nur in einem Zug mitverschlüsseln kann, wenn er in einem Stream mit der Datei steht. Ansonsten gibt das zwischendurch einen Schnitt, der dann wiederum bewirkt, dass die Verschlüsselung hinter dem Header neu beginnt. Und dann ist der Random-Effekt, den ich durch die Kombination von Header und Cipher Block Changing erziele, hin.

Noch schlimmer wird die Sache beim Entschlüsseln, weil ich da dann das Problem bekomme, dass ich den Header erst nach dem Entschlüsseln entfernen kann, was aber auch aus Sicherheitsgründen so sein muss.

Also hier mein genaues Ziel:
1) Die Bearbeitungsgeschwindigkeit soll maximiert werden und die Speicherauslastung gleichzeitig minimiert.
2) Es darf - genau wie jetzt - nur einmal eine Ausgabedatei geschrieben werden. Die Quelldatei darf nicht verändert werden.
3) Die Sicherheit darf nicht leiden. Soll heißen: Dateien, die mit dem Algo oben verschlüsselt wurden, sollen mit dem neuen Algo wieder zu entschlüsseln sein! Das stellt dann sicher, dass es auch wirklich keinen Schnitt zwischen Hash und Datei gibt!
4) Kurz gesagt: Es soll alles so sein wie oben nur eben optimiert.

Ich hab schon einige Sachen in Gedanken versucht, bin dann aber immer wieder auf irgendwelche Probleme gestoßen. Vielleicht fällt einem von euch ja der Stein der Waisen ein.

Ciao,
Daniel.

[Luckie]

Genau daran überlege ich auch noch, wie man das am effektivsten hinbekommt.

[daniel-volk]

Aha, dann steh'n wir ja jetzt vor dem gleichen Problem.

@ Hagen:
Wie ist das denn beim neuen DEC? Baust du da Funktionen ein, die leichter zu verwenden sind? Dann würde ich dich auch bitten, dass du den Funktionen auch die Eigenschaft OnProgress zuweist.
Und es sollte eben auch so sein, dass keine Temp-Datei geschrieben wird. Eine Festplatte ist ja schließlich kein Arbeitsspeicher.
Kleinere Streams oder so kannst du ja auch problemlos in den Arbeitsspeicher auslagern, aber eben schlecht größere Dateien.

MfG,
Daniel.

[negaH]

Zitat:

Wie ist das denn beim neuen DEC? Baust du da Funktionen ein, die leichter zu verwenden sind? Dann würde ich dich auch bitten, dass du den Funktionen auch die Eigenschaft OnProgress zuweist.
Und es sollte eben auch so sein, dass keine Temp-Datei geschrieben wird. Eine Festplatte ist ja schließlich kein Arbeitsspeicher.
Kleinere Streams oder so kannst du ja auch problemlos in den Arbeitsspeicher auslagern, aber eben schlecht größere Dateien.

Bis zum Wochenende habt ihr die neueste Version.
Darin enthalten sind die neuen Registrations Funktionen die auch dafür sorgen das man die Identity benutzen kann um sie in Stream zu speichern.
Ich baue auch ein Skelett für die Benutzung der Ciphers zur Verschlüsselung von Stream's mit ein die zusätzliche Headers enthalten. Allerdings die Verschlüsselung/Entschlüsselung einer Datei läuft immer über eine zusätzliche neue Datei ab. Das hat mehrere Gründe. Man könnte auch eine inplaced Datei-Verschlüsselung coden, diese würde aber enorm kompliziert werden, da durch die zusätzlichen Header sich die Dateigröße vergrößert. Man muß dann per temporären Buffern und interleaved Read/Write Operationen arbeiten.

Das OnProgress Event wird nicht mehr benutzt, da es nicht Threadsafe ist. Ich denke darüber nach die Skelett Funktionen durch ein IProgress-Interface auszubauen. Dieses kann dann den Funktionen übergeben werden.

Allerdings, eines ist jetzt schon klar: das neue DEC ist eine Neuentwicklung und keine direkte Nachfolgerversion vom DEC v3.0. Es wurden sehr viele Sachen geändert, entfernt oder hinzugefügt:
- nur noch ab Delphi 5 lauffähig, da overloads usw. benutzt werden
- Klassen Hierarchie wurde abgespeckt, TProtection gibts nicht mehr
- DEC's Exception's wurden abgespeckt, es gibt nun nur noch EDECException
- Klassen Registration wurde aus DEC v4.0 übernommen und ist einheitlich, zusätzliche Enum Functions
- TString_Format Klassen wurden in eigene Unit ausgelagert und vollständig überarbeitet
- Neue Hash-Algorithmen SHA256,SHA384,SHA512,Panama,Whirlpool 0/1
- alle Hash-Algo's nutzen Tol's optimierte Assembler Umsetzungen, im gesamten sind alle Hash somit ca. 80% schneller
- Cipher wurden alle überarbeitet, und so einige gravierende Fehler beseitigt
- es wurden neue wichtige Ciphermodis hinzugefügt, z.B. cmCFBx, cmOFBx, cmCFSx, cmCFS8
- Modus cmCFBx mit Blowfish verwendet ist identisch mit dem offiziellen CFB64 Modus
- alle Cipher arbeiten nun nicht mehr zwingend inplaced, was mit geänderten Ciphermodis dazu führt das zB. Blowfish 40Mb/sec statt 30Mb/sec oder Rijndael 47MB/sec statt 38Mb/sec schnell sind.
- alle SelfTest's wurden entfernt und müssen durch ein externes Projekt verifiziert werden, dies spart enorm Resourcen, und ist eigentlich auch sicherer.
- die Cipher arbeiten beim Keysetup im Standardmodus, d.h. die Cipher machen nun keine Umwandlung des Paswortes per Hashfunktion in einen Sessionkey mehr. Dies ist nun Aufgabe des Programmierers. Der Grund ist das besonders diese KDF's (Key Derivation Functions) sich weiterentwickelt haben und es dem Programmierer überlassen bleiben muß wie der das Passwort konvertiert. Zusätzlich werden die Cipher's dadurch von Aufgaben entlastet die nicht zu ihnen gehören.
- bei ALLEN Algos wurde strikt darauf geachtet das wenn sie NICHT benutzt werden auch GARNICHTS zusätzlich in die EXE eingelinkt wird. D.h. der Compiler/Linker kann jederzeit alle Daten/Tabellen usw. die zu einem Algo gehören, der nicht benutzt wird, wegoptimieren. Benutzt man z.B. nur Rijndael + SHA so werden nur ca. 16Kb eingelinkt.
- neue zusätzliche Units:
- CRC.pas um eine universelle CRC Checksum Library zu haben, mit ihr können ALLE möglichen 2-32 Bit CRC's erzeugt werden
- CPU.pas eine Unit zu Ermittlung der CPU Daten + CPU Speed
- alle TRandom Klassen wurden entfernt

Fehlen tut jetzt noch:
- Hash MAC's
- RFC2289 Konvertierungen
- DEC eigene KDF die die schlechte IEEE KDF1 ersetzen könnte
- eventuell packe ich noch meine sehr effiziente LZH Komprimierungs Unit mit rein
- Ersatz des enifachen Zufallsgenerators durch einen YARROW ähnlichen sicheren Zufallsgenerator. Dieser kann dann als AddOn direkt den integrierten RNG ersetzen.



Gruß Hagen

[Luckie]

Zitat:

- bei ALLEN Algos wurde strikt darauf geachtet das wenn sie NICHT benutzt werden auch GARNICHTS zusätzlich in die EXE eingelinkt wird. D.h. der Compiler/Linker kann jederzeit alle Daten/Tabellen usw. die zu einem Algo gehören, der nicht benutzt wird, wegoptimieren. Benutzt man z.B. nur Rijndael + SHA so werden nur ca. 16Kb eingelinkt.

Hm, dann lohnt es sich ja doch wieder das ganze ohne VCL zu machen. Nur müßte ich da wahrscheinlich wieder ganz von vorne anfangen.

[negaH]

Eigentlich ist es aus Sicht vom DEC egal ob du VCL oder NonVCL arbeiten willst.
DEC selber baute schon immer nur auf Objecten + Klassesn aus Classes.pas auf.
D.h. es benutzte aus Unit Classes.pas nur die TStream's. Daran hat sich auch nichts geändert.
Das neue DEC ist insofern abgespeckt das es die von mir gehassten THashManager/TCipherManager Komponenten nicht mehr enthält. Schlußendlich ist das neue DEC eine reine Sammlung von symmetrischen Algorithmen die in Klassen gekapselt sind. Im alten DEC war es aber so das viele Benutzer über die Manager Komponenten direkt oder indirekt gearbeitet haben. Damit das funktioniert musste eine Auswahl von Algorithmen registriert werden. Jeder registrierte Algo wird aber, egal ob tatsächlich benutzt oder nicht, in die EXE eingelinkt. Somit machte die Integration vom DEC ohne manuelle Konfiguration die EXE bis zu 500Kb größer als tatsächlich benötigt.
Im neuen DEC muß der Programmierer der eine Auswahl von Algos benutzen will diese Auswahl explizit registrieren. Macht er das nicht, so werden nur die Algos eingelinkt die hardcoded benutzt wurden. D.h. werden direkt TCipher_Rijndael + THash_SHA1 benutzt so werden nur die Klassen TDECObject + TDECHash + THash_SHA + THash_SHA1 + TDECCipher + TCipher_Rijndael und deren Datentabellen eingelinkt. Werden über TCipher_Blowfish.Register + TCipher_RC6.Register zusätzlich diese beiden Cipher registriert so werden diese ebenfalls eingelinkt. Der Programmierer hat nun die Möglichkeit über die Registrations-Funktionen die Klassen TCipher_Rijndael + TCipher_Blowfish + TCipher_RC6 + THash_SHA1 + THash_SHA dynamisch über deren Namen oder Identity anzusprechen.

Betrachtet man VCL strikt als "Visual Component Library" dann dürfte man die Klassen in Unit Classes.pas nicht so ohne weiteres hinzuzählen, da sie fast ausschließlich Non-Visuell sind.
Ich kenne keine professionellen Packages die NICHT die Unit Classes.pas benutzen. Deshalb werde ich auch in Zukunft nicht auf die Funktionalitäten wie TStream aus Classes.pas verzichten.

Für deine eigenen Funktionen ändert sich fast garnichts, wenn du auf die Standard-Methoden der DEC Objecte zurückgegriffen hast. An diesen Schnittstellen habe ich fast nichts geändert.
Der wohl relevanteste Unterschied für dich sollte TCipher_XXX.InitKey() sein. Diese Methode und deren Funktionalität existiert nicht mehr ! Sie sollte durch andere Methoden, die wesentlich sicherer sind, ersetzt werden. Diese Änderungen sollten aber enorm leicht durchführbar sein.

Statt:

Delphi-Quellcode:

with CipherClass.Create('', nil) do
try
  HashClass := THash_SHA1;
  Mode := cmCTS;
  InitKey(Password, nil);
  EncodeStream(Source, Dest, Source.Size - Source.Position); 
finally
  Free;
end;

wird nun:

Delphi-Quellcode:

with CipherClass.Create do
try
  Mode := cmCTSx;
  Init(THash_SHA1.KDFx(Password, Salt, Context.KeySize, TFormat_Copy));
  EncodeStream(Source, Dest, , Source.Size - Source.Position);
finally
  Free;
end;

Der Aufruf von THash_SHA1.KDFx(Password, Salt, Context.KeySize, TForma_Copy) produziert einen binären String der das Password + Salt und SHA1 konvertiert. Dabei wird dieser binäre Wert exakt so lang sein wie die maximale Schlüsselgröße die der Cipher benutzen kann. Dies ist in mehrfacher hinsicht besser als im alten DEC
1.) es wird immer die maximale Schlüsselgröße benutzt, im alten DEC war dies nicht so
2.) es ist für den Programmierer ERSICHTLICH was DEC tatsächlich macht, im alten DEC war diese Funktionalität versteckt in .InitKey() und produzierte viele Supportmails mit der Anfrage warum die Standard Algos im DEC nicht kompatibel zu den Standards wären.
3.) die KDF = Key Derivation Function im neuen DEC sind Standards und erheblich sicherer als die Methode im alten DEC
4.) das Passwort wird erheblich besser geschützt
5.) Brute Force Attacken/Dictionary Attacks auf das reale Passwort sind wesentlich schwerer

Gruß Hagen

[daniel-volk]

Zitat:

Allerdings die Verschlüsselung/Entschlüsselung einer Datei läuft immer über eine zusätzliche neue Datei ab.

Wie jetzt? Wenn ich sage CodeFile(), dann wird doch nur die Datei selbst verschlüsselt und zwar ohne Header etc. Wenn ich CodeStream nehme, dann mache ich das alles ja sowieso selbst.
Hast du da noch eine weitere Datei eingebaut?

Was ist mit dem File-wipen? Die Funktion gibt es doch hoffentlich noch, oder?
Ansonsten hört sich das neue DEC schon ganz gut an. Wird das wieder offizielle Freeware?

MfG,
Daniel.

[negaH]

Also, es gibt drei Wege eine Datei zu bearbeiten
1.) inplaced, nur die Datei wird geöffnet und der Inhalt mit dem neuen Inhalt überschrieben. Danach wird die Datei umbenannt. Dies ist am Resourceschonenden aber ziemlich schwer zu programmieren, besondors wenn sich Dateninhalte in ihrer Größe verändern und somit Verschiebungen entstehen. Dies kann man nur über intelligente und dynamisch Buffer erledigen. Ich habe einmal so was für einen Texteditor gecodet, nie wieder !
2.) kopieren, dabei wird die Ausgangsdatei und die Zieldatei geöffnet. Der Inhalt wird kopiert und verschlüsselt und in die neue Datei geschrieben. Danach hat man die neue verschl. Datei inklusive dem Original. Genau so wird DEC arbeiten, da dadurch einige Probleme klein gehalten werden.
3.) es werden die Ausgangsdatei + ZielDatei + Temporäre Datei benötigt. So arbeitet dein Code.

Gruß Hagen

[mirage228]

Hi Hagen!

Und was ist in dem Fall, das der Nutzer die Quelldatei behalten möchte? Erstellt und dann einfach eine Kopie vom Original und verschlüsselst die?

mfG
mirage228

[negaH]

Zitat:

Und was ist in dem Fall, das der Nutzer die Quelldatei behalten möchte? Erstellt und dann einfach eine Kopie vom Original und verschlüsselst die?

Fall 2.) ermöglicht genau dies. Die Ausgangsdatei wird readonly geöffnet und deren Inhalt in eine neue Datei verschlüsselt und verändert hineingeschrieben. So arbeitet DEC.
Die Originaldatei bleibt erhalten wie gewünscht, kann aber im DEC per Wipe auf sichere Art und Weise gelöscht werden, falls dies erwünscht ist.

Gruß hagen