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.

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.

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