Re: Multiple Remailers at a site?

>I don't think multiple remailers at the same site help anything.

Assume Alice, Bob, and Carol are on abc.com and Xenu, Yak, and Zut
are on xyz.com.  Remailing between Alice, Bob, and Carol doesn't
make appear to make much difference, but it does reduce the damage
if one of the remailer's keys is compromised.  On the other hand,
mail from Alice -> Xenu -> Bob -> Yak -> Carol -> Zut adds traffic
to the system, and makes traffic analysis more difficult,
even if the Bad Guys are watching site abc.com and have stolen
Alice, Bob, and Carol's keys.

The other threat it helps with is that if XYZ.COM gets complaints
about that evil user Zut, she can kick her off (Bad Zut!)
and still leave Xenu and Yak alone; if the remailer service
were provided by the machine owner herself she might be directly liable.
#				Thanks;  Bill
# Bill Stewart +1-415-442-2215 stewarts@ix.netcom.com
# http://www.idiom.com/~wcs
#				Rescind Authority!

Bill Stewart writes:
>>I don't think multiple remailers at the same site help anything.
>
>Assume Alice, Bob, and Carol are on abc.com and Xenu, Yak, and Zut
>are on xyz.com.  Remailing between Alice, Bob, and Carol doesn't
>make appear to make much difference, but it does reduce the damage
>if one of the remailer's keys is compromised.  On the other hand,
>mail from Alice -> Xenu -> Bob -> Yak -> Carol -> Zut adds traffic
>to the system, and makes traffic analysis more difficult,
>even if the Bad Guys are watching site abc.com and have stolen
>Alice, Bob, and Carol's keys.

Wait a minute.  More traffic should make analysis easier, since traffic
analysis is mostly statistical work on the source and destination (not
necessarily "from" and "to").  A bigger sample makes more reliable
results.

For traffic analysis, I don't know *who* sent the message (it was,
after all, anonymized), but I do know a site which transmitted it and
one which received it, the time it was transmitted, and maybe its
size.  Multiply this times a whole bunch of messages, and I can infer
information about "common interests" between those sources and
destinations.

The delays and mixing done by remailers make it harder by
disassociating the true sender from the true receiver.  If a remailer
were to ignore this step, the analyst can deduce from the two data
points

    "message a, source A, destination RemailerX, time t, size s"
    "message b, source RemailerX, destination B, time t+0.001s, size s"

that there's some connection between A and B.  The more such evidence,
the stronger the connection.  If the remailer does a good job with
the delays and shuffling, then it becomes difficult for the analyst
to match message a with message b, leaving him with what he already
knew (that A and RemailerX have a common interest, as to B and RemailerX,
but the interests may be wholly unrelated).

Multiple remailers on the same machine increases the resolution of
the address information, at best, improving the analysts ability to
make connections.  The same traffic load going to a single remailer
at the site makes the analyst's job harder.

>The other threat it helps with is that if XYZ.COM gets complaints
>about that evil user Zut, she can kick her off (Bad Zut!)
>and still leave Xenu and Yak alone; if the remailer service
>were provided by the machine owner herself she might be directly liable.

Hmm.  Nothing really stops the machine owner from creating a personal
anonymous account to run the remailer.  When someone complains, shut it
down and create a new one.  There isn't yet a law which requires that
the owner be able to identify the user.  This affords the same
protection that multiple users does.

Scott Brickner writes:

 > If the remailer does a good job with the delays and shuffling, then
 > it becomes difficult for the analyst to match message a with
 > message b, leaving him with what he already knew (that A and
 > RemailerX have a common interest, as to B and RemailerX, but the
 > interests may be wholly unrelated).

Nope.  Not if each of them runs a remailer.  That's why mixmaster is
SO WONDERFUL.

-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | PGP ok
11 Grant St.      | +1 315 268 1925 voice | It's no mistake to err on
Potsdam, NY 13676 | +1 315 268 9201 FAX   | the side of freedom.

nelson@crynwr.com writes:
>Scott Brickner writes:
> > If the remailer does a good job with the delays and shuffling, then
> > it becomes difficult for the analyst to match message a with
> > message b, leaving him with what he already knew (that A and
> > RemailerX have a common interest, as to B and RemailerX, but the
> > interests may be wholly unrelated).
>
>Nope.  Not if each of them runs a remailer.  That's why mixmaster is
>SO WONDERFUL.

Aside from the fact that your point doesn't address mine, it doesn't
address the issue.  The "to" and "from" values that the traffic analyst
will be using are the IP addresses in the packets.  It doesn't matter
whether mixmaster, cypherpunks, or penet remailers are used, they still
use IP addresses.

Retransmission delays slightly reduce the analyst's ability to
correlate inbound and outbound messages.  Mixmaster significantly
reduces it, since all messages are the same size.  Chaining (and
mixmaster's inter-host mixing) means that the analyst needs to target
more machines to get meaningful correlations.

The discussion was about multiple remailers from multiple accounts on
the same machine.  The very existence of the remailer, independent of
issues like shuffling and chaining, is supposed to eliminate
identifying the originator by the content of the message.  Message
shuffling, delays, and chaining are entirely for the purpose of
reducing the information available to the traffic analyst.  If several
remailers are running on the same machine, they may be treated as if
there were only one remailer, for the purpose of traffic analysis.
Getting more traffic going through them just makes the analysts job
easier, because his statistical conclusions are stronger.

nelson@crynwr.com writes:
 > Scott Brickner writes:

 >  > The "to" and "from" values that the traffic analyst will be using
 >  > are the IP addresses in the packets.  It doesn't matter whether
 >  > mixmaster, cypherpunks, or penet remailers are used, they still use
 >  > IP addresses.
 > 
 > Sure *does* matter.  There's no computationally feasible way to
 > associate one mixmaster message with another.  The only way you can
 > get a clue is by analyzing who sends mail into and out of the
 > mixmaster system.  If both of your endpoints are within the mixmaster
 > system, you have no entering or exiting mail to analyze.  It doesn't
 > matter if the mixmaster remailers are on the same or different systems.

Scott indicates, in private mail, that he needs another, clearer,
explanation.  Okay, here goes:

A is sender, B is recipient, M is mixmaster remailer network, W is
watcher.

A Mixmaster system (there can be more than one, although there is
currently only one published Mixmaster system of remailers) acts as a
single node for the purposes of traffic analysis.  Imagine, if you
will, a remailer that everyone trusts implicitly.  Why would you need
any other remailers??  All W can see is incoming mixmaster messages
(lets you identify A), and outgoing ASCII messages (lets you identify
B).  If W can correlate traffic between A and B, he does it by
watching what happens between A and B, not being privy to the
internals of M.

Now obviously there is no single trustable M.  So, you create many Ms,
who move traffic between themselves.  Let's assume that only one of
them is trustable (M') and happens to be used by A to send a message
to B.  W STILL doesn't know what happens inside M' and has no more
information about the correlation between the message sent by A and
the message received by B than in the first case.

Do you see now, Scott?  Adding mixmasters doesn't need to make traffic
analysis harder (it does, but it doesn't need to).  It makes finding
an M that you trust easier.  And to that end, it doesn't matter if
those mixmasters are all running on the same host or not.

Now, my point about increased security by sender and/or receiver
running a Mixmaster remailer is that W has an easy time identifying A
and B because he can see that A sends a mixmaster message, and B
receives an ASCII message from a mixmaster remailer.  If either A or B
is running a mixmaster, W is denied knowledge that A or B even exists.
He MUST assume that anyone running a remailer is receiving or sending
some or all of the messages.  Message counting (looking for a delta
implying an internally received or transmitted message) is no help.
Since mixmaster happily ignores bogus messages, I could receive a
message, fill its packets with junk, send them one or more hops, and
let someone *else* be under suspicion of having received a message.

As an aside, the TLAs *are* looking for A's and B's.  They spend
millions of dollars a year on telephone traffic analysis.  We MUST
assume that they would spend tens of thousands of dollars a year on
email traffic analysis.

-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | PGP ok
11 Grant St.      | +1 315 268 1925 voice | It's no mistake to err on
Potsdam, NY 13676 | +1 315 268 9201 FAX   | the side of freedom.

Sorry to be following up to my own message Yet Again, but I see a hole
in my analysis that needs patching.

If you have a mixmaster host M, with certain characteristics (latency,
reordering, and traffic volume), that is NOT identical in security to
a mixmaster network M with identical characteristics, but in which
some hosts are not trustable.  The non-trustable host(s) keep track of
their latency, reordering, and traffic volume, so it's removed from
the characteristics of the network above.

Therefore, to keep the characteristics of the trusted host constant
when converting into a partially trusted network, each of the
individual hosts needs to increase their parameters by some amount
(which amount someone else will have to contribute, cuz I have no clue
and need sleep).

-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | PGP ok
11 Grant St.      | +1 315 268 1925 voice | It's no mistake to err on
Potsdam, NY 13676 | +1 315 268 9201 FAX   | the side of freedom.

Scott Brickner writes:
 > nelson@crynwr.com writes:
 > >Scott Brickner writes:
 > > > If the remailer does a good job with the delays and shuffling, then
 > > > it becomes difficult for the analyst to match message a with
 > > > message b, leaving him with what he already knew (that A and
 > > > RemailerX have a common interest, as to B and RemailerX, but the
 > > > interests may be wholly unrelated).
 > >
 > >Nope.  Not if each of them runs a remailer.  That's why mixmaster is
 > >SO WONDERFUL.
 > 
 > The "to" and "from" values that the traffic analyst will be using
 > are the IP addresses in the packets.  It doesn't matter whether
 > mixmaster, cypherpunks, or penet remailers are used, they still use
 > IP addresses.

Sure *does* matter.  There's no computationally feasible way to
associate one mixmaster message with another.  The only way you can
get a clue is by analyzing who sends mail into and out of the
mixmaster system.  If both of your endpoints are within the mixmaster
system, you have no entering or exiting mail to analyze.  It doesn't
matter if the mixmaster remailers are on the same or different systems.

-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | PGP ok
11 Grant St.      | +1 315 268 1925 voice | It's no mistake to err on
Potsdam, NY 13676 | +1 315 268 9201 FAX   | the side of freedom.

nelson@crynwr.com writes:

 > Therefore, to keep the characteristics of the trusted host constant
 > when converting into a partially trusted network, each of the
 > individual hosts needs to increase their parameters by some amount
 > (which amount someone else will have to contribute, cuz I have no clue
 > and need sleep).

Ahhhh, sleep is a wonderful thing.  It clears the brain so well.  The
increase is proportional to the level of distrust of the individual
hosts by other hosts.  If you think half the hosts are TLS moles,
you'd double your characteristics (reordering and traffic).

-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | PGP ok
11 Grant St.      | +1 315 268 1925 voice | It's no mistake to err on
Potsdam, NY 13676 | +1 315 268 9201 FAX   | the side of freedom.