Re: remailer resistancs to attack (fwd)
Forwarded message:
Date: Fri, 16 Jan 1998 04:50:37 -0500 From: "Robert A. Costner" <pooh@efga.org> Subject: Re: remailer resistancs to attack
An obvious thing to try is to add some more remailers. 300 remailers would not be immune to simultaneous shutdown by the authorities, but it would make it more difficult. A dozen of so remailers makes shutdown fairly simple.
Threats to the remailer network come from a few basic places.
1. Traditional law enforcement 2. Unauthorized law enforcement 3. "friends" of message recipients or "friends" of the remailer 4. unreliability of the machines that form the network 5. Hacking attacks 6. Design 7. User incompetence 8. Operator incompetence 9. initial startup difficulties
Considering that the federal law enforcement agencies have had decades to deal with organized crime and such over a national and even international level, 100' level warrants is not even a resource strain if the pay off is large enough. Now if we had 10,000 or 100,000 the picture begins to change radicaly. 10. lack of an effective financial model
Traditional law enforcement takes so long to investigate, the keys could be canceled and replaced several times.
This is another problem with the entire crypto process as now implimented. Users of keys, either for encryption or signing, tend to think of the keys as long term entities. Considering the increase in computing power, the coming ubiquity of law enforcement monitoring on the network, increased payoff for hackers as the traffic of personal info increases, and general human failure keys should in fact be changed often (say a couple of times a year, annualy at least)
A significant problem is in design. The remailer network is not designed to be robust or fault tolerant. There is no error notification to the user. If your message gets dropped along the way, there is no recovery system that gets it through another route. If you misspell your destination address, or other problem exists, you don't get notified of the event.
These are all criticisms of the TCP/IP and associated network mechanisms and not specific faults in the remailer model. It has to work with what it has. ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage@ssz.com | | 512-451-7087 | |____________________________________________________________________|
Jim Choate <ravage@ssz.com> writes:
Ryan Lacket <rdl@mit.edu> writes:
Traditional law enforcement takes so long to investigate, the keys could be canceled and replaced several times.
This is another problem with the entire crypto process as now implimented. Users of keys, either for encryption or signing, tend to think of the keys as long term entities. Considering the increase in computing power, the coming ubiquity of law enforcement monitoring on the network, increased payoff for hackers as the traffic of personal info increases, and general human failure keys should in fact be changed often (say a couple of times a year, annualy at least)
Make that instant key changes for mixmaster remailers by using forward secrecy and direct IP delivery to enable the interactive communications pattern required for immediate forward secrecy. Ulf Moeller (current mixmaster maintainer) has this on his to do list I think. Even for email, I spent a lot of time arguing with PGP Inc employees about how forward secrecy could be obtained within PGP 5.x. (The OpenPGP list seems to have gone dead... wonder what is going on.) The separate encryption and signature keys provided by PGP 5.x / OpenPGP allow you to have short lived encryption keys, and longer lived signature keys. The web of trust is provided by the signature keys. PGP 5.x implements automatic key update. It is cheap to generate new Elgamal keys every week or day or whatever if you share the public prime modulus. You can also opportunistically send use once Elgamal keys in messages which allows someone to have even more immediate forward secrecy. In addition you can use interactive forward secrecy between mail hubs, and you can also authenticate this with PGP's web of trust using a design I posted to cypherpunks and ietf-open-pgp towards the end of last year with a subject of something like "PGP WoT authenticated forward secrecy". Adam
participants (2)
-
Adam Back
-
Jim Choate