SRP (from the cutting-room floor)

[peter.allan@aeat.co.uk (Peter M Allan)]

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