Forwarded message:
Date: Thu, 2 Oct 1997 11:33:00 -0400 From: Anonymous <anon@anon.efga.org> Subject: Re: Remailers and ecash (fwd)
Jim Choate:
For the sender to chain from remailer to remailer to destination the destination has to be in the header info somewhere. Now in the most secure system each packet header will only contain the address of the next hop. When the next site gets it the packet contents are de-crypted (otherwise reading the chaining info is trivial) and the contents are uncovered to reveal another packet with the next hop header and another encrypted block. And on and on we go.
<Question: Are there any remailer sets that impliment the encrypted nested packet system?>
Jim Choate has been amazingly clueless throughout this discussion, but this takes the cake. Does he really not know about encrypted nested chaining? My God! Of course remailers work this way, Jim. They've worked this way practically from the beginning. All remailers work this way.
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.
The mixmaster remailers are built around this idea, making each packet a constant size and adding dummy packets as new ones are stripped off, so outgoing messages look just like incoming ones.
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.
<speculation: an encrypted chain could be made stronger if the next hop header depended on which key was used to decode it. In other words, remailer A's key will produce one next hop address while remailer B's key will send it elsewhere. This is a subset of the different plaintext - same cyphertext problem - a hard problem as I understand it. Find two distinct texts that encrypt with different keys to the same cyphertext>
That won't help. There would be no point in doing this. I'd ask you to explain, but that would just prolong the agony.
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 | |____________________________________________________________________|