1994-08-06 - Re: RemailerNet

Header Data

From: Jonathan Rochkind <jrochkin@cs.oberlin.edu>
To: jdd@aiki.demon.co.uk
Message Hash: 46ad3c2dbbeb4207b17153963d692325e6505b995a73dfab8f2d5f2c9b1c807e
Message ID: <199408051528.LAA18523@cs.oberlin.edu>
Reply To: N/A
UTC Datetime: 1994-08-06 03:44:36 UTC
Raw Date: Fri, 5 Aug 94 20:44:36 PDT

Raw message

From: Jonathan Rochkind <jrochkin@cs.oberlin.edu>
Date: Fri, 5 Aug 94 20:44:36 PDT
To: jdd@aiki.demon.co.uk
Subject: Re:  RemailerNet
Message-ID: <199408051528.LAA18523@cs.oberlin.edu>
MIME-Version: 1.0
Content-Type: text/plain


Part of our disagreement/misunderstanding might be in differing      
conceptions of the form the remailer net should take.
 
> There should be two anonymous IDs, one for sending, one for
> receiving.
 
You seem to be talking about a Julf-style anon system, where the system
knows who you really are. If the system is corrupt, if Julf were an 
NSA agent, then the entire system is compromised and useless. 
I like the cypherpunks remailer concept better, where each link in the chain
only knows the next link in the chain, and security is achieved by
multiple links. If several of the links are actually NSA agents, your security
is reduced, but not compromised completely. If you've got a chain of, say
10 links, even if 7 of them are evil NSA agents, you still can probably retain
your anonymity. Return addresses are accomplished by encrypted  
"resend-to:" blocks. It seems much preferable to have a system where it
isn't neccesary to trust any one net entity completely, as it is in a 
Julf-style anon-ID system. [Of course one could use a combination of both
in communications too, but I wouldn't feel safe unless my anonimity was
safe even if the Finish FBI raided Julf's site.]
 
When looked at with this goal in mind, I think maybe the newsgroup as a method
of passing remailer net information makes a bit more sense. 
 
I don't think the possibility of the newsgroup being spoofed is actually
fatal to the system. Let's examine ways in which it could be attacked:

1)  The Enemy could introduce completely made-up "i'm here" messages, pointing
to non-existent remailers. This doesn't harm anything at all when combined with
a "ping"ing of remailer sites, as I've suggested. (One idea would be just to
periodically mail all your remailers with the resend-to: being yourself, to
make sure they exist, and are forwarding mail at least some of the time).

2) The Enemy could announce his own Evil-remailers to the net. These remailers
would in fact exist, but would do evil things designed to compromise the net.
What could they do? They could publicize all messages they get. Again, as long as
you have 3 or 4 non-evil remailers in your chain, this doesn't really
compromise your anonymity. You can decrease the risk further by only using
remailers whose announced keys were signed by a trusted source. The evil-remailer
could also just drop all communications in the bit bucket. This doesn't
compromise security, but does make the remailer net unusable. By periodically
pinging the remailer sites as I've suggested above, this risk can be minimized.
If you've pinged the site 25 times, and all 25 times the remailer has forwarded
your ping back to you, then odds are that it isn't dropping any messages in the
bitbucket. (remember, the evil-remailer can't tell the difference between your
ping a a normal remailer message, if done correctly.)

3) The Enemy could intercept announcement messages from good remailers, and
replace their public key with his own. He could then intercept all mail to this
good remailer, and read it, and forward it on, or drop it in the bitbucket.
Using web-of-trust for signed remailer keys should help minimize this risk.

4) Denial of service: The enemy could intercept the announcement messages, and
keep them from getting to the newsgroup. This doesn't compromise the security
of the net at all, but is annoying. I can't think of any way to avoid this risk,
but I think it might be acceptable, because it doesn't actually compromise any
security, and would be fairly dificult for the enemy to do for long without
being detected.

5) The enemy could intercept announcement messages from good remailers, and
replace both the public key and address with his own. This is really just a
combination of several of the previous attacks, nothing new.





Thread