NODE 912db48bRe: Remailer Abuse
jrochkin@cs.oberlin.edu (Jonathan Rochkind)Fri, 6 Jan 95 12:39:26 PST
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.
NODE 64d06157Re: Remailer Abuse
roy@cybrspc.mn.org (Roy M. Silvernail)Fri, 6 Jan 95 18:07:47 PST
-----BEGIN PGP SIGNED MESSAGE-----
In list.cypherpunks, jrochkin@cs.oberlin.edu writes:
> At 3:12 PM 01/06/95, Russell Nelson wrote:
>>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.
This might not be as much of a problem as you think. Given that there
will likely be a mixture of free and pay remailers, and that a given
message may chain through one or more of either type, why not place the
stamp for each pay remailer inside the encrypted sub-packet which that
mailer will receive?
Think of each remailer as an independant post office. For each pay
remailer, you need one stamp. Ideally, each stamp would be a bit less
expensive, but since remailers don't need to share their revenue, that
shouldn't be much problem. An intelligent chainer (Chain++, maybe?)
could keep track of your postage and put the stamps in the proper inner
envelopes.
This would work best if all the pay remailers accepted a common brand of
stamp.
- --
Roy M. Silvernail [ ] roy@cybrspc.mn.org
PGP public key available by mail
echo /get /pub/pubkey.asc | mail file-request@cybrspc.mn.org
These are, of course, my opinions (and my machines)
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBLw3VrBvikii9febJAQFozwQAkYUBp9Uc5Lbmc4udL7hwTgBY9I+yfKdy
wvW5xl4TeTeJLAS95yHOyiEKP/nVsjfknr4gx1mOrFZYOxkNRJa78YeQ8tDAVq7Y
S1UQrYqHJAoi/AKdypufIaeu8iF/1pVbYLDdIbbQm3bxlUZHwciYJUvnneRjFbhA
BJB+ruqzEMs=
=CGFS
-----END PGP SIGNATURE-----