Re: [freehaven-dev] RFC: Design for an anonymous network [multiple connections to B]

[Roger Dingledine <arma@mit.edu>]

On Mon, Mar 05, 2001 at 01:22:16PM -0500, Michael J Freedman wrote:
> It is *critical* that PK_net and PK_fs are never correlated.
> 
> The ROUTE_CREATE_PACKET that Alice sends to Bob includes a connection create
> request, naming Bob via PK_fs_B.
> 
> The Meeting place then "joins" its virtual circuits from (A --> M) and (B -->
> M).  M sends A in ROUTE_CREATE_RESPONSE (K_d_4, K_d_3, K_B).  M sends B in
> ROUTE_CREATE_REQUEST (K_2_d, K_1_d, K_A).  [Obviously, I'm making up all these
> names as I go along.]
 
Ok. So here's the big problem that I see so far.

Bob just got his connection "claimed" by Alice. He didn't invite Alice
to start talking to him, and he doesn't even know it's Alice at this
point. But now M doesn't have much to do when some A2 shows up and says
"Hey, I want to talk to PK_fs_B."

This is a hard problem. One solution is to make use of the "rendezvous
point" idea that we had been talking about earlier. Basically, use the
meeting places to locate people and tell them you want to talk, and to
negotiate where to talk. Thus A would tell M "please inform PK_fs_B that
Blob" where Blob = E_B("I'm A, meet me on IP x, the secret handshake
is y").  Then both A and B would go to x (as above), and each ask x
"please connect me to the guy with the secret handshake y." (y is some
random number. A and B would then authenticate through PK means once
x had connected them, to make sure x wasn't playing dirty.)

This is a neat solution because it allows B to choose the connections
he accepts and the frequency of acceptance; because the traffic doesn't
all go over this one (or several) poor meeting server; and because x
doesn't have the foggiest about the PK_fs's of the two parties using it.

This is non-neat because it requires yet another protocol; and because it
requires A and B to build more outgoing connections through the anon-net
-- one per connection could add up pretty quickly, both from a computation
perspective and a traffic analysis intersection attack perspective.

An alternative is for M to multiplex the connections to B. Does that
suck as much as I think it does?

--Roger