From: Charlie Comsec <comsec@nym.alias.net>
Date: Sat, 3 Jan 1998 13:09:08 +0800
To: remailer-politics@server1.efga.org
Subject: Re: Remailer Logs (and Accountability)
In-Reply-To: <199712221346.OAA03091@basement.replay.com>
Message-ID: <19980103050003.766.qmail@nym.alias.net>
MIME-Version: 1.0
Content-Type: text/plain




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

usura@sabotage.org (Alex de Joode) wrote:

> : I suspect that if you polled remailer operators you'd find that some
> : keep logs and some don't.  I don't know about the Replay remailer.  Perhaps
> : Alex DeJoode (the operator of the Replay remailer) would care to comment.  Nor 
> : can logs necessarily positively identify you.  If kept, they would record when 
> : your message came in and when the post to usenet went out, but *PROBABLY* 
> : would not establish a conclusive link between the two.  Many remailers 
> : maintain a "reordering pool" where forwarded messages do not necessarily get 
> : sent out in the order they were received.
> 
> I donnot keep sendmaillogs, I donnot keep remailerlogs and I let 
> usenet do my mail2newslogging ... (They can ofcourse always supena 
> /dev/null, and then they get everything ..) 

Good.  No reason to tempt the Big Brother types (and wannabes).
BTW, people outside the remailer operator and user community seem to
assume that logs ARE kept.  I'm curious to know how often
individuals, organizations, and maybe even governments make requests
for your logs.

Oh ... also, if you don't mind, can you uuencode your /dev/null and
send it to me? <g>

> The "reordering pool" is 
> always a minimum of 5 messages so people can opt for how long their 
> message wil be 'stashed' at replay. (use 'Latency: +00:00' for zero latecy).

Is that default reordering pool size the same for Type I and Type II
messages?

Perhaps someone can double-check my math on this.  Assuming
equally-sized messages that are otherwise indistinguishable, and a
reordering pool size of five, then the odds of matching up an
encrypted incoming message with an encrypted outgoing message are
one in five.

Thus a message chained through n remailers (each having a reordering
pool size of 5) would be diffused among 5^n possible messages to
thwart potential traffic analysis.

What I'm unclear on is how setting a Latency:  flag affects the
diffusion of the output.  Is that lattency IN ADDITION to the pool
size of five, or does Latency:  +00:00 bypass the reordering process
altogether?

My main concern is the security of chained reply blocks which are
more vulnerable to attack than normal anonymous messages.  A single
anonymous message can only be traced BACKWARDS after it's been
received.  An anonymous reply, OTOH, could, theoretically, be
"walked" through each remailer in the chain until the identity of
the recipient was discovered.  While that process would require
convincing each remailer operator in the chain to cooperate, it's a
lot more feasible than tracing a message backwards to its source.
(Yes, I know about posting to a public message pool, such as a.a.m,
but NG posting seems to be rather unreliable lately.)

- ----
Finger <comsec@nym.alias.net> for PGP public key (Key ID=19BE8B0D)


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNK2wqwbp0h8ZvosNAQFcpwf9GzP5jGSURrVZXu3omQXx9+de1aOHZ+Uk
azgpHRZwStL86ztv1U5RcO7TRQ7gNgEd0+8V+z/wJei82f5zsQPCWVITjHBnUBKL
sbGEFTtlkLfehXgF6oRk4xYzngxekYYFXm3UqZFKf/maQvMCRXbXSfTpb0CejpfQ
01PQGmXrShjdiYO8Uj+UoXzEEyAU383ssnJmsDBbnMvilM3aE5f0GXG/dx3QSvQi
CfRzPFpcgfM4kojv8CxH5xfCvCWzKNgi8lnGuMjNwYApuGrYVtJSReq+OcAe9GeQ
O2e+R9emHWiZHO16asfjnx6Eie7BylGrBRCLPWAAxPo16AtGjhJimw==
=HRSR
-----END PGP SIGNATURE-----