Re: strengthening remailer protocols

[Adam Back <aba@dcs.ex.ac.uk>]

Peter Allan <peter.allan@aeat.co.uk> writes on cpunks:
> [re-encrypting as a mechanism to prevent an attacker in a spamming
> attack reconizing his own messages]

The attack Peter is hoping to frustrate is as follows: target message
being sent from Alice to Bob through remailer R.  The attacker in an
active `spam' attack floods remailer R so that he will recognize the
target message and it's destination.

Another approach to making the transmitted message unrecognizable to
it's owner would be to finish the implementation of D-H key exchange
in mixmaster.  (The version I am looking at (2.0.3) does not have the
D-H key exchange and direct socket communication implemented, rather
it delivers mail by sendmail, I believe).

As a bonus this provides forward secrecy, so that not even a supeonaed
remailer operator would be able to reconstruct the destination.

You can still do a spamming attack by recognizing the destination,
rather than the message: Eve forwards enough messages to remailer R to
flush the target message.  Each of Eves messages is headed to a known
(to Eve) address.  Say the remailer R has a buffer of 10 messages, if
Eve sends 9 messages, 3 to each of remailers R2, R3, and R4.  Eve can
then determine the destination of the target message: the remailer
which gets 4 messages is the destination remailer.

(Here my knowledge of mixmasters workings are wearing thin, but I
believe it does these things, or provides facilities so that the
operators/users can make sure these things happen).

The way that this kind of attack is frustrated is that dummy messages
are created as cover traffic by the remailer, and that at some points
messages can be swallowed by a remailer as junk messages.

Sufficient junk cover traffic would ensure that even with a spamming
attack the destination would not be known immediately because the
attacker can distinguish the target message from the junk.

Ultimately a good way to foil this attack in general is to have each
remailer send a fixed amount of mail to each other remailer in cycles.
No traffic analysis if all remailers get equal traffic.

The only entry point for analysis then is the entry and exit points.
The active spam attack then would be to block, or delay all entry
points into the remailer net, apart from the target message.  The only
messages in the network would then be the spam traffic, and the target
message.  When the target message leaves the net, the Eve knows the
destination.

To hinder this attack, the remailers could generate and mail to
previous users junk mail.  Over a long time, statistical attacks could
perhaps be built on a pair of users who communicated frequently.  The
ultimate solution to this is for the users also to receive fixed
amounts of junk each day.

Starting to sound like similar overheads to a DC net, huh?

Peters other suggestions of adding random diversions sound like
reasonable ways to add another form of cover traffic, and should help
make life harder for the attacker,

Adam
--
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)