Thanks Frank, this sounds wonderful. Two issues:
At 08:39 AM 2/10/99 , Frank O'Dwyer wrote:
>... To begin with this will only provide
>datagram communication (although the underlying comms will be TCP),
>... However a stream protocol could in principle be built atop this.
E requires such a stream protocol. Post handshake, we run an SSL-like secure data pipe on top of it. See "Pluribus Protocol: Data Comm Layer" at http://www.erights.org/elib/index.html
>functionality could be wrapped in a SOCKS or plug-gw style proxy,
>avoiding the need to modify applications (but requiring some way of
>advertising and learning of mix participants).
The essential step of capability computation, and therefore the central problem for a secure protocol for E to solve, is the three party handoff, explained in http://www.erights.org/elib/elibmanual.pdf
In order for your mix to appear to be a compatible socket library, I take it that Alice would know Bob and Carol by what appear to Alice to be Bob and Carol's TCP/IP addresses? In you system, how would Alice introduce Bob to Carol? If Alice tells Bob the alleged TCP/IP address by which Alice knows Carol, can Bob contact Carol by using this address? Don't worry about authenticating that it actually is Carol once the contact is made -- we got that one covered. I'm concerned about routing.
If, pre-introduction, none of the three parties could determine the location of the other two, would this still be true post-introduction? How does your system find a Bob-Carol route? And what if Firewalls are in the way? (E doesn't yet route through Firewalls, but see http://www.erights.org/to-be-sorted/DataCommThruFirewalls.html for a plan to handle the bad cases.)
Is your open source license compatible with Mozilla? Most are, including LGPL, but GPL is not.
If it works out, it would be truly superbly wonderful to have a working mix underneath Pluribus.