I've been thinking a bit about anonymous distribution/storage, and here are some thoughts:
1. I've envisioned a network of servers interconnected into a general "cloud" of storage, not physically centralized anywhere. Each server would act as a relay/storage node.
2. Nodes of the cloud would create unique public/private key pairs with which to initiate encrypted communications with a select peer group. The private key would remain in RAM, never stored on a disk, and never transmitted to anything (in case of wiretapping/eavesdropping). This way, if the machine is brought down for any reason, the private key is eliminated, and the contents of the local storage area are safely encrypted with no possibility of reclaiming the private key (i.e. the storage effectively self-destructs)
3. A node should allocate a user-selectable pool of local storage to be used by the cloud for anonymous storage - i.e. encrypted packets of data that form a part of a file (but never the whole file, only several random packets from it). The packets would be encrypted as outlined above, and would be redundantly stored on one to several peer computers (I'm not sure what algorithm would work here, but the goal would be to ensure that if any one machine went down, others would "fill in" the gap and re-distribute redundant packets to peers to make up for the loss - like water filling back in if you remove a cup of it from a lake).
4. When you submit a file, it's torn up into packets, which are encrypted with peers' public keys and send out (redundantly) into the cloud. Periodically, servers would swap packets and otherwise "shuffle" their storage to ensure entropy in the system.
5. Some of the encrypted packets exchanged by servers would include directory information, indicating a unique serial number that tags a particular submitted file (these would be generated when you submit, using some unique physical tag like a one-way hash of an ethernet card MAC address in combination with some other stuff - TBD). All encrypted packets floating around would be so tagged, and have a sequence number as well.
6. A particular node would in this way slowly build up a directory (encrypted and stored in the cache, which again, becomes unreadable if the machine goes down) of available content that could be requested of the cloud, by virtue of the directory fragments being circulated. If the machine is downed, the cache would be lost, and the process would start over once it's started again. Note that the directory fragments would not include any information regarding physical machines the files are stored on. You could probably implement some kind of distributed search capability to ask peers up to a certain hop count if they know of any specifically requested content that's not listed in the local directory, but that's tangential.
7. In any case, Once a user has identified a file (and therefore serial number) to be "downloaded" from the cloud, request packets (again, encrypted) begin filtering out to the nodes, with a list of yet-undelivered packets (which, at first transmission, would be the entire list). As each server gets the list, it would check it's own local storage. If it had a yet-undelivered packet, it would route it back, and delete the packet from the request list. Once the server is done with the packet-request list, it would split it up, and send it out to two of its peers. In this way, eventually you would have single-packet requests floating around until a server finally finds that packet in its local storage (and of course, you could add some kind of Time-To-Live to the request packet to avoid perpetually unanswered requests from littering the cloud).
8. As packets begin showing up at the requesting machine, it decrypts them and aggregates them until the file, in its entirety, is created locally.
9. To allow for the group-aging of content (i.e. to flush the cloud of old stuff) you could have individual server admins specify conditions under which file fragments would be accepted for local storage. You could also locally "delete" a file from your server, in that you could create a blacklist of serial numbers that you will no longer allow to occupy local storage on your machine (this could be persistent (i.e. outside of encrypted storage, thus able to survive a restart), as it's simply a list of ID numbers, and not content itself.) You may also create limitations on the age of a file you would accept, the type of file, etc. However, you could never effect whether another server chose to allow fragments from a particular file to reside in its local storage. In this way, no one (at any level of priviledge, even the original submitter of the file) could centrally delete any file explicitly (say, under duress). So, files never delete, they just "fade away" in the sense that over time enough servers would deny them that they would simply not take up room on anybody's drive, and your local directory/search functions could use the blacklist to effectively shield the files from your eyes forevermore. Some kind of cloud-wide time limit may be appropriate to ultimately kill old content outright (after a couple of years) so the blacklists don't become huge. Also, if files got erroneously timed out after such a long time, if anyone still cared they could re-submit it into the cloud. Timing out content could also eliminate "orphaned" file fragments and other random quirks in the cloud.
Correctly implemented, this seems to provide a pretty airtight method for distributing files in a way as to make their physical locations at any given time impossible to determine, and also make it impossible for any party to specifically prevent content from appearing in the cloud or being deleted from the cloud. Also, as long as the encryption strength kept ahead of cracking techniques, eavesdroppers would also be kept at bay.
Slashdot Mirror
1. I've envisioned a network of servers interconnected into a general "cloud" of storage, not physically centralized anywhere. Each server would act as a relay/storage node.
2. Nodes of the cloud would create unique public/private key pairs with which to initiate encrypted communications with a select peer group. The private key would remain in RAM, never stored on a disk, and never transmitted to anything (in case of wiretapping/eavesdropping). This way, if the machine is brought down for any reason, the private key is eliminated, and the contents of the local storage area are safely encrypted with no possibility of reclaiming the private key (i.e. the storage effectively self-destructs)
3. A node should allocate a user-selectable pool of local storage to be used by the cloud for anonymous storage - i.e. encrypted packets of data that form a part of a file (but never the whole file, only several random packets from it). The packets would be encrypted as outlined above, and would be redundantly stored on one to several peer computers (I'm not sure what algorithm would work here, but the goal would be to ensure that if any one machine went down, others would "fill in" the gap and re-distribute redundant packets to peers to make up for the loss - like water filling back in if you remove a cup of it from a lake).
4. When you submit a file, it's torn up into packets, which are encrypted with peers' public keys and send out (redundantly) into the cloud. Periodically, servers would swap packets and otherwise "shuffle" their storage to ensure entropy in the system.
5. Some of the encrypted packets exchanged by servers would include directory information, indicating a unique serial number that tags a particular submitted file (these would be generated when you submit, using some unique physical tag like a one-way hash of an ethernet card MAC address in combination with some other stuff - TBD). All encrypted packets floating around would be so tagged, and have a sequence number as well.
6. A particular node would in this way slowly build up a directory (encrypted and stored in the cache, which again, becomes unreadable if the machine goes down) of available content that could be requested of the cloud, by virtue of the directory fragments being circulated. If the machine is downed, the cache would be lost, and the process would start over once it's started again. Note that the directory fragments would not include any information regarding physical machines the files are stored on. You could probably implement some kind of distributed search capability to ask peers up to a certain hop count if they know of any specifically requested content that's not listed in the local directory, but that's tangential.
7. In any case, Once a user has identified a file (and therefore serial number) to be "downloaded" from the cloud, request packets (again, encrypted) begin filtering out to the nodes, with a list of yet-undelivered packets (which, at first transmission, would be the entire list). As each server gets the list, it would check it's own local storage. If it had a yet-undelivered packet, it would route it back, and delete the packet from the request list. Once the server is done with the packet-request list, it would split it up, and send it out to two of its peers. In this way, eventually you would have single-packet requests floating around until a server finally finds that packet in its local storage (and of course, you could add some kind of Time-To-Live to the request packet to avoid perpetually unanswered requests from littering the cloud).
8. As packets begin showing up at the requesting machine, it decrypts them and aggregates them until the file, in its entirety, is created locally.
9. To allow for the group-aging of content (i.e. to flush the cloud of old stuff) you could have individual server admins specify conditions under which file fragments would be accepted for local storage. You could also locally "delete" a file from your server, in that you could create a blacklist of serial numbers that you will no longer allow to occupy local storage on your machine (this could be persistent (i.e. outside of encrypted storage, thus able to survive a restart), as it's simply a list of ID numbers, and not content itself.) You may also create limitations on the age of a file you would accept, the type of file, etc. However, you could never effect whether another server chose to allow fragments from a particular file to reside in its local storage. In this way, no one (at any level of priviledge, even the original submitter of the file) could centrally delete any file explicitly (say, under duress). So, files never delete, they just "fade away" in the sense that over time enough servers would deny them that they would simply not take up room on anybody's drive, and your local directory/search functions could use the blacklist to effectively shield the files from your eyes forevermore. Some kind of cloud-wide time limit may be appropriate to ultimately kill old content outright (after a couple of years) so the blacklists don't become huge. Also, if files got erroneously timed out after such a long time, if anyone still cared they could re-submit it into the cloud. Timing out content could also eliminate "orphaned" file fragments and other random quirks in the cloud.
Correctly implemented, this seems to provide a pretty airtight method for distributing files in a way as to make their physical locations at any given time impossible to determine, and also make it impossible for any party to specifically prevent content from appearing in the cloud or being deleted from the cloud. Also, as long as the encryption strength kept ahead of cracking techniques, eavesdroppers would also be kept at bay.
What do people think?