Re: Remailers and ecash (fwd)
Forwarded message:
No they don't, all remailers do not encrypt their outgoing as a matter of course (do any currently do it as a matter of course? I would bet not if I were a gambler). The remailer you used to send this didn't use encryption on its outgoing or else I wouldn't be able to read it. The last time I looked about a year ago the vast majority of remailers didn't encrypt their outgoing traffic as a matter of course, it required the user to do it (I suspect this is still true). Furthermore I specificaly used the word 'set' to mean a group of remailers acting in concert such that this encryption happened automaticaly - I know the answer already - No, there are no sets (ie a cooperative network) of remailers (Mixmaster operaters included) implimenting this unless the user goes to extreme and does it all themselves. As a matter of fact there appears to be little to no cooperation between remailer operators. There are no remailer key servers to manage the server and user keys so the user must contact each remailer and obtain the key which is itself open to traffic analysis, note that such first contacts by definition have to be in the clear. Hope that Mallet starts their analysis AFTER you get your keys or else. If this process can't occur automagicaly there is little commercial utility for the system - it's too cumbersome.
First off, the size of the packets in no way effects the succes of a traffic analysis, only a cryptanalysis of their contents. Traffic analysis looks at four things: the incoming packet header, the outgoing packet header, and the times of receipt and transmission. The idea behind latency is that if it is chosen correctly and the packet re-transmission falls outside the analysis window there is no way to correlate the incoming and outgoing traffic. From the analysis engines perspective the events are distinct and non-related. Simply re-ordering the packets at re-transmission time does nothing if I set the window larger than the time it takes to resend the original traffic and the cover traffic. Setting the analysis window to infinity also causes the analysis overhead to grow quickly though this means that re-ordering and latency are irrelevant. A party implimenting traffic analysis is probably not going to look at the contents until they have a clear understanding of the traffic flow between the surveiled parties. At that point it is cheaper to look at the involved parties and see if one of them has a weakness that can be exploited (ie offer immunity to a herion addict) over doing actual expensive cryptanalysis. If you can subvert a member you are in the classic man-in-the-middle position. When the Austin Cpunks looked at Mixmaster about 1.5 years ago for several months it became clear that as implimented currently Mixmaster can't easily support public remailer key servers or automated non-user-involved chaining and processing (encryption & decryption). Shure the packets look the same, but unless you as the sender go in and manage that material you are shit out of luck. The remailers can't do it themselves without user intervention, that's economicly not viable.
It is actualy quite simple why you would want to do this. You could then in effect send the same packet (identical in every bit) to a set of remailers. Each remailer would then decode the packet and send it on. All but one would go to bogus addresses and the one remailer with the right key would get to resend to the next remailer(s). Plus none of the outgoing traffic would be to the same server, further complicating analysis. This also gives the user some control over how much cover traffic gets generated. However Mallet doesn't know which packets are which and therefore must follow every packet. This multiplies the number of hops in the traffic analysis that need to be analyzed. As mentioned in one of my previous posts, in this situation the complexity goes up by a power causing the required computing resources to trace the traffic to quickly become excessive. Sine this is so painful for you, I assume this is the end of this discussion. ____________________________________________________________________ | | | The financial policy of the welfare state requires that there | | be no way for the owners of wealth to protect themselves. | | | | -Alan Greenspan- | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http:// www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage@ssz.com | | 512-451-7087 | |____________________________________________________________________|
participants (1)
-
Jim Choate