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