Re: How can you protect a remailer's keys?
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
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
participants (2)
-
Adam Shostack -
mccoy＠communities.com