Remailer traffic analysis foiling
Remailer hackers, I've been thinking about the problem of traffic analysis of anonymous remailers and I have a question to pose to those of you whose thoughts on this topic are "more frequent or fully-formed". Would there be any advantage to giving remailers a MIRV capability? The idea goes like this: The message arrives, the PGP wrapper is removed, the message is scanned for some specific token imbedded in the text (ala Matt Ghio's Cutmarks function). That token is a divider between two outbound messages. These messages are sent along their respective ways. The result is something like a 10K message coming in, and a 7K and a 3K message leaving. If one of these goes to the bit bucket, it is like having added padding stripped off. Alternately they each could be part of the real message, previously split and then sent via different paths to reduce chances of complete message interception. I guess the issues involved are: 1) How difficult would this be to code? [Yeah, yeah "Cypherpunks write code"(TM), but some of us write genetic code, not computer code :-)] 2) What is the credible threat of traffic analysis? a) Does multiplication of messages and their routing schemes create problems of scale for these alleged eavesdropers? b) Do you assume that if it's not a compromised server, that what goes on inside the machine is hidden? Now before the Zippos start flicking, I've followed the the latency vs. reordering argument, and accept that latency *may* acheive reordering, but not necessarily. In this system though, different latencies after the split would seem to acheive something because without reliable size in/out information it would be harder to correlate message in with messages out. Comments (incendiary or or otherwise) requested. C. J. Leonard ( / "DNA is groovy" \ / - Watson & Crick <cjl@welchlink.welch.jhu.edu> / \ <-- major groove ( \ Finger for public key \ ) Strong-arm for secret key / <-- minor groove Thumb-screws for pass-phrase / )
On Wed, 3 Aug 1994, cjl wrote:
Remailer hackers,
Would there be any advantage to giving remailers a MIRV capability?
[deleted]
I guess the issues involved are:
[ deleted]
2) What is the credible threat of traffic analysis? a) Does multiplication of messages and their routing schemes create problems of scale for these alleged eavesdropers? b) Do you assume that if it's not a compromised server, that what goes on inside the machine is hidden?
for total anon post/mail How workable is setting up remailers with psudo-cooperation so that when it recieves an anon mail it waits 20 or so min and then randomly sends copies of it to 5 other remailers of which the original reciever randomly decides which 1 of the 6 will post and the rest simply discard. a 5 fold increase in traffic will make it harder to analize if 80% is just noise Duct tape is like the force. It has a light side, and a dark side, and it holds the universe together ... -- Carl Zwanzig
On Wed, 3 Aug 1994, Jidan wrote:
for total anon post/mail How workable is setting up remailers with psudo-cooperation so that when it recieves an anon mail it waits 20 or so min and then randomly sends copies of it to 5 other remailers of which the original reciever randomly decides which 1 of the 6 will post and the rest simply discard. a 5 fold increase in traffic will make it harder to analize if 80% is just noise
I think that sending many copies of the same message sounds like a good way of making sure that it ends up being monitored by some alleged surveillance net. Sending dummy messages is another matter. A fivefold increase in traffic may or may not have an impact on analysis, depending on your assumptions about the adversary's capabilities. Anyway, you still have a message of fixed size going in one end, coming out the other, and landing in someone's mailbox. The superfluous messages may in fact be easy to identify if they are addressed to bit.bucket@dev.null. C. J. Leonard ( / "DNA is groovy" \ / - Watson & Crick <cjl@welchlink.welch.jhu.edu> / \ <-- major groove ( \ Finger for public key \ ) Strong-arm for secret key / <-- minor groove Thumb-screws for pass-phrase / )
Since it was posted twice I guess I can reply twice :-) On Wed, 3 Aug 1994, Jidan wrote:
for total anon post/mail How workable is setting up remailers with psudo-cooperation so that when it recieves an anon mail it waits 20 or so min and then randomly sends copies of it to 5 other remailers of which the original reciever randomly decides which 1 of the 6 will post and the rest simply discard. a 5 fold increase in traffic will make it harder to analize if 80% is just noise
This scheme wouldn't be workable in the currently fragile and ephemeral net of remailers. They would have to spend a lot of time talking to each other and making sure that they all had up-to-date lists of valid remailers. That's too much of a burden to put on the net.philanthropists that are currently operating mailing lists. Any validation of a chained remailer pathway is up to the user (not exactly *caveat emptor* cause you ain't paying for anything, but you get the idea) C. J. Leonard ( / "DNA is groovy" \ / - Watson & Crick <cjl@welchlink.welch.jhu.edu> / \ <-- major groove ( \ Finger for public key \ ) Strong-arm for secret key / <-- minor groove Thumb-screws for pass-phrase / )
participants (2)
-
cjl -
Jidan