Re: REMAIL: problems

[Joe Thomas <jthomas@access.digex.net>]

On Mon, 28 Jun 1993, Sameer wrote:

> 	I've been thinking a little bit about the problems with unreliable
> remailers.
> 
> 	Supposing that we can never rely on the reliability of all the
> remailers in a given path (because of not just bugs in the software, but
> political hassles) it would be good to figure out a mechanism by which
> a problem can be noticed.

I've thought about this as well.  I don't think it's right to _ever_ keep
return path information in a cypherpunk remailer, even for error reporting.
Far better to just drop the message on the floor than provide a loophole
to the anonymity of the system.

That said, I think there are possible solutions to the problem of
vanishing remailers.  Let's say there is a method to quickly and easily
verify the continuing existance (or lack thereof) of a remailer.  When a
remailer receives a request to send a message to another remailer, it can
quickly check to see if that remailer is in operation.  The question is
what to do with the information if it turns out the remailer is really down.
If the message is unencrypted, a smart remailer could simply skip the
missing remailer or send the message on to a substitute remailer, which
would then pass the message down the chain.

But if the message is encrypted with each remailer's key, it is
undeliverable without that remailer to decrypt it.  My idea is for
remailers to share their private keys using a secret-sharing protocol. 
When a remailer goes down, all the other remailers that hold pieces of its
key would choose a replacement remailer and send it the key pieces.  From
then on, all mail for the missing remailer would be routed instead to its
replacement remailer, which would decrypt and process it as usual.

It would be quite a pain to implement, but would make large remailer nets
a lot more reliable if it's done right.

Joe