(simpler) Transfer of a file between two clients, without either client becoming aware of the other’s IP address.
(more clients, but same idea) SAFEtorrent: a swarm of clients sharing chunks of a file until they all have the complete file.
How might SAFEnet be used to obfuscate the IP addresses of the two or more clients without actually uploading the file to SAFEnet? Obviously, you might upload a file to SAFEnet and someone else might download it from there; that’s not what I’m talking about here. The metadata is to be obfuscated, not the bulk data.
EDIT: My thinking is to keep costs down, make it free if possible, by assuming that bulk storage of data on SAFEnet will cost coin, but messaging won’t.
The model that I have in mind might be a synergy between SAFEnet and something like this, the Phantom anonymity protocol from a few years back that doesn’t appear to have gone anywhere. What that is a way of setting up a chain of peers so that each one only has the IPs of his neighbors. The topology is like a SAFEnet path. Seems to me that that idea can be borrowed in simpler fashion: a crowd of SAFEnet peers run a “SAFEtorrent” client that uses SAFEnet messaging to quickly set up such chains.
Ahh…very clever…using the SAFE pipeline/protocol without actually having to have files “touch” the network…I like it…I wonder if the messaging protocol(s) could be used for something like this when they arrive…I would assume (hopefully) they would obfuscate the IPs as well…hmm…wouldnt the file have to be “in” the network somehow to transfer it though…I dont think you could use say a local file on your machine and have it be wrapped in SAFE for the swarm/transfer…
If you use messaging then there is no IP address to get. A ton of messages, bit like NNTP and combining as many messages as needed together to reconstruct your file. You could even add in par2 to your app to account for any messages lost. If you send a large file then the possibility of a lost message is real.
You then have to ensure the receiver is ready to receive (your app handles that) as messaging leaves the messages in your out box until the receiver gets them. And the number of messages are limited due to that.
EDIT: just thought you could use a form of XMODEM from the BBS days to make your messages into a XMODEM protocol for transfer. It had error recovery and handled async transfers nicely, Then you only have a few messages in transfer at any time.
I do not know why you want to use messaging to set up chains. Messaging is direct, loses IP along the way and is completely anonymous. Only the throwaway IDs will be known.
Because the chains are not on SAFEnet, so some mechanism is required to inform each node of the IPs of its two neighbors.
In the presentation of the Phantom protocol, you see that it’s an involved process to set up the chain securely, drawing clients from a Kademlia database. The setup is much more complicated than the operation of the chain. SAFE messaging would greatly simplify the setup.
One possible chain might look like this, with each node having created a key pair and sent its “public” key to a Kademlia database that associates the public key with the node name. Note that this isn’t exactly the same as the method in the presentation, just an adaptation off the top of my head.
A → B → C → D
Imagine the chain is already set up. That means that each node has a table of the SAFE network names the other nodes in the chain. each node also knows the IP address of its two immediate neighbours in the chain.
A requests a file (chunk) from D, using SAFE messaging.
D encrypts the chunk with A’s public key and then again with C’s public key, and sends the resulting chunk to C.
C decrypts the received chunk with its private key, encrypts it with B’s public key, and sends it to B. Note that C does not know who the chunk is destined for; all that it knows is that D sent it something to forward to B.
B decrypts the received chunk with its private key and encrypts it with A’s public key. Note that the chunk is now double-encrypted with A’s public key, since B does not know that A is the final recipient; all that B knows is that it has received something from C to forward to A.
A applies its private key to the chunk twice to decrypt the chunk.
So that’s the simple case, of one-to-one file transfer, and one would want a client software of some kind to automate the process.
The more complicated case of a bittorrent sharing of a file/file-collection would also require a client that, I think, would be 90% the same as a regular bittorrent client, since it uses SAFEnet names instead of IP addresses. It might be even more similar (and thus leverage existing FOSS software) by translating the SAFEnet names into dotted-quad, pseudo-IP addresses analogous to the “AP” addresses of the phantom network.
In such a scheme, greylisting of files is very difficult (although I would hesitate to say anything is impossible), because the chunks are:
Not static (i.e., passing through from D to A), and therefore less amenable to traffic analysis.
Not on vaults, and therefore less exposed to people who might be motivated to curate and filter unacceptable data.
Encrypted with the recipient’s public key, therefore less amenable to fingerprinting.
If set up properly, the clients in any given swarm would be people who are at least indifferent to, and perhaps sympathetic to, the kind of data being transferred. For example, people trading movies are not opposed to the pirating of movies.
The length of the chain is adjustable according to an end node’s trade-off of speed against security, which is distinct from the maximization of security implemented in SAFEnet, regardless of the lower security threat from non-global third-parties, such as the movie and music industry associations and hired-gun law firms.
An obvious niche would be SAFEtorrent indexing sites on SAFEnet, analogous those on the Internet. The differences being: the *.torrent files contain SAFE network names of seeders rather than IPs, and such sites would be resistant to legal threats.