Interessante Diskussion
DEC soll in seiner Schnittstelle möglichst schlank und denoch felxibel bleiben. Das ist immer ein Kompromiss der da geschlossen werden muß. Dieser Kompromiss ist notwendig da es so die Anwendungssicherheit des DECs erhöht. Die Definition Binary = type LongString wurde benutzt um darauf hinzuweisen das alle Funktionen in denen
DEC diesen Datentyp benutzt in diesem String nicht darstellbare Zeichen im kompleten binären Bytebereich enthalten sein können. Der Nachteil mit der autom. Nullterminierung existiert für Delphi im Grunde garnicht. Erst ein Typcast mit PChar(String) würde dieses Problem verursachen, aber auch nur weil die PChar
API Funktionen die Daten bis zum ersten #0 Zeichen auswerten und somit eine Truncation entsteht. Arbeitet man mit LongStrings mit den Delphi Bordmitteln dann wird immer mit der Längenangabe in der LongString Struktur gearbeitet.
Der Vorteil mit Binary als Datentyp zu arbeiten liegt in der direkten Kompatibilität zu Strings. Alle Vorteile die LongStrings haben gelten ach für Binary. Also Autoallokation, Reference Counting, Copy on Write Demand. Das machen die Compilermagic für uns. Binary ist also ein sehr komplexer Datentyp.
Man hätte sowas wie "array of byte" benutzen können, aber das bringt mehr Nachteile als Vorteile. Man muß ständig ein Byte-Speicherbereich in einen Char-Speicherbereich kopieren obwohl das im Grunde das gleiche ist. Bei diesen Kopierungen entstünden Performanceeinbußen und Sicherheitseinbußen da man die wichtigen Daten quasi im Speicher verteilt und somit die Kontrolle darüber immer weniger in der Hand des Entwicklers liegt.
Bestes Beipsiel die .EncodeWidestring(), .DecodeWideString() Vorschläge von oben. Man erzeugt im Speicher eine temporäre Kopie der entschlüsselten Daten, und der Programmierer hat in diesen Funtionen keinerlei Vorkehrungen getroffen vor der Freigabe dieser Variablen deren Inhalt auf sichere Art&Weise zu löschen !
Davon abgesehen enthalten alle
DEC Klassen auch Methoden um mit untypisierten Datenblöcken zu arbeiten. Warum? Ganz einfach weil mit diesen eben nicht direkt unterstützte Datentypen unterstützt werden sollen. Diese Methoden heisen dann .Encode(), .Decode(), .Calc() usw.
Im Grunde besteht also garnicht die Notwengikeit umständlich durch Kopieroperationen über Datentypen hinweg das Problem zu lösen. Man könnte den WideString also auch inplaced direkt mit .Encode(WideString, WideString, Length(WideString) * 2) verschlüsseln und dann mit einem der TDECFormat Klassen umwandeln.
Das größte Sicherheitsrisiko ist immer der Anwender, und in diesem Falle wäre es der Programmierer der seine Datentypen im
DEC unterstützt sehen möchte.
Das heist nicht das ich die direkte Unterstützung vom WideString im
DEC als grundsätzlich falsch empfinde. Nur bisher wurde dieser Wunsch noch nie geäußert, in keiner der wohl mehr als 1000 EMails die ich zum
DEC in den letzten 8 Jahren erhalten habe.
Ich denke das ich mit meinen 20 Jahren Programmiererfahrung mit Borlandprodukten sehr gut einschäzen kann welche Kompromisse ich eingehen kann und welche nicht. Das Ziel ist es doch auch weniger erfahrenen Programmiern eine Cryptolibrary anzubieten die größtenteils Anfängerfehler vermeidet. Denn genau das war eines der Unterscheidungsmerkmale zu anderen Libraries die ich für
DEC haben wollte.
In den obigen Funktionen fehlt der Schutzblock
Delphi-Quellcode:
try
finally
ProtectBinary(b);
end;
Gruß Hagen