1994-08-08 - remailer ideas

Header Data

From: Jonathan Rochkind <jrochkin@cs.oberlin.edu>
To: cypherpunks@toad.com
Message Hash: 43f7e71ef5f4c76a9693fd0625eebb4cddfb9c5b573f6fb79dffb04780b96e66
Message ID: <199408080103.VAA23382@cs.oberlin.edu>
Reply To: N/A
UTC Datetime: 1994-08-08 01:02:49 UTC
Raw Date: Sun, 7 Aug 94 18:02:49 PDT

Raw message

From: Jonathan Rochkind <jrochkin@cs.oberlin.edu>
Date: Sun, 7 Aug 94 18:02:49 PDT
To: cypherpunks@toad.com
Subject: remailer ideas
Message-ID: <199408080103.VAA23382@cs.oberlin.edu>
MIME-Version: 1.0
Content-Type: text/plain


My newsgroup-RemailerNet ideas seem to be getting mixed reviews, but I
think that part of the p
roblem is that some people don't understand what
I'm trying to accomplish. There are several features I think are extremely
desirable in a remailernet infrastructure, which our current
infrastructure doesn't accomplish, and which no proposed infrastructure
that I've seen accomplishes either. I'm not certain my newsgroup/pinging
idea addresses these concerns, either, but I'm going to lay them all out,
and y'all can see what you think.

These points aren't distinct, I realize. They're all interrelated
somewhat.

1) New remailers should be able to enter the "remailernet" easily, and
with a minimum of human intervention. If I decide to run a remailer, the
infrastructure should provide a way to make it visible to all other
particpants in the remailer net, other remailers and users. Whether the
other participants make use of it or not, is another question, and would
presumably depend on a web-of-trust kind of situation. But currently,
someone who wants to stay current with this kind of info basically has to
read cypherpunks, and take notes when people announce new remailers. 
Better, would be if this sort of "new remailer" info could be distributed
automatically, to both users and other remailers.

2)  Remailers should be able to leave the remailernet without devestating
it.
If my remailer is temporarily, or permanently,  down, the remailernet
should route around it.  Again, the current way for operators to announce
this would basically be to post to cypherpunks list, and maybe
alt.security.pgp too. If other remailernet particpants miss the
announcement, havok can ensue. If a middle link of your remailer chain is
down, all you know is your messages aren't getting to their destination,
you won't know which link is down. We shouldn't require all particpants to
read cypherpunks religiously, and if an operator isnt' conscientious
enough to post to the expected places, it shouldn't be fatal. Both users
and remailers should have an automatic way of finding out about down
remailers. 

3) Remailers themselves should have a way of automatically learning the
topography of the remailernet. If we want to form a cohesive black-box
remailernet, remailers are going to need this info. Maybe they're sending
fake padding between themselves to thwart traffic analysis. Maybe they're
encrypting with the key of the next remailer down the line automatically
for you. I don't know enough about it to know what methods are best, but
it seems probable from discussion that remailers are going to need to do
something that requires knowing about all the other remailers, and their
PGP keys and such.

4) Users should have a way of learning the topography of the remailernet
too. A way which doesn't require so much human intervention. I should be
able to tell my software "send an anon message to X, put 10 links in the
remailer chain," and it will do it. To use the remailer net, I shouldn't
need to read cypherpunks in order to keep track of all various remailers,
and which are up, and which are down. My software should do that for me.
And again, your software  doesn't need to use all the remailers that it
knows about, it can rely on web-of-trust based on PGP signatures and such.
[Although I'm not certain this is neccesary, as I've come to the same
conclusion as Hal Finney: as long as you've got one (or maybe two)
trustworthy remailers in the chain, you are pretty much okay. Although Jim
Dixon points out that a concerted effort by the TLAs could make even
finding one trustworthy remailer a serious chore. But this is an
implementation problem; we're talking theory here at the moment.]

5) No one entity participating in the remailer net structure should be
able to compromise the security of the net acting alone. For example, An
"evil remai
ler" operating solely for the purpose of compromising the
remailernet shouldn't be fatal. This is a matter of degree to some extent:
if everyone but you is "evil", you're going to be out of luck in just
about any system. But the more robust the infrastructure is, the more evil
participants it can handle before it cracks, the better. The current
remailer net actually fulfills this requirement fairly well, but it's an
important one, and worth noting anyhow. 

Now I think the infrastructure I've proposed that uses a newsgroup, as
well as a pinging mechanism, fulfills all these requirements. But I'm not
going to try to defend it now, instead, what do you all think about those
requirements? Are they all in fact neccesary? Or desirable? Are there any
more that should be added? Can you think of any infrastructure systems
that might fill some or all of them? 





Thread