Anonymer Datenaustausch
-
Gibt es einen Weg den Austausch von Daten von Person zu Person anonym zu gestalten so, dass man die IP nicht des Daten-Empfängers nicht empfängt. Ich weiß, dass im Internet keine Kommunikation ohne den Austausch von IPs funktioniert, aber Systeme wie Anti-Leech schaffen es ja auch, den Standort eines Downloads unauffindbar zu machen. Da ich leider nicht weiß, wie Anti-Leech funktioniert (was mich sehr interessieren würde) hilft mir das nichts. Was ist der beste Weg eine IP zu verschleiern außer den Datenaustausch über einen Server/Proxy zu leiten und wie kann man sowas programmiertechnisch bewerkstelligen?
-
Man könnte ein "Weiterreich-P2P" basteln. Also das Daten man einen Antrag von Peer zu Peer reicht. Wenn jemand den Antrag erfüllen kann, reicht er die Daten entsprechend von Peer zu Peer weiter, bis jemand gefunden wurde, den es interessiert.
So hat das alles noch viele Probleme. Man darf zum Beispiel keine flache Peer Hierachie wählen, da sonst einfach ein böser Host Daten unterschlagen könnte, das Verfahren müsste man ein wenig verkürzen und man muss auf Hosts Rücksicht nehmen, die weniger Up/Download zur Verfügung stellen.
Ich plane zur Zeit ein wenig in meinem Kopf so ein Protokoll. Aber das ist eher nebensächlich.
-
kingruedi schrieb:
Ich plane zur Zeit ein wenig in meinem Kopf so ein Protokoll. Aber das ist eher nebensächlich.
ach du auch? *hehe*
ich glaube sowas planen viele.meine ideen dazu:
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. -nun könnte man sich bei der gegenseite 'anmelden' mit eigener ID (maybe hash vom nick und passi + UI).
-nun tauscht man die IDs+IPs aus die man hat.
-nun pingt man sich zu den anderen IPs durch und meldet sich dort und tauscht weiter bzw findet fehlerhafte IPs raus.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.
datensuche:
man schickt ein packet mit dem searchrequest ab und gibt an wieviel nodes noch mindestens überbrückt werden müssen, bis eine antwort kommt.
nach der mindestzahl der nodes, kann irgendeine node ihre daten an den request anhängenund das packet den gleichen weg zurück schicken (maybe mit sessionID gekennzeichnet)auf diese weise wüste niemand wer requestet hat und es wüste niemand wer geantwortet hat.
und über diese session könnte man dann auch anfangen daten zu übertragen... an sich müßte man sie nichtmal verschlüsseln, weil eh die endpunkte unbekannt sind, zudem könnte jeder "man in the middle" auch noch für den eigengebrauch mitsniffen.
btw. ich hab kein warez auf meinem rechner, aber die technologie vom distributed nets find ich sehr interessant.
rapso->greets();
-
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();