Anonymer Datenaustausch
-
Ich stelle diese Fragen auch für eine Art Protokoll ^^
raspo, kingruedi: Eure Ideen gefallen mir sehr gut. Dieses Weiterreich-P2P ist eine gute Methode. Ich würde das so umsetzen:Hauptuser (Sender) -> Man-in-the-middle1 (Proxy1 für den Sender) -> Man-in-the-middle2 (Proxy für Proxy1) -> ... -> Empfänger
Das ist allerdings keine Ideale Lösung, da dann jeder die Datenmenge zu tragen hat und es mit mehreren Zwischenmännern immer langsamer wird.
Aber immerhin ist die Idee so gut, dass man damit das Prinzip durchsetzen könnte, dass ich plane. Nur müsste man das ganze so gut verschlüsseln, dass keiner der Mittelmänner Texte/Dateien mitlesen/mitempfangen kann.
Ein mögliches Prinzip wäre:1. Sender sendet SessionID an einen Server und einen generierten Schlüsseln an den Server. Diese Daten werden vorerst komplett blockiert bis die EmpfängerHash kommt.
2. Mögliche Zwischenmänner werden ausgewählt.
3. Eine Kette dieser Zwischenmänner wird aufgebaut.
4. Die Daten werden mit SessionID durch die Proxies der Zwischenmänner weitergerecht
5. Der Empfänger erhält die verschlüsselten Daten.
6. Nach kompletten erhalten wird ein Signal mit dem UserIDHash an den Server gesendet. Sind diese Daten richtig wird der Schlüssel empfangen.
7. Die Daten werden mit dem Schlüssel entschlüsselt.
----------------------------------------------------------------------
Habe ich eine Sicherheitslücke in meinem Konzept?Probleme dabei: Durch verschlüsselungen werden Daten meistens größer. Man müsste also eine Verschlüsslung suchen/entwickeln die das selbe/kompremierte Daten Volum erhält.
-
irgendwie hab ich das alles exakt so schon mal irgendwo gelesen.
dieses system hat eine menge grundlegende schwächen.
du weisst nicht, ob der, der sich als server ausgibt, auch der server ist, den du willst; es könnte theoretisch irgendeiner der rechner sein, die eigentlich nur proxies sein sollen. du kannst auch immer nur den proxy auswählen, mit dem du unmittelbar kommunizierst. logisch, sonst wäre er ja auch überflüssig.
-
Ich hab noch eine Menge konzeptioneller Fehler und ungereimtheiten.
Wichtig ist, dass die Partner von einander nichts erfahren. Man weiß nicht wer was anbietet oder was runterlädt und man vertraut keine Aussage eines Peers.
Einen zentralen Server wie in Diabolos Konzept zu benutzen sollte komplett ausscheiden, da dort sonst der Schwachpunkt des Systems liegt.
Weiterreichen von Verbindungen in der Hierachie und "Vertrauens"-Beziehungen, kann man zum verkürzen der Wege benutzen.
Man muss einen Weg finden die Verbindungsleistung der Hosts messen zu können, ohne eine Möglichkeit zu bieten, dies effektiv faken zu können.
Im Endeffekt würde man mit meinen Protokoll Vorstellungen das OSI Protokoll eigentlich nochmal redundant auslegen und seine eigene Transportschicht basteln. Ich werd mal ein paar skitzen heute abend machen.
-
Freenet!?
(Nee, das ist nicht der besch...eidene Provider ;))
-
Jansen schrieb:
Freenet!?
Was ist aus denen eigentlich geworden?
Irgendwie hört man da seit ewigen Zeiten nix mehr.
-
Hi
da gibt es glaub für mich ein grundlegendes problem.
A will was haben und schickt seine suchanfrage weg.
C hat die daten und will sie verschicken. C darf nicht wissen das er sie an A schicken soll.
möglickeit 1.
C weiss das B die anfrage gestellt hat und schickt sie an B.
B wiess wiederum das A die anfrage gestartet hat und reicht sie weiter
==>> jeder braucht enorm viel bandbreite da z.B. 500 MB bei 4 B's bereits 2GB traffik produziert.möglichkeit 2.
C weiss das die anfrage von einem seinber bekanten nachbarn kamm und verteilt sie an diese. Einer ist das Entsprechende B wertet dieses aus und verschickt es an alle seine server.
==>> noch mehr traffick. da das packet nicht nur an einen sondern ggf an viele unütz verteilt wird.
==>> C weis anhand der ip adresse von welchem B die Anfrage kamm. eine Anonymisierung ist daher nicht möglich.
->> mögliche lösung B schickt die anfrage mit verfälschtem IP header an C damit c nicht weis von wem die anfrage kamm.
==>> Angriffspunkt für das system. ein unbekannter könnte unsinnige anfragen in das system einschleussen ohne ausgespert werden zu können.Weiteres problem wie soll in einen anonymen system die flowkontroll gehändelt werden. wer schickt welches paket. wer hat welches packet. ist die datei überhaupt vollständig vorhanden.
gruss
-
Über so eine Möglichkeit habe ich mir auch schon des öfteren Gedanken gemacht. Die große Schwierigkeit liegt in der Realisierung der Anonymität. Kein darf wissen, von wem er die angeforderten Pakete bekommen hat und der sendende Host darf nicht wissen an wen er diese Daten gesendet hat.
Grundsätzliche Ansätze gibt es ja schon mit Peek a Booty oder Freenet. Aber IMHO bieten diese keine absolute Anonymität.
kingruedi schrieb:
Im Endeffekt würde man mit meinen Protokoll Vorstellungen das OSI Protokoll eigentlich nochmal redundant auslegen und seine eigene Transportschicht basteln. Ich werd mal ein paar skitzen heute abend machen.
An genau so etwas hatte ich auch gedacht. Man erstellt ein Netz im "Netz". Dafür würde sich ein eigenes Protokoll anbieten, aber wie löst man das Problem der Adressierung? In diesem sogenannten Netz im "Netz" würden neue Adressen dynamisch vergeben und darüber keine Log's angelegt, welcher Peer zu welchem Zeitpunkt welche Adresse hat.
Der gesamte Datenfluss wird verschlüsselt. Aber auch dieses Netz funktioniert aus einem best. Grund nicht. Wer vergibt Adressen? Wer versichert mir, dass auch wirklich keine Log's angelegt werden? Zentrale Server funktionieren dafür aus oben genannten Gründen nicht.
@kingruedi: Bin mal auf Deine Ideen gespannt...
-
Ja, das der Server ne Schwachstelle ist stimmt, aber er vereinfacht das System natürlich. Wobei man das mit dem Server machen könnte, wenn die Verbindung zum Server vertuscht werden würde... Anti-Leech macht sowas ja auch die Frage ist nur wie???
@kingruedi: Sollte das mit deinem neuen, sicheren Protokoll was werden, würde ich es gerne verwenden und freue mich darauf. Wenn du Hilfe beim Programmieren oder beim Konzept brauchst dann schick mir ne PM
-
camper schrieb:
du weisst nicht, ob der, der sich als server ausgibt, auch der server ist, den du willst;
1. ist das kein nachteil, sondern genau das was du möchtest
2. du willst keinen server kennen, du möchtest nur ein datenpacket (das man mit md5 signiert bzw könnte man gleich nach einem packet mit einer gewissen md5 signatur pingen)kingruedi schrieb:
Wichtig ist, dass die Partner von einander nichts erfahren. Man weiß nicht wer was anbietet oder was runterlädt und man vertraut keine Aussage eines Peers.
rapso schrieb:
verbindungsaufbau:
-damit es ohne server läuft (wäre ja sonst ein angreifbarer punkt) könnte man sich durch die gegend pingen bis jemand mit der selben software gefunden wurde. .
.
.
so würde ich also erstmal das netz aufbauen, das ohne server auskommt. wenn es 1Mil user gäbe, würde man im schnitt mit ~<2k pings auskommen bis eine connection vorhanden ist.also ne art portscan, für den anfang könnte man server anbieten um andere ips zu bekommen, aber ab ner gewissen userzahl ist es leicht das netz zu finden.
(btw. wenn man port 80 nimmt, dann wäre es auch nicht so einfach das zu sperren *hehe*)kingruedi schrieb:
Weiterreichen von Verbindungen in der Hierachie und "Vertrauens"-Beziehungen, kann man zum verkürzen der Wege benutzen.
braucht man eigentlich nicht, sobald die MD5 summe eines packetes nicht stimmt, verwirft die node die das validiert hat gleich das packet und versucht es von woanders zu bekommen. natürlich kann sie dann für die fehlerhafte node das rating senken, nur für sich und nur für diese eine session.
Glisglis schrieb:
möglickeit 1.
C weiss das B die anfrage gestellt hat und schickt sie an B.
B wiess wiederum das A die anfrage gestartet hat und reicht sie weiter
==>> jeder braucht enorm viel bandbreite da z.B. 500 MB bei 4 B's bereits 2GB traffik produziert.tja, ist zwar ein wenig 'schade', man könnte aber davon ausgehen, das viele mitsniffen würden, sodas der 'verschleiss' vielleicht relativ klein wäre.
Glisglis schrieb:
möglichkeit 2.
da hast du schon genug kirtische dinge aufgezählt die diese deine idee verwerfen.
Glisglis schrieb:
Weiteres problem wie soll in einen anonymen system die flowkontroll gehändelt werden. wer schickt welches paket. wer hat welches packet. ist die datei überhaupt vollständig vorhanden.
die vollständigkeit einer datei bekommt man über die beschreibung der datei.
du sagst also, du suchst "debian" und bekommst eine liste mit möglichen packeten die in deiner näheren umgebung bekannt sind mit der dateigröße und MD5 summen einzelner tokens und des ganzen packetes. dann kannst du ne meldung abschicken, dass du eine bestimmte md5 suchst und wenn du dann den token hast, prüfst du das.
den flowkontroll kann jede node über ein rating der nachbarnodes bestimmen, natürlich könnte man das dann auch distributen.
rapso->greets();
-
rapso schrieb:
also ne art portscan, für den anfang könnte man server anbieten um andere ips zu bekommen, aber ab ner gewissen userzahl ist es leicht das netz zu finden.
(btw. wenn man port 80 nimmt, dann wäre es auch nicht so einfach das zu sperren *hehe*)Willst Du einfach nur die IP's durcheinander würfeln? Dann hast Du im Prinzip keine Anonymität und falls der/die Server log-files anlegt, kannst Du alles genau zurück verfolgen. Was passiert wenn der/die Server down sind?
Wenn man nur die IP's vermischt dann bieten evt. andere Leute mit Deiner IP Sachen an, wofür Du evt. rechtlichen Ärger bekommen könntest. Deswegen wäre eine komplett unabhängige Adressierung interessant.
-
Hi
noch mal ein grundsätzliches problem.
im anonymität zu erreichen darf keine absender IP mit verschickt werden. heist also die IP pakete müssen geändert werden um eine falsche absender adresse einzutragen. was machen eigentlich grosse Internetprovider mit IP packeten aus ihrem eigenen backbone, die absende adressen besitzen, die nicht zu ihrem backbone gehören? weiterleiten oder verwerfen. und was macht der admin wenn er feststellt, das sehr viele datenpakte ohne richtige absenderadresse von einem bistimmten port aus seinem backbone kommen? weggucken oder wegen verdacht auf DOS den port einfach dichtmachen und warten bis sich jemand beschwert.
und noch eine kleine rechtliche überlegung. macht sich ein betreiber eines Rechners der P2P packete weiterleitet nicht genauso strafbar wie derjenige der die strafbaren ihalte zum download anbietet?
und zu meinen beiden vorheringen beispielen
1 kommunikation über bekante nachbarn funktioniert nur mit einschränkungen ( und mit eingeschränkter anonymität und wachsendem traffick)
2 kommunikation über unbekante nachbarn funktionert dann erst recht nicht
3 bleibt nur noch eine direckte kommunikation. von a nach b.selbst dann ist es mit der anonymität noch nicht so weit her. sagen wir mal ein server hat eine datei der er mittels 2 verschicken soll. wer sagt euch das jemand nicht einen server schreibt, der jedem seiner bekanten gegenstellen einen anderen teil der datei beschädigt/ oder nicht zukommen lässt. durch ausnutzen der flowkontroll wird ihm ja irgendwann mitgeteilt, das er doch dein teil noch einmal schicken solle / oder einen anderen. Je nach verfügbarkeit der Datei, kennt man dann zumindestens die gegegenstelle, einreisen.
gruss
-
Magoon schrieb:
rapso schrieb:
also ne art portscan, für den anfang könnte man server anbieten um andere ips zu bekommen, aber ab ner gewissen userzahl ist es leicht das netz zu finden.
(btw. wenn man port 80 nimmt, dann wäre es auch nicht so einfach das zu sperren *hehe*)Willst Du einfach nur die IP's durcheinander würfeln? Dann hast Du im Prinzip keine Anonymität und falls der/die Server log-files anlegt, kannst Du alles genau zurück verfolgen. Was passiert wenn der/die Server down sind?
Wenn man nur die IP's vermischt dann bieten evt. andere Leute mit Deiner IP Sachen an, wofür Du evt. rechtlichen Ärger bekommen könntest. Deswegen wäre eine komplett unabhängige Adressierung interessant.
und wie willst du, bloss weil du IPs von vielen leuten kennst die das programm haben, die packete die transportiert werden in irgendein zusammenhang mit den IPs der empfänger und absender zusammenbringen???
du kannst übers internet keine daten verschicken, ohne bei "send" bzw "recv" eine IP zu haben.
rapso->greets();
-
Glisglis schrieb:
Hi
im anonymität zu erreichen darf keine absender IP mit verschickt werden. heist also die IP pakete müssen geändert werden um eine falsche absender adresse einzutragen.
das ist falsch, man darf nur nicht wissen, von wem die daten kommen, die einem weitergeleitet werden, aber da man ja nicht weißt, ob der 'vormann' der wirkliche absender ist, oder nur eine zwischennode, weiß man nicht wer der absender ist (und andersrum geht das genau so).
die IP des absenders zu manipuliren wäre (sorry, aber) absoluter schwachfug, wie sollte man dann jemals eine antwort bekommen wenn man etwas anfordert? one-way funktioniert sowas nicht, man braucht ein bidirektionales protokoll und dafür muss man absender und empfänger miteinander verbinden. die einzige kunst dabei ist es, allen zwischenstationen nicht zu verraten, ob man schon ein endstück der kommunikation ist oder auch nur eine von vielen nodes.
und große provider würden dir deinen anschluss kündigen, wenn du falsche IPs in deinen packeten angibst, weil du damit auch deren router durcheinander bringst und sie auch nicht wollen, dass leute aus anderen netzen mit falschen absender IPs eine DOS attacke gegen sie starten. deswegen wird aus reinem selbstschutz so ein packet eigentlich nicht weitergeleitet.
sogar mein kleiner billig D-link router leitet keine packete weiter die eine unautorisierte IP für das netz haben.
an sich muss man nichts anderes tun, als der router einer firma, wenn der daten weiterleitet, weiß von außen auch niemand an wievielen stationen die packete noch weiterführen bis sie einen empfänger treffen oder ob nicht sogar der router selbst schon der empfänger ist.
diese art der kommunikation wäre sogar nicht verbietbar, weil man nichts anderes machen würde, als das internet auch schon seit ewigkeiten macht, blos etwas 'erweitert', weil man nicht selbst die route berechnen müßte wohin man ein packet schickt, sondern eine verbindung 'durchschleifen' würde.
rapso->greets();
-
rapso schrieb:
und wie willst du, bloss weil du IPs von vielen leuten kennst die das programm haben, die packete die transportiert werden in irgendein zusammenhang mit den IPs der empfänger und absender zusammenbringen???
Das ich genau jedes Paket zuordnen kann, hab ich nicht behauptet.
Es gibt aber das Problem, dass die IP's so verteilt werden müssen, dass keine Rückschlüsse auf die "echten" IP's möglich sind.Ein anderes Szenario wäre, jemand hat Deine IP und macht damit irgendeinen scheiß. Wie dann dazu die rechtliche Lage bei uns oder in anderen Ländern aussieht, weiß ich nicht.
rapso schrieb:
du kannst übers internet keine daten verschicken, ohne bei "send" bzw "recv" eine IP zu haben.
Genau deswegen meinte ich vorhin eine Art Netz im "Netz". Die echten IP's finden in dem "Subnet" keine Verwendung.
Gruß
-
rapso schrieb:
camper schrieb:
du weisst nicht, ob der, der sich als server ausgibt, auch der server ist, den du willst;
1. ist das kein nachteil, sondern genau das was du möchtest
2. du willst keinen server kennen, du möchtest nur ein datenpacket (das man mit md5 signiert bzw könnte man gleich nach einem packet mit einer gewissen md5 signatur pingen)mit der signatur (ob nun md5, sha1 oder sonstwas) würde es nur funktionieren, wenn du das gesamte datenpaket aus einer quelle und an einem stück bekommst. das erzeugt schon mal ne menge overhead, denn du must ja auch erst mal an die prüfsumme kommen, z.b. über thex-trees. ausserdem kann ein fehlerhaftes datenpaket auch durch einen bösen proxy entstehen (und das ist leider keine graue theorie), und du hast ja keine möglichkeit diesen zu identifizieren und von der transportroute auszuschliessen, weil diese ja anonym ist. kombiniere das mit dem prinzipbedingten geringen datendurchsatz und du erreichst nur eine geringe verfügbarkeit von daten, je grösser eine datei ist, umso wahrscheinlicher wird es, dass du einige teile nie oder nur fehlerhaft bekommst. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
-
Magoon schrieb:
Das ich genau jedes Paket zuordnen kann, hab ich nicht behauptet.
Es gibt aber das Problem, dass die IP's so verteilt werden müssen, dass keine Rückschlüsse auf die "echten" IP's möglich sind.solange du ein packet zu keiner IP zuordnen kannst, kannst du jeden temporären IP inhaber so verklagen wie du auch t-online verklagen kannst, weil alle nur packete weiterschieben und niemand weiß wer es nun schlussendlich für sich behält.
Magoon schrieb:
Ein anderes Szenario wäre, jemand hat Deine IP und macht damit irgendeinen scheiß. Wie dann dazu die rechtliche Lage bei uns oder in anderen Ländern aussieht, weiß ich nicht.
wie gesagt, außerhalb deines privaten netzes kannst du keine falschen IPs durch die gegend schicken (jedenfalls sperren das die INet-provider). somit kannst du nichts anstellen.
Magoon schrieb:
Genau deswegen meinte ich vorhin eine Art Netz im "Netz". Die echten IP's finden in dem "Subnet" keine Verwendung.
es geht nicht um das netz an sich, sondern um das verschleiern der endpunkte. ein netz im netz ist vielleicht ne nette bezeichnung einer ISO ebene, aber es ist ja nur logisch das ein neues protokoll auf eine bestehende protokollschicht aufbauen würde.
rapso->greets();
-
camper schrieb:
mit der signatur (ob nun md5, sha1 oder sonstwas) würde es nur funktionieren, wenn du das gesamte datenpaket aus einer quelle und an einem stück bekommst.
soweit ich weiß, läuft das bisher immer so bei bestehenden shared networks, es gibt nunmal immer eine atomare packetgröße z.b. 512kb?
camper schrieb:
denn du must ja auch erst mal an die prüfsumme kommen
ja, dafür sind eben die von mir beschriebenen suchfunktionen da.
camper schrieb:
ausserdem kann ein fehlerhaftes datenpaket auch durch einen bösen proxy entstehen
ja, deswegen, wie ich schonmal schrieb, prüft jede node vor dem weiterleiten die validität eines packetes und bei fehlern wird es nicht weitergeschickt und die node die es schickte wird in dem lokalen rating des clients runtergesetzt und er ping woanders nach dem packet mit der bestimmten md5 summe.
camper schrieb:
und du hast ja keine möglichkeit diesen zu identifizieren
doch, nach dem ersten kaputten md5 packet. er wird ja wohl kaum ein packet generieren können das die gleiche MD5 prüfsumme hat aber nen anderen inhalt.
camper schrieb:
kombiniere das mit dem prinzipbedingten geringen datendurchsatz
gerade bei oft verlangten dingen wie z.b. einem neu erschienenem demo würden sehr viele das mitsniffen und so wäre die effektivität relativ hoch
camper schrieb:
je grösser eine datei ist, umso wahrscheinlicher wird es, dass du einige teile nie
ja, das ist eines der grundlegenden "gesetze" in allen p2p, wäre also nichts besonderes
camper schrieb:
oder nur fehlerhaft
das wird extrem selten passieren, da kaum jemand ein fehlerhaftes packet weiterleiten wird und falls man doch eines bekommt, weiß man dass der unmittelbare nachbar es kaputt gemacht hat und schliesst ihn aus dem netz aus von der eigenen seite aus und wenn das jeder macht, dann kann er jedem nur 1 kaputes packet schicken und hat dann funkstille
camper schrieb:
. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
ist es gerade nicht, den jede störung wird unmittelbar erkannt.
rapso->greets();
-
rapso schrieb:
camper schrieb:
mit der signatur (ob nun md5, sha1 oder sonstwas) würde es nur funktionieren, wenn du das gesamte datenpaket aus einer quelle und an einem stück bekommst.
soweit ich weiß, läuft das bisher immer so bei bestehenden shared networks, es gibt nunmal immer eine atomare packetgröße z.b. 512kb?
diese grösse variiert von netzwerk zu netzwerk und datei zu datei, z.b.:
kazaa, winmx, opennap - datensicherheit ? vergiss es :p
BT - je nach torrent 32KB - 4MB
edonkey2000 - 9.5mb, ggf. 190KB mit emule
Gnutella1/2 - je nach tiefe des thex-baumes(normal 9, dann 1/256 der datei aufgerunded auf nächste 2er potenz) min 1024Bytees gibt dabei aber einen wesentlichen unterschied, der sender ist nähmlich immer bekannt; wenn wir zufällige übertragungsfehler (und sabotierte netzwerkprozessoren) ausschliessen, kann der schuldige immer identifiziert werden. anders bei anonymisierten daten - wenn die grösse des prüfpackets grösser als die kleinste auftretende MTU ist, dann zerfällt das packet, und es gibt keine garantie, das alle teile aus derselben quelle stammen. und das bedeuted eben, das das elementare datenpaket, das selbständig überprüft werden kann sehr klein ist ( evtl. < 576 bytes ), was wieder enormen overhead für die prüfsignatur bedeutet.
camper schrieb:
denn du must ja auch erst mal an die prüfsumme kommen
ausserdem kann ein fehlerhaftes datenpaket auch durch einen bösen proxy entstehenja, deswegen, wie ich schonmal schrieb, prüft jede node vor dem weiterleiten die validität eines packetes und bei fehlern wird es nicht weitergeschickt und die node die es schickte wird in dem lokalen rating des clients runtergesetzt und er ping woanders nach dem packet mit der bestimmten md5 summe.
und woher weiss der überprüfenmde node, dass das packet invalid ist? ich meine ja gar nicht von veränderungen, die dazu führen, dass die angehängte prüfsumme nicht zum packet passt, sondern falsche daten, bei denen auch die signatur verändert wurde, so dass die integrität des packets gewährleistet ist. woher weiss dann der node, dass dieses packet unerwünscht ist, schliesslich kann nur der empfänger die signatur der gewünschten packete kennen (andernfalls wäre einerseits die anonymität verloren, andererseits kannst du die übertragungsroute nicht wechseln, denn logischerweise wäre die korrekten signaturen nur nodes bekannt, die die gesamte kommunikation mitgehört haben, bei fehlern fängst du also von vorne an)
camper schrieb:
kombiniere das mit dem prinzipbedingten geringen datendurchsatz
gerade bei oft verlangten dingen wie z.b. einem neu erschienenem demo würden sehr viele das mitsniffen und so wäre die effektivität relativ hoch
nimm doch BT
camper schrieb:
je grösser eine datei ist, umso wahrscheinlicher wird es, dass du einige teile nie
ja, das ist eines der grundlegenden "gesetze" in allen p2p, wäre also nichts besonderes
gilt so allgemein eigentlich nur bei bestimmten netzwerken.
camper schrieb:
. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
ist es gerade nicht, den jede störung wird unmittelbar erkannt.
erklär das bitte nochmal, vielleicht hast du es tatsächlich schon, aber ich begreife es nicht. es gibt ja noch andere anfälligkeiten.
-
camper schrieb:
diese grösse variiert von netzwerk zu netzwerk und datei zu datei, z.b.:
kazaa, winmx, opennap - datensicherheit ? vergiss es :p
BT - je nach torrent 32KB - 4MB
edonkey2000 - 9.5mb, ggf. 190KB mit emule
Gnutella1/2 - je nach tiefe des thex-baumes(normal 9, dann 1/256 der datei aufgerunded auf nächste 2er potenz) min 1024Bytewas willst du mir damit sagen? oder bestätigst du mir dass wir packete mit fester größe haben die wir validieren können?
camper schrieb:
es gibt dabei aber einen wesentlichen unterschied, der sender ist nähmlich immer bekannt; wenn wir zufällige übertragungsfehler (und sabotierte netzwerkprozessoren) ausschliessen, kann der schuldige immer identifiziert werden. anders bei anonymisierten daten - wenn die grösse des prüfpackets grösser als die kleinste auftretende MTU ist, dann zerfällt das packet, und es gibt keine garantie, das alle teile aus derselben quelle stammen.
doch, gibt es, schliesslich hollt man sich ein ganzes packet von einer quelle udn nicht nur eine MTU. jede node besorgt sich dann erst ein packet und schickt es dann erst weiter (deswegen sollten die packete nicht zu gross sein, sonst könnte die latenz zu groß werden)
camper schrieb:
und das bedeuted eben, das das elementare datenpaket, das selbständig überprüft werden kann sehr klein ist ( evtl. < 576 bytes ), was wieder enormen overhead für die prüfsignatur bedeutet.
die größe eines packetes kann ein protokoll selbst bestimmen, dafür muss man sich nicht auf die layer darunter beschränken müssen, das machen nur weniger protokolle.
camper schrieb:
und woher weiss der überprüfenmde node, dass das packet invalid ist?
es möchte das packet mit der MD5 von ZA545azerw... und beim erhalt macht es für das packet den MD5 check.
wo ist das problem?
ich meine ja gar nicht von veränderungen, die dazu führen, dass die angehängte prüfsumme nicht zum packet passt, sondern falsche daten, bei denen auch die signatur verändert wurde, so dass die integrität des packets gewährleistet ist. woher weiss dann der node, dass dieses packet unerwünscht ist, schliesslich kann nur der empfänger die signatur der gewünschten packete kennen (andernfalls wäre einerseits die anonymität verloren,
wieso sollte nicht jeder die md5 prüfen von dem packet, das er mittels der MD5 angefordert hat?
camper schrieb:
. wie bereits gesagt, ist das system einfach zu anfällig gegenüber beabsichtigten störungen durch dritte.
ist es gerade nicht, den jede störung wird unmittelbar erkannt.
erklär das bitte nochmal, vielleicht hast du es tatsächlich schon, aber ich begreife es nicht. es gibt ja noch andere anfälligkeiten.
ok, noch einaml
1.du suchst "debian", dazu schickst du das suchpacket an alle dir unmittelbar bekannten nodes und stellst im packet ein "mindestens 5 nodes soll das packet passieren"
2.die nachbarnodes schicken das packet weiter mit "mindestens 4 nodes soll das packet passieren" und schicken dir eine SessionID.
3.die nachbarnodes der nachbarnodes schicken das packet weiter mit "mindestens 3 nodes soll das packet passieren" und schicken deiner nachbarnode eine SessionID für diese kommunikation (NUR FÜR DIE KOMMUNIKATION ZWISCHEN DEN BEIDEN), die packete selbst müssen von jeder node zwischen den einzelnen sessionIDs geroutet werden.
das ganze soweiter bis "mindestens 0nodes soll das packet passieren" im request steht.
4. die letzten nodes leiten das requestpacket noch weiter oder beantwortet nun mit ihr bekannten files (die deiner suchanfrage entsprechen) zu der vorherigen node zurück. dabei steht neben jeder datei eine MD5 summe.
5. diese routet das antwortpacket weiter zurück
das so weiter bis es bei dir ankommt.
wie du sehen kannst, weiß niemand beim request, wer der letzte und wer der erste der kette war.6. du bekommst nun ne auflistung mit möglichen files.
7. du möchtest eines der files nun downloaden, dafür requestest du nun erstmal mittels der beistehenden MD5 summe das packet, das dir alle MD5 summen der einzelnen packete des files liefert, dabei geht das ganze so vorsich wie beim ersten request (also siehe 1.)
8. wenn du nun das packet mit allen md5 summen erhalten hast, kannst du nach den einzelnen md5 summen requesten und zwar genau so wie in den vorherigen beiden fällen.
bei der übertragung wird dabei natürlich jedes packet erst von einer node weitergeschickt, nachdem es vollkommen angekommen ist und die md5 summe des requesteten md5 packetes stimmte.
beachte bitte, dass du das packet mit der MD5 summe xy requestest und dass es das richtige ist kannst du ebenfalls mit der MD5 summe prüfen.
zudem weißt du, wenn ein fehlerhaftes packet von einer nachbarnode ankommt, dass nur sie es hätte falsch schicken können, denn wäre das packet schon bei ihr fehlerhaft angekommen, dann hätte sie das packet erst garnicht weiter geschickt, weil die MD5 summe nicht gestimmt hätte.
rapso->greets();
-
ok, ich hatte angenommen, dass die kommunikation zwischen client und server irgendwie gegen mitlesen gesichert wäre. in deinem falle könnte man möglicherweise dem client nicht so leicht falsche daten liefern, aber was ist mit dem server? die session id ist ja offen, ein bösartiger node könnte den server problemlos mit queries überfluten (nat. mit gefälschtem absender, nähmlich dem original client und dessen sessionid); worauf der server nur mit einem abort ö.ä. reagieren könnte, womöglich setzt er den client auf eine blacklist. ausserdem könnte ein node nat. jederzeit die verbindung einfach unterbrechen. und bei p2p netzwerken ist das ja normal und nicht einfach böse absicht. für eine alternative route musst du die gesamte verbindung neu aufbauen, alle daten, die gerade noch auf dem übertragungswege waren, wären verloren.
ein weiteres problem ist der suchalgorithmus. was hindert irgendeinen node daran, permanent queries im namen anderer zu senden? für den fall dass er sehr viele direkte nachbarn hat, könnte er einen signifikanten teil des netzes aufgrund des potentiell expontentiellen wachstums überfluten. ausserdem skaliert er nicht gut, wegen der ähnlichkeiten könnte das hier interessante lektüre sein:
http://www.tch.org/gnutella.html