From: Anonymous <nobody@replay.com>
Date: Sun, 6 Dec 1998 01:56:17 +0800
To: cypherpunks@toad.com
Subject: ..
Message-ID: <199812051730.SAA20180@replay.com>
MIME-Version: 1.0
Content-Type: text/plain



> > (Furthermore, most remailer structures still can't erase some other security
> > concerns --
> >   1: remailers acutally can be hacked or physically compromised
> >   2: clients really can be screwed
> >   3: etc.
> > 
> > To help solve the first, you'd want a two-box setup doing remailing, with the
> > security-critical stuff loaded on a box not directly connected to the Net with
> > something 140-1ish to make tampering harder, a secure OS, etc. -- or, of
> > course, you can scrap all that to get really big remailer count.
> 
> As long as you do not see the box and do not control its manufacture,
> I see no reason why you should have ny more trust in it.

Well, you shouldn't have complete trust -- a tamper-resistant net could be
compromised, too -- but there's a good reason to have more trust in it than in
the existing one. More on that after a parenthetical remark.

(This brings up the "hardware web-of-trust" issue; you can set up such a web
with trusted spot-checkers and statistical/cryptographic means of assuring the
user that the box works as advertised, if your threat model demands it.  
There's more about it in the "Beyond Class (A1)" section of the Orange Book,
although the section's use to Cypherpunk types is limited because it's written
without any thought to, say, doing things cheaply or having a decentralized
setup.)

The tamper-resistance simply means that if the mailer was set up secure, it's
not going to become compromised. Instead of having to trust that one of the
remailer operators is currently honest and has always done all the necessary
homework to ensure the system was safe, you have to trust that this entity was
honest and diligent when the remailer was set up (unless, of course, you think
the tamper-resistance was circumvented); if the operator is bribed after the
remailer's set up and the public key is published, there's no way to suddenly
and invisibly make messages traceable, as there is in a "normal" Mixmaster
remailer.

(This is because, given the normal assumptions about crypto strength, it takes
the remailer's private key to process a Mixmaster-like packet and that key is
generated by and stays within the tamper-resistant box)

My predictions about the biggest attacks on a tamper-resistant remailer net:
  1: traffic analysis. Until the net structure is overhauled, this will always
     be possible.
  2: propagation and exploitation of faulty server software. Related to the
     whole web-of-trust issue.
  3: direct attacks on specific clients. Again, no web of trust.
  4: creation of bad remailers and attempts to shut down good ones. More
     messages could be traced in a world with 6 good and 47 bad remailers than
     in one with 9 good and 3 bad.
  5: direct attacks on new remailers
  6: attempts to make an operator feign a catastrophe and set up a new,
     compromised remailer. Users, however, would know that the new key not 
     signed by an old one means that they must now trust that the remailer was
     not compromised before the publication of the new key.
  7: attacks on tamper resistance
...
  n: attacks on crypto
n+1: etc.