Scratch Monkey, a nym, described this BlackNet variant on the eternity list(*), which raises some interesting issues I think. I am currently forwarding eternity discussion backwards and forwards between the lists and adding Cc's on my replies. Adam (*) To subscribe see http://www.dcs.ex.ac.uk/~aba/eternity/ there is a CGI form to subscribe, or send message with body "subscribe eternity" to majordomo@internexus.net. ------- Start of forwarded message ------- To: eternity@internexus.net From: nobody@REPLAY.COM (Anonymous) Organization: Replay Associates, L.L.P. Subject: (eternity) Automating BlackNet Services Sender: owner-eternity@internexus.net Precedence: bulk On Tue, 13 Jan 1998, Adam Back wrote:
This suggests that another approach would be to have two classes of services. Users of high risk documents can put up with 24 hour turn around, and lower risk documents can be served by an alternate service, intermediate risk documents can exist by using low risk resources until detection.
Here's a way to do an automated "high risk" server, using many of the same methods as the eternity implementation but with longer delays and more security for the server. For now I am calling this scheme (which is not much more than an automated participant in the BlackNet scheme) ABNS, for Automated BlackNet Server. 1) Server program resides on host with large disk and full news feed. 2) Server program watches alt.anonymous.messages. 3) Alice anonymously posts data to alt.anonymous.messages, in a format similar to eternity documents. However, the data would typicaly be encrypted to the public key(s) of the 4) Server notices the message, processes it and stores the data. 5) Bob anonymously posts a request for a document to alt.anonymous.messages. 6) Server notices the request, and anonymously posts a public key to alt.anonymous.messages along with a statement that the requested document is available. 7) Bob notices the post from the server, and anonymously posts a second request to alt.anonymous.messages, this time encrypted with the server's public key. This second request could include Bob's public key. 8) The server notices and decrypts the second request, and anonymously posts the requested document to alt.anonymous.messages, encrypted with Bob's public key if one was provided. The reason for steps 6 and 7 are to prevent multiple servers from responding to the same request with (potentialy) very large files. Of course, if Bob knew the data was available from a particular ABNS, he could skip steps 5 and 6. Both the client and server software should be trivial to write, and in fact I am working on that now. The server is partially written, but I am at a handicap because I do not have access to usenet at this time. If anyone knows of some canned code (preferably sh or c, but perl would work) that will perform functions such as "Retrieve list of articles in newsgroup x" and "Retrieve article number y", a pointer would be nice. So far, this is not too exciting, but the addition of a couple of extra technologies could make it very usefull... If the "Steganographic File System" being proposed by Ross Anderson comes to fruition, the ABNS could recieve a filename and password as part of each submission, and then promptly 'forget' them. In this way, not only does the server not have access to the contents of the file, it doesn't even know what files it has! Retrieval requests would include the appropriate information to enable the server to fetch the data. The addition of digital cash to the picture would make it really viable, because the server could charge for storage, or retrieval, or both. So picture this: Alice has some data she wants to sell. She encrypts this data to the public key of an ABNS, along with the filename and password to be used for file access and an amount of cash sufficient to pay for storage costs for maybe 6 months. She would also specify a 'value' for the data, which the ABNS will charge for access to this data and of which Alice will recieve a cut. She could also send a small advertisement (for which here storage fees should be minimal) as a separate document, and give it a value of zero. The server decrypts the message and verifies the cash. It then stores the file in the designated filename/password location in the SFS (stego file system). It makes a hash of the filename/password, and stores this hash in a 'table of contents' file that would also contain: - - the 'paid-until' date for the data. - - the public key of the submitter. - - the 'price' for the data It would then forget the filename and password. Bob learns of the existance of the data (how? I haven't thought about that yet but it doesn't seem to me that it would present much of a problem) and wishes to purchase it. He sends a message to the server by encrypting to the server's public key and posting to alt.anonymous.messages. In his message he includes the filename/password of the data he wants, along with an appropriate amount of cash and Bob's public key. The server decrypts Bob's request: - - First, it pockets the cash. (Everything else is just to keep customers) - - It then creates a hash based on the filename/password of the data that Bob is requesting. - - It looks up that hash in the table of contents file. - - If it is not found, it anonymously posts a message encrypted to Bob's public key indicating that the data is not available, but that Bob now has a line of credit at this particular ABNS. :) - - If it _does_ find the hash in the contents file, it checks the paid-until date. - - If the file is not paid up, the server treats it as if the file were not present (and in fact, it deletes the file at this time, something it could not do without the filename/password that Bob supplied). - - If the file is present, and storage fees are paid up, and Bob has enclosed enough cash (or has enough credit), the ABNS accesses the file in the stego filesystem and anon-posts it to Bob's public key. - - The server then forgets the filename/password, but remembers the hash. - - Of the 'fee' collected from Bob, the server allocates it as follows: - 70% is kept. - 10% is credited to the hash retrieved by Bob, to extend it's "Paid up" time. This means that documents that bring in a lot of money can pay for thier own storage costs, without the contributer needing to keep paying. - 20% is encrypted to the public key listed in the table of contents and posted to alt.anonymous.messages, as a royalty to the contributor. Of course, this is just one possible policy for the server to have. Market forces will shape the eventual pricing scheme. I'm actualy not sure if such a system would be used, because Alice may have no motivation to send her data to an ABNS when she can run the server herself and take 100% of the money. Comments on this aspect of operation would be appreciated. Either way, the same software could be used. I hope to post initial versions within a couple of weeks, assuming I can hack myself some account with nntp access for testing. -Scratch Monkey- 85d8e7d860504ba9e90527e7e89210d7 This is a new persistant nym. PGP key(s) will be posted soon, and I will verify that the keys belong to the same person who posted this message by providing the string that produces the md5 hash above.