Progress on single use remailer keys

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

Hi everbody on my favorite mixminion list. I have made some progress
on the single use remailer keys I want to use in my own (very slowly
developing) pseudonym protocol.

I started out with my 'slurf' protocol for retrieving keys. In this
protocol a client would 'reach into' the network by using pseudonyms
to retrieve public remailer node keys. This way the client could
upgrade the keys it retrieved through this 'slurf' (or elephants trunk
in english) to keys with a higher security rating (depending on how
long the 'slurf' or maybe 'fingers' were).

Some weeks ago I woke up with the idea in my head to retrieve keys by
'seeding' nodes with user (public) keys anonymously. It wend like this:
.. well it is not really that important. I will go straigth to how I
envision the protocol now.

-----
The problem with super-ultra-high rotation keys as in my protocol (the
lost biro project) is that a remailer node can tag the user by
remembering which key it sends to which user.

The solution I see now is to seed the remailer network with public keys
from the user. The idea is that this way the user can set up a chain of
remailer nodes of which the first node back to the user only knows that
it send a key somewhere, and where the final node back to the user only
knows who it sends some encrypted info to.

This didn't work for me before you might ask, so why would it work now?
Well, I am contemplating on making my protocol hybrid pseudonymiously
and anonymously. The pseudonymious part that is for receiving anonymous
mail (one reply per chain used in my protocol
<home.hccnet.nl/t.j.boschloo/TLBP>) uses single use keys. The anonymous
part of the protocol, that will work very much like mixmaster does now,
uses a fixed key. Since encrypted stuff looks like encrypted stuff from
the outside there will be no way for echelon to monitor TLBP
communications. The remailer nodes can just decrypt from their fixed
'mixmaster-like' key first and when that fails try all the secret keys
that go with the public keys that the node will send on (anonymously
seeded pseudonymous) request (and which it will keep for as long as it
doesn't crash due to the high workload, since my protocol will gulp up
loads of CPU cycles when it is finalized, if only for generating public
key pairs).
-----

Well, I hope that works. I don't spend a lot of time on my protocol
these days so things are going very slowly.

Regards,
Thomas J. Boschloo
Heerhugowaard/Holland
--
Trinity, The Matrix: "You cannot be dead because I love you and the oracle
told me I would fall in love with the one"