[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I just realized something. There exist at least two deployed "real-time"
mixnets which have very low latency (low enough to do web surfing or
1. onion routing - version 1 is running, version 2 almost out
2. ZKS Freedom (http://www.zks.net)
these use TCP/IP as a transport protocol. We could use them to
implement our system with very low latency.
EXCEPT I do not think either of them offers reply blocks for their TCP/IP
based service. I'm pretty sure Freedom does not, and I am checking up
on Onion Routing.
Without reply blocks, servers can't have persistent identities. If it is
true that these services don't support pseudonymous TCP/IP at the moment,
then it seems to me we have at least these alternatives :
1. Hack system to provide reply blocks and distribute ourselves.
This is possible with onion routing (they'll give us code).
Not possible with ZKS Freedom.
It's questionable how much penetration we'll get.
2. Convince authors to add reply blocks for TCP/IP.
Your guess as good as mine as to whether this would work.
3. Create protocol whereby servers do trades on a 3rd "meeting" server
whose IP address is known.
* Server A opens anonymous connection to known server
* Server B opens anonymous connection to known server
* Server A and Server B matched up by known server
(maybe by looking at what they want to trade)
* Trade executes.
Now the known server is a point of attack, even though it
does not hold any data itself. This was Napster's model!
The upside is that we no longer have to worry about an
adversary hammering servers to find out what their
trading preferences are. We may still want to have
persistent server IDs of some kind - both for our trust
system and to prevent man in the middle attacks. So
if the adversary operates the "meeting" server, he might
be able to link servers to their preferences. We would
want to reduce the chance of this by having many meeting
4. Forget TCP/IP mixnets and go to Mixmaster.
Mixmaster has reply blocks, so servers can have persistent
identity and can be contacted.
Cost : higher latency. Some example stats are at
Note that the lowest latencies on that chart are 8, 15, and 16
We will want to design a program to test latency for
our protocol. After we know roughly how many messages we
need for our protocol, we can run test exchanges through Mixmaster
for a week or longer to see what the latency looks like.