[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open Questions with Mixminion design -> trusting remailer keys, how?



On 17 Feb 2003 00:05:37 -0500, Nick Mathewson <nickm@freehaven.net> wrote:

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 Cottrell) and Nym (Frans Kaashoek) myself.
Greetings, Thomas!
Hey, I feel at home already :-) This is my first mailing list however (that I have actually posted to that is), I hear a lot of complaints about newsgroups from people who have been in them IRL. Thanks for your kindness :-)

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.)
Well, I see it this way. I can never stop an attacker from disrupting the inline to the server, effectively taking it out. When your enemy is the TLA (NSA, FBI, AIVD, etc), you don't stand much hope at winning. If your enemy is your ISP, you are also done for (xganon was driven of their .no domain e.g. because of a new TOS by the top-level domain provider).

Less serious attackers are Script-Kiddies with worms like SQL-Slammer that target your site in their destructive payload or Script-Kiddies that compromise a thousand machines within a few days with <www.bo2k.com> to mount a DDoS attack. These attacks will only take your site out for a few days or weeks and allow the administrator to complain or mount a counterattack to the compromised machines (but that would unfortunately be highly illegal in most countries these days).

So when you are not trying to defend yourself against any of the above the situation becomes a lot more transperant. In my protocol (when it is ready) , I will probably try to put the hashcash at the top of each mail message. Maybe even in the headers, but that didn't work out in Type I remailers so I had better not do this perhaps. On the other hand, I am also thinking about an anonymous proxy like that GnuPG thing for Windows (haven't tried to install it yet though). In this case less paranoid users will be able to send and retrieve messages through Outlook Express 6, which will make remailers and encryption highly succesful! (and vulnerable, I know OE is a very bad example as it the platform it mainly runs on).

Let my try from my mind:

[hashcash for using SMTP server, ?collides on public key retrieved from remailer?]
[RSA/ECC encrypted AES-192 key + 64 IV]
[encrypted data]
[garbage till next 4096 byte boundery (that is the cluster size on FAT-32 file-systems, the size of an intel 386 memory page file, etc)]

Then inside this encrypted data:

[user RSA/ECC public key]
[hashcash for storage on remailer server for up to two weeks on average (five days sending, five days receiving, few days latency, reordering and replying depending on remailer load]
[length field of what comes after this]
[minimal RFC 822 headers (From, Reply-To, ordered)]
[message body in fixed format (kind of ASCII-Armor in case of in-between hops)]
[signature on everything to proof ownership of secret key from user (also used in reply-blocks to proof ownership of 'remailer seed')]
[garbage or 4096 byte (octet) boundery]

Hope that is it :-) I forgot about the IV last time, which is kind of serious I think.

[...]
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.
<ot>
Well, I tend to get disappointed at times, which kind of makes a person less 'goodwilling' :-( It is just hard to find people who both have the time and expertise to know about these kinds of things and discuss them with yourself. I just think I finally found a place where these kinds of things can get discussed without getting trashed like in 'some' groups on usenet. This is not important to the protocol however at all! I just found myself thinking more about 'Form' than 'Content' over the last few years. Though using Form to say ignorant things is kind of fun I have experienced ;-) [but I haven't made many friends doing this I must add, people usually are prepared the second time you pull such a prank, it is kind of social engineering I figure, yet there are few people not willing to talk to me anymore these days, though their number rises slighly each month (made fun of a director of a dutch Electronic Highway Platform in www.automatiseringsgids.nl a few issues back, sorry, I get dragged off topic easily and I must admit I kind of like talking about topics that interest me, I will try to concentrate on mixminion again from now on)].
</ot>

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.
In case of (1), all remailer traffic becomes transperant to the attacker. E.g. Carnivore could probably do this with some small modifications.

In case of (2), it is actually much, much worse in my protocol I discovered a few weeks in the pipe-line. In my protocol, because of single key use, the actually user who requested this key can be identified by the attacker and matched up with the (single) message he sends to the (compromised) key. Thus even the last hop in a mix chain could compromise the anonimity of the user using that remailer as a last hop. I don't think I have read about this before in Chaums paper or Lance's FAQ or anything. This attack, can however be extended to mixmaster remailers at a price (coding + controlling *all* stats sources of the user, which should be trivial for the TLA if they control the ISP of the user, a firewall will catch the users behaviour (+ used client software if he hadn't downloaded that yet) after which 'rotating' the keys for the (suspected) last hop (which should have good stats, good extensions like From line support, non-middle, etc) should be childsplay. The user wouldn't know his identity had been compromised before it was too late. Even code signing wouldn't help here.

I am not sure on how to fix it, but I have an idea that might help do so (called 'The Elephants Trunk' or 'Slurf' in dutch; in it, important keys for stronger anonimity are retrieved through less secure tlbp mixes themselves). This solution is not perfect however and it will be very expensive in both hashcash and network traffic and time itself.

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 wouldn't work for my protocol. I think this solution is very elegant (though my question on how to trust even a single directory server list signature remains). A big problem I see is however in how easy the 'government' (wether democratic or of some other form) could take down these servers or block them country wide (or at the ISP level for 'suspected terrorists' if torture is not recommended by the local TLA).

I have spend a lot of time and came up recently with this idea for my key distribution protocol. I figured just !today! that in case I trigger reply- blocks when a remailer is cleaning up their public user key pools, they could just as well send some STATS along with this message. The beauty of this for me is that this also solves the stats retrieval problem for me! I won't be needing any remailer-stats commands at all (though they could be published like they are now). /And/ I guess the TLA won't be able to tweak them for every remailer.

I have been thinking about my stats specification today (non-binary however still). I think it should have anything it the TLA will have access to, as I hope to aspire to twarting them as I see Intelligence Agencies as the biggest treat to our democracies these days because it seems to me that only a single person controls them (in Holland a politician died less then a decade ago, she was very healthy according to friends at the time and she had been chosen to clean up our secret service a bit or something, could be a coincidence though, but I have other reasons to distrust secret services everywhere in the world (mostly through what I see on documentaries about them, like the Appolo 11 flight and Krubic e.g., sorry I am getting <ot> again!)).

Well, this should be in the stats:

[in messages]
[out messages]
[histogram of the sizes of these messages]
[histogram of the hashcash payed in these messages]
[count of all messages to all other remailers (per remailer)]
[count of all messages from all other remailers (per remailer)]
[top ten non-remailer IP addresses (to allow usenet groups to catch the kind of flooder we are experiencing in APA-S still)]
[current hashcash costs at that remailer for new public user keys and for retrieving public server keys]

What the client software of the user should be able to generate from this is a graph of all remailers he knows of. Note that these remailer list grow from what I have included in the stats above :-)). So remailers servers don't even need to announce themselves anymore! Nor need they update they keys (and maybe capabilities, but I think I will put them in with the key requests, since high loads should make key pairs from the remailer more expensive to retrieve, up till the full collision size! (in which case the remailer should be considered 'down').

So a graphical representation of all tlbp remailer servers, the connections between them and the loads on those connections. Only non-abusive, low- profile home users should not be listed in these stats. They will be counted in a special node called 'others' with the right figure for them.

Of course, dropped messages is the most interesting figure in the stats.

I have some other ideas on the 'ideal' tlbp client (like an address book, highlighted nodes for which the user has server keys and highlighted nodes for servers at which the user still has public keys + their estimated remaining time on that remailer).

So I am quite a way on the road towards my protocol. I have been thinking about these kinds of things on and off since 1998 I think, starting in ASP with PGP (I don't like the fact that RFC 1991 even is so big and allows so many different types of encryption to the user).

This idea is described and justified more fully in the specification and
the design paper.
I printed it out this morning :-) I am not sure I get everything yet however, the trust problem is just something I discovered from working on my own protocol and I think I was able to extend it to even mixminion (thus the subject I chose).

(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?
Well, there is the RABS list for auto-dest-blocking at every remailer. A lot of remops use it (about ten I think). A directory server would be less controversial since the RABS list allows rough remailers to block users against their will. (not sure about this, RABS might require confirmation from the user).

(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,
Well, I think I don't have to comment on your directory server since it doesn't seem to apply to my own protocol and I must admit that I don't fully understand mixminion yet (the shuffling is not clear to me e.g. and I don't get why you would need a turning point, since I sure don't need one in my own protocol (only discovered this a few months ago, it has to do that when receiving a singled message, the tlbp server either has a public key for that (reply) or not (forward)).

I think this is enough from me for now. I hope you can use some of the stuff in my protocol in the mixminion design (like the stats specs I gave above and the client GUI). I have been reading the Chaum paper thoroughly for the first time this morning and I gave up when I reached anonymous digital voting, but it got me thinking about voting myself. My protocol is not really suited for nym servers and only allows reply back anonymous message right now. It would be possible to create a nym server which should be kept filled with tokens, but it seems to me nobody would be able to afford these nyms as the tokens will auto-expire every few weeks at the remailers (without the nym server even knowing about this right now).

I guess my protocol right now allows the private speech in the corn field I read about somewhere on the internet. Both participants know each others e- mail address, but they don't want their communications know to other parties besides themselves. I cannot find good arguments for allowing pseudonyms that last over a longer period of time, but I am thinking about some sort of From line which allows pgp signatures. It would probably something like the X-Author line now in mixmaster 2.90, but with a strong signature. Also, I figure when people are posting to newsgroups, only one can reply to such a post, which should be enough in my limited usenet experience. The upside to this limitation is that flooding is now impossible and tracking or replay becomes nearly impossible, giving a very strong, but very limited pseudonym functionality. So that is my line of thinking about how my tlbp protocol will differ from nym.alias.net right now.

Forgive the huge length of this post (I don't even feel like re-reading it I must admit), but this is about how far I have come so far with my protocol. There are some details, but I all worked out perfectly so far (which is kind of an almost magical experience, like at the start of drafting tlbp protocol, before it even had a name, I also envisioned a kind of field that would allow a server to detect in which direction a message to send, until I discovered that my single use public key principle had the excellent property of making this detectable only to the server itself! (depending on whether the public key of the user was still present at its pools)).

Of course, in my protocol users can flush their old keys from remailers by triggering them with an simple anonymous chain that routes back to no valid e-mail address. Maybe even using these adres fields to clean up other parts of the chain, it is just SOO much better then I could ever have hoped it to be. Even Chaums paper doesn't allow a different route back to the sender! My protocol allows things even Mixminion can't do as it seems to me. Like I can seed nodes in one anonymous message, seed other nodes in other anonymous messages or even replies back and then have an extra secure reply back route combining all of them.

Seems like something I would not want to be up against if I were the TLA ;-) ) I really fear for my own safety but sharing this (draft) protocol with the people on this mailing list makes you all a possible victim of 'meeting with an unfortunate accident'. Sorry about this, but I think we think alike and just like me you are willing to pay the price of death in order to preserve freedom in a democratic world and accademic freedoms (just read today about the science papers not publishing stuff that could be used by terrorists, I am sure terrorists would simple LOVE my protocol, I know I do, so that is why I am also working on seperate documents on how to attack my protocol, like how the TLA or even a single user like myself could compromise a especially chosen target by sending them a 'bullet with their name on it' instead of a normal remailer-key). Besides, the genie I out of the bottle now I hope (I can't imagine the trouble I would have been in with a well functioning TLA if I ever tried to patent this idea, I mean, just read the books on RSA and DH, it is not the kind of life I am aspiring to lead).

Argg!! I told you you should not be nice to me! Just see how off topic you are getting me again 8*] It is always the same with me, I either insult people if I don't get enough attention, of I smother them with my (temporarily) love for them until I put them off :-((

Sorry about this,
Thomas

P.S. Just wait for my paper if this message is too much a waste of your time. I guess it is almost as long as the whole Mixminion paper and I am very capable of posting such lenghty messages on a multi-weekly basis :-) [Some people in APA-S hate me for that and I don't blame them, I also like talking more than listening to people, it is the second worse problem I have in life. I didn't even want to read this mailing list until tomorrow and now look at the time I have spend on this post (couple of hours I must admit) :-) ]
--
Free low-memory/high-security Word Frequency Counter Utility in ANSI-C <home.hccnet.nl/t.j.boschloo/wordcnt> ;-)