Hash- Werte der Files "fälschbar"

[Bennel]

Ich habe mal eine Frage an all die Programmierer hier im Forum.
Besteht eine Möglichkeit in eMule- Netzen die Hash- Werte zu fälschen, so dass man sozusagen "Fakes" erzeugen kann? Also Dateien mit verschiedenem Inhalt, aber gleichem Hash- Wert?
Ich kenne mich zwar mit Technik aus, aber leider fehlt mir für solche Überlegungen leider der software-technische Background.

Eine finnische Firma namens Viralg soll beispielsweise versucht haben, Hash- Werte zu fälschen um die Filesharing- Netzwerke zu korrumpieren. Inzwischen verkaufen die ihr Patent bei Ebay.
Link: *****

Kann sich jemand vorstellen ob das möglich ist, auch im Bezug auf den eMule- Client? Wenn ja, wie????

Wäre sehr dankbar für Hilfe

[Jok3r]

Es gab vor einiger Zeit, ca 2004 rum , mal eine Newsmeldung auf heise.de das man das MD5 Hash Verfahren, welches eMule soweit ich weiß benutzt, aushebeln könnte. Das ist richtig.

Wenn das ganze stimmt, was das Unternehmen da redet, wäre die logisch notwendige Reaktion der Entwickler das Hashverfahren um ein weiteres zu ergänzen (MD5+SHA1 usw.), oder es gänzlich Auszutauschen, was Emule aber die Abwärtskompatibilität zu den Links nehmen würde. Das wäre sehr schlecht für die gängigen Esel Seiten und Piraten Boards

heise.de/security/news/meldung/50148

Kann sich jemand vorstellen ob das möglich ist, auch im Bezug auf den eMule- Client? Wenn ja, wie????

Praktisch kann ich mir das schlecht vorstellen. Ich vermute das dass mit viel Aufwand verbunden ist, jedenfalls gibt es in eMule bereits "AICH" Hashes (de.wikipedia.org/wiki/Advanced_Intelligent_Corruption_Handling).

Wen ein ed2k Link einen solchen AICH Hash enthält ist der File sicherer

[Bennel]

benutzt emule nicht md4?

ich denke auch, dass das nicht so einfach möglich ist, da - wenn ich richtig informiert bin - der hash ja vom client selbst berechnet wird, wenn man eine datei ins netz stellt.
wenn man also eine "gefakte" datei ins netz stellen will, dann müsste man schon mal irgendwie den client davon "überzeugen" eine datei mit dem selben hash einer anderen datei zu erzeugen.

wenn man (ohne emule- client und filesharin usw.) eine kollision (also eine datei mit anderem inhalt, aber selben hash) erzeugen will, dann muss man eine gewisse anzahl von versuchen starten, damit das klappt, wobei ich leider nicht weiß, ob das im zusammenhang mit dem inhalt der dateien steht. ich weiß also nicht, ob man 2 völlig verschiedene dateien mit den selben hashes erzeugen kann oder ob die dateien sich wenigstens ähneln müssen.

die frage ist dann ja, wie man es beim einstellen einer datei mit einem client schaffen will so viele versuche zu überbrücken, dass man schließlich einen doppelten hash hat. muss man dann die datei x-mal ins netz stellen, damit der client dann den selben hash berechnet?? oder schreibt man einen mod für den client?

insofern sehe ich das wie du, dass das eher nicht möglich ist, da ja die chunks ebenfalls noch mal einzeln gehashed werden und die chance für eine kollision stark sinkt.

[Bennel]

habe mir mal das patent dieser finnischen firma angeschaut und so wie es aussieht, haben die die hash- werte gar nicht gefaked. dieses patent bezieht sich soweit nur auf kazaa und nutzt eine schwachstelle im hash- verfahren aus. bei kazaa werden wohl nur die ersten 300kB der datei gehashed. die nutzen das so aus, dass der rest der datei (jenseits der 300kB) einfach verändert wird, sodass man eine datei mit bad content aber einem selben hash bekommt und die user so auch den bad content herunterladen.

sowas kann bei emule ja gar nicht funktionieren, da die gesamte datei gehashed wird.

[Myth88]

Und das ist auch gut so....aber ich glaube das irgendjemand doch Fakes reinstellt....weiss aber auch nicht wie...

[Bennel]

naja fake- files können ja ganz einfach hineingestellt werden, in dem man einfach den dateinamen ändert. nur dieses verfahren hat sich für firmen wie viralg oder overpeer als unwirksam erwiesen, da sich die emule- kommunity gegen solche fakes rüsten kann. wenn ein solches fake erkannt wird, stempelt man es einfach als fake ab und so lädt es keiner mehr runter.

firmen wie overpeer oder viralg haben versucht den hash zu fälschen, sodass die filesharing nutzer korrupte dateiinhalte über diese gefakten hashes herunterladen.

interessant ist, ist das einige firmen bzw. es einige patente gibt, die behaupten, dass genau dieses verfahren funktionieren soll. (siehe us- patent nr.: 20030095660, 20050108248, 20050267945)

ich würde dieses fragwürdige thema gerne in meine diplomarbeit einbauen, aber scheinbar geht das wirklich nicht bzw. es wird nicht angewandt.

[Sorrow]

...es gibt auch genügend file-fakes in ed2k-netz...
...mach dir doch selbst einmal den spass und schalte den ip-filter ab, wenn du eine grosses, sehr gefragtes archiv lädst...
...spätestens beim entpack-versuch sollte dieser kläglich an defekten parts scheitern, was mit eingeschaltetem ip-filter (grösstenteils) nicht der fall ist...


Sorrow

[Januar1956]

@ Sorrow

Hmm...ich bin mir ziemlich sicher, so einfach ist das nicht, weil eMule defekte Teile erkennt und repariert. In der Regel treten eher Fehler bei den entsprechenden Pack/Entpack-Programmen auf, die nach Empfang verwendet werden.

Januar

[aalerich]

Zitat von Bennel

interessant ist, ist das einige firmen bzw. es einige patente gibt, die behaupten, dass genau dieses verfahren funktionieren soll.

Hätte es das damals schon gegeben, hätten wir auch massenhaft Perpetuum Mobile-Patente. Gerade in Amiland kann man den absurdesten Unsinn patentieren lassen; selbst eine bloße Idee ohne jede Überlegung zur praktischen Umsetzbarkeit läßt sich so "schützen". Der Rechenaufwand zur Hashfälschung ist absurd hoch; im unwahrscheinlichen Fall, daß die gesamte Rechenkapazität der Erde dafür ausreicht, könnte sie doch niemand bezahlen.

Mit freundlichen Grüßen
aalerich

[Stulle]

grundsätzlich ist es schon möglich mit einem client den datei hash zu fälschen, wenn er entsprechend modifiziert ist. sobald er aber das netzwerkbetritt fliegt der schwindel auf. soll heißen, dass seine versendeten blocks als fehlerhaft erkannt werden und die corruption blackbox ihn nach einer bestimmten anzahl von fehlern rauskickt.

früher gab es das problem mit den 0-filled part sender, welche im grunde genommen das getan haben. der o.g. corruption blackbox code filtert diese ebenso raus, wie die, die so tun als hätten sie datei A und datei B senden.

wie hier aber schon festgestellt wurde ist es wenig effektiv fakes unter falschem namen hochzustellen. somit konzentrieren sich die angriffe gegen das netzwerk eher auf die infrastruktur, also KAD und Server. effektive Angriffe gegen KAD sind aber bisher nicht gelungen, bei den Servern zwar schon, jedoch kommen die ebenso wieder, wie es warez files tun. die gute alte sand-ins-getriebe-taktik...

[Bennel]

Der Rechenaufwand zur Hashfälschung ist absurd hoch

prinzipiell schon, nur gibt es eben die erkenntnisse bzw. den beweis dieser chinesischen wissenschaftler, die mit einer rechnung auf dem papier bewiesen haben, dass kollisionen mit md4 leicht zu erreichen sind. von daher macht mich das schon etwas stutzig.

grundsätzlich ist es schon möglich mit einem client den datei hash zu fälschen, wenn er entsprechend modifiziert ist.

ja, aber der aufwand wäre extrem hoch und daher eher unwahrscheinlich würde ich sagen oder?

sobald er aber das netzwerkbetritt fliegt der schwindel auf. soll heißen, dass seine versendeten blocks als fehlerhaft erkannt werden und die corruption blackbox ihn nach einer bestimmten anzahl von fehlern rauskickt.

also könnte man sagen, dass dateien mit gefakten hashes wie defekte dateien behandelt werden und somit für ein solches verfahren, dass diese besagten unternehmen verfolgen, unbrauchbar ist.

wenn ich die dokus von emule richtig verstanden habe, dann werden beschädigte dateien mit dem AICH repariert bzw. aussortiert. richtig?
das AICH geht dann (zumindest laut wiki und emule-project.net) davon aus, dass bei 10 anderen quellen, von denen 92% von diesen quellen den werten ensprechen müssen (ob mit wert hier hash oder dateiinhalt gemeint sein soll, kann ich aus der doku leider nicht rauslesen).

[Jok3r]

ja, aber der aufwand wäre extrem hoch und daher eher unwahrscheinlich würde ich sagen oder?

Nein - Stulle meinte das anders. Die Clients tun so als ob, berechnen da aber nicht wirklich was.

[Bennel]

Zitat von Jok3r

Nein - Stulle meinte das anders. Die Clients tun so als ob, berechnen da aber nicht wirklich was.

verstehe.

würde im endeffekt aber auch nichts bringen, weil es 1. keinen sinn macht und 2. vom AICH automatisch erkannt bzw. beseitigt wird. richtig?

[Stulle]

szenario wie folgt: firma stellt datei B online und der modifizierte client von ihnen schickt immer HASH h raus, der im ed2k der datei A zugeordnet ist. die firma hat bewusst den modifizierten klienten so gefüttert, dass er für die datei B den hash A vorgibt, damit nun die leute A von der firma wollen, die firma sie aber mit nutzlosen daten der datei B füttern kann. wie ich aber auch schon sagte verhindert AICH und die corruption blackbox so eine manipulation.

hat ein client den passenden AICH hash zu einer datei, so ist er also gefeit. nun besteht noch die möglichkeit, dass der client die suche genutzt hat und sich den AICH hash von anderen clients zusenden lässt. hier und bei übergabe von ed2k links durch die firma lässt sich der AICH hash manipulieren. das ist wiederum sehr aufwändig. genau genommen wäre es so aber sogar möglich dem client vorzugaukeln, dass richtige quellen ihm korrumpierte daten senden. wie aber gesagt, das ist mit viel aufwand verbunden. wie genau die nachfrage und das setzen des AICH hashs abläuft weiß ich jetzt nicht aus dem kopf, aber mir ist so, als hätte mal jemand vorgeschlagen den code besser abzusichern. vielleicht möchtest du diese stelle als ausgangspunkt für weitere recherche nutzen.

[Sorrow]

...nungut, zu meiner verteidigung muss ich gestehen, dass die von mir geschilderte situation schon etwas länger her ist...
...quasi aus der zeit, als der ip-filter in sachen emule noch eher unbenutzt war...
...welches hashverfahren seinerzeit zum tragen kam, weiss ich nicht...
...nur machte ich eben dazumal mehrfach solche erfahrungen, welche mich darauf schliessen liessen...

...und seit ich nen filter nutze, hats mich auch nurnoch minimal tangiert...
...ich werde mich aber diesbezüglich nocheinmal dezent über die jetzigen techniken belesen...

...man lernt ja bekanntlich nicht aus...


Sorrow