Home Upgrade Search Memberlist Extras Hacker Tools Award Goals Help Wiki Contact

A New Approach to File-Sharing - Dissociated File-Sharing Protocol

Hey All,

Recently, I was sitting around and thinking about file-sharing and the inherent risks that come with it, when an idea popped into my head. This idea could be a possible solution to file-sharing without the risk of being snooped on or people knowing who's downloading what and when. The concept I came up with is called the Dissociated File Sharing Protocol. It works like so;

https://i.imgur.com/2M7a1.png or
Diagram (Warning Large) (Click to View)

When a client initially starts a session, the client Idenifies themselves through a TCP Connection with the 'Peer Identification Server', this simply adds them to a list of peers that other peers may connect to depending on the latency between them. Once identified, a client can then begin connecting to a number of peers by asking the Peer Identification Server for peers to connect too. Peer are connected to one-another using a TCP connection that is encyrpted with a form of asymmetric key cryptography (Such as RSA), the more peers the client is connected to the better.

Once the client has 2 or more unique routes, they are ready to start file-sharing. I will be using client-A (See Diagram) as an example. To initiate a file transfer the user of client-A would simply enter a SHA-256 checksum of the file they wish to download and then hit a 'search' button, From there client-A will send a file request packet through all available routes. The file request packet is only contains the SHA-256 Checksum and a time-out value, why will become clear soon.

Upon any one client recieving a request from another, the next client (lets assume Client B) will check if they have the file in question, check if the time-out for the packet has been reached and then pass the packet to all available routes regardless of if Client B is in possetion of the file or not.

Once the packet reaches a Client that is in possetion of the requested file, that client not only still sends the packet through all avalible routes (assuming the timeout hasn't been reached) but also sends a file-found packet through all avalible routes.

This packet exchange approach carries on through-out the entire file transfer process, a point worth noting is that If a client recieves the same packet numerous times within a short space of time, it will not pass it along, to try and avoid infinate circular loops.

So, By referancing the diagram, If Client D had the file and Client C Requested it;
  • Client C would send the file request to Client D and Client B.

  • Client B would also send the same request to Client A and Client C.

  • Client D would send a file found packet back along with passing the file request on to Client A.

  • Client C would disregard the packet sent from Client A.

  • Client A would send the same packet to Client D.

  • Client D would also disregard that packet as it has already recieved and acted upon it.

  • Client A would disregard the packet recieved from client D as client A has already seen and acted upon it.



And that would be it, a successfull file request would have been made, and this same technique would be applied for every single packet sent. Although this concept would be lengthy, slower compared to standard p2p file-sharing and bandwidth intensive, it does achieve it's goal, and because this protocol not only encrypts the link between two peers, but also removes any way to track where a packet origionated, it makes file sharing very secure and completely anonymous.

Thoughts? Ideas?

Regards,

Logic_Bomb
If there is a link between clients (that already means every client is a server too) why would they send a identification link? that part seems exploitable.

i think im wrong anyway, i don't understand much but that's what i think.
don't take my opinion without throughly criticizing it, i might have not understood something.

intresting thought, i'v been thinking of ways to share files too, but HTTP sharing went really low and i hate torrents. i did upload some though..
Though it is encrypted, the system is centralized and if the peer identification server were to go down, everything would fall through. And though hashes would be sent as far as file names, if the private keys in the RSA keypair became exposed the traffic would be vulnerable, and hashes could be compared to figure out which files were being downloaded. Also you would have to use some sort of symmetric encryption algorithm for actual data transfer, asymmetric algorithms can be used to deliver a common symmetric key but are unable to transfer large amounts of data due to size restrictions on the mathematical properties that allow them to work as well as the extreme overhead. It's a good idea though, I like your thinking. ^^
(Jun 16, 2012 08:38 AM)itai19901 Wrote:  If there is a link between clients (that already means every client is a server too) why would they send a identification link? that part seems exploitable.

i think im wrong anyway, i don't understand much but that's what i think.
don't take my opinion without throughly criticizing it, i might have not understood something.

intresting thought, i'v been thinking of ways to share files too, but HTTP sharing went really low and i hate torrents. i did upload some though..

The identification server would only show who is using a client, that doesn't always mean that they are illegally downloading files, file-sharing is perfectly legal, file-sharing copyrighted material is the illicit part. So having an identification server would make no difference really.

(Jun 16, 2012 09:33 AM)Fallen Wrote:  Though it is encrypted, the system is centralized and if the peer identification server were to go down, everything would fall through. And though hashes would be sent as far as file names, if the private keys in the RSA keypair became exposed the traffic would be vulnerable, and hashes could be compared to figure out which files were being downloaded. Also you would have to use some sort of symmetric encryption algorithm for actual data transfer, asymmetric algorithms can be used to deliver a common symmetric key but are unable to transfer large amounts of data due to size restrictions on the mathematical properties that allow them to work as well as the extreme overhead. It's a good idea though, I like your thinking. ^^

Hmm, I see your logic there, Maybe over time it could work more like p2p, in the fact that there's no centralized server to keep a record of peers, instead, every peer would keep a small database of peers (around 200 say) and then you simply contact other peers in order to find more peers! xD Paradox. And as for the RSA Keys, that is true, but that's true with any encryption, even the encryption TOR uses, unlikely to happen, But a slight flaw non-the-less. And ooh, good thinking about the size restrictions on the asymmetric key encryption, but at-least a standard form of encryption could be established under the RSA encryption, thus still keeping things secure. Thanks for the good feedback! I like feedback that gets me thinking! xP

Regards,

Logic_Bomb


Possibly Related Threads...
Thread / Author Replies Views Last Post
by TheArchitectSep 24, 2023 12:49 PM 2 172 Sep 24, 2023 12:49 PM
Last Post: Rottw3il3r