Re: How can you protect a remailer's keys?

[Adam Shostack <adam@homeport.org>]

	I'm not sure that, even in theory spreading your key over
multiple machines isa good idea.  The issue to me is reliability.  If
you (the remailer op) have a single machine thats well secured, you
can get a decent idea of its state at a given time.  It is dependant
on those things that the net depends on, DNS and IP being close to
working.  If the remailer is distributed, you've raised the work to
maintain by a factor of N, and increased the probability of the
machine being insecure by the same amount.  You've also reduced
reliability to that of the least reliable machine.

	The better model (imho) is to have 'co-processing' strong
remailers in safe places.  (I think Alex described these here a few
months back; you have a firewall host that talks to the net, and a
second machine attached to it which does the mixing, and passes
messages back to the firewall for distribution.

Adam

Jim McCoy wrote:

| Lance Cottrell writes:

| > 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.

Yeah.


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume