A simpler way to model directory services (and why it might fail)

["Thomas J. Boschloo" <t.j.boschloo@hccnet.nl>]

The way I envisioned the directory servers is that of the stats we have now for mixmaster type II remailers, but with signatures added. I will also try to make it somewhat distributed so there will be no controlling entity that might be replaced by ill-willed organisations or individuals.

In mixmaster the stats take the form of:
name 3245345633 87%

These stats might look different from a different directory server's perspective as might the percentage of uptime, so once such an entry is signed by a single directory server, an additional entry must be made for every other directory server. If these signatures (with a time stamp) are distributed to other directory servers however, they could be ordered deterministically by e.g. sorting on the value of the signature.

The client would retrieve the list from *all* servers (which grows quadratic in data load with the number of directory servers). In this list it can compare the signatures to the same signatures on other lists crafted by other directory servers. A well coded client can probably derive all sorts of stats and data on this signed list. IOW, the client does the final calculation on the state of the mix network.

If the lists are retrieved in a deterministic way, perhaps the *all* requirement could be dropped. The client would just download from all servers in a certain order (e.g. sorted by the hash of the IP + current date), and stop when the user presses a stop-button in the software.



Furthermore, mixmaster stats have broken links (from the viewpoint of the stats generator). These, together with a hash of the key of the current day (which could be retrieved from the mixminion mix itself to keep the amount data more compact, keys seem very large to me), would be stored only once for each mix node. Of course, for key retrieval also *all* mixes should be pinged in a deterministic order.


So, this protocol would be easier to understand (I just looked inside a dictionary and couldn't find the meaning of the word 'quorum' e.g., it also isn't in the terminology list in the directory server draft document and somehow I believe the system hasn't yet proven itself in a deployed system like mixmaster II).


There is one other design issue I would try to look into, and that is of making every mix node a directory server and retrieving stats info by the nyms mixminion will allow. That is how I would do things in the TLBP protocol <home.hccnet.nl/t.j.boschloo/TLBP>, if only I could find a way to solve my user-tagging-by-unique-remailer-key attack :-((( The downside to having all mix nodes be directory services is that it allows two pieces of software on the server to attack and it will double the code base running on mix nodes :-(

Good luck on Mixminion, I think it is better than my TLBP could ever be for now. It is just very hard to understand for my simple brains :-(((

Regards,
Thomas J.

(P.S. Found Quorum in Oxford Dict: number of persons who must, by the rules, be present at a meeting (of a committee, etc) before its proceedings can have authority. Sounds a lot like split pgp keys somehow).
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/