md5 hash einer Datei Lazarus

[himitsu]

Klar, wenn MD5 schon in der Lazarus-CL drin ist, isses natürlich nicht schlecht.

Code, welcher in Lazarus und Delphi laufen soll, aber für Windows geschroeben wurde, könnte natürlich die WinAPI nutzen (in Delphi hat man versäumt MD5 und Co. zu integrieren)
http://www.delphipraxis.net/151812-mini-sha1.html (sind eigentlich nur je 3 kleine APIs, also das Selbe nochmal für MD5)

und ansonsten müßte man wohl seinem Lazarus+Delphi-Code eine systemunabhängige Implementation direkt mitgeben, damit man es dann überall und für alles kompilieren könnte.
Ich programmiere halt nur für Windows und da kann ich uch getrost die WinAPI ausnutzen ... dafür isses ja schließlich da.

[CCRDude]

Hmmm... das hat mich doch jetzt nicht losgelassen, daher habe ich mal angefangen zu testen...

Vorab: der CryptAcquireContext-Part ist sauteuer. Wer nur einen Hash braucht, sollte eine andere Methode verwenden; wer mehrere Hashes braucht, sollte den Provider nur einmal darüber acquirieren (ich habe das in den initialization/finalization-Teil der Test-Unit dafür gepackt).

Meine Ergebnisse folgen, und obwohl ich bisher nur kurze und mittlere RawByteString untersucht habe und gar nicht auf Dateien gegangen bin, sieht man schon unterschiedliche Ergebnisse für unterschiedliche Anwendungsfälle.

WinCrypt ist bei größeren Datenmengen tatsächlich sehr gut, bei sehr kleinen dagegen das genaue Gegenteil. DEC ist das Gegenteil zu WinCrypt - bei kleinen Mengen um Längen besser, bei großen langsamer. advapi32.dll schlägt sich ebenfalls sehr gut (Windows-intern evtl. gar dasselbe wie WinCrypt?). Der FPC-Code bleibt zurück, ist aber in einer ähnlichen Kategorie wie DCrypt.

Meine Konsequenz? Danke für die Anregungen hier, ich werde den Test mal auf diverse Dateien ausweiten (sowohl per Stream als auch File Mapping) und daraus sicherlich etwas gewinnen

Code:

= MD5 (Message Digest 5) =
== String tests ==
=== String test "short text" ===
Test line:    Hallo Welt, Hello World!
Test length:  24
Repeat count: 500000

           RFC 1321 by Matthias Fichtner: 00:01.559 (93421b70ad52f2495be431fa727179c1)
            Free Pascal development team: 00:01.214 (93421b70ad52f2495be431fa727179c1)
                      Windows (WinCrypt): 00:02.565 (93421b70ad52f2495be431fa727179c1)
                Hagen Reddmann (DEC 5.2): 00:00.490 (93421b70ad52f2495be431fa727179c1)
            DCPcrypt v2.0 (David Barton): 00:01.221 (93421b70ad52f2495be431fa727179c1)

=== String test "random long text" ===
Test line:    (0*!!!4%(0)(1(5 2 "$($&*+32()' ',07 4...
Test length:  99999
Repeat count: 1000

           RFC 1321 by Matthias Fichtner: 00:02.317 (db60c7fab72be4c6887b6160df41e45f)
            Free Pascal development team: 00:01.326 (db60c7fab72be4c6887b6160df41e45f)
                      Windows (WinCrypt): 00:00.215 (db60c7fab72be4c6887b6160df41e45f)
                Hagen Reddmann (DEC 5.2): 00:00.180 (db60c7fab72be4c6887b6160df41e45f)
            DCPcrypt v2.0 (David Barton): 00:00.986 (db60c7fab72be4c6887b6160df41e45f)

= SHA-1 (Secure Hash Algorithm 1) =
== String tests ==
=== String test "short text" ===
Test line:    Hallo Welt, Hello World!
Test length:  24
Repeat count: 500000

                             Dave Barton: 00:01.602 (017c54b20080d80e03b1b80ecbdf68a86665e644)
                  Windows (advapi32.dll): 00:00.877 (017c54b20080d80e03b1b80ecbdf68a86665e644)
                      Windows (WinCrypt): 00:02.253 (017c54b20080d80e03b1b80ecbdf68a86665e644)
                Hagen Reddmann (DEC 5.2): 00:00.792 (017c54b20080d80e03b1b80ecbdf68a86665e644)
            DCPcrypt v2.0 (David Barton): 00:01.621 (017c54b20080d80e03b1b80ecbdf68a86665e644)

=== String test "random long text" ===
Test line:    2621%1-+,2(*,*#2*+/0#*/2(*0,'+0%#2%+"...
Test length:  99999
Repeat count: 1000

                             Dave Barton: 00:02.602 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
                  Windows (advapi32.dll): 00:00.264 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
                      Windows (WinCrypt): 00:00.260 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
                Hagen Reddmann (DEC 5.2): 00:00.972 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
            DCPcrypt v2.0 (David Barton): 00:01.638 (28f429f7e4ab4e631ac5cad469ce8d6056336015)

[1234567890987654321]

@CCRDude, kannst du mir mal deinen Quellcode schicken?
Besonderes der zu WinCrypt würde mich sehr interresieren!

[CCRDude]

Ich habe meinen ersten Ansatz mal angehhängt. Benötigt JwaWinCrypt (Jwa wird doch auch von Lazarus installiert, oder?) und irgendwas, um den Hash vom Binärformat in etwas lesbares zu übertragen, daher das snlNumbers, kannst Du sicher austauschen. Geht ja auch mehr um die Idee, wie man damit eine Datei hasht, kannst Du ja in md5.pp abkupfern (neben BlockRead/BlockWrite gibt's noch mindestens zwei weitere Varianten, file streams und file mappings... viel Spaß beim Probieren )

[Gargoyl]

Kurz Google gefragt und da kam das: http://www.hackchina.com/en/r/117772/Unit1.pas__html
Da kannst du den Delphi Code einfach "klauen" um MD5 zu berechnen, und hast auch gleich ein Beispiel.
EDIT: hier http://www.hackchina.com/en/cont/117772 gibt es das ganze Projekt.

[CCRDude]

@Gargoyl: mal abgesehen davon, daß sicher niemand klauen will - dieser japanische Code ist von der Implementierung von Matthias Fichtner geklaut, lediglich der Header ist rausgeschnitten.

Der ist nicht nur schlechter als die FPC-Implementierung, die der Threadersteller ja bereits hat, sondern verwendet zudem noch ein FileMapping "am Stück", das bei Dateien ab ca. 2 GB keine Hashes mehr ausspuckt, da die Datei komplett in den Speicher gemappt wird. Aber selbst wenn man dan anpasst und in passenden Stücken mappt, handelt es sich um die langsamste Implementierung.

[himitsu]

Du wirst nichtmal die 2 GB voll in den Speicher bekommen, da man dafür einen zusammenhängenden Speicherbereich benötigt.
Und bei stantardmäßig nur 2 GB virtuellem Speicher, wird es schon schwer werden überhaupt noch 1 GB reinzubekommen.

PS: Bei Dateien über 100-200 maximal 500 MB würde ich sowieso keine MMF verwenden, denn solche Daten auch noch durch die WindowsFileCache zu scheuchen ist nicht grade optimal,
abgesehn davon daß es das system schnell mal ausbremmst, wenn man mehr Daten in die Cache laden will, als aktuell als physischer RAM frei sind (inkl. anderer gecachter Nurlesedaten).
Wird die Cache dann vergrößert, wird schnell mal Programmcode ausgelagert, wellcher dann wieder zurückgeladen werden muß (bremst also das System extrem aus) und/oder es werden andere zu speichernde Daten aus der Cache geschmissen, welche beim Speichern auch bremsend wirken (besonders schlimm, wenn sie danach nochmal verändert und eventuell zurückgeladen werden müßten).
Hier kommt man mit NonCached-Leseoperationen also besser, denn wenn die Daten eh nur einmal sequentiell gelesen werden, macht soeine Cache absolut keinen Sinn.

PS: Wir haben übrigens auch mehrere MD5-Quellcodes in der DP rumliegen.