DEC 5.1 wie benutzen?

[negaH]

Andererseits möchte ich auch nicht das das Forum hier zu einem ständigen Nörglerforum verkommt, mit Links zum Duden und so'n Quatsch. Ich habe also nichts dagegen einzuwenden das sich die deutsche Sprache auch weiterentwickeln kann. Das ist auch ein Grund dafür das ich einfach kurz und bündig darauf reagiere -> willst du Hilfe dann rede deutsch mit mir, fertig. Das mag zwar arrogant oder sonstwas erscheinen, aber die Faktenlage ist nun mal so, ich kann diesen Druck ausüben. Das heist also nicht das ich ein Nationalist oä. bin, sondern ich reagiere aktiv, statt es hinzunehmen.

Also nochmal: dein "jez" ist die Mücke die ich zum Elefanten gemacht habe. Das du dran glauben musstest lag einfach daran das ich Bock und Zeit hatte eine Kritik zu formulieren. Normalerweise antworte ich dann einfach nicht und widme mich meinen Katzen, meiner Freundin, meinen Basteleien oder sonst was Interessanterem.

Gruß Hagen

[Luckie]

Ich hänge hier mal meine Unit mit der Klasse an, um eine Datei mit dem DEC zu ver- und entschlüsseln. Ich werde dass dann noch mal richtig offiziell veröffenlichen.

[Dezipaitor]

Kurze Frage:
Sind die DEC Units closed source und nur für Freeware-Programme?
Wie kam es denn dazu?

[Die Muhkuh]

Hi,

DEC Part I ist imho open source, DEC Part II nicht.

[negaH]

Aus gegebenen Anlaß

Luckie's Unit ist ein Beispiel dafür wie man die Funktionalität vom DEC in eine Klasse kapseln kann.
DEC selber ist nur eine Zusammenstellung von vorgefertigten kryptographischen Verfahren. Mehr nicht, aber auch nicht weniger, da ich hoffe das die Qualität des DECs gerade im Source und seinen Schnittstellen sehr hoch ist.
DEC muß also nicht so wie üblich wie eine Komponente installiert werden, sondern es reicht einfach die notwendigen Units einzubinden und den Pfad auf die Source oder kompilierten Units oder Packages zu legen.

Bei der Entwicklung einer kryptographischen Bibliothek hat der Programmierer ganz besondere Anforderungen, im Gegensatz zu normalen Bibliotheken. Einige dieser Anforderungen widersprechen sich, zb. möglichst viel zu unterstützen und damit eine hohe Komplexität im Gegensatz zur kryptrographischen Sicherheit und damit möglichst anwendungssicheren und somit einfach gestrickten und denoch flexiblen Schnittstellen. Nun DEC versucht eben nicht alles zu können sondern beschränkt sich auf eine klare und sichere Schnittstelle. Daraus ergibt sich das ein Nutzer vom DEC noch einiges drumherum basteln muß und nichts im DEC quasi readymade ist.

Soweit zum Vorwort Kommen wir nun zur konkreten Aufgabe eine Datei zu verschlüsseln.

Der einfache aber unflexible und nicht ganz kryptographisch sichere Weg

Delphi-Quellcode:

procedure EncryptFile(const ASourceFileName, ADestFileName, APassword: String);
begin
  with TCipher_Rijndael.Create do
  try
    Init(APassword);
    EncodeFile(ASourceFileName, ADestFileName);
  finally
    Free;
  end;
end;

fertig. Bei diesem Source fällt folgendes auf:

- Einfachheit
- Unflexibel da der verwendete Cipheralgo. usw. nicht konfigurierbar ist
- Verfahrensunsicher da zb. nicht klar ist was passieren würde wenn ASourceFileName und ADestFileName identisch sind
- kryptographisch nicht so besonderst sicher da das APassword direkt im Cipher.Init benutzt wird und somit einige effiziente Angriffe möglich sind

Also müssen bzw. können wir das verbessern, fragt sich nur womit man am besten anfängt. Wir wollen folgendes abändern

1.) Konfigurierbarkeit
Das ist eine Forderung nach kryptographischer Sicherheit denn wenn in der Zukunft bekannt werden sollte das AES-Rijndael als Verfahren geknackt worden sein sollte dann müssen wir möglichst schnell unseren Source abändern. Sowas macht man zB. über globale Konstanten.

2.) krypto. Sicherheit inkrementieren
Wir wissen das es heute schon effiziente Angriffe auf direkt benutzte Paswörter gibt, zb. Rainbow Tabellen. Obiger Source ist dagegen anfällig also müssen wir das abändern. Nun taucht das erste wirkliche Problem auf. Wie ändern wir das ab wenn es dafür keine anerkannten Standards gibt ? Klar, wir müssen einen prohibitären Weg einschlagen, besonders bei der Frage der Datenformate usw. Wir können aber unsere benutzten Algorithmen dabei an empfohlenen Vorgehensweisen ausrichten. Diese Diskrepanz entsteht immer wenn man anfängt pure krypto. Verfahren in krypto. Protokollen anzuwenden. Es gibt PKCS, PGP, IEEE, NIST, AES, ASN1 usw. usw. Standards und alle machen es anders in ihren Datenformaten. Allen liegen zwar die gleichen mathmatisch kryptographsich orientierten Forderungen zugrunde aber was hinten rauskommt ist absolut unterschiedlich. DEC hatte sich mal vorgenommen die wichtigsten dieser Standards auch umzusetzen aber wie jeder sich denken kann ist das ne Menge Holz an Arbeit. Im Besonderen wenn man bedenkt das dies meistens kommerziell orientierte Standards sind und man sich defakto damit in seiner Bibliothek dem Goodwill dieser Konzerne aussetzt. Ergo, die Entscheidung ist die das der Endbenutzer des DECs sich selber entscheiden muß. Das heist aber auch das in der korrekten Benutzung vom DEC auch der Benutzer dieser Bibliothek Ahnung von Kryptographie haben muß. Naja meiner Meinung nach sollte jeder der Kryptographie benutzt auch das notwendige Wissen besitzen, denn nur das ist echte Sicherheit.
Zurück zum Thema: wir erhöhen die Sicherheit des APassword enorm wenn wir dazu eine randomisierte KDF benutzen. KDF bedeutet Key Derivation Function und übersetzt Schlüsselableitungsfunktion (ein schönes deutsches Wort das es exakt auf den Punkt bringt )
Eine KDF erzeugt also auf irgendeine sichere Weise aus einem Schlüssel=APassword einen anderen Schlüssel mit kryptographisch besseren Eigenschaften. Später mehr dazu.

3.) Flexibilität
Wir wissen das man in der VCL eine Datei ver-entschlüsselt über TStream Objekte. Also wäre es sinnvoll gleich damit eine Funktion zu schreiben und dann darauf aufsetztend die Ver/Entschlüsselung von Dateien. Von Haus aus kann das ja das DEC schon aber wir wollen ja auch ansonsten noch Drumherum mehr.

Also fangen wir an mit der TStream basierten Funktion und der Konfigurierbarkeit:

Delphi-Quellcode:

const
  ACipherClass: TDECCipherClass = TCipher_Rijndael;
  ACipherMode: TDECCipherMode = cmCTSx;

procedure Encrypt(ASource, ADest: TStream; const APassword: String);
begin
  Assert(ASource <> ADest, 'Encrypt(), ASource must be distinct to ADest');

  with ValidCipher(ACipherClass).Create do
  try
    Mode := ACipherMode;
    Init(APassword);
    EncodeStream(ASource, ADest, -1);
  finally
    Free;
  end;
end;

Als erstes nutzen wir Assert() um zu prüfen ob die Objekte ADest und ASource unterschiedlich sind. Sowas prüft DEC intern nicht ab da es durchaus möglich sein könnte das es eine Streamklasse geben könnte die inplaced und überlappend auf dem gleichen Datenbereich arbeitet. Ich kenne zwar sowas nicht aber möglich wäre es. In unserem Beispiel möchten wir aber sicherstellen das man nur mit zwei unterschiedlichen Streamobjekten arbeiten kann. Deshalb eine Assertion da es ja ein Programmierfehler ist wenn er auftritt.

Als nächstes erzeugen wir wieder eine Cipherinstanz, aber diesesmal überprüfen wir mit ValidCipher(ACipherClass) ob die übergebene Klassenreferenz eine gültige ist. Man könnte also ACipherClass auf nil initialisieren und ValidCipher() würde die mit DECCipher.SetDefaultCipherClass() global installierte Cipherklasse zurückgeben. Dh. DEC enthält quasi schon eine globale Variable um eine Cipherklasse, Hashklasse und DECFormat Klasse zu registrieren. Wir nutzen dieses Feature hier aber nur indirekt.
Dann initialisieren wir das Cipherobjekt, erstmal den Feedbackmodus und dann das Passwort. Und danach wird der Stream verschlüsselt.

Wir können also in Zukunft sehr schnell unsere Procedure konfigurieren. Man könnte auch alle notwendigen Parameter der Procedure Encrypt() übergeben aber das hat weniger Vorteile als man denkt. Normalerweise entscheidet sich der Programmierer für einen Algorithmus pro Algorithmentyp. Er überlässt also eben nicht die Wahl der Qual dem Anwedner seiner selbst geschaffenen Schnittstellen sondern legt alles fest. Das erhöht dann die Anwendungssicherheit und wir möchten ja das Ziel errichen das wir eine Readymade Schnittstelle haben.

Nun möchten wir aber ua. die Passwordsicherheit inkrementieren indem wir eine KDF benutzen.

Delphi-Quellcode:

const
  ACipherClass: TDECCipherClass = TCipher_Rijndael;
  ACipherMode: TDECCipherMode = cmCTSx;
  AKDFClass: TDECHashClass = THash_SHA1;
  AKDFIndex: Cardinal = 1;
  AKDFSaltSize: Byte = 16;

procedure Encrypt(ASource, ADest: TStream; const APassword: String); overload;
var 
  Salt,SessionKey: Binary;
begin
  Assert(ASource <> ADest, 'Encrypt(), ASource must be distinct to ADest');

  with ValidCipher(ACipherClass).Create do
  try
    Salt := RandomBinary(AKDFSaltSize);
    SessionKey := ValidHash(AKDFClass).KDFx(APassword, Salt, Context.MaxKeySize, TFormat_Copy, AKDFIndex);

    Mode := ACipherMode;
    Init(SessionKey);
  
    ADest.WriteBuffer(Salt[1], Length(Salt));

    EncodeStream(ASource, ADest, -1);
  finally
    Free;

    ProtectBinary(SessionKey);
    ProtectBinary(Salt);
  end;
end;

Wir erzeugen einen Zufallssalt "Salt" der 16 Bytes groß ist. Das ist also ein 16 Bytes großer Speicherbereich der mit Zufallsdaten befüllt wird. Nun wird mit Hilfe einer KDF aus diesem Salt und dem APassword ein Cipher.Context.MaxKeySize langer Wert berechnet. Dieser Wert ist auf Grund des Salt pseudozufällig und hat exakt die Größe an Bytes die nötig ist um die Sicherheit des Cipher's auszunutzen. Zb. beim AES Rijndael gibt es eine 128, 196 und 256 Bit Verschlüsselungsstärke. In unserem Beispiel nutzen wir also immer die 256 Bit Verschlüsselung des AES aus.
Auf Grund der Hashfunktion, das ist eine kryptographisch sichere Einwegfunktion, kann man nicht so ohne weiteres vom so erzeugten Sessionkey auf das Passwort zurückrechnen. Aber viel wichtiger ist eben die Eigenschaft das wenn wir die exakt gleichen Daten im Stream mit dem exakt gleichen Passwort erneut verschlüsseln wir jedesmal einen anderen Salt benutzen und somit auch jedesmal einen anderen Sessionkey erzeugen. Somit wird in ADest immer ein anderes Produkt der Verschlüsselung entstehen. Wir haben quasi über die Schlüsselableitung per zufälligem Salt einen psuedozufälligen Sessionkey erzeugt und somit eine pseudozufällige Verschlüsselung der Daten. Zu jedem der möglichen Passwörter wird es also 2^128, da 16 Bytes Salt = 128 Bit sind, verschiedene Salts und somit minimal 2^128 mögliche Sessionkeys zu einem spezifischen Passwort.
Eine Wörterbuchattacke erzeugt offline zu jedem der möglichen Passwörter die benutzten Sessionkeys. Wenn aber die KDF bei ihrer Berechnung einen 128 Bit Salt benutzt so heist dies das man nun statt nur einem Wörterbuch nun 2^128-1 mal mehr Wörterbücher erzeugen müsste. Das ist praktisch gesehen bisher unmöglich. Ergo: über diese Methode haben wir zusätzlichen kryptographsichen Schutz eingebaut und die Gesamtsicherheit des Systemes erhöht.
Der AKDFIndex ist eine Zahl mit der man die Berechnung des Sessionkeys applikationsbezogen serialisieren kann. Mit einem anderen AKDFIndex wird man also auch andere Sessionkeys produzieren.

Da der Salt zufällig gewählt wurde müssen wir diesen nun auch für die notwenige Entschlüsslung abspeichern. Also schreiben wir diesen Salt in unseren Destinationstream. Das führt zu einer Expansion der Datenmenge, dh. in ADest sind später mehr Bytes gespeichert als in ASource, hier konkret 16 Bytes == AKDFSaltSize.

Am Ende der Procedure zerstören wir den Inhalt von Salt und Sessionkey im Speicher. Das erhöht ein bischen die Anwendungssicherheit und schützt vor offline Spionagesoftware die zb. das SwapFile oder die Harddisk des Betriebsystemes auslesen kann.

Nun bauen wir drumherum die Schnittstelle um Dateien zu verschlüsseln.

Delphi-Quellcode:

procedure Encrypt(const ASourceFileName, ADestFileName, APassword: String); overload;
var
  ASource, ADest: TStream;
  ATempFileName: String;
begin
  ATempFileName := ChangeFileExt(ADestFileName, '.$$$');
  try
    ASource := TFileStream.Create(ASourceFileName, fmOpenRead or fmShareDenyNone);
    try
      ADest := TFileStream.Creare(ATempFileName, fmCreate);
      try
        Encrypt(ASource, ADest, APassword);
      finally
        ADest.Free;
      end;
    finally
      ASource.Free;
    end;
    DeleteFile(ADestFileName);
    RenameFile(ATempFileName, ADestFileName);
  except
    DeleteFile(ATempFileName);
    raise;
  end;
end;

Es hat sich bewährt bei der Verschlüsselung von Dateien erstmal die Originaldatei in eine temporäre Datei zu verschlüsseln und im Anschluß die temporär angelegte Datei einfach umzubennen. So erlangt man wiederum eine höhere Anwendungssicherheit da nun zb. bei einer Exception keine Datei unabsichtlich zerstört wird. Man kann auch ASourceFileName identisch zu ADestFileName festlegen.

Die Procedure DeleteFile() sollte noch durch eine Procedure wie SecureDeleteFile() ersetzt werden. Diese Procedure macht das gleiche wie DeleteFile() nur mit dem Unterschied das sie vor dem Löschen noch mehrmals den Inhalt der Datei überschreibt. Diesen Vorgang nennt man Wipe. Allerdings ist es auf den meisten Betriebsystemen utopisch anzunehmen das man damit wirklich alle Daten der Dateien gelöscht hätte.

Delphi-Quellcode:

procedure SecureDeleteFile(const AFileName: String);
var
  Stream: TStream;
begin
  if FileExists(AFileName) then
  begin
    Stream := TFileStream.Create(AFileName, fmOpenReadWrite or fmShareDeny);
    try
      ProtectStream(Stream);
    finally
      Stream.Free;
    end;
    DeleteFile(AFileName);
  end;
end;

Nun möchten wir noch die Flexibilität im fertigen GUI verbessern. Dazu wäre es hilfreich wenn wir zb. eine Progressbar im GUI hätten damit der Anwender sieht wie's vorwärtsgeht. Auch möchten wir zb. das der Anwender die Verschlüsselung abbrechen kann.
Dazu stellt DEC schon eine relativ komfortable Möglichkeit zur Verfügung, das Interface IDECProgress.
Alle Methoden von DEC Klassen die zb. mit Hilfe von TStream's arbeiten unterstützen dieses Interface. Wir ändern erstmal unsere beiden Encrypt() Procedure dingehend ab.

Delphi-Quellcode:

procedure Encrypt(ASource, ADest: TStream; const APassword: String; const AProgress: IDECProgress = nil); overload;
var 
  Salt,SessionKey: Binary;
begin
  Assert(ASource <> ADest, 'Encrypt(), ASource must be distinct to ADest');

  with ValidCipher(ACipherClass).Create do
  try
    Salt := RandomBinary(AKDFSaltSize);
    SessionKey := ValidHash(AKDFClass).KDFx(APassword, Salt, Context.MaxKeySize, TFormat_Copy, AKDFIndex);

    Mode := ACipherMode;
    Init(SessionKey);
  
    ADest.WriteBuffer(Salt[1], Length(Salt));

    EncodeStream(ASource, ADest, -1, AProgress);
  finally
    Free;

    ProtectBinary(SessionKey);
    ProtectBinary(Salt);
  end;
end;

procedure Encrypt(const ASourceFileName, ADestFileName, APassword: String; const AProgress: IDECProgress = nil); overload;
var
  ASource, ADest: TStream;
  ATempFileName: String;
begin
  ATempFileName := ChangeFileExt(ADestFileName, '.$$$');
  try
    ASource := TFileStream.Create(ASourceFileName, fmOpenRead or fmShareDenyNone);
    try
      ADest := TFileStream.Creare(ATempFileName, fmCreate);
      try
        Encrypt(ASource, ADest, APassword, AProgress);
      finally
        ADest.Free;
      end;
    finally
      ASource.Free;
    end;
    DeleteFile(ADestFileName);
    RenameFile(ATempFileName, ADestFileName);
  except
    DeleteFile(ATempFileName);
    raise;
  end;
end;

Fertig. Nun wenden wir das mal in einem TForm an.

Delphi-Quellcode:

type
  TForm1 = class(TForm, IDECProgress)
    Button1: TButton;
    Progressbar1: TProgressbar;

    procedure Button1Click(Sender: TObject);
    procedure FormCloseQuery(Sender: TObject; var CanClose: Boolean);
  private
    FInAction: Integer;
    FNextTick: Cardinal;
    procedure Process(const Min,Max,Pos: Int64); stdcall;
  end;

procedure TForm1.Process(const Min,Max,Pos: Int64); stdcall;
begin
  if GetTickCount >= FNextTick then 
  begin
    FNextTick := GetTickCount + 100;
    Application.ProcessMessages;
    ProgressBar1.Position := Round((Max - Min) / 100 * (Pos - Min));
    ProgressBar1.Update;
    if FInAction > 1 then 
      Abort;
  end;
end;

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  CanClose := FInAction = 0;
  if not CanClose and (MessageBox('Wollen Sie die aktuelle Aktion abbrechen ?') = mrYes) then
    Inc(FInAction);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  if FInAction = 0 then
  try
    FInAction := 1;
    Button1.Caption := 'Abort';
    // Button2.Enabled := False;  // hier alle Bedienelemente deaktivieren die nicht bedienbar sein dürfen
    FNextTick := 0;
    try
      Encrypt(GetSourceFileName, GetDestFileName, GetPassword, Self);
    except
      on E: EAbort do ShowMessge('Abbruch durch Benutzer')
       else raise;
    end;
  finally
    FinAction := 0;
    Button1.Caption := 'Encrypt';
    // Button2.Enabled := True;
  end else
    Inc(FInAction);
end;

Das ist mal ein stark abstrahiertes Beispiel. Auf dem TForm1 sitzt ein Button1 mit Caption := 'Encrypt'.
Die Funktionen GetSourceFileName, GetDestFileName und GetPassword müssen von euch noch implementiert werden.

Drückt der Anwender nun Button1 das erste mal so ist FInAction == 0, wir verzweigen also in den try finally Block oben im Source. Nun setzen wir FinAction auf 1 und zeigen somit an das wir gerade ver-entschlüsseln. Zusätzlich setzen wir die .Caption von Button1 auf 'Abort' und fangen an eine Datei zu verschlüsseln. Dabei übergeben wir Self als IDECProgress Interface, was dazu führt das die Methode TForm1.Process() periodisch duch die internen DEC Funktionen aufgerufen wird. In TForm1.Process() rufen wir Application.ProcessMessages; auf und somit friert das GUI der Anwendung nicht mehr ein. Danach updaten wir die Progressbar1 und prüfen ob FInAction > 1 ist. Wenn das der Fall ist muß der Anwender in der Zischenzeit erneut den Button1 gedrückt haben oder er hat versucht das TForm1 zu schließen. Denn nur in diesem beiden Methoden inkrementieren wir FInAction falls es > 0 ist. Wir lösen dann einfach per Abort; eine stille Exception aus. Diese EAbort Exception unterbricht dann die internen DEC Verschlüsselungsmethoden, da ja aus diesen heraus erst die Methode TForm1.Process() aufgerufen wurde. Natürlich fangen wir diese Exception in unserer zu äusserst liegenden Methode, hier .Button1Click(), gezielt ab.

Diese Methode hat den Vorteil das das GUI nicht mehr einfrieren kann, das der Benutzer einen Fortschrittsbalken sieht, das er die Aktion sauber abbrechen kann und wir benötigen keine TThread's, keine Synchronisation usw. Der Nachteil besteht darin das der Programmierer sehr sehr genau darauf achten muß welche Bedienelemente er aktiviert bzw. deaktiviert. Meistens wird man alle Steuerelemente deaktivieren in .Button1Click() und nur das TForm1 selber und den Button1 der zum Abbruch dient aktiviert lassen. Das ist wichtig !

Nochwas zu FNextTick. Es kann nun vorkommen das TForm1.Process() sehr sehr schnell nacheinander aufgerufen wird. Das führt dann dazu das durch den Aufruf von Application.ProcessMessages; und das Updatiung der ProgressBar1 die Gesamtperformance stark reduziert. Wir verhidnern dies indem wir über FNextTick und GetTickCount() nur alle minimal 100 Milisekunden diese Aktionen durchführen, also ca. 10 mal pro Sekunde. Das ist für einen Menschen ausreichend, sowohl in der Visualisierung des Fortschrittsbalken wie auch in der
Interaktion des Benutzers über die Steuerelemente.

Möchte man ohne diese Möglichkeit der Progressbar arbeiten so ruft man Encrypt() einfach ohne den letzten Parameter Self auf. Durch unseren Defaultparameter ist dieser dann == nil und intern wird ohne dieses Callback-Interface gearbeitet.

Man muß auch nicht das IDECProgress Interface direkt im TForm1 implementieren und könnte eine eigene Klasse oder Komponente dafür schreiben. Allerdings erachte ich das bei diesem geringen Aufwand und dem direkten logischen Zusammenhang zwischen IDECProgress zum GUI einer Applikation für weniger geschickt, bzw. oversized. Man muß halt immer abwägen. Jede Kapselung solcher Funktionen zb. in eigene Klassen/Komponenten stellt eine Erhöhung der Komplexität dar und macht meistns reingarnichts wirklich besser. Somit reuziert sich die Gesamtsicherheit da man mehr Fehler reinbaut, der Anwender keinen Vorteil erlangt usw. Die rein prozedurale Lösung ist noch die geschickteste in diesem Fall.

Nun nochmal alles als Unit zusammengefasst:

Delphi-Quellcode:

unit MyCrypt;

interface

uses Classes, DECUtil;

procedure Encrypt(ASource, ADest: TStream; const APassword: String; const AProgress: IDECProgress = nil); overload;
procedure Decrypt(ASource, ADest: TStream; const APassword: String; const AProgress: IDECProgress = nil); overload;

procedure Encrypt(const ASourceFileName, ADestFileName, APassword: String; const AProgress: IDECProgress = nil); overload;
procedure Decrypt(const ASourceFileName, ADestFileName, APassword: String; const AProgress: IDECProgress = nil); overload;

procedure SecureDeleteFile(const AFileName: String);

implementation

uses Windows, DECRandom, DECCipher, DECHash, DECFmt;

const
  ACipherClass: TDECCipherClass = TCipher_Rijndael;
  ACipherMode: TDECCipherMode = cmCTSx;
  AKDFClass: TDECHashClass = THash_SHA1;
  AKDFIndex: Cardinal = 1;
  AKDFSaltSize: Byte = 16;

procedure Encrypt(ASource, ADest: TStream; const APassword: String; const AProgress: IDECProgress = nil); overload;
var 
  Salt,SessionKey: Binary;
begin
  Assert(ASource <> ADest, 'Encrypt(), ASource must be distinct to ADest');

  with ValidCipher(ACipherClass).Create do
  try
    Salt := RandomBinary(AKDFSaltSize);
    SessionKey := ValidHash(AKDFClass).KDFx(APassword, Salt, Context.MaxKeySize, TFormat_Copy, AKDFIndex);

    Mode := ACipherMode;
    Init(SessionKey);
  
    ADest.WriteBuffer(Salt[1], Length(Salt));

    EncodeStream(ASource, ADest, -1, AProgress);
  finally
    Free;

    ProtectBinary(SessionKey);
    ProtectBinary(Salt);
  end;
end;

procedure Decrypt(ASource, ADest: TStream; const APassword: String; const AProgress: IDECProgress = nil); overload;
var 
  Salt,SessionKey: Binary;
begin
  Assert(ASource <> ADest, 'Decrypt(), ASource must be distinct to ADest');

  with ValidCipher(ACipherClass).Create do
  try
    SetLength(Salt, AKDFSaltSize);
    ASource.ReadBuffer(Salt[1], Length(Salt));
 
    SessionKey := ValidHash(AKDFClass).KDFx(APassword, Salt, Context.MaxKeySize, TFormat_Copy, AKDFIndex);

    Mode := ACipherMode;
    Init(SessionKey);
  
    DecodeStream(ASource, ADest, -1, AProgress);
  finally
    Free;

    ProtectBinary(SessionKey);
    ProtectBinary(Salt);
  end;
end;

procedure Encrypt(const ASourceFileName, ADestFileName, APassword: String; const AProgress: IDECProgress = nil); overload;
var
  ASource, ADest: TStream;
  ATempFileName: String;
begin
  ATempFileName := ChangeFileExt(ADestFileName, '.$$$');
  try
    ASource := TFileStream.Create(ASourceFileName, fmOpenRead or fmShareDenyNone);
    try
      ADest := TFileStream.Creare(ATempFileName, fmCreate);
      try
        Encrypt(ASource, ADest, APassword, AProgress);
      finally
        ADest.Free;
      end;
    finally
      ASource.Free;
    end;
    SecureDeleteFile(ADestFileName);
    RenameFile(ATempFileName, ADestFileName);
  except
    SecureDeleteFile(ATempFileName);
    raise;
  end;
end;

procedure Decrypt(const ASourceFileName, ADestFileName, APassword: String; const AProgress: IDECProgress = nil); overload;
var
  ASource, ADest: TStream;
  ATempFileName: String;
begin
  ATempFileName := ChangeFileExt(ADestFileName, '.$$$');
  try
    ASource := TFileStream.Create(ASourceFileName, fmOpenRead or fmShareDenyNone);
    try
      ADest := TFileStream.Creare(ATempFileName, fmCreate);
      try
        Decrypt(ASource, ADest, APassword, AProgress);
      finally
        ADest.Free;
      end;
    finally
      ASource.Free;
    end;
    SecureDeleteFile(ADestFileName);
    RenameFile(ATempFileName, ADestFileName);
  except
    SecureDeleteFile(ATempFileName);
    raise;
  end;
end;

procedure SecureDeleteFile(const AFileName: String);
var
  Stream: TStream;
begin
  if FileExists(AFileName) then
  begin
    Stream := TFileStream.Create(AFileName, fmOpenReadWrite or fmShareDeny);
    try
      ProtectStream(Stream);
    finally
      Stream.Free;
    end;
    DeleteFile(AFileName);
  end;
end;

initialization
  RandomSeed;
finalization
end.

Wir binden zusätzlich noch die Unit DECRandom mit ein um einen kryptographisch sicheren Zufallsgenerator zu benutzen. Dieser wird mit RandomSeed; so wie Borland's Randomize; beim Starten der Applikation zufällig initialisiert. Diese Initialisierung erfolgt per default mit der aktuellen Systemzeit und PerformanceCounter(). Dies ist eine Archillesferse des Ganzen und wenn man es sehr sicher haben möchte so muß man dies ändern. Im Allgmeinen ist es aber so das die Gesamtsicherheit erstmal immer vom gewählten Passwort abhängt und dies ist bei menschlich gewählten Passwörtern eh viel geringer als die Sicherheit der angewendeten Algorithmen.

Die Decyrpt() Procedures sind das Pendant zu ihren Encrypt() Procedures.

Man kann nun diese Beispiele immer mehr ausbauen. Zb. könnte man in den Streamfunktionen zusätzlich noch Daten über den verwendeten CipherMode, Cipherklasse, KDF Funktionstyp, Länge des verwendeten Salt usw. usw. als Header abspeichern und natürlich entsprechned auch wieder laden in der Decrypt() Procedure. Damit wird das System immer flexibler aber eben auch eventuell störanfälliger oder sogar kryptrographisch unsicherer. Man könnte auch am Ende des verschlüsselten Streams eine prüfsumme der Daten abspeichern damit man bei der Entschlüsselung die Daten und das Passwort auf Richtigkeit überprüfen kann. Für all dies finden sich in der DP aber schon Beispiele.

Gruß Hagen

PS: alle Sourcen habe ich mal eben so eingehackt und sind leider noch nicht real getestet. Sie dienen also erstmal nur als Beispiele.

[Dezipaitor]

Heftig, heftig. Ich hoffe du hast dir deinen Text auch lokal gespeichert Für den Fall der Fälle. Wäre schade, wenn er verloren geht.

Andere Frage: Welche Delphiversionen können die DEC verwenden?

[delphin06]

Ich sag nochmal danke für die umfangreiche Erklärung hier!

Um nochmal auf das Thema "deutsche Sprache" zurückzukommen...ich will jez nich großartig darauf rumreiten aber meiner Meinung nach ist solche "Slang"-Sprache nicht unbedingt so schlimm. Das ist nunmal so die Sprache befindet sich in einer ständigen Entwicklung. Das sieht man ja auch sehr stark an den vielen englischen Begriffen die zunehmend "eingedeutscht" werden.
Aber ich verstehe auch, dass das hier kein Chat ist und man so auch mal vernünftig deutsch sprechen sollte (um es nicht zu verlernen^^)
Diesen Chat-Slang gewöhnt man sich halt viel zu sehr an, weil man ja auch sehr viel damit zu tun hat in der heutigen Zeit. Da geht es dann nicht mehr um genaue Schreibweisen, sondern es muss möglichst kurz sein aber dabei immer noch verständlich, weil das Schreiben numal nicht so schnell geht wie das Sprechen


Auf jeden Fall Danke an Luckie und Hagen für die Unit, die die Anwendung des DEC 5.1 nochmal deutlich zeigt. Es sind hier denke ich mal sehr viele Hobby-Programmierer (wie ich) und die sind halt nich alle solche Delphi Profis wie ihr. Ich bin schon zufrieden das ich so einigermaßen eigene Programme schreiben kann und das reicht mir auch. Man lernt hier in solchen Foren einfach das meiste. Und durch solche Anwendungsbeispiele wird das ganze auch für Leute wie mich verständlicher^^

Gruß

[EDIT] Respekt an Hagen. Wenn man sich das so durchliest könnte man denken man redet mit einem Kryptographie Professor (bist du das?^^). Wahnsinn

[negaH]

Doch Slang-Sprache ist sogar massiv schädlich meiner Meinung nach. Slang entsteht wenn sich Gang's bilden und diese sich von den Anderen separieren möchten. Was daran soll gut sein ? Und meistens wird ein solcher Slang aufgegriffen von zb. Gangster-Rap-Musik-Gruppen mit dem Anspruch das reale Leben damit widerzuspiegeln. Dabei geht es aber eigentlich nur darum sich auf seinem Markt zu positionieren, qausi Einschaltquoten zu machen. Unsere frühkindliche Psyche fällt exakt darauf rein. Meistens sollte man dann als Erwachsener von solchen Tricks geheilt sein aber immer öfters passiert das eben nicht. Einfach weil diese Art zu sprechen und damit auch zu denken im eigenen Lebensumfeld des privaten Konsums verankert wurde. Wir konsumieren nur noch das was Slang ist, was Lebensgefühl ohne inhaltlichen Sinn darstellt. Wir haben Manager, haben Facility Manager und wissen nicht das es der Hausmeister ist, wir kennen die Back-Factory dei dem jeder Englänger sich fragt, was ist das ? Ja, die Bäckerei von nebenan.
Ein Auto kaufst du weil es chick ist und nicht mehr weil es dich wirklich von A nach B fährt. Slang ist also nichts weiter als ein Werbeversuch und unnötig. Das ist so wie annodazumals als die Indianer in Amerika durch uns Weiße verdrängt wurden. Wenn wir nicht aktiv die deutsche Sprache pflegen dann stirbt sie aus, sie wird verdrängt. Und das ist das eigentliche Problem, was übrigbleibt ist eine so schnell zeitlich wechselnde Sprache, weil sie nur noch ein Modetrend ist, die aufgefüllt ist mit Slang, mit Kunstworten, rein aus kommerziellem Interesse, das am Ende sich keiner mehr mit dem anderen versteht.

Egal, wenn du begriffen haben solltest das ich in diesen Punkten intolerant bin dann solltest du so intelligent und auch höflich sein deinen Chat-Stil hier nicht zu benutzen.

Gruß Hagen

[delphin06]

Naja ich seh das ein bisschen anders. Du hast deine Meinung und ich meine und dann ist auch gut. Das soll ja nicht das Thema hier werden.

Gruß

[Dezipaitor]

Zitat von Dezipaitor:

Andere Frage: Welche Delphiversionen können die DEC verwenden?