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

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

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> ;-)