MD5 32 Bit und 64 Bit

[himitsu]

Zitat von Weeze14:

Hier kann nicht viel schieflaufen denke ich:

Zitat von Sir Rufo:

(sehr beliebt wenn ein Hash von einem String erzeugt werden soll und mal wieder nicht auf das Encoding geachtet wurde)

[Weeze14]

Mhh.. ich dachte der holt sich die Kodierung automatisch - falsch gedacht.
Füge ich nun aber TEncoding.ANSI als kodierung hinzu, ist der Hash mit 32-Bit korrekt, nicht aber mit 64-Bit

[himitsu]

Zitat von Weeze14:

Mhh.. ich dachte der holt sich die Kodierung automatisch - falsch gedacht.

Aus dem hier sichtbaren Code ist das nicht erkenntlich und reingesehn hatte ich aber auch nicht.
Es kommt drauf an, was die innen machen, aber da der String früher einfach als "ANSI" gehasht wurde, kann es jetzt zu Problemen kommen, denn die können ja nicht blind das Unicode (seit Delphi 2009) in ANSI umwandeln.

Viele Codes kodieren das sorgar dann einfach als Unicode (also ganz einfach unverändert den binären Inhalt und manchmal sogar wird auch noch nur die Hälfte gehascht, da man gerne mal das SizeOf(Char)=2 vergessen hat.

Und selbst ANSI war früher schonmal falsch, denn wenn ein Russe, Japaner und selbst ein Ami seinen ANSI-String hashen tat, dann kam dennoch schnell mal etwas Anderes raus, als wenn das ein Deutscher machte.

Zitat von Weeze14:

nicht aber mit 64-Bit

Hmmmm, also entweder machst du immernoch einen Fehler, oder

Zitat von Sir Rufo:

Wenn das nicht gegeben ist, dann ist entweder die Hash-Funktion falsch implementiert oder die Eingangsdaten sind eben nicht identisch

[Weeze14]

Die Eingabedaten sind nur ein Teststring (const s: String = 'Test'; ) und der ist immer gleich.
Sehr misteriös denke ich.

Demnach ist diese Funktion also sehr schlecht nehme ich an. Denn Angenommen ich übergebe "Tèst", dann ist das Ergebnis wieder falsch, da man den Encoding ja angeben muss.
Gibt es denn sinnvolle Alternativen?

Edit:
bisher habe ich zum Vergleichen den hash-Generator http://hashgenerator.de benutzt. Leider muss ich sagen, dass der schlecht ist und daher die falschen Werte kommen.

Ich übergebe der MD5-Funktion jetzt auch als Encoding das "TEncoding.Default". Ist das ok so oder nicht?

Der Wert der 64-Bit-Version ist aber noch immer ungleich der 32-Bit-Version.

[Sir Rufo]

Ich denke ich war noch nicht deutlich genug:

Um wirklich die Funktion eines Hash-Generators zu prüfen muss ich dem Hash-Generator gesichert identische Daten übergeben.

Und was verarbeitet so eine Hash-Funktion? Richtig, Byte-Mengen.

Also gibt man so einem Hash-Generator eine definierte Byte-Menge um die Ergebnisse zu überprüfen.

Und wie wird ein String dann gehasht? Der wird vorher in eine Byte-Menge umgewandelt.
(Sollte ich dieses umgewandelt irgendwie noch größer oder bunter oder irgendwie lauter schreiben?)

Eignet sich ein String jetzt für so eine Überprüfung? Nein, denn nun ist ja nicht nur der Hash-Generator involviert, sondern auch die Umwandlung von String in eine Byte-Menge!

Für eine sinnvolle Überprüfung der Hash-Funktion führt man auf den unterschiedlichen Systemen einen Test mit identischen Byte-Mengen durch.
Für eine sinnvolle Überprüfung der String in Byte-Menge führt man auf den unterschiedlichen Systemen einen Test mit identischen Strings durch - und wundert sich

[himitsu]

Nur um das mal zu erklären (falls wirklich ein Fehler im Hash-Code ist):
Viele MD5-Codes arbeiten absichtlich mit Integerüberläufen, um sich das manuelle Kürzen zu sparen,
aber dafür müssen in dem Code die Typen und Ähnliches auch genau stimmen.

Aber ich würde schon stark davon ausgehn, daß soein Fehler im Indy in den letzten 2 Jahren aufgefallen wäre und behoben wurde.



Gerade bei solchen schrottigen Testwebseiten kann man eigentlich fast nur von ASCII halbwegs sicher ausgehn, daß es "wie gewollt" funktioniert, da sich beim Rest kein Encoding angeben lässt und auch nirgendwo verraten wird, womit das Ding rechnet.

Zitat von Sir Rufo:

Um wirklich die Funktion eines Hash-Generators zu prüfen muss ich dem Hash-Generator gesichert identische Daten übergeben.

Dieses ist dort also nicht möglich.

• Entweder man hat von der Gegenseite Vergleichshashs und kann damit arbeiten.
  Also z.B. da wo der eigene Hash letztendlich benutzt wird und von anderen Stelen erstellt/geprüft wird.
  Es gibt bestimmt auch irgendwo Hashs bekannter Test-Daten.
• Oder man nutzt einen anderen Hash-Code, von dem man weiß, daß er ordentlich arbeitet.

[Weeze14]

Ich glaube ich werde das niemals hinbekommen (Danke Sir Rufo, deine Schläge auf den Hinterkopf haben geholfen). Einen String hashen, funktioniert nun sowohl mit 32-, als auch mit 64-Bit und die Resultate sind identisch.
Jedoch will das Erzeugen eines Hashs für eine Datei noch immer nicht (unterschiedliche resultate 32-Bit <> 64-bit):

Delphi-Quellcode:

function MD5File(const s: string): string;
var
 MD5: TIdHashMessageDigest5;
 fs: TFileStream;
begin
 Result:='';

 if FileExists(s) then
  begin
   MD5 := TIdHashMessageDigest5.Create;
   fs := TFileStream.Create(s, fmOpenRead or fmShareDenyWrite);

   try
    Result := MD5.HashStreamAsHex(fs);
   finally
    fs.Free;
    MD5.Free;
   end;
  end;
end;

Die einzige MD5-Implementieren, die ich bisher gesehen habe, die auch den korrekten Hash für eine Datei erzeugt, ist die von Assarbad:
assarbad.net/en/stuff/!export/md5.zip (leider aber nicht mehr lauffähig unter neueren Delphi Versionen)