Re: A stab at the sealer in E
Tue, 9 Nov 1999 10:27:21 -0800

At 09:53 PM 11/8/99 , 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
> and users who consider the untraceability of value. I don't want to blow
> this kind of value elsewhere in the architecture.

Freedom ( 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.