CNN.com on Remailers

[Bill Stewart]

At 09:01 PM 12/17/2001 -0600, Jim Choate wrote:
>On Mon, 17 Dec 2001, Trei, Peter wrote:
> > and sends the contents on to the next address (yes, this type of remailer
> > does not include nice features such as cover traffic).
>
>And it can't encrypt that outgoing traffic since it doesn't have the key
>to the destination (I assume the user must nest these themselves).

Yes, the user must nest those himself.  If he doesn't like doing it by hand,
there are client programs that can do this automagically.

The only way to get security is for the originator to do the encryption -
otherwise, if ANY remailer in the chain is compromised,
the Bad Guys can read the message.  If the originator does the crypto,
then EVERY remailer in the chain has to be compromised to break it.

>The sender having to know all the steps is a major threat to the standard
>remailer model. In fact it's one of the major shorcomings with the current
>approaches. The sender should at most be able to set the number of
>remailers, not which ones. That way there's on evidence sitting around on
>their machines (and you can posit throwing the keys away each time - but
>then you have to go out and get them again...and around and around we go).

The remailer-stats pingers publish this information on web pages;
you can retrieve it and read it by hand, or use a client program to fetch it.
If you don't want to keep it, don't.
And some of the clients are web pages themselves (Javascript or whatever),
so you can just retrieve them.

And obviously the sender needs to be able to pick the remailers to use -
depending on the type of message, some messages need to be sent through
remailers in appropriately safe jurisdictions, other messages don't
need much security but need high reliability or high speed
(so you want to pick remailers with good stats.)