Ich frag mich ja schon länger wie das geht. Geht das nach Pc-Ausstattung oder wird einfach nur zufällig irgendwas genommen (da kanns ja dann auch doppelte geben)


Bitte für die Frage nicht schlagen

CODE

void CPreferences::CreateUserHash(){ for (int i = 0;i != 8; i++){  uint16 random = rand();  memcpy(&userhash[i*2],&random,2); } // mark as emule client. that will be need in later version userhash[5] = 14; userhash[14] = 111; }

kann es da nicht schonmal vorkommen, dass eMule einen Hash kreirt, der schon existiert? Ich meine 16 Zahlen sind schon ne Menge aber genau so groß kann auch die Wahrscheinlichkeit sein das mein Nachbar den selben Hash hat wie ich oder etwa nicht?

QUOTE (sambal-olek @ Apr 19 2003, 12:00 PM)

CODE void CPreferences::CreateUserHash(){ for (int i = 0;i != 8; i++){  uint16 random = rand();  memcpy(&userhash[i*2],&random,2); } // mark as emule client. that will be need in later version userhash[5] = 14; userhash[14] = 111; }

Da ich nichts mit solchen Programmcodes anfangen kann, bitte etwas einfacher ausdrücken

Es werden nacheinander 8 16Bit(= 2 Byte) große Zufallszaheln erzeugt. Dieser werden aneinadergefügt.

Man erhält also einen 16 Byte großen Zufallswert. Das entspricht 281.474.976.710.656 unterschiedlichen Kombinationen (abzüglich der Bytes 5 und 14, die feste Werte erhalten bleiben also noch 4.398.046.511.104 Kombinationen übrig)

Danke, so versteh sogar ich es

und was bedeutet:

QUOTE

// mark as emule client. that will be need in later version userhash[5] = 14; userhash[14] = 111;

mfg flow de

Ich denke mal das sind die Bytes 5 und 14, die einen festen Wert erhalten in dem Fall 14 und 111. Das geht je bereits aus Sambals Erklärung hervor.

P.S.: Sambal-Olek schmeckt gut.

QUOTE (sambal-olek @ Apr 19 2003, 10:46 AM)

Es werden nacheinander 8 16Bit(= 2 Byte) große Zufallszaheln erzeugt. Dieser werden aneinadergefügt. Man erhält also einen 16 Byte großen Zufallswert. Das entspricht 281.474.976.710.656 unterschiedlichen Kombinationen (abzüglich der Bytes 5 und 14, die feste Werte erhalten bleiben also noch 4.398.046.511.104 Kombinationen übrig)

Also ich weiss ja nicht was Du für einen Taschenrechner hast, aber bei mir ist 8 Werte a 16 Bit eine Zahl mit 128 Bit. Und 2 hoch 128 ist deutlich mehr als 281.474.976.710.656.

BTW: die rand-Funktion liefert nur 15-Bit Integer.

QUOTE (devil_jo @ Apr 19 2003, 01:42 PM)

Also ich weiss ja nicht was Du für einen Taschenrechner hast, aber bei mir ist 8 Werte a 16 Bit eine Zahl mit 128 Bit. Und 2 hoch 128 ist deutlich mehr als 281.474.976.710.656.

Jo, ich Trottel hab ohne nachzudenken nur 8^16 eingetippt statt 2^128. Danke für den Hinweis.

Dann sinds halt 3,9402006196394479212279040100144 *10^115 mögliche Kombinationen

256^14
die beiden festen bytes sind dazu da um eMules (fast) sicher identifizieren zu können

Es scheint, unsere Rechner kommen tatsächlich auf unterschiedliche Ergebnisse:
Bei mir ist 2^128 = 3,4028236692093846346337460743177*10^38

Is aber auch egal. Auf jeden Fall ist es wahrscheinlicher, auf zwei hintereinanderfolgenden Samstagen 6 Richtige mit Zusatzzahl zu erhalten als dass zwei gleiche Userhashs auftreten.

QUOTE (devil_jo @ Apr 19 2003, 02:08 PM)

Es scheint, unsere Rechner kommen tatsächlich auf unterschiedliche Ergebnisse: Bei mir ist 2^128 = 3,4028236692093846346337460743177*10^38

Ich gebs auf Weiß der Geier auf welche Tasten ich da gepatscht habe, aber du hast natürlich recht. (und nein: ich hab heute noch nix gesoffen)

QUOTE (sambal-olek @ Apr 19 2003, 12:10 PM)

ich hab heute noch nix gesoffen

vieleicht liegts ja daran

QUOTE (Technoboy @ Apr 19 2003, 11:32 AM)

Ich denke mal das sind die Bytes 5 und 14, die einen festen Wert erhalten in dem Fall 14 und 111. Das geht je bereits aus Sambals Erklärung hervor. P.S.: Sambal-Olek schmeckt gut.

schon klar, ich wolte aber wissen warum diese werte festgesetzt werden!

QUOTE

// mark as emule client. that will be need in later version userhash[5] = 14; userhash[14] = 111;

Das hat etwas mit dem Erkennen des Clients zu tun. Anhand der festen Werte werden einige Typen (eMule, MLDonkey, usw) und machmal auch Versionen erkannt. Wenn eMule einen anderen als eMule erkennt, schickt er Telegramme aus dem sogenannte Extented (eMule) Protocol, die die anderen ja gar nicht kennen. Darüber läuft z.B. der Quellenaustausch.

Hey Danke!

QUOTE (devil_jo @ Apr 19 2003, 01:08 PM)

Is aber auch egal. Auf jeden Fall ist es wahrscheinlicher, auf zwei hintereinanderfolgenden Samstagen 6 Richtige mit Zusatzzahl zu erhalten als dass zwei gleiche Userhashs auftreten.

Das glaube ich nicht, da es nicht möglich ist, 6 Richtige mit Zusatzzahl zu haben. Höchstens 6 Richtige mit Superzahl

SCNR

Andreas

Mist! Ich wußte, ich wollte da noch etwas ändern, konnte mich aber nicht mehr erinnern wo.

*uraltthreadwiederherkram*

und wie sieht das ganze mit dateien aus?
das muss ja anders gehen, da wenn ich eine datei in den share gebe, die schon existiert, dann der hash ja gleich ist

(p.s.:suche und docs habe ich nichts gefunden)

Die werden logischerweise nach ihrem Inhalt berechnet....


Es ist ein komplizierter Algorithmus, der das ganze File durchliest und am Schluss den Datei-hash ausspuckt.

Einfach mal die Suchmaschine deines Vertrauens mit "MD5" füttern.

thx

für alle dies interessiert: google hat mir diese Seite gefunden, die meiner Meinung nach das ganze ganz gut erklärt.
allerdings sollten nur profis sich den algorithmus am schluss ansehen

ganz nette fakten von dort habe ich:

md5 hat einen hashwert von 128
bei einer länge von 64 dauert es 600.000 Jahre eine Datei zu finden, die gleich ist.

Ich dachte eMule nutzt MD4?!

de MTX

Selbst wenn, das Prinzip ist ja gleich

Wenn das stimmt...

das habe ich gerade in der fixed-Liste gefunden:

Dann zieh von meiner Antwort ne "1" ab

äähm, auf dieser seite (siehe einer meiner vorherigen Beiträge) stand, dass md4 knackbar wäre.

wäre es dann nicht klug auf md5 umzusteigen? oder verliert man dann die kompatibilität vollkommen?

Alle jetzigen eD2K-Links wären unbrauchbar.

de MTX

wäre es nciht so, dass man die alten zwar noch lesen könnte, aber die Benutzer von eMule<neuesten Version und eDonkey(,....) mit den neuen nichts mehr anfangen könnten?

Der Aufwand, einen MD4 Hash zu fälschen (eine Datei mit gleichem Hash zu generieren) ist immer noch so groß, dass es nicht rechtfertigt, eMule völlig umzubauen und somit keine Kompatibilität zum restlichen eD2K Netzwerk zu haben.

de MTX

PS: Das wäre ein Thema, wenn massenweise Dateien-Hashes gefakt werden - Hab ich aber bisher noch NIE erlebt.

Wenn es sich bei der Quell-CD/DVD um Audio oder Video handelt, kann es sein, daß beim zweiten Rippen (andere) interpolierte Lesefehler entstanden sind als beim ersten Mal -> anderer Hash

Sera, vor längerem, ich glaub wüstenbrot wars, hatte er files auf CD ausgelagert und anschließend wieder auf Platte kopiert und im muli eingelesen. Ergebniss war anderer filehash. Ich glaub, da kannst du nichts dagegen machen.

Also, bei 'ner Daten-CD sollte das wirklich nicht passieren (außer man hat 'ne beknackte CD-Firmware, die Datenlesefehler unterschlägt). Der Hash wird doch auch nur über den Datei-Inhalt gebildet (also unabhängig vom Änderungsdatum). Entweder sind da Bits gekippt oder der Hash muß der gleiche werden.

Also beim Zurückspulen eines Releases von CD auf Platte hatte ich erst 1xPech: Eine mp3 wurde im hash verändert. (gebrannt als Daten-CD) Seitdem packe ich alles und jeden, selbst wenn es nicht nötig wäre.

Schade, daß es nicht so einfach ist, eine Datei zu rekonstruieren. Wäre gut zur Leichen-Bekämpfung. So muß man bei reshare-Anfragen ein neues Release starten, obwohl zum alten noch einige chunks evtl. vorhanden sind

Es ist nicht unwahrscheinlich das beim rippen eines Filmes oder sonstiger Bearbeitung der anschließende Hashvorgang einen anderen Hashwert erzeugt als urprünglich erwartet. Der Algorithmus zur Berechnung ist dahingehend ausgerichtet möglichst kollisionsfrei Hashwerte zu erzeugen. Es reicht bereits ein kleiner Unterschied in der Bitfolge, der sich weder auf die Dateigröße noch auf den sichtbaren Inhalt auswirkt und es ergibt sich ein anderer Hash. Der Dateiname und das Datum haben auf den Hash keine Auswirkung. Emule verwendet einen abgewandelten md4 Hashvorgang.

PS: Wenn es leicht wäre den Hash zu rekonstruieren, wäre er wohl sinnlos. Es gab zum Thema Hash bereits einen guten Thread in diesem Board. Eigenartigerweise lässt sich dieser über die Suche nicht mehr finden. Scheint, aus welchem Grund auch immer, gelöscht worden zu sein.

cu