[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Sending unique/recogniziable remailer keys to suspect mixminion users

On Sun, 10 Aug 2003 11:34:50 -0400, Nick Mathewson <nickm@freehaven.net> wrote:


On Sun, 2003-08-10 at 08:53, Thomas J. Boschloo wrote:

Hello group, I wrote my own 'mixminion' protocol in February 2003
(IIRC), and a big problem that I couldn't solve was key-distribution
from the remailer to the user.

Hello again.  (If it's not too much to ask, please call the protocol you
design something different from 'Mixminion'.  I don't want to confuse
users.)

Sorry, 'The Lost Biro Project' AKA TLBP. You have good memory ;-) My protocol is widly different from Mixminion (like distributed, no directory servers).


[...]

For my protocol this is fatal. But it also seems to apply to protocols
like Mixminion (I haven't read the paper recently, sorry) en
Mixmaster. A suspect Mixmaster user could be given a special key upon
key request. Then, upon faulty decryption with the 'normal' remailer
key, every planted 'suspect' key is tried and once it decrypts
succesfully with one of these 'planted' keys, the whole chain up to
this point of decryption is compromised.

This is one of the reasons that Type III currently doesn't support key
retrieval from individual servers.  Instead, clients retrieve trees from
directory servers.

I suppose I could call this the 'penet.fi' way to distribute your 'autorized/signed' keys. Basically the directory server functions as an anonimizing hop between the mixminion servers and the user. Maybe it would be possible to distribute keys the 'mixminion' way, but there would likely be some problems like you have when programming with recursion (using the same function call inside the same function call). I am just trying to be creative here, not sure if it would actually be possible, you guys are the experts on mixminion!


You asked a very similar question in February, when you said:

Oh, I totally forgot about that. Must have been around the time my laptop broke down since that message is not listed in my current mailing program (my reply to it is however, sorry that it was such a lenghty reply, I tend to get carried away at times).


> 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?

and I outlined Mixminion's planned approach in
http://archives.seul.org/mixminion/dev/Feb-2003/msg00018.html :
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.
(The message in question goes into more detail.  Unfortunately, the
agreement protocol is still in the works, but I think we're getting
closer and closer.)

I reread some of this, plus the remark that there would be a more finalized version in March. I stopped reading this list about the 26th of Februari or some time sooner and I am now in the process of reading up on some of it (I really miss my laptop computer for this).

I would like to share some thoughts I have myself on 'directory servers in mixminion'. Like, can I call this (in addition to the penet.fi approach which twarts 'key tagging' attacks) the 'verisign' approach on trust? I like to compare it to verisign because the directory servers validate the remailer keys. The only difference is that multiple directory servers must all sign the same remailer keys.

I wonder what would happen if a (malicious) mixminion server refuses to give its keys to all but a select group of directory servers it can control. Also, a (good) mixminion server might not send its key to the directory servers because an attacker disrupts the connections to those directory servers (or controls the directory server all together!), slowly killing the mixminion server off :-( By killing off mixminion server after mixminion server the whole network could be controled in time by misusing the directory service protocol!

In other words, directory servers could compete for popularity and kill off non-controlled mixminion servers by:
- not listing them and blaming it on something else (like bad connections, lousy administrator/provider)
- listing owned mixminion servers (and loads of them), which do not give stats to non-controlled directory services.

This is dangerous because:
- he who controls the directory services, also controls which keys are distributed. iow, a 'special' user gets a 'special' key, signed by all directory services he uses, which will result in a message arriving at a certain mixminion server that can be traced back to the user. The user will just notice that his message did not arrive. Of course, this user could whistle-blow about these directory servers, but I fear the discussion that will follow then (after all, who trusts an anonymous or pseudonymious person they do not know?), especially then these rouge directory services have gained a firm foothold in the groups that support them.
- it is generally bad if well maintained and trustworthy mixminion servers disappear because of a possible problem with the directory services, which do not list these servers as explained above.

IMHO, the mixminion servers should also be directory services somehow so that each mixminion server has equal weight (maybe they could distribute old stats somehow which they signed for clients to check). And maybe they could somehow be distributed in nature. But that of course is just the bias I have because I still want to get my own tlbp protocol working that way some day. It is on-going research for me. In my protocol the world is a remailer server, stats server, etc. all at once (even for clients, but they can set their hashcash requirements for 128+ bits so they won't be actually used if they don't want to be).

Friendly regards,
Thomas
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/