Pipe-Net
Punk
punks at tfwno.gf
Thu Oct 17 15:47:00 PDT 2019
From: "Wei Dai" <weidai at eskimo.com>
Date: Tue, 7 Feb 95 17:32:30 PST
To: cypherpunks at toad.com
Subject: a new way to do anonymity
Message-ID: <199502080132.AA26151 at 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 at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: Johnathan Corgan <jcorgan at aeinet.com>
Date: Tue, 7 Feb 95 19:29:22 PST
To: weidai at eskimo.com
Subject: RE: a new way to do anonymity
Message-ID: <Chameleon.4.01.950207192939.jcorgan at 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 at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: eric at remailer.net (Eric Hughes)
Date: Tue, 7 Feb 95 20:10:39 PST
To: cypherpunks at toad.com
Subject: Re: a new way to do anonymity
In-Reply-To: <199502080132.AA26151 at mail.eskimo.com>
Message-ID: <199502080409.UAA22376 at largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain
From: "Wei Dai" <weidai at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: eric at remailer.net (Eric Hughes)
Date: Tue, 7 Feb 95 20:23:52 PST
To: cypherpunks at toad.com
Subject: RE: a new way to do anonymity
In-Reply-To: <Chameleon.4.01.950207192939.jcorgan at comet.aeinet.com>
Message-ID: <199502080422.UAA22395 at largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain
From: Johnathan Corgan <jcorgan at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: Johnathan Corgan <jcorgan at aeinet.com>
Date: Tue, 7 Feb 95 22:53:33 PST
To: eric at remailer.net>
Subject: RE: a new way to do anonymity
Message-ID: <Chameleon.4.01.950207225342.jcorgan at 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 at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: eric at remailer.net (Eric Hughes)
Date: Wed, 8 Feb 95 06:20:39 PST
To: cypherpunks at toad.com
Subject: RE: a new way to do anonymity
In-Reply-To: <Chameleon.4.01.950207225342.jcorgan at comet.aeinet.com>
Message-ID: <199502081418.GAA23140 at largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain
From: Johnathan Corgan <jcorgan at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: "Wei Dai" <weidai at eskimo.com>
Date: Wed, 8 Feb 95 14:44:03 PST
To: eric at remailer.net (Eric Hughes)
Subject: RE: a new way to do anonymity
Message-ID: <199502082243.AA19005 at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: Matt Blaze <mab at research.att.com>
Date: Wed, 8 Feb 95 15:35:55 PST
To: weidai at eskimo.com
Subject: Re: a new way to do anonymity
In-Reply-To: <199502082243.AA19005 at mail.eskimo.com>
Message-ID: <9502082318.AA21943 at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: "Wei Dai" <weidai at eskimo.com>
Date: Thu, 9 Feb 95 17:50:02 PST
To: cypherpunks at toad.com
Subject: RE: a new way to do anonymity
Message-ID: <199502100149.AA28876 at 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 at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: "Wei Dai" <weidai at eskimo.com>
Date: Thu, 9 Feb 95 17:52:22 PST
To: Johnathan Corgan <jcorgan at aeinet.com>
Subject: RE: a new way to do anonymity
Message-ID: <199502100152.AA29075 at 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 at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
From: jrochkin at cs.oberlin.edu (Jonathan Rochkind)
Date: Thu, 9 Feb 95 18:48:28 PST
To: cypherpunks at 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 at MHonArc.venona Wed Dec 17 23:17:14 2003
-----End-Of-Message----------------
More information about the cypherpunks
mailing list