A stab at the sealer in E

hal@finney.org hal@finney.org
Tue, 9 Nov 1999 10:27:21 -0800

At 09:53 PM 11/8/99 , hal@finney.org wrote:
>Also, your Vat to Vat protocol does not try to camouflage traffic
>patterns; although the data is encrypted, an eavesdropper can determine
>when communications occur, and how much data is sent.

MarkM replies:
>  From talking to Ian Goldberg, I believe Pluribus would be perfectly happy to 
> live on top of the Freedom network.  Pluribus does nothing for 
> untraceability.  Freedom (from our point of view) does nothing but 
> untraceability.  These seem like orthogonal composable parts of the puzzle.  
> Our standard high security scenario for analyzing possible risk should 
> therefore probably be Pluribus on Freedom (assuming ZKS open sources it), 
> and users who consider the untraceability of value.  I don't want to blow 
> this kind of value elsewhere in the architecture.

Freedom (http://www.zeroknowledge.com/) does try to hide traffic patterns
by padding the links with dummy traffic so there is always data flowing.
However, I think this may be just on the internal links, and not necessary
on the links to end users, because that would be somewhat costly and
annoying in some circumstances.  Their literature is not completely
clear about this, so I'm not sure at this point whether Freedom would
perfectly camouflage your traffic patterns.

However I see this as a relatively minor leak of information; most crypto
protocols which claim to provide high levels of privacy and security
don't even consider this issue.  On the other hand when you are talking
about very highly secure operating systems they do pay a lot of attention
to timing issues and other ways of leaking information.

I'm not sure whether Pluribus would run on top of Freedom without some
work.  There are a couple of issues that I see.  (A caveat: I am not
all that familiar with Freedom, and I base my comments on their white
paper which is a year or two old.)

The first is that Freedom supplies application specific filters to
check the outgoing data stream for privacy leaks.  IP packet headers
contain the source IP address, and of course the system strips those out.
However some protocols include this kind of information within the packet
bodies as well, and Freedom has special software to check for this.
I imagine that Pluribus must send the source IP address at least during
its handshake protocol, and possibly at later times as well.  This would
need to be changed somehow.

The way Freedom works, instead of Alice's machine connecting directly to
Carol's, she connects to the Freedom network, which sets up a path through
~3 machines.  The last one is called the "wormhole" and it connects
to Carol.  Any place Carol would normally see Alice's IP address, the
system must be set up so that she instead sees the wormhole's.  The IP
address of the wormhole is known to Alice's machine, so her software can
make the substitution (which is what the application-specific Freedom
filters do, presumably).  Pluribus would have to be changed to do this
(or equivalently a Freedom proxy would need to be designed).

The other thing that might go wrong is if Carol passes to Bob a pointer
to an object on Alice's machine.  This would come down to giving him
the IP address Carol knows as a reference to Alice.  However, this is
actually the IP address of the wormhole machine.

The wormhole machine has been forwarding packets from Carol back to Alice.
It knows to do this because it knows that it has a connection from the
Freedom network outward to Carol.  When it receives a packet from Carol,
it looks up her address on the list of connections it knows about,
and this tells how to handle it so it gets back to Alice eventually.
(The wormhole doesn't know Alice's address, but it knows how to send
the packet into the rest of the network so it will get there.)

Now if Carol passes Alice's object to Bob, he receives the IP address
of the wormhole.  When he tries to connect to Alice, the packet goes to
the wormhole.  However, the wormhole won't know what to do with it.  It
only knows how to handle packets from Carol's machine, because it has a
table of all the existing connections.  Bob isn't in that table.  So it
won't know that the packet is supposed to be handled by the same routing
rules as packets from Carol's machine, hence it won't get back to Alice.

There is also the issue, which I saw in your mailing list archives, that
Freedom has only one-sided anonymity.  The client's true address is hidden
from the server, but not vice versa.  The client must know the server's
address in order to connect.  In E, where there is symmetry, it would
be necessary to have an intermediary running at a known address which
would pair up clients who wanted to talk while each remaining anonymous.
I haven't given this enough thought to judge whether this could be done
transparently or whether Pluribus would have to be modified to support it.

> Btw, an I using the right terminology?  I would say that E/Pluribus provides 
> pseudonymity & bearer rights, Freedom provides untraceability, and Blinding 
> provides unlinkability.  Robust privacy benefits from having all three 
> together.

I will write more about this in another message.