Scalable Distributed Security with Bearer Certificates

Frank O'Dwyer
Fri, 12 Feb 1999 12:10:50 +0000

"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

> 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 also
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
> 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.

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

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.

Frank O'Dwyer.