JAM> Rather than divert messages, then, I propose that for each input JAM> message there is a 10% chance that a piece of cover traffic is JAM> generated. AB> The way that this kind of attack is frustrated is that dummy messages AB> are created as cover traffic by the remailer, and that at some points AB> messages can be swallowed by a remailer as junk messages. Automatic decoy traffic was in my draft, but was not in the slimmed-down document I posted to CP. This was mainly because Lance Cottrell and I agreed on that bit, and thought it could be passed over. Unlike JAM, I was in favour of decoy traffic being _inversely_ related to genuine traffic. AB> You can still do a spamming attack by recognizing the destination, AB> rather than the message: Diversion was intended to make that harder too. Eve's messages won't all go straight where she wants them. They should turn up after some of them completed the diversion, but I suggested that would sometimes be too late to track it further through the chain. As for "messages can be swallowed by a remailer as junk messages", there's a catch for the unwary in that. See below. TCM> Note that merely fiddling around with probabilities of transmission, such TCM> as described above, will not be enough. This just adds a layer of noise, TCM> which will disappear under a correlation analysis. Kelsey wrote on 28th June about correlating messages at the points of entry & exit from the remailer network. I don't know what an attacker gains by correlating _inside_ the net. Here are the bits I omitted before. DECOY MESSAGES The sending of decoy messages by users is recommended, and serves to hide statistical correlations between your sending a message and somebody receiving one. This practice should continue. It is also desirable that a remailer be able to originate decoy messages itself. Advantages include better traffic load following. The remailer knows when traffic is light and can generate more decoys. This could be important at times of low traffic such as public holidays. It would be especially important during a denial-of-service attack. When an attacker prevents messages from reaching the remailer (in the hope of isolating a small number of target messages) a locally-produced set of decoys, immune from the denial-of-service, could be crucial. DESTINATION Addressing all automatic decoys ultimately to "nobody" would ensure that they circulate in the network and then disappear. Nonconservation of message number should prove annoying to an eavesdropper. (An implementation detail on this will be mentioned later.) Addressing some of them outside the network, to test newsgroups for instance might also be useful - confusing an attacker looking at the point of exit. NUMBER A possible means of matching the traffic would be to use an exponential- along the lines of those in thermodynamics. decoys = max ( D.exp(-kT) , E ) The "max" operator here ensures that every time a batch of messages is sent a minimum number of decoys will be included. Values for the constants can doubtless be suggested by remailer operators familiar with the traffic load. ..... SILENT SPAMMING Re-encryption as discussed here will not do any good if remailers allow "silent spamming". To exploit this feature the attacker addresses his messages to "nobody" (or "null" in Mixmaster jargon). These mails fill the message pool, sweeping out all the target messages, but when they come to be sent they disappear. They do not show on the net, they do not need to be recognised and eliminated from the search. All the attacker sees leaving the spammed host is undiluted target mail. Obviously the remailer should detect messages of this type and process them without storing them in the message pool. Any message that will not be delivered to a remote host comes into this category, including those to most local accounts. I briefly examined the source of 2.0.3 (from ftp://utopia.hacktic.nl/pub/replay/pub/remailer on 11 July 1996) and could not find code to deal with this attack. [Cottrell tells me this is on the to-do list.] -- Peter Allan peter.allan@aeat.co.uk