md5.pas bringt anderes Ergebnis als php md5

[sx2008]

Bei Hashfunktionen sollte man immer eine Selbstest-Funktion mit an Bord haben!
Testvektoren findet man auf Wikipedia.
Also ungefähr so:

Delphi-Quellcode:

procedure MD5Selftest;
begin
  if MD5DigestToStr(MD5String('Franz jagt im komplett verwahrlosten Taxi quer durch Bayern')) <>
    'a3cca2b2aa1e3b5b3b5aad99a8529074' {bitte alles in Goßbuchstaben, bin gerade zu tippfaul} then
    raise Exception.Create('MD5 Selftest failed');
end;

[CCRDude]

Zitat von sx2008:

{bitte alles in Goßbuchstaben, bin gerade zu tippfaul}

Dafür vergleiche ich Hashes gerne per AnsiCompareText, dann ist das upper/lowercase egal (nicht weil ich keine Konventionen bzgl. des cases hätte, sondern weil es spätestens beim Testen anderer Algo-Implementierungen dann doch wieder übersehen wird und zu Fehlersuche führt).

[Zacherl]

Hatte letztens ein ähnliches Problem. Eine MD5 Unit, die ich vor Ewigkeiten mal hier im Forum gefunden hatte, hat unter XE4 auf einmal mehr oder weniger zufällige Hashs produziert. Konnte das Problem leider nicht identifizieren, aber vermute, dass es am eingestreuten Assembler Code lag.

[Namenloser]

Zitat von sx2008:

Bei Hashfunktionen sollte man immer eine Selbstest-Funktion mit an Bord haben!
Testvektoren findet man auf Wikipedia.
Also ungefähr so:

Delphi-Quellcode:

procedure MD5Selftest;
begin
  if MD5DigestToStr(MD5String('Franz jagt im komplett verwahrlosten Taxi quer durch Bayern')) <>
    'a3cca2b2aa1e3b5b3b5aad99a8529074' {bitte alles in Goßbuchstaben, bin gerade zu tippfaul} then
    raise Exception.Create('MD5 Selftest failed');
end;

Für solche Tests sind eigentlich Assertions prädestiniert – das ist schöner als if und raise Exception.

[sx2008]

Zitat von NamenLozer:

Für solche Tests sind eigentlich Assertions prädestiniert – das ist schöner als if und raise Exception.

Kommt drauf an...
Hier habe ich if und raise verwendet, weil ich möchte dass die Prüfung auch in der Releaseversion der Software stattfindet um Manipulationen an sicherheitsrelevanten Funktionen vorzubeugen.
Ansonsten hast du natürlich recht.

[Furtbichler]

Zitat von sx2008:

Hier habe ich if und raise verwendet, weil ich möchte dass die Prüfung auch in der Releaseversion der Software stattfindet um Manipulationen an sicherheitsrelevanten Funktionen vorzubeugen.

Man lernt nie aus.

[sh17]

"Sicher" ist MD5 aber nicht mehr

[CCRDude]

Zitat von sh17:

"Sicher" ist MD5 aber nicht mehr

Das kommt auf den Anwendungszweck an - und wen ich den Anwendungszweck hier zu erraten versuche (Passwort-Hash?), wäre ein Hinweis auf die Nutzung von Salts angebrachter (und daher hiermit genannt) - denn dank Rainbow Tables wäre hier auch ein SHA-2 nicht wesentlich "sicherer" als MD5.

[BUG]

Zitat von CCRDude:

Nutzung von Salts angebrachter (und daher hiermit genannt) - denn dank Rainbow Tables wäre hier auch ein SHA-2 nicht wesentlich "sicherer" als MD5.

Auch wenn wir etwas vom Thema abkommen: Klassische Hashfunktionen ermöglichen Brute-Force-Angriffe, da sie zu effizient sind; deshalb wird meist zu Algorithmen wie bcrypt oder PBKDF2 geraten.