"Mark S. Miller" wrote:
> 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?
I think the basic requirement is that it forward data properly and not disrupt the connection. If it failed to do that, the parties should be able to detect it (e.g. by timing out) and go meet somewhere else. The forwarder might also attempt to introduce traffic patterns and track the bump through the network in order to discover the anonymous parties' locations, but the mix-net as a whole must defend against this attack anyway.
> Might our VLS serve the role of the unobscured 3rd party in your
> protocol, allowing Alice, Bob, and Carol to remain obscured?
That might work, however it would be very onerous for the VLS to forward all that traffic (all anonymous object communications would flow through it). Alice, Bob and Carol would also need to know trustworthy (encryption-capable) public keys of a number of VLSes in advance, since they effectively source-route their communications through the mix. They need to inject dummy cover traffic too, which the VLSs would have to forward to one another. This is all very compute and bandwidth intensive for the VLS--plus there are DOS issues since anonymous objects can poke away at the VLS without fear of identification (e.g. they could flood it). Anyway, you probably want to keep any mixing functionality logically distinct from the VLS, even if they would run on the same box--for example, if an E user already had a suitable anonymity infrastructure at the IP level then they could just run your current protocol over that, and not bother with any of this.
> >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.
The socket interface is a nice-to-have feature really. In the first instance I want to build a library of anonymous IPC primitives, which will most likely have a means of obtaining java OutputStreams and InputStreams in order to read and write to them. Anything built on sockets should not be too painful to move to that--however I do expect serious performance and bandwidth hits. (It remains to be seen just how bad, I am going to simulate a few possible schemes to see how they behave. I would like to get decent performance, but for chat it's not all that important.)
Incidentally, thinking of these connections as IPC primitives makes me
wonder if capabilities could be used to access control them. There is
obviously a chicken-and-egg thing here, but consider that Alice and Bob
have met before and want to communicate while obscuring their location.
They build sender-anonymous pipes to some previously agreed rendezvous
point R in the network. Now, in the literature on this there is a notion
of an "RTA" (return to anonymous) structure, which allows reply messages
to flow to an anonymous sender. (This sort of thing is used by
cypherpunk remailers, for example, to allow replies to anonymous mail. I
think of it as a sort of mailbox strung out at the end of an untraceable
OK, suppose Bob wants only Alice to have write access to the RTA pipe,
and is willing to trust R to enforce this. Is there anything in E
(ignoring communications issues for the moment) which allows Bob to give
Alice this capability, and allows R to check for it, while
OK, suppose Bob wants only Alice to have write access to the RTA pipe, and is willing to trust R to enforce this. Is there anything in E (ignoring communications issues for the moment) which allows Bob to give Alice this capability, and allows R to check for it, whilealso preventing Alice from giving write access to Carol? Failing this, if Carol gets write access, can Bob determine who gave it to her? Lastly, supposing in a later (or simultaneous) communication a different rendezvous point R2 is used. Ideally R should not have write access to the RTA on R2, even if it is able to perform the capability check. I suppose the basic questions here are if it is possible to divorce E's capabilities from its communications system (e.g. can I simply email someone a capability?), and if there are any delegation control features. I envisage that the endpoints will all have DSS and DH keys, if that is any help, but they will be distinct from the nyms they use for application data.
> 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
Yes, except I think there is a subtle issue in the case of anonymous communication between total strangers (no prior reputation for each other's keys). I would argue that for such parties end-to-end encryption is of very limited value. This is because if you really don't know who/where is receiving your messages, you may as well assume your worst enemy is receiving them. Ditto for the sender side, you may as well assume your worst enemy is injecting the messages in the first place rather than worry about him acting as MITM. (On the other hand, there is a safety net aspect to doing the end-to-end thing anyhow, just in case the other party is not in fact your adversary. In other words, for communication between total strangers anonymity is primary and conventional privacy & integrity are only important in case anonymity fails.)
In the case where the two parties do have some prior reputation with each other, then I believe you do need end-to-end protection to preserve that and defend against MITM. In this case the two parties will "know each other" in some sense (so authentication means something), but they just won't know each other's location. (i.e. "Hi it's Bob, but I'm not telling you where I'm calling from").
> You may be interested in a project Marc Stiegler is currently working on,
> SecureIt-EChat -- no mixing, blinding, buddy list, or multi-way chat
> rooms; but a secure (secrecy, authenticated, integrity) point-to-point chat
> built in a *tiny* amount of E code. In its current form it's intended, not
> so much as a serious app (though it's quite usable), but as a demonstration
> of how easily you can build secure distributed apps on a distributed
> capability language. He's about to use it in a course he's teaching, and
> expects to open source it at his site fairly soon.
Excellent, I would love to get a copy of that.