From: mccoy@communities.com (Jim McCoy)
Date: Thu, 6 Jun 1996 16:36:23 +0800
To: cypherpunks@toad.com
Subject: Re: How can you protect a remailer's keys?
Message-ID: <v02140b00addba12bd414@[205.162.51.35]>
MIME-Version: 1.0
Content-Type: text/plain



Lance Cottrell writes:
> At 11:55 PM 6/1/96, Bill Stewart wrote:
> >Encryption is critical for protecting against traffic analysis,
> >but it's tough to protect a remailer's keys.  Unlike regular email,
> >where you can type the key in as you read it, remailers need to
> >run automatically once you set them up.  Some of the choices are:
> >- leave it around in plaintext with only Unix file protections
> >- type it in to a long-running remailer process
> >- SSL-based remailers, where the web server handles crypto on
> >        a per-machine basis instead of per-remailer
> >- use unauthenticated Diffie-Hellman
> >- off-line or off-site remailer such as a POP3 winsock remailer
> >- human intervention on every message
> >
> >Anybody have any other approaches?  These are mostly weak,
> >annoying, or both.
>
> The best solution I could come up with (and was willing to write and use)
> is to specify the passphrase on the command line argument to the compiler

This is little better than leaving it around in a plaintext file, a pass
or two with gdb on your binary and I have your private key.

The "difficult, expensive, and pain in the ass code to write" solution that
I favor is to use secure multiparty computation to create the remailer.  It
does not exist on a single host, but is rather the sum of a collection of
hosts running on widely seperated machines.  It has the same type of drawback
as a per-execution password entered into a long-lived process (anyone with
root access to the host can yank it out of memory with little difficulty,)
but this is spread out across a larger collection of hosts, making the task
of actually getting the complete password somewhat difficult.  Getting a
subset of the individual host passwords does not provide any partial
information about the collective password (similar to secret sharing.)
The other drawback is that certain operations can be very slow, you end
up emulating a circuit with a _very_ slow clock (8-10 Hz.  Not MHz, not KHz,
but 8-10 ticks/second); as compensation you get a word-size that if
effectively infinite. I have to continue work on a subset of these methods
for a secure digital poker/card-playing system over the next couple of months
and if I have some spare time I might see just how difficult creating a
toolkit for building such virtual circuits really is...

OTOH, a secure PCMCIA or smart-card will probably end up being a better
practical solution.

jim