Re: RemailerNet

-----BEGIN PGP SIGNED MESSAGE-----

Quoth Jonathan Rochkind <jrochkin@cs.oberlin.edu>:
>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.]
> 

I have been worrying a lot about these anonymous return addresses. They seem
very vulnerable to attack.

Say I post a message through remailers to Cypherpunks giving one of these
reply blocks. The TLA need only send a flood of known size messages to this
address, and look to see where the pop out of the net of remailers. Even if
all messages were quantized and only reconstructed by the final recipient, the
TLA could send timed bursts of messages which (even with reordering) would 
allow a statistical determination of the recipient.

I think that the solution to this is some sort of hold and forward on demand
system. An anon ID would be posted to Cypherpunks, and that account ID with
a key, sent to the message holder. One would then request for a certain number
of messages or number of kilobytes of messages to be sent to the address
specified by the old sort of remailer block. This message would be signed by the
key, and could indicate remailing to anywhere, even to another hold and forward
location. This prevents the TLA from sending many messages to the final
destination in such a way that they could be used for traffic analysis.

Thoughts?

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBLkmSPVVkk3dax7hlAQGElQP7B14ChmebN2iEBRidpDFm1qrzbDRSE/Eh
WGdcNwhn5wThxCKVaY6OjAgs61xMQPk7XGwO8MjJdZOAXCm9Mqos7wVEFaz5UqUV
7nnOcTHrCdCQcPULFt6mpjAug1KYtkFx+2NXa6PBzNTxkZ9Svh6Hk6mii/5p+dLH
tEW3uihAERo=
=tSI9
-----END PGP SIGNATURE-----

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki@nately.ucsd.edu
PGP 2.3 key available by finger or server.

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche

In message <199408110444.VAA20478@jobe.shell.portal.com>, hfinney@shell.portal.com (Hal Finney) wrote:

>Other ideas have been proposed for this problem.  Chaum suggested
>having a public area where messages for a group of people would arrive;

This is an excellent way of getting around this problem, but it uses
lots of bandwidth.  Another idea I have been interested in is picking
a message up from the middle of a chain.  In other words, your return
address block lists 10 remailers (for example), and you just happen to
run the 7th.  After the message hits your remailer, it continues
through a few more hops and then gets eaten by /dev/null.  Your
remailer, meanwhile, has snarfed a copy of ALL of the traffic running
through it to another machine.  There you manually enter parameters to
use to scan for messages to you.  If the feds come to you and demand
that you perform this process while they monitor it, you enter
a different set of parameters that uncover innocent messages that you
arrange to be occasionally passing through.  If they've traced a
message all the way to the end, they'll know it was to one of the 10
remailer operators in the chain, but several of them are in
inconvenient jurisdictions...  and maybe one of these tap-points was
arranged to start another chain.....

>One problem with anonymous return addresses is that the address changes
>deterministicly as each layer is stripped off.  This allows the message
>to be tracked by introducing copies with different bodies but the same
>ARA (which is why Chaum specified use-once).  Eric Messick proposed a
>system in which the message bodies would be changed at each step by the
>remailers involved.  I don't recall the details, but I think that in order
>to read the message the user had to send it back through those same re-
>mailers after receiving it, to undo the transformations which had been
>done on it.

Not quite that bad.  Another message would have to be sent only if
there was insufficient postage for one of the remailers, and that
remailer decided to deliver it rather than just dropping it.
Otherwise, all of the info necessary to decode the message is known to
the recipient.

>  It was a complicated scheme and we really didn't spend enough
>time on it.

That is certainly true.  I've been trying to figure out how to
subdivide the project so that early implementations can be done
without sacrificing the ability to do the more complex stuff later.

>I view easy-to-use, secure ARA's as an unsolved (and perhaps unsolvable)
>problem.

I don't think they can be unconditionally secure without wasting lots
of bandwidth.  Having one of the links be a wide area broadcast is
very secure, but expensive in bandwidth.  It's all economics...

>Hal Finney

-eric messick

lcottrell@popmail.ucsd.edu (Lance Cottrell) writes:

>Say I post a message through remailers to Cypherpunks giving one of these
>reply blocks. The TLA need only send a flood of known size messages to this
>address, and look to see where the pop out of the net of remailers. Even if
>all messages were quantized and only reconstructed by the final recipient, the
>TLA could send timed bursts of messages which (even with reordering) would 
>allow a statistical determination of the recipient.

>I think that the solution to this is some sort of hold and forward on demand
>system. An anon ID would be posted to Cypherpunks, and that account ID with
>a key, sent to the message holder. One would then request for a certain number
>of messages or number of kilobytes of messages to be sent to the address
>specified by the old sort of remailer block. This message would be signed by the
>key, and could indicate remailing to anywhere, even to another hold and forward
>location. This prevents the TLA from sending many messages to the final
>destination in such a way that they could be used for traffic analysis.

This problem has long been recognized with anonymous reply blocks.  Chaum,
in his original 1981 CACM paper, suggested that anonymous reply blocks
should be use-once in order to prevent variations on this attack.  Of course,
a use-once address is of limited usefulness.

A problem with the maildrop idea is that the wiretappers can presumably
follow the messages to the maildrop.  Then the only question is whether
they would be able to tell when your message came in and requested further
forwarding of the collected messages.  Maybe this could be done securely;
I'm not sure.

Other ideas have been proposed for this problem.  Chaum suggested
having a public area where messages for a group of people would arrive;
everyone downloads all of them but can only read the ones for them.
For  this you would want a "stealthy" encryption envelope which did not
give away any information about the recipient's ID.  Miron Cuperman has
been running such a "message pool" for over a year now.

One problem with anonymous return addresses is that the address changes
deterministicly as each layer is stripped off.  This allows the message
to be tracked by introducing copies with different bodies but the same
ARA (which is why Chaum specified use-once).  Eric Messick proposed a
system in which the message bodies would be changed at each step by the
remailers involved.  I don't recall the details, but I think that in order
to read the message the user had to send it back through those same re-
mailers after receiving it, to undo the transformations which had been
done on it.  It was a complicated scheme and we really didn't spend enough
time on it.

I don't think anyone really trusts (or should trust) the ARA's we can
make now with the remailer network.  An ARA is a sitting duck, a tempting
target for attacks.  With an ordinary remailed message, by the time it
arrives and someone is interested in tracking it, most of the needed infor-
mation is (ideally) gone.  With an ARA you are entrusting your deepest
secret, your True Name, to a few layers of encryption with other people's
keys.  That is not a good feeling.

I view easy-to-use, secure ARA's as an unsolved (and perhaps unsolvable)
problem.

Hal Finney
hfinney@shell.portal.com