Dateien verschlüsseln - aber wie?

[negaH]

@Luckie:

Zitat:

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

Ich arbeite, arbeite und arbeite sehr hart daran. DEC version 3.0 erzeugt diese Identities als Word, was leider nicht ausreicht.
Momentan bin ich am ausmisten und "neuerschaffen" der DEC Formate/Hashs/Ciphers. Das Klassenkonzept wurde enorm stark reduziert, und somit wird einiges an Resourcen gesparrt. Zusätzlich habe ich mich gleichmal dazu entschlossen die optimierten und neuen Hash Sourcen von Tol einzubauen. Es wird also demnächst SHA256, SHA384, SHA512, bugfixed Haval, Panama, Whirlpool 0/1, Snefru 128/256 und bugfixed Sapphire geben. Im gesammten wurde die Performance alle Hashs um 80% gesteigert.

Im neuen DEC wird mit Stream.Write(Hash.Identity) ein Cardinal gespeichert. Mit HashByIdentity(Stream.ReadCardinal) wird die registrierte Hashklasse ermittelt.

Bis jetzt habe ich durch diese Reorganisationen ca. 100Kb an Code gesparrt.

Gruß Hagen

[Luckie]

Ach so, sorry, du arbeitets noch dran, ich dachte das wäre schon drin. Dann laß dir nur Zeit.

[daniel-volk]

@ Hagen:

Hi,

eine Frage ist mir noch unbeantwortet:
Mit welcher Schlüssellänge arbeitet Rijndael im DEC? 128 Bit oder 256 Bit?

Danke,
Daniel.

[negaH]

Cipher.MaxKeySize = Bytes der maximal nutzbaren Keylänge.
Wird mit Cipher.InitKey() gearbeitet so wird intern das Passwort mit hilfe von Cipher.HashClass in einen Sessionkey umgewandelt. Ist diese Funktion zB. MD4 dann würde somit mit 128 Bit Sessionkey gearbeitet.
Es gibt aber drei wichtige Größen eines Ciphers die die Eigenschaften bestimmen:
1.) MaxKeySize = maximal nutztbares Keymaterial, bei 128Bit sagt man es ist eine 128 Bit Verschlüsselung
2.) BlockSize = Datenbreite mit der der Algo. intern arbeitet, 1 Byte sind die meisten StreamCipher, 8-16 Bytes die meisten BlockCipher
3.) reale KeyBitSize / Wahrscheinlicheit für Password-Wörterbuch attacke IST die reale Sicherheit

Also, 1.) gibt die offizielle Sicherheit an, und es hört sich immer schön an wenn man behaupten kann das man einen 1024 Bit Algo. benutzt. Allerdings kann durch 3.) die Sicherheit des Algo. auf NULL gehen, nämlich wenn als Passort "A" benutzt wird. "A" stammt aus einen Alphabeth aus 256 Zeichen, wobei "A" selber aber mit 1/26 Wahrscheinlichkeit tatsächlich vorkommt. Nun noch diese 5 Bit durch die Wahrscheinlicht dividieren das eine Wörterbuchattack mit "A" beginnt und übrig bleibt 0 Prozent Sicherheit ! Selbst mit einen 13476 Trillion Bitcipher wäre eine simple 56 Bit DES mit echten 56 Bit Schlüssel weitaus sicherer.

Es ist also wichtig das wenn man eine 128 Bit Verschl. benutzten will das man auch ein echtes 128 Bit Passwort benutzt. Ein Passwort wie "Dies ist mein Passwort" hat bei weitem KEINE 128 Bit Datengehalt.

Im alten DEC wird zur Erzeugung des Sessionkeys einfach der Hashdigest vom übergeben Passwort benutzt. Dies bedeutet das entweder der Hashdigest kürzer als die mögliche Bitlänge des Passwortes des Ciphers ist, oder aber das der Hashdigest zu lang ist und Keymaterial abgeschnitten wird. Dieses Vorgehen ist besser als ohne Hashfunktion zu arbeiten und trotzdem nicht gut. Im neuen DEC wird dies eliminiert und eine sogenannte "KDF = Key Derviation Function" benutzt. Diese erzeugt aus dem Passwort per Hashfunktion exakt soviele Bytes wie der Cipher schlucken kann.

Rijndeal.MaxKeySize = 32, somit 256 bit.

Gruß Hagen

[daniel-volk]

Das heißt für mich mit SHA-1 und AES also, dass mein System mit maximal 160 Bit arbeitet. Würde ich einen anderen Hash (MD5 oder so) verwenden, dann könnten das auch 256 Bit sein. Ist das korrekt?
Was passiert denn mit den Leerstellen? Die bleiben doch nicht unverschlüsselt, oder? Bei Rijndael ja auf jeden Fall nicht, weil AES ja eine variable Keylänge hat.

Wann gibt es denn das neue DEC?

Gruß,
Daniel.

[negaH]

Zitat:

Das heißt für mich mit SHA-1 und AES also, dass mein System mit maximal 160 Bit arbeitet. Würde ich einen anderen Hash (MD5 oder so) verwenden, dann könnten das auch 256 Bit sein. Ist das korrekt?

Jain :) Ein Cipher initialisiert sich selber immer so das er den Inputkey durch eine Transformation auf seinen kompletten Schlüsselraum verteilt. Im Prinzip wohlgemerkt. Es gibt aber hier Abweichungen von Cipher zu Cipher. Einige nehmen das Passwort direkt ohne Keyshedduling, andere wiederum initialisieren sich abhängig von der Länge des Inputs und die neueren spreizen das Keymaterial auf deren maximale Keylänge auf. D.h. ein Passwort "Test" würde in Rijndael auf 256 Bit's gestreckt und eine andere Initialisation als "Test1" erzeugen. Wie gesagt dies ist abhängig vom Cipher. Generell hängt es, egel ob gutes oder schlechtes Keyshedulling, aber nur von der Länge des Passwortes ab.

Nun, würdest du ein 256 Bit Zufallspasswort mit SHA1 und Rijndeal nehmen so würde SHA1 dieses gute Passwort in ein weniger gutes 160 Bit Passwort transformieren und Rijndael damit seine 256 Bit Initialisierung machen. Dazu werden die 160Bit mit Nullen am Ende expandiert auf 256 Bits.
Nun, angenomen 256 Bit AES heist 2^256 mögliche Passwörter und eines von diese wäre 160Bit Hash + 96Bit 0 ! Somit wäre die Sicherheit dennoch 256 Bits, aber nur 160Bit Passwörter * 2^96 würden benutzt.

Entscheidend bei solchen Größen ist dann nicht mehr der Cipher sondern NUR das er die Wahrscheinlichkeiten der Sicherheit extakt gleich auf alle möglichen Passwörter in seinem Schlüsselraum verteilt. Der Schlüsselraum bei AES ist 2^256, ein gutes Beispiel für Un-Gleichverteilung ist DES. In diesem gibt es 2^56 mögliche Schlüssel, aber viele dieser Schlüssel sind schwächer als die anderen. In Blowfish tritt das gleiche Phenomen auf. In AES nicht.
Ein Schlüsselraum von 2^128 gilt allgemein als sicher, aber ein Passwort wie "A" in diesem Schlüsselraum ist in jedem Falle unsicher.

Somit sind "kurze" Passwörter garnicht das Problem da ein zu kurzes Passwort aufgefüllt mit Nullen exakt in den Schlüsselraum hineinpasst. Problematischer sind zu lange Schlüssel da diese dann gutes Schlüsselmaterial verschwenden und eine Sicherheit suggerieren die nicht existiert. Auch eine 256Bit hashfunktion reduziert die Sicherheit eines 360Bit Schlüssels !

Zitat:

Was passiert denn mit den Leerstellen? Die bleiben doch nicht unverschlüsselt, oder? Bei Rijndael ja auf jeden Fall nicht, weil AES ja eine variable Keylänge hat.

Diese Frage verstehe ich nicht ganz, was sind Leerstellen ?
Alles in der Kryptographie läuft binär ab, eine Leerstelle im eigentlichen Sinne gibt es dann nicht, denn auf Byteebene = 256 mögliche Zeichen werden auch alle 256 Zeichen berücksichtigt und benutzt.

Zitat:

Wann gibt es denn das neue DEC?

Die Grundlagen, Hashs, Formate, CRC's sind fertig. Es fehlen noch die Cipher. Diese werden von 40 Stück stark reduziert. Es wird also nur noch eine Auswahl geben. Allerdings dies ist nicht das eigentliche Problem. Viel problematischer ist die Frage wie die Cipher in Zukunft benutzt werden sollen. Ich streite mich noch mit mir selber über die Frage ob die Cipher nun Low-Level-Algos. oder Higher-Level-Algos. sein sollen. Im bisherigen DEC sind es Low-Level-Algos. bei denen der Benutzer wissen muß wie er was mit den Cipher macht. Zb. Messagepaddings, Blocksize berücksichtigen, Header einfügen und rausnehmen, Progresscallbacks usw. D.h. die bisherigen Cipher sind nur die Algos. und ein bischen Interface. Da dies im DEC nirgendswo implizit steht haben viele Benutzer falsche Vorstellungen entwickelt was z.B. Cipher.EncodeStream() wie macht.
Würde ich aber dies "benutzersicher" machen, dann hiese das aber das die Cipher nicht mehr universell nutzbar sind und alles was ver/entschlüsselt wird eben DEC spezifisch ist.

Gruß Hagen

[daniel-volk]

Danke erstmal. Ich verwende jetzt SHA1 (also mit 160 Bit) und das soll mir dann an Sicherheit reichen. Man muss ja nur mal bedenken, dass Steganos lediglich 128 Bit verwendet. Und dann werden meine 160 Bit wohl mehr als genug sein.

Zitat:

Zitat:

Zitat:

Was passiert denn mit den Leerstellen? Die bleiben doch nicht unverschlüsselt, oder? Bei Rijndael ja auf jeden Fall nicht, weil AES ja eine variable Keylänge hat.

Diese Frage verstehe ich nicht ganz, was sind Leerstellen ?
Alles in der Kryptographie läuft binär ab, eine Leerstelle im eigentlichen Sinne gibt es dann nicht, denn auf Byteebene = 256 mögliche Zeichen werden auch alle 256 Zeichen berücksichtigt und benutzt.

Du hast Sie schon in der ersten Frage beantwortet. Ich meinte mit Leerstellen einfach nur die unbelegten Bits, die dann mit Nullen aufgefüllt werden. (Also bei einem 160 Bit Hash und 256 Bit Cipher.) Ich hatte mir schon gedacht, dass die 0 werden, hab darin (bei meinem wenigen Wissen über diese Profi-Cipher) dann aber ein Sicherheitsrisiko darin befürchtet. Und das wäre es bei einfachen Algos ja auch.

Zitat:

Zitat:

Zitat:

Wann gibt es denn das neue DEC?

Die Grundlagen, Hashs, Formate, CRC's sind fertig. Es fehlen noch die Cipher. Diese werden von 40 Stück stark reduziert. Es wird also nur noch eine Auswahl geben. Allerdings dies ist nicht das eigentliche Problem. Viel problematischer ist die Frage wie die Cipher in Zukunft benutzt werden sollen. Ich streite mich noch mit mir selber über die Frage ob die Cipher nun Low-Level-Algos. oder Higher-Level-Algos. sein sollen. Im bisherigen DEC sind es Low-Level-Algos. bei denen der Benutzer wissen muß wie er was mit den Cipher macht. Zb. Messagepaddings, Blocksize berücksichtigen, Header einfügen und rausnehmen, Progresscallbacks usw. D.h. die bisherigen Cipher sind nur die Algos. und ein bischen Interface. Da dies im DEC nirgendswo implizit steht haben viele Benutzer falsche Vorstellungen entwickelt was z.B. Cipher.EncodeStream() wie macht.
Würde ich aber dies "benutzersicher" machen, dann hiese das aber das die Cipher nicht mehr universell nutzbar sind und alles was ver/entschlüsselt wird eben DEC spezifisch ist.

Die Frage kann ich dir einfach beantworten:
Mach beides. Ich persönlich hätte lieber die fertige Variante gehabt, aber mit der jetzigen bin ich auch ganz gut klargekommen.
Dennoch ist es sicherlich für den Anfänger immer sicherer, wenn der Cipher einfacher zu verwenden ist. Mach es doch so:
Du lässt es wie es jetzt ist, fürst dann aber noch Funktionen zu professionellen vorgegebenen Verschlüsseln etc ein.
Also z.B.:

Delphi-Quellcode:

//Die Funktionen zum vorgefertigten Verarbeiten von Daten (gleich mit speichern von Zufallsdaten, Hash etc)
function CompletelyEncodeString()
function CompletelyDecodeString(): boolean; //Ausgabe: Hash-Werte stimmen überein
function CompletelyEncodeFile(CipherClass, HashClass, Passwd...)
function CompletelyDecodeFile() //Cipher und Hash sind im Header gespeichert und werden automatisch verwendet

// Und natürlich noch die normalen Funktionen, wie sie jetzt existieren

Ich fände es so am besten. Dann kann man nämlich, wenn man selbst nicht so viel Ahnung hat, deine Funktionen verwenden und kann sich dennoch sicher sein, dass es professionell verschlüsselt ist.

Aber ich weiß natürlich auch, dass es kein unerheblicher Arbeitsaufwand ist das so zu gestalten, dass die Leuts das dann auch vernünftig verwenden können. :?

MfG,
Daniel.

[Luckie]

Mal eine dumme Frage: Wie lautet im DEC die CipherClasse zu Rijndael? TCipher_Rijndael ist es nicht. Ich wollte mich jetzt auch von BlowFish verabschieden.

Du verschlüsselts den Header mit, wenn ich da sin deiner Hilfe richtig gelesen habe.

[daniel-volk]

Für Rijndael musst du zusätzlich zur Unit Cipher auch noch Cipher1 implementieren. :-)
Dann ist es TCipher_Rijndael!

MfG,
Daniel.

[Luckie]

Hm, das soll mal einer wissen. Besten Dank.

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

[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. :gruebel: Nur müßte ich da wahrscheinlich wieder ganz von vorne anfangen. :roll:

[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

[daniel-volk]

Hi,

ich möchte bei meinem CryptMaster vor der großen Änderung im Bezug auf das neue DEC erst noch einmal die Performance mit dem alten DEC verbessern (muss mich ins neue DEC dann ja erstmal einarbeiten ;-) ).

Dafür werde ich u.A. auch mit einer TEMP-Datei arbeiten, damit der Arbeitsspeicher nicht mehr so stark belastet wird.

Aber zudem möchte ich noch weitere Änderungen vornehmen: Ich möchte nicht mehr SHA-1 verwenden und stattdessen einen Hash mit 256Bit. Welchen kannst du mir von denen, die im alten DEC enthalten sind, da am ehesten empfehlen? Es gibt nicht um Geschwindigkeit, sondern lediglich um Sicherheit.

Außerdem habe ich vor, auch bei der Verschlüsselung von Dateien einen Random-String hinter dem Hash-Wert mit anzuhängen. Aber wie groß ist die Blockgröße bei Rijndael? Der Hash mit 256 Bit hat ja nun 32 Byte. Angenommen ein Block hätte 1024 Byte, dann müsste ich ihn aus Sicherheitsgründen mit 992 Byte auffüllen. Wäre also nett, wenn du mir die Blockgröße sagen könntest.

Ja, das war's eigentlich schon.

MfG,
Daniel.

[negaH]

Zitat:

Aber zudem möchte ich noch weitere Änderungen vornehmen: Ich möchte nicht mehr SHA-1 verwenden und stattdessen einen Hash mit 256Bit. Welchen kannst du mir von denen, die im alten DEC enthalten sind, da am ehesten empfehlen? Es gibt nicht um Geschwindigkeit, sondern lediglich um Sicherheit.

Du meinst zur Erzeugung des Sessionkeys aus dem Passwort ?
Im neuen DEC würde ich SHA256 empfehlen, aber....
In deinem Falle ist SHA1 mit echten 160Bits gut, du könntest aber auch RipeMD256 nehmen, allerdings meinen die Experten das dieser nicht sicherer als 128 Ripe MD wäre, da eben nur ein Derivat davon.
Im alten DEC gibt es bis auf Sapphire in fakt keinen Hash mit mehr als effektiven 160 Bits. Man muß stark differenzieren ob einen Hash funktion mit 256,384,512 Bits diese Digest real produzieren oder aber nur durch Anwendung eines kleineren Bruders. Bei Ripe MD ist dies der Fall. Der 256 Bit RipeMD ist ein Trick der auf 128 Bit RipeMD basiert. Trotzdem würde ich Sappihre nicht empfehlen, da er eigentlich ein umgebauter Cipher ist. Besser wäre dann schon Haval, denn der produziert echte 256 Bit.

Zitat:

Außerdem habe ich vor, auch bei der Verschlüsselung von Dateien einen Random-String hinter dem Hash-Wert mit anzuhängen. Aber wie groß ist die Blockgröße bei Rijndael? Der Hash mit 256 Bit hat ja nun 32 Byte. Angenommen ein Block hätte 1024 Byte, dann müsste ich ihn aus Sicherheitsgründen mit 992 Byte auffüllen. Wäre also nett, wenn du mir die Blockgröße sagen könntest.

Die Blockgröße von Rijndael ist = .BufferSize. Im neuen DEC habe ich auch daran gearbeitet da die .BlockSize <> .BufferSize sein kann. Dies trifft aber nur auf Stream Cipher zu.
Schau dir TCipher_Rijndael.GetContext() an.

Im DEC gibts keine Cipher mit so enorm großen Blockgrößen. Meistens sind sie 8,16,24,32,64 Bytes groß.
Wenn du den Hashwert + Randomsalt als erste Daten verschlüsselst dann sollte der Randomsalt >= 16 Bytes sein und (Length(HashWert) + Length(RandomSalt)) mod Cipher.BufferSize == 0. D.h. die Gesamtlänge des Hashes + Salts sollte ein mehrfaches der Blockgröße sein. Damit umgehst du das Problem das z.B. im CBC/CTS Modus ein Padding notwendig wäre. Denn in diesen Modis müssen alle sequentiellen Daten immer in Stücken zu BufferSize Bytes dem Cipher übergeben werden. Im neuen DEC habe ich deswegen auch neue Ciphermodis implementiert. Ideal wären in diesem Falle die neuen CFBx,OFBx,CFSx Modis. Bei denen muß man nicht mehr auf dieses Blockgrößen Problem achten.

Ich arbeite daran universelle Funktionen zur ver/Entschl. von Streams in's neue DEC einzubauen. Diese wird einen Header benutzen um den verwendeten Hash/Cipher Algo. zu speichern. Desweiteren wird ein PasswortSalt eingeführt der zusammen mit dem Passwort per KDF gehasht wird. Der entstehende Wert ist der Sessionkey der immer die maximale Schlüsselgröße des Ciphers berücksichtigt. Zusätzlich dazu wird eine sichere Checksumme verschlüsselt gespeichert die es ermöglicht die Korrektheit des Passwortes zu prüfen, usw. usw. Eventuell integriere ich noch meine LHSZ Komprimierung.

Gruß Hagen

[Eagelone]

Hallo,

hab jetzt formatiert und versucht, DEC neu zu installieren.
Leider geht das jetzt nicht mehr, auch nicht nach der Anleitung in diesem Thread. Hab Delphi 7.

Hoffe, dass mir wer helfen kann!