Hm so aus dem Stegreif weis ich auch nicht was falsch ist. Ein WideString ist aber ein Array of WideChar und WideChar ist ein 2 Bytes Datentyp. Bei Ansicode Zeichensatz wird nur 1 Byte davon real benutzt das andere muß immer 0 sein. Also sieht es eher so aus als ob die MessageBox() einen WideString als normalen String anzeigt oder aber als ob die
VCL aus einem WideString einen Wide-WideString macht. Ich habe meine obigen Funktionen dahingehend getestet das ich das WideString Resultat im Debugger View im Speicherauszug angezeigt habe. Dann wirst du sehen das das Resultat ein echter WideString ist, also 2. Bytes wobei das 2. Byte pro Zeichen immer 0 ist. Es drängt sich also der Verdacht bei mir auf das irgendwas nach der Ver/Entschlüsselung, also in der Anzeigeroutine, falsch sein muß. Nur kann ich eben in deinem Source bisher keinen Fehler sehen. Kurz gesagt: ich denke das meine Funktionen alles richtig machen und der "Fehler" ausserhalb zu suchen ist. Leider habe ich bisher nur sehr wenig mit WideString gearbeitet und somit wenig Erfahrungen mit deren Eigenheiten.
Das Passwort sollte bei einer WideString Version natürlich auch WideString sein. Das macht zwar in unseren Regionen keinen wirklichen Sinn aber bei zb. Russischen oder Chinesischen Zeichensätzen ist es sehr wichtig. Denn jedes Bit an Information innerhalb des Passwortes bedeutet Sicherheit. Würde man ein WideString Passwort direkt in Cipher.Init() benutzen in dem jedes 2. Byte #0 ist so würde das die Sicherheit wieder reduzieren. Da wir aber mit einem Salt und einer KDF quasi die binären Daten des Passwortes in einen binären kompatiblen LongString als SessionKey umwandeln, entsteht dieses Sicherheitsrisiko nicht. Die KDF arbeitet quasi so ähnlich wie eine Komprimierungsfunktion aus Sicht der verwertbaren Entropie innerhalb der Passwortdaten.
Gruß Hagen
Achso: ein TypCast mit PChar() oder PWideChar() wandelt einen Delphi Datentyp, der intern eine separates Feld zu Längenangabe des Strings benutzt, in einen C typischen Nullterminierten String um. Sollte im Delphi Datentyp also ein #0-Teriminator mittten im String vorkommen, was durchaus ohne Probleme mit Delphis Datentypen möglich ist, dann wird durch diesen "Typcast" bzw. der später benutzten
API Funktion der Strng quasi virtuell "abgeschnitten". Die
API Funktion, zb. eine MessageBox() und damit die
GDI Funktion DrawText() schneitet dann in der Anzeige diese String ab. Auch alle PChar/PWideChar Kopieroperatione wie StrLen(), StrCopy() usw. arbeiten mit dem #0-Terminator und schneiden die Delphi Datentypen ab. Normalwerweise kommen in einem String/LongString/WideString im Delphi ja keine #0-Terminatoren mitten im String vor. Aber im Falle vom
DEC habe ich quasi den LongString als neuen Datentyp Binary mißbraucht um auch binäre Daten damit zu speichern. Das hat, wenn man nur mit Delphi Datentypen arbeitet enorme Vorteile. Man hat einen Stringkompatiblen binären Datentyp der 1 zu 1 zuweisungskompatibel ist, man hat Autallokation, Copy on Write Demand und eben Garbarge Collection über die Delphi interne Refernezzählung dieser Datentypen. Deshalb habe ich mich für LongStrings statt dynamsichem Array of Byte entschieden.