Umstellung DEC 3.0 auf 5.2

[automatix]

Hallo!

Wir haben einige DCOM-Server die ihre DB-Anmeldedaten aus der Windows Registratur holen. Das Passwort wird verschlüsselt dort hinterlegt. Mit folgendem DEC 3.0 Code wird das Passwort entschlüsselt:

Delphi-Quellcode:

  // cm ist TCipherManager mit THashManager
  cm.InitKey(KEY, nil);
  pw := cm.DecodeString(passwort);

Nun habe ich schon erfahren, dass es nicht gut war diese Komponenten zu verwenden, da sie nur zu Testzwecken gedacht waren. Leider ist es damals so gemacht worden.
Als Properties wurden die Standardeinstellungen genommen.
HashManager.Algorithm: Ripe Message Digest 256
CipherManager.Algorithm: Blowfish
CipherManager.Mode: cmCTS

Jetzt versuche ich das umzustellen auf DEC 5.2 und habe dabei schon einige Möglichkeiten durchprobiert, die alle nicht das gewünschte Resultat brachten. Ich möchte vermeiden, bei den Kunden die ganzen Passwörter neu verschlüsseln zu müssen und / oder unterschiedliche Verschlüsselungsverfahren je nach Server zu haben.

Delphi-Quellcode:

var
  CipherClass: TDECCipherClass = TCipher_Blowfish;
  CipherMode: TCipherMode = cmCTSx;
  HashClass: TDECHashClass = THash_RipeMD256;

function Decode(const aPasswort: string): string;
var
  cipher: TDECCipher;
  pw: Binary;
begin
  cipher := nil;
  Result := '';
  try
    cipher := ValidCipher(CipherClass).Create;
    cipher.Mode := CipherMode;
    pw := ValidHash(HashClass).CalcBinary(KEY);
    cipher.Init(pw);
    Result := cipher.DecodeBinary(aPasswort);
  finally
    FreeAndNil(cipher);
  end;
end;

Was muss ich ändern, damit ich die alten Passwörter entschlüsselt bekomme?
Oder ist die gewählte Algorithmus / Mode Kombination inkompatibel zwischen V3.0 und V5.2?

Vielen Dank

[Assertor]

Hi automatix,

bist Du denn sicher, daß so wie Du es nutzt bei der alten DEC auch der Hash vom Passwort angewendet wurde? Ich kenne leider die DEC 3 nicht mehr so gut, aber wenn das Kennwort direkt als Basis der Verschlüsselung ohne Hash angewendet wird, wäre das eine mögliche Ursache.

Zu Deinem Code:

Zitat:

Zitat von automatix

Delphi-Quellcode:

var
  CipherClass: TDECCipherClass = TCipher_Blowfish;
  CipherMode: TCipherMode = cmCTSx;
  HashClass: TDECHashClass = THash_RipeMD256;

function Decode(const aPasswort: string): string;
var
  cipher: TDECCipher;
  pw: Binary;
begin
  cipher := nil;
  Result := '';
  try
    cipher := ValidCipher(CipherClass).Create;
    cipher.Mode := CipherMode;
    // Edit: Ich hatte fälschlicherweise hier KEY durch aPasswort ersetzt, da ich
    // von dem Fkt.Parameter ausging beim überfliegen. Mfg Assertor
    pw := ValidHash(HashClass).CalcBinary(KEY);
    cipher.Init(pw);
    Result := cipher.DecodeBinary(aPasswort);
  finally
    FreeAndNil(cipher);
  end;
end;

Ich würde jetzt

1) prüfen, ob in der DEC 3 der Hash oder das Passwort direkt verwendet wird
2) prüfen, in welchem Format die Ausgabe des Hash bzw. Ciphers vorliegt

Es kann ja z.B. sein das bei der DEC 3 das Encoding bsp. einen MIME32 oder HEX-Text zurückliefert. Dies wäre dann mit deinem obigen DEC 5.2 Code inkompatibel, hier müsstest Du entsprechend das Encoding anpassen.

Ich hätte jetzt fast gesagt, nenn mir mal einen Beispieltext aus der Registry und das Passwort, dann guck ich ob das geht - aber das scheidet wohl aus wegen gewisser Sicherheitsaspekte ;)

Gruß Assertor

P.S.: Zusätzlich kannst Du schon den Code für D2009 "vorbereiten" in dem Du - ähnlich meinem DEC 5.2 Beispiel - Length(aPasswort) * SizeOf(aPasswort[1]) nutzt. Dann kommt bei einer Umstellung der Code auch mit der geänderten Größe der Chars klar.

[gammatester]

Zitat:

Zitat von automatix

Was muss ich ändern, damit ich die alten Passwörter entschlüsselt bekomme?

Passwörter werden hier weder entschlüselt noch wurden sie vorher verschlüsselt. Der Hashwert (oder Vergleichbares) wird als Schüssel für die Chiffrieralgorithmus verwendet.

Zitat:

Zitat von Assertor

Hi automatix,

bist Du denn sicher, daß bei der alten DEC auch der Hash wirklich auf das Passwort angewendet wurde? Ich kenne leider die DEC 3 nicht mehr so gut, aber wenn das Kennwort direkt als Basis der Verschlüsselung ohne Hash angewendet wird, wäre das eine mögliche Ursache.
Ich würde jetzt

1) prüfen, ob in der DEC 3 der Hash oder das Passwort direkt verwendet wird
2) prüfen, in welchem Format die Ausgabe des Hash bzw. Ciphers vorliegt

Es kann ja z.B. sein das bei der DEC 3 das Encoding bsp. einen MIME32 oder HEX-Text zurückliefert. Dies wäre dann mit deinem obigen DEC 5.2 Code inkompatibel, hier müsstest Du entsprechend das Encoding anpassen.

...

Gruß Assertor

P.S.: Zusätzlich kannst Du schon den Code für D2009 "vorbereiten" in dem Du - ähnlich meinem DEC 5.2 Beispiel - Length(aPasswort) * SizeOf(aPasswort[1]) nutzt. Dann kommt bei einer Umstellung der Code auch mit der geänderten Größe der Chars klar.

Das ist mM alles nur "herumdoktern" :) Was soll es bringen, wenn die Bit/Byte-Kodierung der Passwörter anders ist? Wenn jetzt 'abc' 6 Bytes lang ist, wirst Du auch nicht den gleichen Hashwert erhalten,
egal, ob Du etwas wie Hash('abc',3) or Hash('abc', 6) berechnest. Ich hoffe, daß diese Unicode-String=Default-Desaster endlich dazu führt, daß man Byte- oder Bitstring bei Hashalgorithmen verwenden, denn dafür sind ja geschrieben.

Gruß Gammatester

[gammatester]

Inzwischen denke ich, daß ich mich durch Assertors Beitrag habe verwirren lassen, der automatix' KEY durch aPasswort ersetzt hat. D.h. mein Kommentar zu automatix ist hinfällig in dem Sinn, das seine Passwörter durchaus ver/entschlüsselt werden, mit einem KEY (nicht aPasswort, darauf hatte ich mich bezogen).

Die Frage hängt u.a. davon ab, was KEY eigentlich ist. Wenn's vorher ein (ansi-)String war und jetzt ein (Unicode-)String, ist das Problem offensichtlich. Wenn eine array of byte oder ähnliches ist, müßte man mehr wissen.


Gammatester

[Assertor]

Hi gammatester,

Zitat:

Zitat von gammatester

Das ist mM alles nur "herumdoktern" :)

So?

Zitat:

Zitat von gammatester

Zitat:

Zitat von automatix

Was muss ich ändern, damit ich die alten Passwörter entschlüsselt bekomme?

Passwörter werden hier weder entschlüselt noch wurden sie vorher verschlüsselt.

...

Zitat:

Zitat von automatix

Wir haben einige DCOM-Server die ihre DB-Anmeldedaten aus der Windows Registratur holen. Das Passwort wird verschlüsselt dort hinterlegt. Mit folgendem DEC 3.0 Code wird das Passwort entschlüsselt:

Eigentor, da schon wieder nicht richtig gelesen? ;)

Zitat:

Zitat von gammatester

Was soll es bringen, wenn die Bit/Byte-Kodierung der Passwörter anders ist? Wenn jetzt 'abc' 6 Bytes lang ist, wirst Du auch nicht den gleichen Hashwert erhalten, egal, ob Du etwas wie Hash('abc',3) or Hash('abc', 6) berechnest. Ich hoffe, daß diese Unicode-String=Default-Desaster endlich dazu führt, daß man Byte- oder Bitstring bei Hashalgorithmen verwenden, denn dafür sind ja geschrieben.

Das hast Du auch nicht richtig gelesen und dich nochmehr verwirren lassen...

1) Stand es nicht OHNE Grund unter post scriptum... Ich rede von Code-Portabilität falls der TE mal auf D2009 wechseln will. Ist ja nicht so unwahrscheinlich derzeit. Das hat nichts, aber auch garnichts mit dem aktuellen obigen Code zu tun...

2) Das DEC 5.2 arbeitet an RawByteStrings - rate mal, ob das ein "Byte- oder Bitstring" ist

Gruß Assertor

Edit: Das mit dem Key stimmt natürlich. Ich hatte den Code nur überflogen. Aber Unrecht hast Du mit dem Textkonversionen - wenn die Eingabedaten in einem anderen als dem erwarteten Format kommen, kann es nichts werden. Bleibt die Frage, ob der Hash wirklich im alten DEC genutzt wird oder das Passwort direkt zur Ver/Entschlüsselung kommt (ja, das wäre nicht schön).

Edit2: Jetzt wurde soviel editiert, der rote Kasten fehlte auch. Am besten wir starten den Thread nochmal neu ;) Neuer Fakt: Alle haben recht und alle liegen richtig. Der obigen KEY != aPasswort als Fkt.Parameter war falsch - das kommt vom Überfliegen. Die Textkonversionen bleiben aber wichtig.

P.S.: @gammatester: Das war ein lustiges Chaos ;)

:dp:

[automatix]

Hallo!

Erstmal vielen Dank für das Chaos. :)

Ja, der Parameter aPasswort ist das verschlüsselte Passwort aus der Registratur, KEY der Schlüssel zum ver/entschlüsseln. Ein salt oder weitere Sicherheitsmassnahmen waren in diesem Fall überkandiedelt. Die Passwörter standen vorher im Klartext in der Registratur. Die Rechner stehen gegen unbeaufsichtigten physischen Zugriff geschützt, und auch nur einge Administratoren haben übers Netzwerk Zugriff auf den Rechner, zumal auch die Berechtigungen für jeden hier in der Registratur gespeicherten Benutzer auf der Datenbank auf die tatsächlichen Aktionen des jeweiligen DCOM-Servers beschränkt sind.

Ob der Hash in DEC 3.0 angewendet wird, kann ich nicht sagen. Ich denke allerdings schon.
Denn in TCipherManager.InitKey wird jedenfalls die HashClass aus dem zugewiesenen HashManager zugewiesen und in TCipher.InitKey wird dann

Delphi-Quellcode:

procedure TCipher.InitKey(const Key: String; IVector: Pointer);
var
  I: Integer;
begin
  Hash.Init;
  Hash.Calc(PChar(Key)^, Length(Key));
  Hash.Done;
  I := Hash.DigestKeySize;
  if I > FKeySize then I := FKeySize; {generaly will truncate to large Keys}
  Init(Hash.DigestKey^, I, IVector);
  EncodeBuffer(Hash.DigestKey^, Hash.DigestKey^, Hash.DigestKeySize);
  Done;
  SetFlag(0, True);
end;

ausgeführt. Für mich sieht das erstmal so aus, dass der Hash angewendet wird.

Allerdings fürht auch dies

Delphi-Quellcode:

function Decode(const aPasswort: string): string;
var
  cipher: TDECCipher;
  pw: Binary;
begin
  cipher := nil;
  Result := '';
  try
    cipher := ValidCipher(CipherClass).Create;
    cipher.Mode := CipherMode;
    cipher.Init(KEY);
    Result := cipher.DecodeBinary(aPasswort);
  finally
    FreeAndNil(cipher);
  end;
end;

nicht zum Erfolg.

Die Umstellung auf DEC 5.2 ist ausgelöst worden durch Delphi 2009, allerdings teste ich im Moment dies hier alles mit Delphi 2007, so das der KEY ein einfacher string ist, wie in der DEC 3.0 Version auch.

Wo kann ich noch ansetzen?

Vielen Dank

[Assertor]

Hi automatix,

ich befürchte cmCTS aus DEC 3 != cmCTSx aus DEC 5.

Aus dem Quellcode von DEC 5:

Zitat:

cmCTSx = double CBC, with CFS8 padding of truncated final block
...
Modes cmCTSx, cmCFSx, cmCFS8 are prohibitary modes developed by me. These modes
works such as cmCBCx, cmCFBx, cmCFB8 but with double XOR'ing of the inputstream
into Feedback register.
...
Modes cmCTSx, cmCBCx need no external padding, because internal the last truncated
block is padded by cmCFS8 or cmCFB8. After padding these Mode can't be used to
process more data. If it needed to process chunks of data then each chunk must
be algined to Cipher.BufferSize bytes.

Soweit stellt Hagen schon damals klar, es handelt sich um einen eigenen Block cipher mode.

Du kannst dies nur prüfen, in dem Du mit dem alten DEC 3 unter z.B. D7 einen Text "test" mit Deinem Key verschlüsselst und das Ergebnis mit der Verschlüsselung mit dem gleichen Key und Text aus DEC 5.2 vergleichst.

Da Du keine Zufallsdaten (Salt und Default IV mit n*$FF bei cm <> cmECB) verwendest, ist das Ergebnis der Verschlüsselung bei gleichem Passwort und Eingabetext immer identisch, d.h. wenn Du die Verschlüsselung in D7 mehrmals hintereinander aufrufst und z.B. ein TMemo mit dem Ergebnis befüllst, werden alle verschlüsselten Text gleich lauten.

Dies gilt auch für D200x und DEC 5.x. Wenn nun aber das Ergebnis abweicht, bist Du hier in die Falle eines proprietären Block Modes gelaufen. Ich vermute, daß sich hier in DEC 5 damals das Padding in cmCTSx gegenüber cmCTS geändert hat.

Als Hilfe böte sich an, den Kunden eine Zwischenversion mit Dx/DEC3 zu liefern, die mittels DEC 3 die Passwörter in der Registry auf einen Standard-Blockmode umstellt. Dieser kann dann auch von der DEC 5 richtig gelesen werden.

Alternativen, ohne Zwischenversionen, sind a) Update-Tool welches DEC3 nutzt (um die alten Passwörter zu lesen und in ein DEC 5 taugliches Format zu bringen) oder b) Die Kunden bei der neuen Version einmalig zum neuen Eingeben der DB Passwörter aufzufordern.

Welche Block Modes in DEC 3 und 5 identisch sind, kann ich Dir ad hoc leider nicht sagen - ich habe die DEC 3 nicht im Einsatz... Hier hilft aber testen und vergleichen, also einmal die Ergebnisse in D7 mit Blockmode X mit D2007 Blockmode Y vergleichen.

Gute Kandidaten wären aber sicherlich: cmOFB/cmOFB8 und cmCFB/cmCFB8.

Gruß Assertor

[automatix]

Hallo!

Vielen Dank für Deine Unterstützung, auch für die verschiedenen Vorschläge zur möglichen Umstellung.
Leider kann man nicht DEC3.0 und DEC 5.2 so ohne weiteres im selben Projekt verwenden. Also habe ich mit Delphi 2006 ein Testprogramm erstellt mit DEC 3.0 und eines mit Delphi 2007 und DEC 5.2.

Im Ergebnis sieht es erstmal so aus, dass mir der CipherManager oder HashManager in die Suppe spuckt.

Mit folgenden Routinen habe ich mir ein Memo gefüllt für alle möglichen Modi.
Delphi 2006 und DEC 3.0

Delphi-Quellcode:

procedure TfrmStart.AddEncryptedPassword(aMode: TCipherMode);
var
  cipher: TCipher_Blowfish;
  hash: THash_RipeMD256;
  initHash: string;
  pw: string;
begin
  cipher := nil;
  try
    hash := THash_RipeMD256.Create(nil);
    cipher := TCipher_Blowfish.Create(MASTER_KEY, hash);
    cipher.Mode := aMode;
    pw := cipher.EncodeString(ePasswort.Text);
    memoErgebnis.Lines.Add(ePasswort.Text + '=' + pw);
  finally
    FreeAndNil(cipher);
  end;
end;

Delphi 2007 und DEC 5.2

Delphi-Quellcode:

var
  CipherClass: TDECCipherClass = TCipher_Blowfish;
  HashClass: TDECHashClass = THash_RipeMD256;

procedure TfrmStart.AddEncryptedPassword(aMode: TCipherMode);
var
  cipher: TDECCipher;
  initHash: string;
  pw: Binary;
begin
  cipher := nil;
  try
    cipher := ValidCipher(CipherClass).Create;
    cipher.Mode := aMode;
    initHash := ValidHash(HashClass).CalcBinary(MASTER_KEY);
    cipher.Init(initHash);
    pw := cipher.EncodeBinary(ePasswort.Text);
    memoErgebnis.Lines.Add(ePasswort.Text + '=' + pw);
  finally
    FreeAndNil(cipher);
  end;
end;

Verschlüsselte Paßwörter:

Delphi-Quellcode:

DEC 3.0    DEC 5.2
cmCTS   =  cmCTSx
cmCBC   =  cmCBCx
cmCFB   =  cmCFB8
cmOFB   =  cmOFB8
cmECB   =  cmECBx

Aber alle (DEC 3.0 und DEC 5.2) ungleich:

Delphi-Quellcode:

CipherManagerTest.InitKey(MASTER_KEY, nil);
pw := cmTest.EncodeString(ePasswort.Text);

Der CipherManager oder HashManager scheint irgend etwas noch aufzufüllen, denn die verschlüsselten Resultate sind bei einem 8 Zeichen langen Paßwort alle 8 Zeichen lang, mit dem CipherManager/HashManager aber 12 Zeichen.

Ich werde mit jetzt nochmal den CipherManager und HashManager zur Brust nehmen.
Wenn jemand (Assertor ?) noch eine Idee hat oder einen Geistesblitz nach dem Motto: "Ach ja, das liegt daran", bitte her damit.

Grüße

[negaH]

Hi

du musst zwingend umstellen ? Wenn ja wird es hart.
Es haben sie einige und wesentliche Änderungen vom DEC 3 zum DEC 5 ergeben und das sind ne Menge.

1.) .InitKey() und .Init() der Cipher sind nicht direkt kompatibel
2.) einige Hash Funktionen haben sich geändert, dürfte aber in diesem Falle nicht relevant sein
3.) die Cipher Modis sind komplett neu, den alten cmCTS gibts in der Form nicht mehr

Man muß
1.) die per HashManager benutzt Routine um ein Plainkey in einen Sessionkey umzuwandeln reimplementieren in DEC5
2.) die Funktionalität von .InitKey() aus DEC 3 in DEC 5 reimplementieren, das geht mit der Methode .Init() zu Fuß
3.) in DEC5s .Init() Methode ist die Überprüfung der übergeben Keys strenger, du musst also zu lange Keys schon vor der Übergabe an .init() beschneiden da ansonsten diese Methode einen Fehler meldet. In DEC3 war es so das stillschweigend das zu lange Keymaterial beschnitten wurde.

In DEC 5 ist der Mode cmCTSx kompatibel zu cmCTS aus DEC 3.

Tut mir ja leid aber mit neuem Wissen wird man in neueren Versionen eben auch Fehler der alten Versionen beseitigen, und das führt in diesem Fall zur Inkompatibilität.

Gruß Hagen

[Assertor]

Hallo Hagen,

Danke fürs klären! Ich war gerade schon am Wühlen im DEC3 Code bevor mein Notebook sich leider verabschiedete...

Gruß Assertor

[automatix]

Hallo!

Vielen Dank für eure Hilfe.

Ich hatte gestern noch ein bischen mit dem Debugger rumgespielt und gehofft, dass es vielleicht mit ein paar Füllbytes getan wäre. Vielen Dank an Dich, Hagen, dass Du mir mit deinen Erleuterungen der Innereien die weitere Suche ersparst. Schade, dass es nicht einfacher ist.
Zwingend umstellen muss ich jetzt nicht. Aber wenn ich das erste Projekt auf Delphi 2009 konvertiere will, muss oder ein neues Projekt beginne wird es auf mich zukommen. So habe ich jetzt noch die Zeit mir einen Schlachtplan zu überlegen.

An den Clients der DCOM-Server hängt nämlich fast 24x7 Produktion dran und es ist nicht so einfach möglich da zwischendurch eine neue Version des Servers einzuspielen. Änderungen / Erweiterungen erfolgen aber hin und wieder.

Ich denke, ich werde jetzt eine Funktion implementieren, die das aus der Registratur gelesene verschlüsselte Passwort mittels DEC 3.0 einmal mit und einmal ohne CipherManager/HashManager entschlüsselt. Dann probiere ich die Datenbankanmeldung mit dem ohne CipherManager/HashManager entschlüsselten Passwort. Funktioniert das, dann ist es ok. Ansonsten nehme ich das mit CipherManager/HashManager entschlüsselte, verschlüssele es ohne CipherManager/HashManager und schreibe es in die Registratur. Somit sollte ich über kurz oder lang alle Passwörter DEC 5.2 kompatible in der Registratur haben.

Oder gibt es eine andere Möglichkeit zu erkennen ob das Passwort mit oder ohne CipherManager/HashManager verschlüsselt wurde?

Grüße

[Assertor]

Hi automatix,

Zitat:

Zitat von automatix

Vielen Dank für eure Hilfe.
...
Oder gibt es eine andere Möglichkeit zu erkennen ob das Passwort mit oder ohne CipherManager/HashManager verschlüsselt wurde

Bitte, gerne! Ich denke, Dein Ansatz ist richtig. Eine Möglichkeit die Passwörter zu unterscheiden gibt es afaik nicht, aber Du könntest an die zukünftigen Passwörter ein Prefix hängen und dann darauf prüfen.

Ist es nicht da, weißt Du, daß es noch DEC3 ist, ist es da, entschlüsselst Du alles nach dem Prefix mit DEC5. Muß ja keine Textfolge sein, kann ja auch ein kleiner - eindeutige Binärfolge sein. Oder alternativ ein zweiter Registry Schlüssel, der für die neuen Passwörter ist. Gibt es den alten Registry Schlüssel, ist es DEC 3 beim neuen halt DEC 5.

Gruß Assertor

[negaH]

Zitat:

... das erste Projekt auf Delphi 2009 konvertiere will

Bedenke aber auch das es fürs DEC 5 keine Portierung für D2009 gibt !

Gruß hagen

[Assertor]

Zitat:

Zitat von negaH

Zitat:

... das erste Projekt auf Delphi 2009 konvertiere will

Bedenke aber auch das es fürs DEC 5 keine Portierung für D2009 gibt !

Gruß hagen

Hagen, hast Du die DEC 5.2 vergessen? Die läuft mit Unicode auch unter D2009. Oder meinst Du die DEC 3?

Gruß Assertor

[automatix]

Hallo!

Ich verwende die hier DEC 5.2. Das hat bisher ganz gut funktioniert.

Zitat:

Bitte, gerne! Ich denke, Dein Ansatz ist richtig. Eine Möglichkeit die Passwörter zu unterscheiden gibt es afaik nicht, aber Du könntest an die zukünftigen Passwörter ein Prefix hängen und dann darauf prüfen.

Ist es nicht da, weißt Du, daß es noch DEC3 ist, ist es da, entschlüsselst Du alles nach dem Prefix mit DEC5. Muß ja keine Textfolge sein, kann ja auch ein kleiner - eindeutige Binärfolge sein. Oder alternativ ein zweiter Registry Schlüssel, der für die neuen Passwörter ist. Gibt es den alten Registry Schlüssel, ist es DEC 3 beim neuen halt DEC 5.

Danke für die Vorschläge, leider funktionieren die ganauso wenig wie meine Lösung. Die Werte liegen unter HKEY_LOCAL_MACHINE und der Benutzer unter dem die Server laufen hat keine Schreibberechtigung auf diesen Zweig.

Also doch worst worst case. :(

Grüße

[negaH]

Zitat:

Zitat von Assertor

Hagen, hast Du die DEC 5.2 vergessen? Die läuft mit Unicode auch unter D2009. Oder meinst Du die DEC 3?
Gruß Assertor

Natürlich nicht, werde mich hüten deine Arbeit zu schmälern ;) Allerdings kann ich eben nicht garantieren das durch diese Umstellung keine Fehler in's DEC gelangt sein können. Damit meine ich nicht dich und deine Arbeit sondern den Fakt das von Version zu Version bei Borland immer mehr Fehler in der RTL entstanden sind. Das wäre im Besonderen auch bem Unicodeproblem der Fall. Siehe Varianten in D7 und folgende Versionen, oder Unit DateUtils bei der in den Umrechnungen von Sekunden nach Millisekunden nicht multipliziert sondern um +1000 addiert wurde.

Gruß Hagen

[Assertor]

Hi Hagen,

Zitat:

Zitat von negaH

Natürlich nicht, werde mich hüten deine Arbeit zu schmälern ;)

Merci :)

Zitat:

Zitat von negaH

das von Version zu Version bei Borland immer mehr Fehler in der RTL entstanden sind. Das wäre im Besonderen auch bem Unicodeproblem der Fall. Siehe Varianten in D7 und folgende Versionen, oder Unit DateUtils bei der in den Umrechnungen von Sekunden nach Millisekunden nicht multipliziert sondern um +1000 addiert wurde.

Absolut richtig, sowas kann man natürlich nicht ausschließen. Alles, was ich testen konnte, habe ich getestet. Insbesondere jedes Textformat, jeden Hash und Cipher - und das nicht nur stichprobenartig. Immer im Vergleich D2006 zu D2009. Sollte es trotzdem irgendwo haken, werde ich natürlich nachbessern.

Gruß Assertor