On Sun, 2003-02-16 at 16:22, Thomas J. Boschloo wrote: > Sorry if I haven't introduced myself, but I am working on a replacement > system for Mixmaster (Lance Cotrell) and Nym (Frans Kaashoek) myself. Greetings, Thomas! > In short, I use these primitives to archive my goals: [...] Sounds like an interesting direction. I look forward to reading your protocol specification when you've got it more finalized. (Say, at the byte level. The devil's in the details, they say. ;) As you're doubtlessly aware, you're facing some trade-offs, and the community can always use more experience from deployed systems. (In fact, if you come up with a hashcash system that actually prevents flooding and DoS in the wild, I'd be quite glad. There are some tricky problems in that area that need solving.) [...] > So that is who I am. Just a drop out from computer science in Amsterdam > somewhere.. (I am still trying to prove myself to the world, so forgive my > arogance and relentless violence at times, it's 'psychological', working on > that). Glad to hear it. Goodwill among protocol designers and implementers can only help the remailer community. > HERE is my question to the group; > o PGP has WoT > o S/MIME has TTP > > I think these things are very basic ingredients to any type of public key > communications, so what does Mixminion do to solve a Key Tagging Attack as > I will call it here? I'm not 100% sure what you mean by the Key Tagging Attack. It sounds like you're describing a situation where a user doesn't get a server's official key (K_good), but gets something else (K_bad) instead. An attacker can exploit this situation in two ways: (1) If the attacker is not the server, the attacker can now read the user's traffic to the server when he could not before. (2) In any case, messages sent with K_bad will be distinguishable from messages sent with K_good; the attacker can tell which messages through the server were sent by the user who has K_bad. Our solution to this is to have directory servers, as described in the spec and the paper. These servers keep a list of active Type III nodes, and act as pingers to check on node performance. Once a day, the servers agree on a list of recommended nodes -- nodes which they believe will be good for at least the next 24 hours -- and publish a list of those nodes, their keys, and their capabilities. This list is signed by *all* the directory servers. If any directory server signs a different list, or a list with different keys, users will be able to tell that directory server is misbehaving. The directory servers generate only a single directory, so every user will have the same official set of servers and keys. In order to deceive any the users, a majority of the directory servers must be corrupted or compromised. This idea is described and justified more fully in the specification and the design paper. (If users want to use servers not on the directory, or to avoid servers on the directory, they can tell their clients to do so at some risk to their anonymity.) Of course, you probably noticed that I waved my hands around two important points above: (1) How do the directory servers "agree" on a directory? (2) How do the directory servers even agree about who is a legitimate directory server? This is an active area of research, and we don't have a perfect solution. Roger floated a proposal in January (see http://archives.seul.org/mixminion/dev/Jan-2003/msg00015.html ), and there have been a few more handwritten and verbal designs since then. None has been perfect, but I think we're converging on something 'good enough for now'. We'll probably have a "good enough" design by mid-March. (In the code as it stands today, there is only a single directory server, run manually by me. Clearly, nearly anything would be an improvement.) I hope this answers your question. Best wishes, -- Nick Mathewson <nickm@freehaven.net>
Attachment:
signature.asc
Description: This is a digitally signed message part