Heyho,

nach langer Pause meld ich mich hier mal wieder und wie immer hab ich ein mehr oder weniger kleines Problem bei dem ich selbst nicht so recht weiter weiß.
Ich möchte eine ID aus den Hardwaredaten des PCs berechnen um damit eine Lizenzprüfung durchzuführen. Dazu hol ich mir die Daten aus der WMI, pack die alle in einen String und errechne dann daraus einen 4 Byte großen Hash. Problem dabei ist, das der Hash möglichst kollisionsfrei sein sollte und die Frage ist wie ich das am besten hin bekomm. Gibt es vlt. schon einen standardisierten Hash der mir einen 4 Byte großen Wert ausspuckt, oder muss ich mir wirklich die Mühe machen und selbst einen implementieren und testen?

MfG Bergmann.

Wenn es nicht kryptografisch sicher sein muss, dann reicht doch sowas wie CRC32 aus, oder?

Die üblichen guten Hashverfahren sollten so ~random~ in ihrer Bitfolge sein das man einfach einen nehmen und auf die gewünschte Länge kürzen kann (also einfach nur die ersten 32 bit nehmen). Die Kollisionswahrscheinlichkeit sollte sich nur um den Faktor der konkret benutzen Hashlänge ändren.

Das ist aber mehr eine Vermutung. Den Beweis(oder Wiederlegung) müßte jemand liefern mit mehr Begabung für Mathe.

Das Abschneiden eines kryptografischen Hashwertes ist sicher im Rahmen der Geburtstagsparadox-Grenze, vgl. de.wikipedia.org/wiki/Geburtstagsparadox. Das heißt, beim Abschneiden auf 32-Bit mußt Du verstärkt mit Kollisionen rechnen, wenn mehr als ca 2^16 ~ 65000 IDs ins Spiel kommen.

Gruß Gammatester

Edit: Im englischen Wiki findest Du eine Wahrscheinlichkeitstabelle mit einer Zeile für 32-Bit, zB 75% Kollisionswahrscheinlichkeit für ca 110000 IDs.

Warum soll der Hash nur 4 Byte groß sein?
Wenn es kein "Platzproblem" beim Speichern der Hashes gibt, würde ich einfach einen SHA1 oder so benutzen.

Ok. Da von einem simplen Faktor zu sprechen war sicherlich unpassend.

Aber es wiederlegt noch nicht meine Vermutung das ein auf 32bit gekürzter längerer Hash (egal ob MD5 oder SHA-irgendwas) nicht wirklich schlechter wäre als ein Verfahren das gleich 32bit auswirft. Ob 4Byte überhaupt grundsätzlich ausreichen können um ein tolerierbares Kollisionsrisiko zu haben ist eine andere Frage. Wo liegt Bergmann89s Schmerzgrenze?

Ralf Jansen hat folgendes geschrieben :

Ok. Da von einem simplen Faktor zu sprechen war sicherlich unpassend. Aber es wiederlegt noch nicht meine Vermutung das ein auf 32bit gekürzter längerer Hash (egal ob MD5 oder SHA-irgendwas) nicht wirklich schlechter wäre als ein Verfahren das gleich 32bit auswirft.

Richtig, es ist nicht schlechter, sondern besser als zB CRCs (das war übrigens keine Kritik an Deinem Beitrag)! Für alle endlichen Verfahren gibt es halt Kollisionen, wie man sich leicht an 8-Bit-IDs etc klar macht (im Gegensatz zu Marketingversprechen die totale Sicherkeit in 16-Bit-Codes packen).

Zitat:

(das war übrigens keine Kritik an Deinem Beitrag)

Und wenn wäre auch nicht schlimm

Hey,

in diesem Fall ist der Speicher wirklich begrenzt, deshalb waren nur 4 byte vorgesehen. An CRC32 hab ich auch schon gedacht, aber da hab ich in nem anderen Forum gelesen, dass das in diesem Fall ungeeignet ist, da es wohl mehr Kollisionen geben würde (keine Ahnung ob das stimmt). Ein Arbeitskollege von mir hat einen anderen HashAlgo gefunden, der Int64 Hashs generiert. Den haben wir dann am Ende auch genommen und dafür an anderen Stellen etwas gespart.
Noch kurz zum besseren Verständnis: Ich generiere nicht eine ID aus allen Komponenten des PCs sondern 4-5 IDs aus den Teilkomponenten (HDD, CPU, Mainboard, ...). Solange nur eine dieser Teil-IDs ungültig ist, dann ist der Gesamt-Hash trotzdem noch gültig. So kann man auch mal schnell eine Festplatte oder ähnliches tauschen ohne gleich Nachhause zu telefonieren und das Produkt neu freischalten zu müssen

MfG Bergmann.