Das with do kann man natürlich auflösen, so wie es der Compiler dann bei der Compilation ja auch macht.
Delphi-Quellcode:
function TSomeClass.GetSomePW: string;
var
Key: Binary;
Cipher: TDECCipher;
begin
Cipher := ValidCipher(ACipherclass).Create;
try
Cipher.Mode := ACipherMode;
Key := ValidHash(AHashClass).KDFx('somepw', '', Cipher.Context.KeySize, TFormat_Copy, AKDFIndex);
Cipher.Init(Key);
Result := Cipher.DecodeBinary(FSomePW, TFormat_MIME64);
finally
Cipher.Free;
ProtectBinary(Key);
end;
end;
Das ist alles. Es gibt ürbigens keinen technisch relevanten Grund aus Sicht des DECs das man unbedingt mit der with do Konstruktion arbeiten muß. Es ist einfach eine Stilfrage des Programmierers.
With do ist kein "Goto der
OOP", diese Aussage halte ich für falsch, da dann die Auflistung von Units in den USES Klauseln ebenfalls ein "Goto der
OOP" wären. So wie die Reihenfolge der Units in der USES Klausel bestimmte Abhängigkeiten der in den Units deklarierten und doppeltdeutigen Typen mit sich bringt tut es auch das WITH DO Konstrukt.
Wenn nun der Programmierer nicht geschlampt hat, bzw. sein System exakt konsturiert hat dann besteht mit WITH DO keinerlei Gefahr, und so ist es auch in diesem speziellen Fall. Der Cipher und Cipher.Context innerhalb der WITH DO Klausel sind Teile des gleichen Objekttypes, der gleichen
Unit, und es wurde sichergestellt das es darin keine Doppeldeutigkeiten in den Benamungen der Typen, Objektfelder, Recordelemente gibt.
Bedenklicher an diesem geänderten Source ist das Weglassen des zufällig gewähltem Salt, da es die Funktionalität und somit kryptographische Sicherheit stark beeinflußt. Aus Sicht der Kryptographie ist die Anwendung der KDF ohne Salt im Vergleich zu mit Salt, nur mariginal stärker als komplett ohne KDF zu arbeiten. Die KDF hat 2 Aufgaben:
1.) Schutz des Passwortes vor dem "Zurückrechnen" aus einem so erzeugten Sessionkey
2.) Randomisierung des Sessionkeys um sicherzustellen das der Cipher mit gleichen Passwort immer ein anderen Sessionkey benutzt und somit die Erhöhung der Sicherheit des Ciphers bzw. dessen verschlüsseltem Output
Ohne Salt träfe bedingt nur noch Punkt 1.) zu. Bedingt deshalb weil man mit speziellen offline Brute Force Angriffen wie die Rainbow Tabellen sehr wohl diesen Schritt 1.) effizient angreifen kann. Würde man aber einen zufälligen Salt benutzen so ist auch 1.) sicher vor diesen Angriffen. Also auch Punkt 1.) wird durch das Fehlen des Salts in der Sicherheit stark reduziert.
Aus meiner Sicht heraus ist also das Weglassen des zufälligen Salts ein grober konzeptionell-kryptograpischer Fehler. Man kann eine
OpenGL 3D Vektor Berechnung für Grafiken aus performancegründen in der Exaktheit/Genauigkjeit ohne Probleme reduzieren, das geht mit fast allen Aufgaben der Informatik, aber in der Informatik der Kryptographie ist das eine absolut falsche Herangehensweise. Und das erst recht wenn dieser Salt nur 5% des Gesamtaufwandes darstellen aber die Sicherheit ver-2^128'facht, also nicht 100% oder 1000% oder Millionen Prozent mehr Sicherheit bringt sondern 2^128 mal sicherer wenn man mit 128 Bit Kryptographie arbeitet.
Es besteht also alle Notwendigkeit, gerade auch vom Aufwand-Nutzen-Verhältnis betrachtet den Salt nicht zu entfernen.
Gruß Hagen