Anonymer Datenaustausch
-
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
-
camper schrieb:
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.
ließ nochmal in der vorherigen post das dickgedruckte (irgendwie wuste ich, dass das nicht klar wird)
1. es gibt keinen server zwischen den nodes, jede node ist ihr eigener server und client
2. eine sessionID ist nicht öffentlich, eine sessionID ist nur für 2 kommunikationspartner bekannt.rapso->greets();
-
und wie verhinderst du, dass jemand mitliest? die sessionid muss schliesslich beim verbindungsaufbau mitübertragen werden. mit server und client bezog ich mich auf die jeweiligen endpunkte der verbindung.
edit: naja, vielleicht hast du auch recht, iss schon spät ... ich möchte ja auch nur behilflich sein schwachstellen aufzuzeigen
-
camper schrieb:
und wie verhinderst du, dass jemand mitliest? die sessionid muss schliesslich beim verbindungsaufbau mitübertragen werden. mit server und client bezog ich mich auf die jeweiligen endpunkte der verbindung.
edit: naja, vielleicht hast du auch recht, iss schon spät ... ich möchte ja auch nur behilflich sein schwachstellen aufzuzeigen
also nochmals
" 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."
vielleicht mal graphisch
clientA <--SID1--> clientB <--SID2--> clientC <--SID3--> clientD <--...rapso->greets();
-
Ach so, jetzt verstehe ich was Du meinst.
Soweit ich mich an die Funktionsweise von Freenet erinnern kann, entdecke ich bisher keinen Unterschied zu Deinen Ideen.
Gruß
-
emm... ich kannte freenet bisher nur als einen provider mit ziemlich schlechtem ruf *kopfkratz*
und ich hab es mir bis jetzt noch nicht angesehen wie die das ganze machen, aber wenn's das gibt, kann es der threadstarter ja gerne nutzen.
rapso->greets();
-
Ich habs auch noch nicht ausprobiert, aber falls Du es Dir mal anschauen möchtest: