From: "Wei Dai" <weidai@eskimo.com> Date: Tue, 7 Feb 95 17:32:30 PST To: cypherpunks@toad.com Subject: a new way to do anonymity Message-ID: <199502080132.AA26151@mail.eskimo.com> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- A week ago I made a suggestion for a new protocol for untracibility, but only got one response. I'll try again, this time more forcefully. I'm not trying to convince anyone to implement this (though of course you're welcome to!), but just to think about it and give me feedback. Why is another protocol needed? Right now we have only two, each of which has its own set of tradeoffs. To summarize: Mix-Net (i.e., remailer-net): high latency, moderate bandwidth costs, and low complexity DC-Net: moderate latency, high bandwidth costs, and high complexity While the DC-Net will probably never be widely used, the remailer-net has a fair chance of one day providing a way for many people to send e-mail that not even governments can trace. However, I don't think this is enough. Efficient social and business relationships require that people be able to converse to each other in real time. Cryptoanarchy will not come about if people cannot do this anonymously. How well can two pseudonymous agents negotiate a contract if each message they send must be delayed several hours? The protocol I sugguested would have low latency, moderate bandwidth costs, and moderate complexity. It would be well suited for people to interact anonymously in a textual environment. This is what I wrote:

Imagine a server that allows you to open a low bandwidth (let's say around 100 cps, in order to reduce costs) link-encrypted telnet session with it, and provides you with a number of services, for example a link-encrypted talk session with another user. You'll need to maintain the link 24 hours a day to defend against statistical analysis, and of course you can chain a number of these servers together in a way similiar to chaining remailers.

Lance pointed out the chain cannot be built quickly. This is not a problem if servers connect to each other with relatively wide link-encrypted pipes and multiplex your connection into these pipes. In this system, latency would never be more than a few seconds, bandwidth cost is N*100 cps (point to point), N being the number of links in your chain. Implementation would probably be harder than remailers, but much easier than DC-Nets. The protocol would also provide both sender and receiver untracibility without any need for broadcasting. Wei Dai P.S. I never gave a name for the protocol... let's call it Pipe-net. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzgewDl0sXKgdnV5AQGzvAQAgFaOxOzFPgS031z4jZRYUJp/+3BS5Con Kza7WsvZPvxzaNLh9ecD3aCx5dtf4muaiUKjC2HIItaLKEdZZPdzUGFd4wg1cY8G k8mvYNzDImr3ZtQ0HiqQ59PWhznad0GuhjQajB7RtpI+K/Z4uBaUEZGVoZZT+LHN MSjOl/k/yfg= =jgq6 -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai@eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: Johnathan Corgan <jcorgan@aeinet.com> Date: Tue, 7 Feb 95 19:29:22 PST To: weidai@eskimo.com Subject: RE: a new way to do anonymity Message-ID: <Chameleon.4.01.950207192939.jcorgan@comet.aeinet.com> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE-----

This is what I wrote:

...

Imagine a server that allows you to open a low bandwidth (let's say around 100 cps, in order to reduce costs) link-encrypted telnet session with it, and provides you with a number of services, for example a link-encrypted talk session with another user. You'll need to maintain the link 24 hours a day to defend against statistical analysis, and of course you can chain a number of these servers together in a way similiar to chaining remailers.

There are many, many analogies you can draw about a network of this type to an ATM (asynchronous transfer mode) network. By simplifying just slightly from what you describe to only include an encrypted, switched-pipe methodology, you now have a "cloud" type network with service entry points that are defined by a pair of byte streams (one in each direction). The switched path could be set up and torn down dynamically by the user by interacting with the "switch" at each point to select the next hop the encrypted byte stream will follow. Of course, just like in remailer chaining, the data that indicates which hop to follow is encrypted with the data in a form only the switch can decrypt. Alternatively, once a path is set up between switches, it can be assigned a virtual path identifier that has only local significance at each hop, with the switch performing a lookup to forward packets and substituting a new path number with significance at the next hop. The above description is pretty unclear, I think, but many of these concepts have been fleshed out to a significant amount of detail in ATM circles. Fixed length data packets (at the encrypted telnet level) also make it very easy to aggregate individual circuits into higher bandwidth pipes that connect server to server. With these continuously running with cover traffic, individual circuit establishment is much more immune from traffic analysis. Cover traffic is substituted with real traffic as necessary, up to the bandwidth of the pipe. To summarize, what has been described is a method to establish a "network within a network", using encrypted telnet, to provide a connection oriented, unreliable packet switched link layer protocol. Sounds remarkably similar to IP (except for the connection oriented portion of it.) What can you do with a network like this? By layering a TCP process on top of this "Pipe-Net" IP like service, any of the standard TCP based application protocols can function between two end point systems, such as SMTP, FTP, HTTP, etc. What is so neat about this is that it could probably be done in user space, and since the packet based protocol is defined as unreliable, switches could come and go, with some sort of switch-to-switch protocol that propagates route availability. Eric, you could probably chew on the trust implications of all this. Perry, I'm sure all the IPSP/SSL/SOCKS/whatever stuff you know so well could provide a lot of building blocks for this type of thing. Wei, your traffic analysis treatment of this sort of thing would go a long way toward uncovering weaknesses and determining operational requirements and limitations. Tim, what massive social effects would it have if this type of network service were to become widely deployed? :) At first glance, this Pipe-Net idea doesn't seem to take a lot of rocket science; it seems that most of the components or algorithms are are already in use, just in a very different way. I can think of a number of problems already, however. Spamming. Bandwidth limitations. Complexity of client and switch software. Standards. Flow control. In other works, all the stuff the ATM forum is already dealing with :) Come to think of it, has anyone thought of something like this before? == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan@aeinet.com -Isaac Asimov WWW: ftp://ftp.netcom.com/pub/jc/jcorgan/home.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzg6ME1Diok8GKihAQEBygP/do7MnM2Ha/b3nYNeVb/7mpJqAwgke3D6 VlyhtVjxTM2tn42Voz47BtwTMiR+zkiwI5Ha3EQs/fpJGY7x69YGY+arGXAn/VsI Xq7/onQd/LOv8JAjrxrgH2gLTCmfs57+sLJXqghHmSrxgothsK8XRLY1HDoYDfai EgiNUmMTXEM= =ENYC -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: eric@remailer.net (Eric Hughes) Date: Tue, 7 Feb 95 20:10:39 PST To: cypherpunks@toad.com Subject: Re: a new way to do anonymity In-Reply-To: <199502080132.AA26151@mail.eskimo.com> Message-ID: <199502080409.UAA22376@largo.remailer.net> MIME-Version: 1.0 Content-Type: text/plain From: "Wei Dai" <weidai@eskimo.com> P.S. I never gave a name for the protocol... let's call it Pipe-net. I don't think we really need a separate name for it just yet. The idea is composed of two pretty much independent elements: packet forwarding and virtual link encryption. These can be implemented separately and then combined to yield the kind of network interaction described. Getting the details right will be difficult, and I'd suggest that is where the discussion might profitably turn next. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: eric@remailer.net (Eric Hughes) Date: Tue, 7 Feb 95 20:23:52 PST To: cypherpunks@toad.com Subject: RE: a new way to do anonymity In-Reply-To: <Chameleon.4.01.950207192939.jcorgan@comet.aeinet.com> Message-ID: <199502080422.UAA22395@largo.remailer.net> MIME-Version: 1.0 Content-Type: text/plain From: Johnathan Corgan <jcorgan@aeinet.com> There are many, many analogies you can draw about a network of this type to an ATM (asynchronous transfer mode) network. Thank you for the analogy. It's always good not to reinvent the wheel when you don't need to. The switched path could be set up and torn down dynamically by the user by interacting with the "switch" at each point to select the next hop the encrypted byte stream will follow. When you set up a mapping on a packet forwarder, this is exactly the kind of initialization that would be required. It is also at this point that keying would be negotiated, etc. Fixed length data packets (at the encrypted telnet level) also make it very easy to aggregate individual circuits into higher bandwidth pipes that connect server to server. Now here's an important detail that needs to get done right. Is the forwarding for fixed length packets, variable length packets, or streams? Is this decision global or local? What are the latency and aggregatation effects? How important are these for different classes of data? (telnet v. voice, e.g.) I'd suggest just getting something running first, to get some prototyping experience. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: Johnathan Corgan <jcorgan@aeinet.com> Date: Tue, 7 Feb 95 22:53:33 PST To: eric@remailer.net> Subject: RE: a new way to do anonymity Message-ID: <Chameleon.4.01.950207225342.jcorgan@comet.aeinet.com> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE-----

There are many, many analogies you can draw about a network of this type to an ATM (asynchronous transfer mode) network.

Thank you for the analogy. It's always good not to reinvent the wheel when you don't need to.

Exactly. Anywhere we can "stand on the shoulders" of others reduces wasted time and effort.

When you set up a mapping on a packet forwarder, this is exactly the kind of initialization that would be required. It is also at this point that keying would be negotiated, etc.

Encrypt-Telnet to a switch process. Use text based command line sequence to check outbound paths, bandwidth available, negotiate quality of service, execute digital payment arrangements, etc. Conclude the transaction and get bumped to your next hop, where it happens all over again. Done right, it could probably be automated. It seems like a lot of effort, but if you remember that once an initial session is established with your Pipe-net Service Provider (tm), a given circuit can be relatively long-lived.

Now here's an important detail that needs to get done right. Is the forwarding for fixed length packets, variable length packets, or streams? Is this decision global or local? What are the latency and aggregatation effects? How important are these for different classes of data? (telnet v. voice, e.g.)

One of the lessons learned in the years-long debate between the telco folks pushing synchronous time-division multiplexing point to point circuit switches and the data folks pushing variable length packet-switched broadcast medium networks is that fixed length packets can give you both TDM and statistical multiplexing. So, at the bottom most session layer, moving bits around in fixed chunks allows you to do things easier like bandwidth pre-allocation, aggregation, circuit based congestion control, and negotiated quality of service agreements to end points in the network. To learn from the efforts that have come from the thousands of people working on ATM, we could take a look at what has emerged as the "ATM Adaptation Layer." AAL specifies methods to encapsulate various data formats and quality of service requirements onto this fixed length, continuous stream of data packets. There is one for voice traffic, which requires fixed bandwitdth and very little relative latency, another for LAN type data packets, which have bursty bandwidth requirements and variable packet sizes. Your comment above is accurate in that the requirements involved in a Telnet session are vastly different from say, PGP Phone over TCP. The good part about all this is that a lot of the thinking, testing, prototyping, and standardization has already been done. The standards exist today for adapting variable bandwidth, variable packet length, variable latency data packets onto a continous stream of fixed length packets moving through a switched network. This reminds me of the old days of Packet Radio which used intelligent repeaters that you would access (via command line), determine your next repeater, then log into it, etc. I once established virtual circuit from Connecticut to Florida over 2 meter packet that took 25 or so hops, and had a transit delay of a half an hour. Primitive, kludgy, unreliable, and essentially useless, but totally cool. An opportunity presents itself here to establish this Pipe-net style service network, that would greatly expand the ability for network users to essentially bypass all the crap which appears to be coming down on us from our friendly representatives in Washington, who are trying so hard to "protect" us from ourselves.

I'd suggest just getting something running first, to get some prototyping experience.

Of course. What I've outline is a pretty ambitious goal. I'd be happy to see primitive switch implementations that do nothing more than forward TCP streams. Its a start and we would learn a lot along the way. Alas, I don't do Unix; my programming expertise is in (gasp) the Windows environment. So it looks like I could start looking at the requirements implementation of a Winsock interface that made all this stuff transparent to an end user. Important consideration. I suppose the IRC folks could add their experience to the mix. In a very real way, IRC _is_ a packet switched unicast/multicast stream service on top of the 'net. Do we have any IRC op types onboard here? == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan@aeinet.com -Isaac Asimov WWW: ftp://ftp.netcom.com/pub/jc/jcorgan/home.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzhqMU1Diok8GKihAQGRxAP/dWIvYMuqX5c1y/Mlmc73WQlQ/1263vqb YzGMvgTFEP0p/jZZstb8tMOyHY2KKp7WWLXV94jd8/KhdQgYFtGHphVm93WP3Bu8 hRK8kV5UEtANQ/JycVHG6HU3MMxLhE+Yh+M/CFLBwBZZYYglnV3DLqBHv4kq+5Tg /7ZiTjnHRDk= =ee6L -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: eric@remailer.net (Eric Hughes) Date: Wed, 8 Feb 95 06:20:39 PST To: cypherpunks@toad.com Subject: RE: a new way to do anonymity In-Reply-To: <Chameleon.4.01.950207225342.jcorgan@comet.aeinet.com> Message-ID: <199502081418.GAA23140@largo.remailer.net> MIME-Version: 1.0 Content-Type: text/plain From: Johnathan Corgan <jcorgan@aeinet.com> One of the lessons learned in the years-long debate between the telco folks pushing synchronous time-division multiplexing point to point circuit switches and the data folks pushing variable length packet-switched broadcast medium networks is that fixed length packets can give you both TDM and statistical multiplexing. There's an important difference here. Namely, the telco/ATM folks were building hardware from scratch and we're not. We're layering on top of an existing Internet routing environment. This doesn't mean that your point is wrong, but that it may no longer be true when the base layer is IP. I'm not familiar enough with the ATM arguments to know whether they're still valid in this other domain. Eric From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: "Wei Dai" <weidai@eskimo.com> Date: Wed, 8 Feb 95 14:44:03 PST To: eric@remailer.net (Eric Hughes) Subject: RE: a new way to do anonymity Message-ID: <199502082243.AA19005@mail.eskimo.com> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE-----

I'd suggest just getting something running first, to get some prototyping experience.

Now that I've just spent some time compiling and playing with Matt's ESM program, it seems almost perfectly suited for prototyping Pipe-Net since you can use it to do nested encryption. All that's needed is to hack it so that it implements link encryption (i.e., send a constant stream of random data in between keypresses). This is what the user would do: (LESM for Link Encrypted Session Manager) lesm -l lesm -l login to server 1 lesm -s lesm -l (or better yet take over a free LESM session already running between server 1 and server 2) login to server 2 lesm -s lesm -s I wonder if Matt has the time and interest do this... If not then I guess I can try, but I've never done real crypto programming before... Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzlIdDl0sXKgdnV5AQFKuwQAqhJulKWcPV8GWUM11+2zonT+EQ8q18YV TAymUlhjuYo0csHP/nmoMDRpf/9veISdBQE/GlRkc1k0JsWpPBD0+6e0nA7kCTMO xqVoXdM3F/qN31CXjMT9rgAanIXFat2Ox3bjT3g07ReaN372TPnGGvNauxO69Z52 kvWajSSXiSY= =yF/i -----END PGP SIGNATURE----- From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: Matt Blaze <mab@research.att.com> Date: Wed, 8 Feb 95 15:35:55 PST To: weidai@eskimo.com Subject: Re: a new way to do anonymity In-Reply-To: <199502082243.AA19005@mail.eskimo.com> Message-ID: <9502082318.AA21943@merckx.info.att.com> MIME-Version: 1.0 Content-Type: text/plain ...

since you can use it to do nested encryption. All that's needed is to hack it so that it implements link encryption (i.e., send a constant stream of random data in between keypresses). ... You could just send a stream of some uncomon ascii character, which you filter out on the receiving end (if you wanted to this right, you could add a simple escape mechanism for actually passing that character).

To avoid flooding the network and also bringing the machines on which its running to its knees, you'd probably want to add a bandwidth-choke mechanism to run the white noise at some reasonable rate. You'd have to limit the real traffic output to the same rate. Link encryption over a broadcast network is a tricky business.

I wonder if Matt has the time and interest do this... If not then I guess I can try, but I've never done real crypto programming before...

For the next couple of months, I have absolutely no free hacking time. Things on the stack include: - ESM 1.0 - Diffie-Hellman encrypting and authenticating Telnet (almost ready...) - CFS 1.3 - The course - The book - My real work So I don't even have the time to figure out whether I have the interest. -matt From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: "Wei Dai" <weidai@eskimo.com> Date: Thu, 9 Feb 95 17:50:02 PST To: cypherpunks@toad.com Subject: RE: a new way to do anonymity Message-ID: <199502100149.AA28876@mail.eskimo.com> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Eric Hughes wrote:

Now here's an important detail that needs to get done right. Is the forwarding for fixed length packets, variable length packets, or streams? Is this decision global or local? What are the latency and aggregatation effects? How important are these for different classes of data? (telnet v. voice, e.g.)

I'm not sure I understand the first question. My idea was originally based on link encrypted streams. How can forwarding variable length packets help untracibility? Wouldn't an attacker just have to match up the sizes of incoming and outgoing packets? Forwarding fixed length packets, on the other hands, just makes the system a remailer-net (so you'll have to do mixing, etc.). What am I misunderstanding here?

I'd suggest just getting something running first, to get some prototyping experience.

I just finished hacking ESM to do link encryption. (see my other post) Now if someone is willing to run a MUD type program and hook LESM up with it, then we'd have the first prototype of a pipe-net. Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzrFzzl0sXKgdnV5AQFfOAP7BpGWmo7FLK02a10NVTfgLEeheBosazzz 0TbFs2dwhtL4IRtY6To25e7MN2cz4X+qKJOleWy6uGbUowygHKbd1uiHOS9DNRmx /fKeyIlGd/Ogv6hSpiL/JDd0vx7vVx9Ho1CIy+oAFq4v8Kwd0sqQenqqvhBdoEfA zmVUpc+82nU= =3mfe -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai@eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: "Wei Dai" <weidai@eskimo.com> Date: Thu, 9 Feb 95 17:52:22 PST To: Johnathan Corgan <jcorgan@aeinet.com> Subject: RE: a new way to do anonymity Message-ID: <199502100152.AA29075@mail.eskimo.com> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Johnathan Corgan wrote:

Wei, your traffic analysis treatment of this sort of thing would go a long way toward uncovering weaknesses and determining operational requirements and limitations.

It seems to me that if a user maintains a 24-hour a day pipe to an uncompromised server, then the method I described earlier against remailers should not work against that user. Otherwise, some kind of in-out statistical analysis may work.

Tim, what massive social effects would it have if this type of network service were to become widely deployed? :)

See Verner Vinge's _True Names_ for a fictional description of a future where real time anonymous interactions are possible.

At first glance, this Pipe-Net idea doesn't seem to take a lot of rocket science; it seems that most of the components or algorithms are are already in use, just in a very different way.

This is certainly true. The system Vinge describes is almost a pipe-net. But he didn't say anything about link encryption, without which the system can be trivially broken.

I can think of a number of problems already, however. Spamming. Bandwidth limitations. Complexity of client and switch software. Standards. Flow control.

In other works, all the stuff the ATM forum is already dealing with :)

I haven't responded to the comments you made about the similarity between pipe-net and ATM, mostly because I'm not very familiar with ATM. But as I understand it, ATM is based on forwarding fixed length cells, whereas pipe-net is based on fixed-bandwidth link encrypted streams. Spamming, and flow control shouldn't be problems, since all users of a server will connect to it with pipes of the same bandwidth, so it can just accept a certain number and then stop. Bandwidth limitations will depend on how fast the server CPU can do the encryption and decryption. With LESM at 100 cps, each connection took 2% of the CPU capacity of a Sun 4-CPU(90Hz) 4/670MP. Of course, I made no consideration for efficiency when I hacked ESM, so this can probably be decreased quite a bit. Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLzrGOzl0sXKgdnV5AQE1TQP/UR0xfaS/Nxk7ta/AfdRhzV+v+BmpxT4O UqiMkCpXRZbMFTuw/hnhlJ9fuOF2QS/50MUHXu+kiFSASH5wBFpLNSgWuFIHADny 76RYSjpA+A4IpWomihGT1/BPZkyIcooDXCKGUbgWjZhi50S0oCfAILjV/1ti2f02 AOyBxRYRYvM= =IhUw -----END PGP SIGNATURE----- E-mail: Wei Dai <weidai@eskimo.com> URL: "http://www.eskimo.com/~weidai" =================== Exponential Increase of Complexity =================== --> singularity --> atoms --> macromolecules --> biological evolution --> central nervous systems --> symbolic communication --> homo sapiens --> digital computers --> internetworking --> close-coupled automation --> broadband brain-to-net connections --> artificial intelligence --> distributed consciousness --> group minds --> ? ? ? From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message---------------- From: jrochkin@cs.oberlin.edu (Jonathan Rochkind) Date: Thu, 9 Feb 95 18:48:28 PST To: cypherpunks@toad.com Subject: RE: a new way to do anonymity Message-ID: <ab60837505021004ea5d@[132.162.201.201]> MIME-Version: 1.0 Content-Type: text/plain At 8:51 PM 02/09/95, Wei Dai wrote:

It seems to me that if a user maintains a 24-hour a day pipe to an uncompromised server, then the method I described earlier against remailers should not work against that user. Otherwise, some kind of in-out statistical analysis may work.

Ay, what a good point. I know this connection is incredibly obvious, but just in case no one has yet made it, I will. A "pipe-net" host running Wei's L- modification to Matt's ESM, which was also running a remailer, would provide pretty much untraceable entrance to the remailer net. The remailer software wouldn't even need to be integrated with the pipe software in any way, as long as the user had a secure connection to the host, he could just connect to the SMTP port and send the message to the remailer that way. I would guess that the attack Wei described, as well as almost every other, if not every other, traffic analysis attack would fail if users were utilizing this. You could trace the message to a given "pipe net" host using traffic analysis, but you wouldn't be able to trace it to a user, if he was using the pipe net appropriately. Obviously, this also requires a sufficient number of people to be using the pipe net host, so that no real information is gained just by tracing the connection to a given pipenet host. And of course non-pipe-net users are using the remailer on the machine to, which makes things a tiny bit more complicated for the traffic analysits Note also that the bandwith could be kept extremely low. Even something like 10cps. So, maybe it takes you up to a couple hours to actually transit your message to the pipe-net host remailer, but we currently dont' expect instantaneous remailernet transmission anyway. We've learned to live with latency on the order of hours, as opposed to seconds, so adding several more hours onto the chain isn't a problem. And with a bandwith maintained that low, the pipenet host could theoretically host many many "pipe net remailer" client users, without causing a serious problem. This seems like a really exciting thing to me. That we already have the tools available for, right now at this very second, now that Wei has done the link encryption mod to ESM. From cypherpunks@MHonArc.venona Wed Dec 17 23:17:14 2003 -----End-Of-Message----------------