MD5 unter x32 anders als unter x64

[franktron]

Ich nutze folgenden Code um ein MD5 Hash zu erstellen

Delphi-Quellcode:

Function MD5(const Text : string) : string;
var
  idmd5 : TIdHashMessageDigest5;
begin
  idmd5:=TIdHashMessageDigest5.Create;

  Result:=idmd5.HashStringAsHex(Text);

  idmd5.Free;
End;

Aber wenn ich eine 32Bit Exe mach ist alles schön aber unter 64 Bit kommt ein andere Hash raus

[TiGü]

Eingangs- und Ausgangsdaten für beide Fälle lauten?

[Der schöne Günther]

Kann ich bei mir nicht nachstellen.

Delphi-Quellcode:

 MD5('Hallo Welt')

liefert unter 32 und 64 das Gleiche bei mir (getestet mit 10 Seattle).

[Aphton]

Vielleicht verwendest du zwei Delphi-Versionen (hättest du klären sollen, sonst wüsst ich es genau);
die eine, mit der du die 32 Bit Version erzeugst, verwendet String, die andere, die die 64 Bit Version erzeugt,
verwendet WideString.
Letztendlich hash't du somit zwei verschiedene Datensätze!

Änder mal String um auf AnsiString!

[himitsu]

Na wenn schon, dann doch eher UTF-8, da es sonst beim Unicode ein paar "Verluste" geben könnte.

Viele Hash-Libs arbeiten "geziehlt" mit Integerüberläufen und bei 64 Bit könnte es da natürlich Problemchen geben, wenn dort Mist gebaut wurde.

[Sir Rufo]

Ein Hash wird nur auf Basis von Bytefolgen berechnet.

Um wirklich sicher zu sein, dass man auch wirklich das gleiche vergleicht, dann prüft man die Bytefolgen vor dem Hashen. Alles andere ist nur blindes Herumgestochere.

Ein guter Ansatz ist schonmal sich per

Delphi-Quellcode:

TEncoding.GetBytes

die Bytefolge für den string zu beschaffen und diese dann zu vergleichen. Dann durch den Hash-Algorithmus jagen.

Jetzt kann man zuverlässig sagen, wo sich der Fehler befindet, sollte er überhaupt noch da sein.

[Peter1999]

Der Bug ist unter XE2 reproduzierbar, unter Seattle ist er behoben.

Der Bug lag in den Indys in der Unit IdGlobalProtocols.pas.
Dort ist die Function ROL in der Version bei XE2 falsch implementiert.

Delphi-Quellcode:

function ROL(const AVal: LongWord; AShift: Byte): LongWord; assembler;
asm
  mov  cl, dl
  rol  eax, cl
end;

statt neu

Delphi-Quellcode:

// 32-bit: Arg1=EAX, Arg2=DL
// 64-bit: Arg1=ECX, Arg2=DL
function ROL(const AVal: UInt32; AShift: Byte): UInt32; assembler;
asm
  {$IFDEF CPU64}
  mov eax, ecx
  {$ENDIF}
  mov  cl, dl
  rol  eax, cl
end;

Ein Update der Indys sollte also Abhilfe schaffen.

Viele Grüße...

[franktron]

Zitat:

Zitat von Peter1999 (Beitrag 1341835)

Der Bug ist unter XE2 reproduzierbar, unter Seattle ist er behoben.

Der Bug lag in den Indys in der Unit IdGlobalProtocols.pas.
Dort ist die Function ROL in der Version bei XE2 falsch implementiert.

Delphi-Quellcode:

function ROL(const AVal: LongWord; AShift: Byte): LongWord; assembler;
asm
  mov  cl, dl
  rol  eax, cl
end;

statt neu

Delphi-Quellcode:

// 32-bit: Arg1=EAX, Arg2=DL
// 64-bit: Arg1=ECX, Arg2=DL
function ROL(const AVal: UInt32; AShift: Byte): UInt32; assembler;
asm
  {$IFDEF CPU64}
  mov eax, ecx
  {$ENDIF}
  mov  cl, dl
  rol  eax, cl
end;

Ein Update der Indys sollte also Abhilfe schaffen.

Viele Grüße...

Danke ich werde mal Updaten