Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
MOD Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007 Beiträge: 1003
|
Verfasst am: 07.02.2010, 02:08 Titel: MD5 |
|
|
Ich hab für zukünftige Zwecke mal einen Code für MD5-Hashes portiert.
Es gibt hier und da zwar verschiedene FB-Versionen, aber entweder funktionieren sie nicht oder nicht so, wie ich es brauchen könnte.
Der Code ist dank OOP (C++ Portierung) ziemlich übersichtlich und durch zwei zusätzliche Funktionen ziemlich einfach zu bedienen. Diese wären:
Code: | createHash(text As String) As String |
und
Code: | createFileHash(file As String) As String |
Die Zip enthält auch ein Beispiel.
Einige Funktionen hab ich gegen Makros ersetzt um die Performance zu erhöhen.
Viel Spaß damit:
Download
Zuletzt bearbeitet von MOD am 16.01.2011, 16:46, insgesamt einmal bearbeitet |
|
Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007 Beiträge: 949 Wohnort: Austria
|
Verfasst am: 07.02.2010, 02:37 Titel: |
|
|
Ich hab schon öfters eine MD5 Berechnung benötigt und hab bis jetzt immer auf ein altes Code-Schnipsel aus dem englischen FB-Forum zurückgegriffen. Deins scheint mir für manche Anwendungen aber etwas komfortabler, also möchte ich mich schon im Voraus bei dir für diesen Code bedanken, da ich ihn sicher einmal verwenden werde.
Kleiner Tipp:
Damit die Funktion memcpy nicht beim Inkludieren von "crt/string.bi" manuell auskommentiert werden muss könntest du mit einer Pre-Compiler Bedingung lösen:
Code: | #ifndef memcpy
Function memcpy(destination As UByte Ptr, source As UByte Ptr, num As UInteger) As UByte Ptr
'[...]
End Function
#endif |
So wird die Funktion nur deklariert, wenn memcpy nicht bereits deklariert wurde. _________________ Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
Nach oben |
|
|
MOD Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007 Beiträge: 1003
|
Verfasst am: 07.02.2010, 02:41 Titel: |
|
|
Gute Idee, daran hab ich gar nicht gedacht. Schon aktualisiert. |
|
Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008 Beiträge: 1917
|
Verfasst am: 07.02.2010, 05:14 Titel: |
|
|
Code: | Function memcpy(destination As UByte Ptr, source As UByte Ptr, num As UInteger) As UByte Ptr
'Ersatz für "crt/string.bi"
'Prüft nicht nach der Größe von Destination
For i As Integer = 0 To num - 1
destination[i] = source[i]
Next
Return destination
End Function |
Meinst du nicht, dass es einfach wäre, einfach die CRT Funktion zu deklarieren? Die wäre auch deutlich perfomanter. |
|
Nach oben |
|
|
MOD Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007 Beiträge: 1003
|
Verfasst am: 07.02.2010, 15:48 Titel: |
|
|
Performanter könnte sein, aber nachdem ich das geändert habe, hab ich die Geschwindigkeit gemessen und konnte keine Veränderung feststellen. Die Funktion wird auch pro Durchlauf nur dreimal ode so aufgerufen, da fällt das nicht ins Gewicht. Ich wollte schlicht nicht auf die crt angewiesen sein und die ganzen anderen Funktionen unnötig mitschleppen müssen.
Der Code ist offen und wenn jemand lieber die crt verwenden will, hab ich damit keine Probleme. |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 07.02.2010, 16:15 Titel: |
|
|
du kannst ja ein #ifdef USE_CRT oder so benutzen... _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008 Beiträge: 1917
|
Verfasst am: 07.02.2010, 20:45 Titel: |
|
|
Die CRT wird so oder so gelinkt. Sogar bei dem Programm hier:
(Vermutlich sogar bei einem leeren Programm, weil die Ctors und Dtors der FBRT ganz sicher die CRT benötigen)
Aber egal, zumindest auf modernen Systemen ist die CRT immer schneller. Erstrecht, wenn man die nicht für i386 sondern für i686 oder noch höher kompiliert hat.
</ot> |
|
Nach oben |
|
|
MOD Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007 Beiträge: 1003
|
Verfasst am: 23.02.2010, 21:01 Titel: |
|
|
Kurzes Update:
Ein paar unnötige Operationen entfernt und demzufolge die Hashes in der Beispieldatei angepasst. |
|
Nach oben |
|
|
AxelNiedenhoff
Anmeldungsdatum: 24.03.2016 Beiträge: 8
|
Verfasst am: 12.04.2016, 11:06 Titel: MD5: Absturz ab einer bestimmten Länge der Eingabe |
|
|
Hallo MOD,
ich habe festgestellt, dass die MD5-Generierung abstürzt, wenn die Länge der Eingabe 16390 Zeichen überschreitet (mit dem 32-Bit-Compiler unter Windows). Ein Beispiel:
Code: | #INCLUDE "MD5.bi"
PRINT createHash(SPACE(16390))
PRINT createHash(SPACE(16391))
|
Das erste PRINT wird ausgeführt, das zweite läuft in einen Absturz.
Lässt sich das reparieren?
Mit dem 64-Bit-Compiler funktioniert das obige Beispiel, allerdings ergeben sich damit bei noch größeren Eingaben Endlosschleifen. Vielleicht ist das ein zweites Problem, vielleicht ist das das gleiche. |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 12.04.2016, 16:38 Titel: |
|
|
Ein Blick in die MD5Checksum.bas klärt den Fehler schnell auf: In der Funktion createHash wird ein temporärer Puffer der Länge 16384 angelegt, aber der String wird vollständig in den Puffer reinkopiert - ist er länger als 16384 Zeichen, wird also unweigerlich der restliche Programmspeicher überschrieben - daher der Crash.
Gemeint war hier wohl, dass der String in 16KB-Blöcken, wie in der Funktion createFileHash direkt untendrunter, verarbeitet wird. Um längere Strings zu verarbeiten, müsstest du also einfach nur die beiden Funktionen etwas angleichen. Noch besser wäre es natürlich, nicht ständig den String zu kopieren. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
AxelNiedenhoff
Anmeldungsdatum: 24.03.2016 Beiträge: 8
|
Verfasst am: 13.04.2016, 10:05 Titel: |
|
|
Sehr guter Hinweis, vielen Dank! Ich könnte einen Patch für die Bibliothek zur Verfügung stellen. Was sind dafür so die Gepflogenheiten? PN an MOD? |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 13.04.2016, 15:05 Titel: |
|
|
MOD ist auch regelmäßig im Forum unterwegs, von daher wird er den Thread auch so sehen. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
MOD Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007 Beiträge: 1003
|
Verfasst am: 14.04.2016, 17:56 Titel: |
|
|
Jojo hat Folgendes geschrieben: | MOD ist auch regelmäßig im Forum unterwegs, von daher wird er den Thread auch so sehen. |
...mit der Ausnahme, dass ich im Urlaub war.
Du kannst deinen Patch gerne einfach hier in code-tags packen, ich versuche es die Tage anzupassen. Davon ist dann wohl auch mehr betroffen (seltsam, dass es bisher nicht aufgefallen ist), da SHA1 und SHA512 ebenso davon betroffen sind, wie auch mdMessageDigest aus dem mdTypes Paket. |
|
Nach oben |
|
|
AxelNiedenhoff
Anmeldungsdatum: 24.03.2016 Beiträge: 8
|
Verfasst am: 15.04.2016, 12:35 Titel: |
|
|
Hier kommt der Patch:
Code: | Function createHash(text As String) As String
'Dim As UInteger nLength = Len(text)
Dim As Integer nLength = Len(text)
If nLength = 0 Then
Return "Kein Text enthalten"
EndIf
Dim As UByte buffer(16384)
'For i As Integer = 1 To nLength
' buffer(i - 1) = Asc(Mid(text, i ,1))
'Next
Dim As MD5Checksum MD5
'NEW CODE
Dim n As Integer = 16384
For i As Integer = 1 To nLength STEP 16384
If i > nLength - 16384 Then n = nLength - i + 1
For j As Integer = i To i + n - 1
buffer(j - i) = Asc(Mid(text, j, 1))
Next
MD5.Update(@buffer(0), n)
Next
'END OF NEW CODE
'MD5.Update(@buffer(0), nLength)
Return MD5.Final()
End Function
|
Den Typ von nLength habe ich geändert, da LEN wohl tatsächlich einen vorzeichenhehafteten Wert zurückgibt und ich das in meiner Schleife frech ausnutze.
Eine Beobachtung noch: Mit dem 64-Bit-Compiler erzeugt die MD5-Bibliothek andere Werte als mit der 32-Bit-Version (ganz unabhängig von obigem Patch). Ich habe da die Umkopierfunktionen im Verdacht, weil die viel mit (U)Integer arbeiten; und der ist ja unter 64 Bit länger/breiter als unter 32 Bit. Ich hab’s mir aber noch nicht genau angesehen. Vielleicht findest Du da was raus. |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 15.04.2016, 13:03 Titel: |
|
|
Code: |
For j As Integer = i - 1 To i + n - 2
buffer(j) = text[j]
Next
|
Is n ticken flotter so.
Ach, und übrigens is in diesem Code noch n fetter Bug enthalten (wer siehts?)
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007 Beiträge: 949 Wohnort: Austria
|
Verfasst am: 15.04.2016, 16:32 Titel: |
|
|
Ich frage mich, wieso man überhaupt einen Buffer verwendet und nicht direkt von den String-Daten die MD5 Prüfsumme "errechnet". Soweit ich mich an meine letzte MD5 Implementierung erinnere, ist das nicht notwendig - ich hab mir allerdings diese Implementierung hier nicht angeschaut. Neben der entfallenden Längen-Beschränkung sollte sich das auch noch bzgl. Laufzeit positiv auswirken, da das unnötige kopieren entfällt.
Das betrifft übrigens genauso SHA-1, SHA-256 oder CRC (für den Fall, dass es dort genauso mit einem zusätzlichen Buffer gemacht wird). _________________ Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
Nach oben |
|
|
MOD Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007 Beiträge: 1003
|
Verfasst am: 15.04.2016, 17:50 Titel: |
|
|
Ich erinnere mich nicht mehr genau, warum ich den Buffer verwende, aber ja, im Prinzip wäre die beste Lösung den Buffer rauszunehmen und @text[0] zu übergeben.
Der Code ist relativ alt und MD5, SHA1 und SHA512 (CRC habe ich nie umgesetzt) sind mittlerweile als mdMessageDigest in mdTypes enthalten. Habe dort den einfachen Fix bereits eingecheckt und das Downloadpaket wird heute Nacht selbstständig auf den aktuellsten Stand gebracht.
Die Downloads der alten Versionen hier habe ich auch gefixt und an 64bit angepasst. |
|
Nach oben |
|
|
AxelNiedenhoff
Anmeldungsdatum: 24.03.2016 Beiträge: 8
|
Verfasst am: 17.04.2016, 22:35 Titel: |
|
|
Das finde ich toll an der FreeBASIC-Gemeinschaft, dass Probleme so ratzfatz behoben werden. |
|
Nach oben |
|
|
|