Re: Technical Remailer Analysis.

[bogus@no.return.address (Underdog)]

-----BEGIN PGP SIGNED MESSAGE-----

From: Louis Cypher


Hal Writes:
>Good point.  There is a related attack which Chaum pointed out in his
>1981 CACM paper: the attacker intercepts and keeps a copy of an incoming
>message, then later re-sends it.  This one will go to the same place and
>by repeating this multiple times we can figure out where the original
>message went.

This raises a fundamental problem with current remailers. It is clear that
next generation remailers will have to encrypt all messages sent between
them, on top of any nested encryption of the message done by the
originator.

Timothy C. May Writes:
>157.3.  Some possible fixes:
>
>        157.3.1.  remailers can recognize duplicates and agree not to
>remail them, or to remail them off in different directions (adding their own
>hop-wrappers)
>
>        157.3.2.  digital postage helps a bit, as the attacker at
>least has to spend money
>
>        157.3.3.  (If the inner layers of a message each have some
>digital money, or a "one-use" coupon, then an attacker who copies and resends
>the whole message is effectively double-spending and this should be detected.
>Most simply, the "use once" coupon will only allow one passage through the
>remailer.)

If the remailers also batched messages to a given destination, or padded
outgoing messages before encrypting them, they would be far less
susceptible to this kind of attack. Re-encrypting the message with padding
(to some standard size) would prevent attackers from recognizing their own
messages in a flood attack, except by noting destination (which could be a
giveaway). Batching would do the same, but would also hide the number of
messages trashed or locally delivered. Neither of these does much against
the concerted "spam attack". I think in the end, remailers will need to run
something like encrypted links, sending a constant volume of data between
them, which would be random garbage when not a real message. This leaves
open the denial of service attack of sending more data per hour then the
link supports, therefore causing long queues at the remailers. Sigh, I
really need to get down to a library and dig up the Chaum articles I hate
to always reinvent the wheel.

While waiting for good digital postage, a substitute could be used. If one
added a "Msg-ID:" header similar to the Ghio remailer's "Cutmarks", which
contained a large random number, this number could be stored at the
remailer, and messages with the same ID simply send to /dev/null. This
would be simple to do with remailer chaining scripts like "premail".

Hal writes:
>If I follow this, the attack is something like, every time Alice sends
>a message Bob receives one.  Observing this happening over a period of
>time we conclude they are communicating.  Could this be defeated by
>sending dummy messages so that Alice sends exactly 10 messages every day?
>Then the fact that Bob receives messages on some day can't very well
>be associated with Alice.

Since I assumed that a typical user sends one message per day, Alice may
draw attention to herself through this mechanism. 10 messages is not
enough, it would leave some correlation. Alice needs to send at least one
message per tick (e.g. 48 in my example), in which case she shown 100%
correlation with all recipients always. There is no way to know that she is
sending to Bob, but I suspect she will be on a short list at the FBI unless
everyone else is doing the same (which violates my assumptions). If
everyone sent a message every tick, traffic analysis would be impossible.

Matthew J Ghio writes:
>This attack can be defeated if both Alice and Bob are running remailers.
>Then their correspondence is hidden in the 100 messages a day of
>remailer traffic.  An observer can not tell wether the messages were for
>Alice or Bob, or if they were for the remailer (assuming latency was
>used) or if they were bit bucket messages.  Alice could even forward her
>personal messages to a bitbucket (after saving a copy for herself) to
>further increase security.  This is why everyone should be running a
>remailer if they are concerned about their privacy.

I do not think that the "everyone is a remailer" idea works. At the assumed
one message per day, and an average message chain of 5 remailers, then only
5% of users can maintain remailers with a real traffic flow of 100 messages
per day. Other than that, this idea is functionally similar to Hal's.

Sending messages on to bit buckets is a nice idea. Assuming cutmarks, or
standard message sizes, and reordering are used, this is indistinguishable
from a remailer which just delivers the local mail, and also sends out
periodic junk messages to various bit buckets. As I mentioned in my
original message, this should be done anyway to ensure  complete mixing of
all messages within the web during any given tick.

                -Louis Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLo557qyHUAO76TvRAQFSJwQAmenSoAZAkOtGww9F/giy80AmJJk30I6D
y5Fp0d8fgNy3MiCnG6onlvvJdBShgonvsbKRF0r94cYtYgtnczK/rqmhIDyc/UB2
a0V55YRdb84YwGpGPmrFepH8yXdueEgQvUq5Fs1FV9jNtSAK9kK2G1+QmSVdq/Uy
pkRIf8iPbJA=
=xZdv
-----END PGP SIGNATURE-----