Re: (eternity) Automating BlackNet Services

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

Scratch Monkey writes:
> 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.

This design ties in pretty well with what I understood Tim May's
suggestion to be of using BlackNet to provide eternity services.

I notice that you are assuming that all document delivery would be via
digital dead-drop (alt.anonymous.messages).

Depending on the usage pattern of this service it has the potential to
be higher bandwidth than by Eternity USENET design.  The BlackNet with
dead-drop only scheme you propose will become more expensive in
bandwidth than Eternity USENET at the point at which the volume of
satisfied document requests being posted to USENET for different
recipients exceeds the volume required to repost the traffic at the
desired update rate.  This is because you may have multiple requests
for the same document, all of which must be posted to
alt.anonymous.messages.

One thing you could do to reduce this overhead would be to combine
requests for the same document.  To do this you could add an extra
delay to satisfying requests to increase the chances of accumulating
more requests for the same document.  Alternatively, documents which
were sent out within the last 24 hours or so could have just the bulk
symmetric key encrypted for the subsequent recipients sent together
with a message-id.  (A separated multiple crypto recipient block).

A more subtle problem you would probably want to address with this
design is that you don't really want anonymous requested documents to
be linkable, so you would need to do stealth encoding of the messages.
This tends to be more complex for multiple recipients, but it is
doable, and is made easier by standardising on public key size.


In general I think I consider my Eternity USENET design more secure
than your design and of similar overhead depending on whether the
usage pattern results in lower bandwidth.  I make this claim because
users are offered better security with E-USENET because they are
completely anonymous, and don't need to submit requests.  They can
passively read E-USENET, perhaps on a university campus, or with a
satellite USENET feed.  The readers are much harder to detect.

This is significant because remailers are complex to use, and the
users should be assumed to be less technically able (ie more likely to
screw up remailer usage).

Publisher anonymity is of basically the same security.


A lower bandwidth alternative, to either E-USENET or what you have
termed Automated BlackNet alternative is therefore to send messages
via use-once mixmaster remailer reply blocks of the sort used by some
nymservers.  Clearly this is also lower security because the user must
creating reply blocks which ultimately point back to himself.

However the performance win is big.  With this architecture BlackNet
can win significantly over E-USENET because the volume is reduced to
just indexes of available documents.

Also I consider indexes are probably low enough risk for people to
mirror on the web or cache on the web or whatever.  My E-USENET
prototype design has a separate index mechanism.

(I understand there is some magic inside mixmaster which prevents
packet replay, which helps avoid message flood attacks, though didn't
locate the code fragment responsible for this functionality when I
examined the sources.)


Also I found your use of hashes and passwords so that the server does
not necessarily know what it is serving interesting.  I have similar
functionality in my prototype E-USENET implementation.

I mainly included the functionality because the prototype is also
being used as an publically accessible eternity USENET proxy, to allow
the operator to marginally reduce risks.  I think this approach is of
marginal value, in that the attacker will be easily able to compile an
index from the same information as users.

This is really a form of secret splitting: the key is one part, and
the data the other part.  The key can be considered to be part of the
URL.

> 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.

	http://www.dcs.ex.ac.uk/~aba/eternity/

I have done most of the work already I think.  What you are trying to
do is so similar that you should be able to acheive what you want with
some light hacking of my perl code.

For testing purposes I am in the same position as you; dialup ppp
connection and linux machine.  What I did was to implement both
newspool access code, and NNTP access code.

For local testing I just create a dummy news-spool.  The eternity
distribution comes with a few documents in this dummy news spool.  A
real local news spool would work also.

Then you can simulate everything you want offline.  You can change the
config file to switch to an open access NNTP news-server at any time
for a live test.

All the code to read USENET is there, and to scan chosen NNTP headers,
etc.  I would highly recommend perl as a rapid prototyping language.
What you see took 3 days (long days, mind, motivation was at an all
time high around then).

Adam