1995-01-06 - Re: Remailer Abuse

Header Data

From: jrochkin@cs.oberlin.edu (Jonathan Rochkind)
To: cypherpunks@toad.com
Message Hash: 912db48b7eb1da9410320d2012c3e7249d84e9d22a2e6608188e15102a820c7b
Message ID: <ab33592305021004d062@[132.162.201.201]>
Reply To: N/A
UTC Datetime: 1995-01-06 20:39:26 UTC
Raw Date: Fri, 6 Jan 95 12:39:26 PST

Raw message

From: jrochkin@cs.oberlin.edu (Jonathan Rochkind)
Date: Fri, 6 Jan 95 12:39:26 PST
To: cypherpunks@toad.com
Subject: Re: Remailer Abuse
Message-ID: <ab33592305021004d062@[132.162.201.201]>
MIME-Version: 1.0
Content-Type: text/plain


At 3:12 PM 01/06/95, Russell Nelson wrote:
>   Date: Fri, 6 Jan 1995 14:19:07 -0500
>   From: jrochkin@cs.oberlin.edu (Jonathan Rochkind)
>
>   In a First Virtual payment-scheme remailernet, no matter how many remailers
>   I send my message through, any _one_ operator, together with First Virtual,
>   can burst my anon bubble.
>
>Why?  Why wouldn't the FV remailers use settlements?  At the end of
>the month, everyone settles accounts in re who gets what fraction of
>what.  No logs are needed other than counters.

Oh, you're suggesting that I'd only actually pay the first remailer on my
chain, and at the end of the month he'd pay some of the money I (and
others) paid him to all of the other remailers his transacted with over the
month?  I hadn't thought of that, but now that I do, I can see several
problems arising.

1) The initial remailer has no way of knowing how many subsequent links
there are in the chain, and so doesn't know if I've paid him enough to
reimburse everyone else.  I can easily cheat. He also doesn't know _who_
the subsequent chains are. He can deduct one "stamp" from the amount, and
forward the rest on to the next remailer, and trust them to do the same,
but if I'm cheating there won't be enough to make it to the end of the
chain.  Both of these facts (initial op doens't know how long the chain
will be, or who will be on it) are essential to the security I get from
using anon remailers, so even if they could be "fixed", it would be bad to.


2) This system requies a good deal of cooperation and organization among
remailer operators. They've got to agree to send each other the proper
amount of money, they've got to set up policies for what the proper amount
of money is, they've got to stay in relatively constant contact to keep
everything running smoothly.   In effect, a remailers trade association is
created, and if I want to use any of the remailers in that group, I've got
to use _only_ remailers in that group in my chain.  I'd rather use a chain
of remailers which aren't associated that closely, hopefully don't even
know each other, and possibly some of which only exist for a short period
of time (guerilla remailers, a risk if I'm paying, in that I can't
neccesarily trust them not to steal my money, but if the money I'm paying
is something like $.05 to each remailer, not a real serious risk).
Assuming that there will be some free as well as some charging remailers,
I'd also like to use some of each in my chain.  I see some problems with
the Remailer Trade Association allowing those transactions to happen.
(will they accept incoming mail from a non-affilated remailer, which surely
won't be paying them at the end of the month?  Surely not, which means if I
use any affilated remailers in my chain, no affilated remailers can come
afterwords. So all affilated remailers I'm using have to come before all
non-affiliated remailers, which is an undesirable restriction which could
aid traffic analsysis. If there are several affiliations, things get even
more complicated.)

There are probably other problems too, that I haven't thought of yet.  An
FV-style system doesn't seem to do the trick.  And it isn't an issue of
certain sacrifices you have to make in order to set up for-pay remailers,
as a Chaum digicash based for-pay remailer system would work admirably, and
none of my objections would apply to it.







Thread