(fwd) Automating BlackNet Services

[Adam Back <aba@dcs.ex.ac.uk>]

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.