Attacks on remailers

[remail at tamsun.tamu.edu]

Hal Finney writes a nice "To Do" list for the cypherpunks
remailers by enumerating and describing possible attacks.
Let's priortize these items.  First we should do those
items that are easy to implement, and those items needed
to prevent any remaining cheap 'n easy attacks.  We can
leave expensive attacks for future projects.

> Response: Encrypt the messages.  Use "nesting", so that all that is
> visible as each message leaves a remailer is the destination of the
> next remailer.

This should be made smoother.  The learning curve needed to
get to this stage : install PGP & get it working, learn
how to use remailers, install remailer nesting script, debug
all of the above, because something in there is bound to
break at this stage : quite a lot of work!  Just
improving things up to here with clearer documentation,
and better scripts and GUIs, would greatly increase the number
of remailer users and traffic.

> Response: Run the remailer on a machine which does not keep mail logs,
> or on a machine to which you can deny the attackers access.

The former is much to be preferred!  The first link in the
remailer chain, especially, needs to be trusted not to
maintain logs.  The trustworthy remailer operator goes to 
great lengths to minimize the temptation to look at messages.

>[Attack 3: timing & ordering of messages in & out]
>[Attack 4: look at subject line, message size, etc.]
>[other attacks involving intercepting mail stream]

Batching and random delays only work well if there is large
message traffic through the remailer.  What in specific
detail is needed to gain access to the mail stream to
make these attacks?  If no mail logs are kept, and the remailer
denies access to a spool file, by hiding it or putting
random garbage in it or denying access to its host computer,
an attack looks to me like it requires a sophisticated wiretap.
Avoiding expensive attacks is low priority at this 
point.

>[Message pools] have the problem that they expose everyone
> in some group to all of the messages intended for every group member,
> hence the number of messages will scale as the square of the number of
> group members. 

First let's make the problem happen.  Then we can solve it!

Here's another item: faster links!  The delay between
when I post this and when it arrives on "cypherpunks" can
be half a day. 

What about that idea of using direct sockets instead of
SMTP between remailers?  That could kill two birds with one stone:
delivery speed and cheap attacks against the intermediate
links via logging or spool files.