At 03:23 PM 2/10/99 , Frank O'Dwyer wrote:
>Obscuring both ends of a connection is possible but more complex. I
>think this would require two parties to initiate a connection to a 3rd
>party, and splice those connections together.
What trust, if any, would need to be invested in such a third party? Our protocol already assumes a third party called a Vat Location Service (VLS), and the E source distribution contains slightly stale code for such a service that we hope to resurrect soon. We had always hoped that the Vat-locating part of the protocol might eventually grow to enable a mixing network. Might our VLS serve the role of the unobscured 3rd party in your protocol, allowing Alice, Bob, and Carol to remain obscured?
VLS protocol description:
A Vat has a long-lived identity, denoted by its VatID (fingerprint of its public key). A Vat incarnation is a process running on some machine and listening at a particular TCP/IP. A Vat may have no more than one incarnation at a time, but overall a Vat lives through a series of incarnations, each of which may listen on a different TCP/IP port.
A Vat exports references to objects it hosts (but only according to capability discipline). An exported reference must provide the ability to send messages to the object they designate, and therefore to the Vat hosting this object. But what if this Vat has been reincarnated in the meantime? It would have the same VatID, but be listening on a different TCP/IP port? How can it be found?
We intend to run a set of well known Vat Location Servers at well known stable TCP/IP addresses. (And we already have several volunteers sites.) A Vat is configured to know a set of these as its "Search Path". When a Vat is [re]incarnated, it registers itself with all the VLSs on its Search Path that it can contact. (And it re-registers once an hour) Note: The VLS currently accepts unauthenticated registration. This will be fixed.
When a Vat exports a reference to an object it hosts, such as Carol, this reference contains this Search Path. When the receiver of a reference, such as Bob, wishes to contact Carol, Bob's Vat does a breath-first search for Carol starting with all the TCP/IP addresses in Carol's reference's Search Path. The search is breadth-first so malicious VLSs cannot prevent Bob from finding Carol as long as any of the paths starting from one of Carol's VLSs successfully leads to Carol.
>I don't think a
>transparent socket interface to that would be easy, but something like
>sockets but requiring a few extra method calls might be possible.
We don't require transparent operation through the existing socket interface, but might one define an interface through which one could use either the existing socket library or your library? In any case, I don't think this is a big deal.
>It
>might be easier in your case to have well-known (or discovered?) proxy
>objects which existed to provide the rendezvous point and the forwarding
>functionality, using half-anonymous connections as a basis. The 3rd
>party would be in a position to inspect content, though, so if that's a
>problem another layer of encryption is needed, and some higher level
>means of authenticating the endpoints.
Pluribus requires and supplies an end-to-end encrypted and authenticated data pipe. If intermediate data-forwarding proxies are in the way, as in http://www.erights.org/to-be-sorted/DataCommThruFirewalls.html they cannot see or disrupt any of the content. Mixing would seem to require hop-to-hop encryption as well, resulting in a doubly encrypted stream. Any system would seem to require this -- the security resulting from the end-to-end encryption is far more important than that resulting from the hop-to-hop encryption.
>In the half-anonymous case, initiators would need to know the location
>of responders--so depending on how your introduction is done, somebody
>needs to reveal their location. In the fully anonymous case, the
>location of the 3rd party needs to be known, but the other partipants
>locations remain hidden.
This would seem to fit the role of VLSs.
>Yes, it would be interesting from my angle too. I think I could use E
>for my project if it hid location.
TCQ by any chance? That'd be great!
Cheers, --MarkM