 eine kleine idee |
|
|
angenommen man wollte ein neues filesharing system aufbauen, dass es nicht erlaubt, zweifelsfrei herauszufinden was ein user gerade herunter läd...
zudem soll design kriterium sein, dass keine oder nur sehr begrenzte rückschlüsse auf die quelle möglich sind...
angenommen man teilt ein datenpaket in stücke einer oder mehrerer fester größen und verschlüsselt jedes der stücke via one time pad. die schlüssel daten werden wie die anderen datenstücke behandelt...
jedes datenstück bekommt einen namen, einen index oder ein sonstiges identifizierungsmerkmal
möchte man nun mehrere verschiedene dinge "bereitstellen" werden zukünftig bestehende datenstücke als OTP schlüssel verwendet...
will man nun jemand anderem ermöglichen die betreffenden original daten zu laden, teilt man ihm eine oder mehrere möglichkeiten mit sie aus den datenstücken zusammen zu setzen (der einzige punkt an dem zweifelsfrei ersichtlich wird um welche originaldaten es sich handelt) ...
möchte man verhindern dass dieser rückschluss auch über die stücke möglich ist die ein client anfragt, so verwede man die stücke für möglichst viele dinge und stelle möglichst viele stück-paare für die gleichen daten bereit
ein client der die daten herunter läd, kann sofern er listen der möglichen datenstücke hat selbst eine kombination wählen die er herunterladen will ... sind lokal die entsprechenden datenstücke verfügbar(also geladen), kann die OTP verschlüsselung aufgehoben werden, und die originaldaten sind wieder lesbar ... nötigenfalls müssen nur noch die datenstücke der lesbaren daten in der entsprechenden reihenfolge angeordnet werden ...
in bisherigen filesharing protokollen war es möglich dem anbieter von datenstücken (chunks) nachzuweisen, welche daten er angeboten hat, sofern man von ihm die entsprechenden chunks geladen hat ...
in diesem aufbau ist das zwar immernoch möglich, jedoch sind die chunks nicht mehr zweifelsfrei einem chunk originaldaten zuzuordnen, da, je nach dem mit welchem anderen chunk sie kombiniert werden, mehrere mögliche originaldaten dabei heraus kommen, und man ohne die intention des jeweiligen clients zu kennen, nicht zweifelsfrei sagen kann welche daten beabsichtigt waren.
ein praktisches beispiel findet sich im wikipedia artikel zu OTP
nicht alle anforderungen die an ein normales OTP setup gestellt werden, müssten hierfür umgesetzt werden ... mehrfachverwendung ist hier beispielsweise erwünscht ...
ein nachteil dieses verfahrens ist es, dass das nötige übertragungsvolumen um den faktor 2 steigt ...
anregungen / meinungen dazu?
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
01.12.2007 21:24 |
|
|
|
|
also wenn ich die sache richtig verstanden habe, stellst du dir das so vor:
man zerteilt eine datei in kleine teile und legt sie auf einen server, mit vielen andern kleinen teilen von andern programmen.
der client läd jetzt viele stücke vom server runter, unter denen auch viele stücke von andern programmen sind, aber effektiv weis nur er, welche dieser stücke er nachher braucht, um die eigentlich datei wieder zusammenzusetzten, was er dann im letzten schritt auch tut.
ich verdecke also mein eigentliches vorhaben mit einer flut von information, die es sehr schwer macht das eigentliche vorhaben zu ersichten.
__________________
Alle sagten, es geht nicht, da kam einer, der wusste das nicht und tat es einfach...
|
|
|
01.12.2007 23:54 |
|
|
|
|
ich will das ganze nicht auf einen server packen ... p2p
und ich bezwecke nicht das eigentliche vorhaben in einer flut von informationen zu verbergen ...
stelle dir folgendes vor:
ich stelle einen download online ... dieser zerfällt in 10 teilstücke ... exemplarisch betrachte ich nun einen ausschnitt aus einem davon ...
sagen wir "00110011"
nun denke ich mir initial einen OTP schlüssel aus(hier nur für diesen ausschnitt): "10101010"
heraus kommen nun durch die OTP operation 2 teile:
einmal der otp schlüssel "10101010"
und einmal der daten teil "10011001" (ergebnis von "00110011" XOR "10101010")
ich behandle allerdings beide gleich, es wird also nicht zwischen daten und schlüssel unterschieden ... beides sind downloadbare chunks
für sich betrachtet haben die beiden chunks nun nichts mit den ursprünglichen daten zu tun ... erst wenn man DIESE 2 chunks miteinander verbindet kommen wieder die ursprünglichen daten raus ...
nun könnte man argumentieren, dass durch verschlüsselung (das hier ist bis hier hin ja nix anderes als one time pad, mit der ausnahme dass ich sogar den schlüssel veröffentliche) immernoch die gleichen daten im spiel sind, und ja irgendwer auf die ein copyright haben könnte ...
dumm nur, dass diese 2 chunks aber auch zu anderen daten gehören, auf die der jeweilige rechteinhaber kein copyright hat ...
stelle ich noch 2 weitere chunks zur verfügung, sagen wir "11001100" und "01010101" dann ist aleine aus den chunks nicht mehr ersichtlich dass "10101010" und "10011001" zusammen gehören ... ich biete alle diese chunks zum download an ... die sache ist nun, wer sagt überhaupt dass sich unter diesen chunks überhaupt ein paar(daten und schlüssel) befindet?
gerade das ist das lustige an OTP ... wenn du verschlüsselte OTP daten bekommst, kann man nicht sagen was der schlüssel ist, sogar wenn man unbegrenzte rechenleistung zur verfügung hat und alle möglichen schlüssel testen kann ...
das one time pad ist das einzige bekannte crypto verfahren das man via brute force nicht brechen kann ... nichtmal in der theorie ...
nehmen wir einen text A
"Ich bin ein durch Copyright geschützter Text"
und einen Text B
"--------- Haselnüsse sind echt Toll --------"
ich kann nun einen zufälligen schlüssel nehmen und text A mittels one time pad verschlüsseln ... nennen wir den verschlüsselten text C
vorrausgesetzt du kennst den schlüssel kannst du aus C wieder A bestimmen ... probierst du allerdings alle möglichen schlüssel durch, wirst du JEDEN anderen text gleicher länge, inklusive text A bekommen ... unter anderem auch text B ... du hast allerdings keine möglichkeit herrauszufinden welchen text ich verschlüsselt habe ...
zudem ist es sehr einfach, sofern text B gegeben ist den nötigen schlüssel zu berechnen, um B aus C zu entschlüsseln ...
auf diese weise könnte man ausreichend lange chiffrate erstellen, und nur durch variation des schlüssels beliebige klartexte erhalten ...
die chunks aus denen eine illegal bereitgestellte kopie eines films/spiels/programms besteht, sind GLEICHZEITIG chunks aus denen man mit anderen chunks ein linux ISO errechnen kann, welches frei kopiert werden darf ... mit welchem recht will man mich also daran hindern diese chunks bereit zu stellen? es kommt nur darauf an wie die chunks wieder zusammengesetzt werden, und mit welchen anderen chunks sie wieder durchs XOR (die operation hinter otp) gehen ... einzeln für sich betrachtet steht ein chunk für JEDE möglichkeit daten in der chunk größe anzugeben
erst die kombination mit einem 2. chunk, ergibt die eigentlichen daten ... welche chunks nun wie kombiniert werden, hängt nicht von demjenigen ab der die chunks bereit stellt ...
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
02.12.2007 02:21 |
|
|
|
|
das is ne echt gute idee dann befindest du dich in ner rechtlichen grauzone^^
wäre gut wenn du das machen könntest
__________________
?- god(X).
X = green.
|
|
|
02.12.2007 03:15 |
|
|
|
|
ich meine ich würde gern mitmachen aber ich weis das mir wahrscheinlich die programmierkompetenzen fehlen -.-
__________________
Alle sagten, es geht nicht, da kam einer, der wusste das nicht und tat es einfach...
|
|
|
02.12.2007 12:11 |
|
|
|
|
| Zitat: |
Original von Schatten
ich meine ich würde gern mitmachen aber ich weis das mir wahrscheinlich die programmierkompetenzen fehlen -.- |
|
Ein Versuch ist es doch sicher wert. 
|
|
|
02.12.2007 14:44 |
|
|
|
|
noch geht es nur um die idee, und ob dabei das gewünschte resultat überhaupt erzielbar ist ...
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
02.12.2007 16:00 |
|
|
|
|
Die Idee finde ich gut. Das gefällt mir 
Ich würde gerne aus reinem Interesse und Erfahrungsgewinn mithelfen.
Allerdings befürchte auch ich, dass ich nicht genug Programmierkompetenzen hab 
Ob das Resultat erzielbar ist, weiß ich deshalb leider nicht...
Hast du dir schon Gedanken gemacht, in welcher Sprache du das P2P-Programm schreiben würdest, und für welches OS es programmiert wird?
|
|
|
11.12.2007 23:17 |
|
|
|
|
Ich denke es geht unserem Eichhörnchen nicht um die praktische Umsetzung seiner Theorie/Idee sondern darum, hier mal einen kleinen Denkanschups zu geben, bzw. das Forum mal mit etwas qualitativen "aufzupeppeln".
|
|
|
11.12.2007 23:19 |
|
|
|
|
Ok. Also soll hier um die Theorie diskutiert werden, wie man so etwas programmiert und ob es möglich ist bzw. ob es bessere alternativen gibt, so etwas umzusetzen?
|
|
|
11.12.2007 23:21 |
|
|
|
|
es geht mir nicht so sehr um die umsetzung/programmierung, das wie ist hier nebensächlich...
es geht um das konzept, welche möglichen schwächen es hat, was noch zu beachten ist, verbesserungsvorschläge, kritik, etc ...
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
12.12.2007 00:04 |
|
|
|
|
Würdest du die Downloads von einem Rechner eingrenzen?
Die Verschlüsselung mit OTP verbraucht doch genausoviel Speicherplatz auf der Festplatte, wie die Datei groß ist. Dadurch ist ein etwas älterer Rechner schnell voll.
Ich habe nicht richtig verstanden, was alles runtergeladen wird. Der Schlüssel und das eig. Programm müssen ja runtergeladen werden. Würdest du dann noch weitere chunks, die nichts mit dem Ursprünglichen Programm zu tun haben downloaden lassen?
Wie soll der Client wissen, welcher Chunk der Schlüssel und welcher der zu entschlüsselnde Teil ist?
|
|
|
12.12.2007 17:57 |
|
|
|
|
| Zitat: |
Original von Meik1988
Würdest du die Downloads von einem Rechner eingrenzen?
|
|
verstehe die frage nicht
| Zitat: |
Die Verschlüsselung mit OTP verbraucht doch genausoviel Speicherplatz auf der Festplatte, wie die Datei groß ist. Dadurch ist ein etwas älterer Rechner schnell voll.
|
|
eigentlich sogar noch schlimmer: der otp schlüssel ist genauso groß wie das chiffrat ... die chunks die du für eine datei brauchst sind zusammen ca. doppelt so groß wie die datei...(ein klein wenig größer wegen der einheitlichen chunk größe)
| Zitat: |
Ich habe nicht richtig verstanden, was alles runtergeladen wird. Der Schlüssel und das eig. Programm müssen ja runtergeladen werden. Würdest du dann noch weitere chunks, die nichts mit dem Ursprünglichen Programm zu tun haben downloaden lassen?
|
|
es müssen alle chunks die zum download gehören auch geladen werden ... das daten zu nutzdaten verhältnis ist ca 2:1, also schlecht im vergleich mit üblichen p2p protokollen die schlimmstenfalls so bei 1:1,1 rumdümpeln
| Zitat: |
Wie soll der Client wissen, welcher Chunk der Schlüssel und welcher der zu entschlüsselnde Teil ist? |
|
es macht für den client keinen unterschied welcher chunk schlüpssel, und welcher chiffrat ist ... er muss nur wissen welche 2 chunks zusammen gehören ... das muss ihm vorher mitgeteilt werden, z.b. ähnlich wie bei torrents mit einer kleinen datei die alle wichtigen angaben enthält ...
warum das mit dem schlüssel und dem chiffrat beliebig gegeneinander austauschbar ist:
nehmen wir 01010101 als chiffrat, und 10101010 als schlüssel...
durch XOR (exklusiv oder ... überall da wo die beiden teile gleich sind, ist das ergebnis 0, wo unterschiede sind ist es 1) ergibt sich:
01010101
10101010
======
11111111
drehen wir es um:
10101010
01010101
======
11111111
die XOR operation ist also kommutativ: von daher spielt es wirklich keine rolle welchen der beiden chunks der client als schlüssel betrachtet, und welchen als chiffrat ...
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
12.12.2007 21:50 |
|
|
|
|
Mit downloads von einem Rechner eingrenzen meinte ich, dass von einem Rechner nicht beliebig oft heruntergeladen werden kann, sondern pro Client meinetwegen 5 Downloads VON diesem Client erlaubt sind.
Jedes mal, wenn jmd. etwas von einem anderen Client runterladen will, muss doch ein Chunk für den Schlüssel erstellt werden, was Speicherplatz verschlingt, oder?
Wenn das so ist, ist ja irgendwann die Festplatte voll, wenn unbegrenzt viele Nutzer von diesem Client runterladen.
Dann noch neue Fragen:
Was soll mit dem Schlüssel nach dem abgeschlossenen Download passieren?
Hab gelesen, dass die Schlüssel beim OTP-Verfahren immer nur ein einziges mal benutzt werden sollen, da sonst die Verschlüsselung gehackt werden könnte.
Wie lange dauert es denn die OTP-Verschlüsselung durchzuführen?
Das dauert doch bei z.B. einer Iso von 4 GB saulange, oder?
Wie würdest du den Schlüssel berechnen lassen?
|
|
|
12.12.2007 22:00 |
|
|
|
|
zu einem download wird ein satz chunks angelegt ... bereits bevor der erste runterladen kann ...
danach wird die liste mit den chunks und ihrer anordnung erstellt, die du dann an den oder diejenigen geben kannst die laden sollen/wollen
die laden dann alle die gleichen chunks ... es wird nicht pro user ein neuer satz chunks erzeugt ... man kann natürlich noch nen 2. satz anlagen wenn man wollte, aber das ist nicht notwendig...
es wird je satz chunks der bereit gehalten wird der zweifache platz der datei benötigt ...
es gibt keinen schlüssel mehr wenn der satz von chunks erstellt ist ... dann gibt es nur noch chunks ... es wird keine unterscheidung mehr zwischen daten und schlüssel gemacht
das mit der schlüsseleinschränkung für OTP ist soweit korrekt, nur ist hier eine andere eigenschaft von OTP gefragt, die auch bei mehrmaliger nutzung der schlüssel erhalten bleibt: wenn du nur die chunks siehst, ist es nicht möglich zu sagen was davon daten und was schlüssel ist ... (ausser du kennst den schlüssel, oder meinst ihn zu kennen) ... es ist nicht ziel des verfahrens den schlüssel geheim zu halten ... er ist öffentlich
die laufzeit der OTP operationen hängt von verschiedenen aspekten des systems ab, ist aber vom komplexitätsgrad so gering, dass eine logische binäroperation in der CPU genügt um ein datenfragment zu verarbeiten ... XOR ist eine operation die jeder heutige prozessor den du in einem PC findest nativ beherscht... beschränkt wird das ganze vermutlich eher durch die schreibgeschwindigkeit deiner massenspeicher...
schlüsselberechnung -> CSPRNG
sinn und zweck des aufwandes ist folgender:
angenommen ich habe etwas das ich übertragen darf ... nen linux ISO ... FILE_A
nun habe ich etwas von dem ich nicht möchte, dass man sieht das ich es anbiete ... FILE_B
- man nehme einen CSPRNG und erstelle einen OTP schlüssel ...
- man verschlüssele damit FILE_B und erhält X_FILE_B und Y_FILE_B (eins der beiden ist der schlüssel, das andere chiffrat)
- man nutze X_FILE_B als schlüssel für FILE_A und erhält X_FILE_A
- man nutze Y_FILE_B als schlüssel für FILE_A und erhält Y_FILE_A
nun wird alles was mit X_ und Y_ beginnt zum DL angeboten
man kann nun nichtmehr zweifelsfrei sagen, dass dass FILE_B angeboten wird ...warum?
wirft man mir vor eine verschlüsselte version davon mit X_FILE_B anzubieten, kann ich behaupten X_FILE_B und X_FILE_A gehören zusammen ... kombiniert man sie, erhält man ein unverfängliches linux iso ...
das selbe gilt für Y_FILE_B und Y_FILE_A
nur der vorwurf gleichzeitig alle X_FILE_B und Y_FILE_B anzubieten könnte noch zu problemen führen ...
aber wenn man soetwas verbreiten möchte, muss man nicht zwingend den X und den Y satz von einem peer aus anbieten ... bei entsprechender verteilung, bietet keiner der peers wirklich das komplettierbare FILE_B an ... lediglich eine der verschlüsselten versionen von FILE_A, welches legal kopiert werden darf ...und dennoch kann man sich aus den chunks der anbietenden peers FILE_B laden und konstruieren ...
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
12.12.2007 22:29 |
|
|
|
|
Achso. D.h. ja aber dann, dass man, damit dein Plan aufgeht, ein vermeintliches Linux-Iso herunterzuladen, alle 4 X und Y-Files herunterladen muss, also das 4-Fache der eigendlichen Datei herunterläd, oder?
Angenommen, man würde jetzt ein Filesharing Programm entwickeln, das diese Methode nutzt, würde es wahrscheinlich nicht sehr verbreitet sein, da es zwar einigermaßen sicher ist, aber der Download sehr lange dauert und weil der Download sowie das Bereitstellen der Dateien eine Menge Speicherplatz benötigt.
|
|
|
12.12.2007 22:55 |
|
|
|
|
du brauchst nicht alle 4 quellen laden ... nur die x un y teile von FILE_B ...
du darfst in dem fall aber nur entweder die x ODER die y teile wieder zum dl anbieten ...
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
12.12.2007 23:21 |
|
|
|
|
Ok. Wenn du aber nur X und Y von File B brauchst und auch nur diese lädst, kann man dich doch trotzdem anzeigen, weil du zweifelsohne die illegale Software heruntergeladen hast. Wenn du sagst, das gehört zu File A kannst du nicht nachweisen, dass du tatsächlich File A herunterladen wolltest...
|
|
|
12.12.2007 23:25 |
|
|
|
|
Wenn wir davon ausgehen, das File B mit One Time Pad verschlüsselt wurde(unter der Annahme absolut zufälliger Zufallszahlen) kann man nicht sagen, das es ein illegales File ist. Es kann auch ein legales File sein, genaugenommen kann es JEDES beliebige File sein, das exakt die Größe deines Files B hat.
|
|
|
13.12.2007 00:13 |
|
|
|
|
Schon klar. Allerdings kannst du das File wiederherstellen, wenn du X_File_B und Y_File_B hast.
|
|
|
13.12.2007 00:15 |
|
|
|
|
Ich glaube, wir reden aneinander vorbei ^^
| Zitat: |
- man nehme einen CSPRNG und erstelle einen OTP schlüssel ...
- man verschlüssele damit FILE_B und erhält X_FILE_B und Y_FILE_B (eins der beiden ist der schlüssel, das andere chiffrat)
- man nutze X_FILE_B als schlüssel für FILE_A und erhält X_FILE_A
- man nutze Y_FILE_B als schlüssel für FILE_A und erhält Y_FILE_A |
|
Du verschlüsselst File_B.
Daraus werden X_File_B und Y_File_B. Eine der beiden Dateien ist der Schlüssel. Die andre das Chiffre.
Wenn du X_File_B und Y_File_B hast, kommt wieder File_B heraus ;-)
Ich sprach bei
| Zitat: |
| Ok. Wenn du aber nur X und Y von File B brauchst und auch nur diese lädst, kann man dich doch trotzdem anzeigen, weil du zweifelsohne die illegale Software heruntergeladen hast. Wenn du sagst, das gehört zu File A kannst du nicht nachweisen, dass du tatsächlich File A herunterladen wolltest... |
|
davon, dass nur X_File_B und Y_File_B heruntergeladen werden, da nur diese 2 Dateien benötigt werden um das illegale gewollte File herauszubekommen.
Wenn das jmd. mitbekommt und z.B. Alle Daten mitliest und kopiert braucht er nicht mehr wissen, welches der Key war und kann dir direkt nachweisen, dass du die illegale Software heruntergeladen hast.
Deine Ausrede "Ich wollte File_A haben" hilft dir dann nicht mehr, weil du es nicht beweisen kannst...
Um also etwas zu beweisen musst du mind. X_File_A oder Y_File_A herunterladen.
Edit: Sprich, um die illegale Software *mit Ausrede* herunterzuladen, musst du doch das 3-Fache seiner Größe herunterladen, oder?
Und wer läd für ein legales Programm schon das 2-Fache seiner Größe herunter? Man kann also davon ausgehen, dass Nutzer dieses Programms illegale Software sicher herunterladen wollen....
Wer legale Software mit so einem Programm herunterläd ist doof oder will die illegale Software haben...
Is mir grad gekommen. So ein Filesharing-Programm is eig. (leider) zum scheitern verdammt, oder?
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Meik1988: 13.12.2007 00:34.
|
|
|
13.12.2007 00:31 |
|
|
|
|
wer sagt denn dass das herunterladen illegal ist in .de ?
*g* ... dafür ist bisher noch niemand verknackt worden ...
das ANBIETEN ist die heikle sache ... und solang du nur die x ODER die y komponenten anbietest, kann man dir nicht nachweisen dass du FILE_B anbietest ... die können genausogut zu FILE_A gehören ... im zweifel steht dann aussage gegen aussage ... BEWEISEN, dass du FILE_B anbietest kann man nicht, da du es nicht tust ...
die aufspaltung durch zufallszahlen in 2 teile, die zufallszahl und ihr komplement zur bildung des original files, erzeugt 2 teile, die jedes für sich betrachtet exakt so zufällig sind wie die zufallszahlen mit hilfe derer getrennt wurde ...
die sache der größeren transfers kann man auch noch etwas entschärfen ... am anfang sind noch keine chunks verteilt, daher ist der overhead groß... bei zukünftigen transfers, kann man die meist bekannten chunks als key verwenden ... die wahrscheinlichkeit, dass diese chunks bereits beim user vorhanden sind, oder entsprechende quellen für einen schnellen transfer verfügbar sind, ist recht groß ... zumal man auch ein verteilungs netz in bittorrent manier aufziehen kann, um die verfügbarkeit von chunks zu erhöhen (nur dass hier halt auch einzelne chunks oder gruppen von chunks übertragen werden die du selbst nicht haben wolltest) ... jeder peer wird sozusagen auf freiwilliger basis als mirror verwendet ... es bedürfte allerdings eines algorithmus der die jeweiligen chunks für das mirrorsystem effizient auswählt
weiterer nutzen: da die daten verschlüsselt sind, und nur ihr jeweiliger absender, respektive empfänger in der lage ist zu entschlüsseln, kann man nicht nachvollziehen zu was die chunks eigentlich gehören ... es sind daten, die ohne ihren zusammenhang, also die anordnung, und chunk kombination völlig willkürlich erscheinen...
jeder peer könnte also ähnlich wie eine TOR node agieren, da er daten von peers anfordert, die für andere bestimmt sind, und nur der verfügbarkeit wegen gespiegelt werden ... man kann nicht zweifelsfrei sagen für wen die daten endgültig bestimmt sind (läd der peer nun für sich selbst, oder wird gespiegelt?), wo sie her stammen(ist der andere peer nun quelle für den ganzen dl, oder spiegelt er nur häufig angefragte chunks?), oder zu welchen klartextdaten sie gehören (es ist nicht ersichtlich in kombination mit welchen anderen chunks was als datei herrauskommt, da wenn man alle möglichen chunks testet, jede datei gleicher länge entstehen würde, und es daher für einen mirror vermutlich unzumutbar, und vorallem nutzlos ist alle möglichkeiten zu prüfen, da die intendierte sowieso nicht zweifelsfrei ermittelt werden kann) ...
welchen zweck man dem protokoll auch unterstellen mag, man kann immer dagegen halten dass es die anonymität schützt, und somit verhindert dass jemand der darüber seine meinung äussert, politische verfolgung zu befürchten hätte... zumal ... wer kann dir denn vorschreiben was du mit der von dir bezahlten verbindung anstellst? wo steht geschrieben, dass es verboten ist datenschrott durch die gegend zu schieben, um in der heutigen zeit zu versuchen einem überwachungsstaat das schnüffeln schwer zu machen?
gut, die typische bandbreite eines privaten i-net zugangs mag noch zu gering sein, um das hier effizient betreiben zu können, aber ein bischen rumspinnen und laut über ideen nachzudenken kann ja zumindest die langeweile bekämpfen ... und, wer weiß schon was die zukunft bringt 
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
13.12.2007 01:39 |
|
|
|
|
Hehe, da haste wohl Recht ^^
Sag mal, was studierst du eig.?
Ich tippe mal auf Informatik und Recht. Du kennst dich anscheinend ganz gut im StGB aus *g* Mir ist aufgefallen, dass du öfters auf §§ im StGB verweist.
Jetzt aber wieder zurück zur Theorie:
Du sagtest, häufig genutzte Chunks könnte man spiegeln, also herunterladen, obwohl sie nicht gebraucht werden.
Irgendwie musst du die Chunks aber auch identifizieren können.
Wenn du z.B. ein chiffre-Chunk einer gewollten Datei herunterlädst und diese de-chiffrieren willst brauchst du bekanntlich den Schlüssel.
Da du vorgeschlagen hast, dass häufige Chunks als Schlüssel dienen setze ich hier mal vorraus, das Chunk I der Schlüssel zu unsrem chiffrierten Chunk J ist.
Du hast jetzt J auf dem Rechner. Wie willst du aber feststellen, dass du auch I auf deinem Rechner hast, um J zu dechiffrieren und die gewollte Datei zu erhalten?
Nicht nur die Bandbreite ist zu niedrig.
Wenn du vor hast häufig verwendete Chunks auf anderen Clients zu spiegeln, ohne, dass diese die gespiegelten Chunks brauchen, sammelt sich nach einiger Zeit eine riesige Datenmenge an, die nicht gebraucht wird.
Würdest du diese Chunks irgendwann automatisch löschen lassen?
Hauptproblem ist aber, die Chunks zu identifizieren, oder?
|
|
|
13.12.2007 01:53 |
|
|
|
|
jeder chunk kann im netz eine eindeutige nummer bekommen ... man wähle eine 128 bit zufallszahl, und bilde einen hash über den inhalt des chunks ... beides zusammen kann einen chunk eindeutig identifizieren (kollisionswahrscheinlichkeit ... naja ... eher hast du 1000 mal nacheinander nen 6er im lotto)
was ich studiere? IT-Sicherheit
der §168 StGB den du ansprichst ist "Störung der Totenruhe"...
aber zurück zu den chunks ...
für den betrachter und nutzer gibt es nur chunks im netz die er anfordern kann ... will er einen bestimmten download haben, bekommt er aus irgend einer nicht näher spezifizierten quelle eine kleine datei:
die enthält eine liste mit chunks (also die IDs der chunks) sowie die anordnung der chunks (zu jedem chunk ein offset wo er zu platzieren ist, überschneiden sich 2 chunks, wird an den stellen der überschneidung ein XOR gebildet)
bsp:
angenommen chunks haben eine größe von 10 und in der datei steht folgendes:
chunk / offset
1 / 1
2 / 1
3 / 11
4 / 11
5 / 18
6 / 18
nun müsste der client sich die chunks 1 bis 6 herunter laden und wie folgt verarbeiten:
er beschaffe sich platz für 28 stellen (wie groß eine der stellen auch immer sein mag)
der gesammte speicher wird mit 0 gefüllt
chunk 1 wird bei stelle 1-10 via XOR aufaddiert
chunk 2 wird bei stelle 1-10 via XOR aufaddiert
chunk 3 wird bei stelle 11-20 via XOR aufaddiert
chunk 4 ...
die überlappung bei den stellen 18-20 ist absicht, da die eigentliche datei kleiner sein kann braucht man eine methode bei einer fixen block größe eine variable dateigröße erreichen zu können... man könnte anstelle dieser überlappung auch einfach mit irgend einem padding auffüllen, und das padding im nachinen abschneiden...
im bereich 1-28 stehen danach die daten des DL ... evtl als gepacktes tarball mit prüfsumme
zu jedem chunk sollte ebenfalls eine prüfsumme mitgeladen werden um übertragungsfehler ausschließen zu können ... steht diese prüfsumme zudem in der datei mit der liste, ist sie eine weitere sicherheit...
was den langsam wachsenden datenberg angeht ... man kann das selbstverständlich mit einer art quota regeln, und alte files nach und nach aussortieren
__________________
Gräten auf dem Sofakissen wird man wohl entfernen müssen.
|
|
|
13.12.2007 13:01 |
|
|
|
