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!
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.
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.
participants (3)
-
Bill Stewart -
nelson＠crynwr.com -
Scott Brickner