[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
REMAIL: Cover traffic
Several people have suggested that cover traffic is more valuable than
I had suggested in helping prevent tracing of messages through
remailers.
I drew up some diagrams to show what I mean. Suppose we have
remailers R1 through R6 exchanging dummy messages all the time that
are introduced into the remailer network by cover traffic sources C1
through C3:
C1 C2 C3
| | |
| | |
| | |
| | |
V V V
R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6
Now user U1 sends to user U2 through some remailers in this network:
C1 C2 C3 U1
| | | |
| | | |
| | | |
| | | |
V V V V
R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6
|
|
|
|
V
U2
As you can see, it doesn't exactly take Sherlock Holmes to figure out
who is talking to whom. If the "true" traffic through the network is
light and latencies low, someone monitoring the whole network can
track messages in this way.
Now, suppose we also had U3 send to U4. Then there is some benefit:
C1 C2 C3 U1 U3
| | | | |
| | | | |
| | | | |
| | | | |
V V V V V
R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6
| |
| |
| |
| |
V V
U2 U4
An observer may be able to deduce that U1 and U3 are sending to U2 and
U4, but they can't tell which is sending to which. So the cover
traffic had some effect. But consider: you can get the same result
from a SINGLE batching remailer:
U1 U3
\ /
\ /
\ /
R1
/ \
/ \
/ \
U2 U4
Here we also have U1 and U3 sending to U2 and U4, without being able
to tell which is which.
It has also been suggested that "bit-bucket" addresses, people who
would receive messages from the network and discard them, would help.
Here is how cover traffic might look with bit-bucket addresses B1
through B3:
C1 C2 C3
| | |
| | |
| | |
| | |
V V V
R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6
| | |
| | |
| | |
| | |
V V V
B1 B2 B3
Here again, though, if true message traffic is light, and U1 sends to
U2, we will have:
C1 C2 C3 U1
| | | |
| | | |
| | | |
| | | |
V V V V
R1<------->R2<------->R3<--------->R4<-------->R5<-------->R6
| | | |
| | | |
| | | |
| | | |
V V V V
B1 B2 U2 B3
Again, the changes in the background pattern of communication reveal
the true messages.
The only way this cover traffic will work is if there are a very large
number of traffic generators, (C's) and a large number of bit-bucket
addresses (B's). Even then it will mostly serve to cover messages
which are from C's to B's. And you still have the problem that the B
addresses may become well known (people have to find out about them
somehow), making this analysis easier.
It has also been suggested that in pointing out these difficulties I
am overlooking the fact that at least the cover traffic makes the
eavesdropper's task more difficult, as he now must monitor the whole
network. But I think he has to monitor the whole network anyway. If
I send a chain-encrypted remailed message through half a dozen
remailers (even without cover traffic), the observer must watch that
message going into and out of each of those remailers in order to see
where it finally goes. Looking at only one remailer will not help.
So, since the eavesdropper must monitor the whole network in order to
follow messages even without cover traffic, I think it is fair to
point out that adding cover traffic doesn't help much against an
eavesdropper who can monitor the whole network.
The real solution, as suggested by the diagrams, is to have a large
volume of true remailed messages in the network - messages which go to
a wide variety of people. Individual users can protect themselves to
some extent by serving as cover-traffic generators and bit-bucket
receivers; but this does not protect other users who are not able to
perform these functions.
Hal