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*',/((..)*)$/)