October 2019 - cypherpunks - lists.cpunks.org

Darkweb News, Busts, USPS Supports DropGangs, Sites Galore...
by grarpamp 26 Oct '19

26 Oct '19

DarknetLive http://darknet7rl4epe24.onion/ Dreaddit http://dreadditevelidot.onion/ DarkFail http://darkfailllnkf4vf.onion/ https://news.ycombinator.com/item?id=21347820 USPS Supports Development of DropGangs http://darknetq7skv7hgo.onion/post/some-darkweb-vendors-are-concerned-about… Panopticlick 3.0 https://panopticlick.eff.org/ BBC on Darkweb https://www.bbcnewsv2vjtpsuy.onion/ https://news.ycombinator.com/item?id=21343241

1 0

Pipe-Net
by Punk 26 Oct '19

26 Oct '19

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

4 8

Re: Neowin: New OnionShare 2.2 update makes it easy to share files and host sites on the Tor network
by jim bell 26 Oct '19

26 Oct '19

Now, I'm sending to the list, also. On Thursday, October 17, 2019, 05:23:40 PM PDT, jim bell <jdb10987(a)yahoo.com> wrote: Okay, I'm not advocating (or opposing) this concept. It just seemed to me that since we are talking TOR-related features, we should pay attention to what TOR currently claims to provide. I think a few months ago, I mentioned the idea (which I assume somebody else thought of first, probably years ago) of splitting a file into two (or more?) pieces, stored in two (or more?) separate systems), which when XOR'd together, provide the (forbidden, banned, 'reallybad!!!' 'highly-illegal') product file. Neither file, alone, would be 'forbidden'. The purpose of this is not 'secrecy' of course, but merely deniability. Without the other file(s), the one file _I_ possess will be indistinguishable from a random number. In fact, it could be a random number, which when XOR'd with a forbidden text, becomes what amounts to another random number, and somebody else's system will hold the other 'random number' . Think Vernam cipher, otherwise known as a "one-time pad". https://en.wikipedia.org/wiki/One-time_pad Jim Bell On Thursday, October 17, 2019, 12:36:16 PM PDT, Steven Schear <schear.steve(a)gmail.com> wrote: Filesharing is a privacy dead end. Only something like Mojo Nation / Mnet publishing, where few or no participants need be aware of or hold file contents, offer viable plausible deniability. On Thu, Oct 17, 2019, 6:07 PM jim bell <jdb10987(a)yahoo.com> wrote: Neowin: New OnionShare 2.2 update makes it easy to share files and host sites on the Tor network. https://www.neowin.net/news/new-onionshare-22-update-makes-it-easy-to-share…

3 10

ElyNet - SIM-LESS blockchain telecom network
by grarpamp 26 Oct '19

26 Oct '19

https://medium.com/@elynet http://www.elynet.io/ https://t.me/elynet https://www.youtube.com/watch?v=CWBxQzl74pg

2 1

IQNets: OFFSystem - cursory review and conclusion
by Zenaan Harkness 26 Oct '19

26 Oct '19

The OFFSystem https://en.wikipedia.org/wiki/OFFSystem and similar (that "free speech" XOR concept it was related to and/or based on), is kinda cool at first glance. It uses RAID disk type principles to mix blocks (/files), to successfully mess upthe concept of copyright on a block: Choose a block size, say 128KiB. Take an original "copyrighted" block A of a file, which we want to store in our file/cache/block store. XOR A together with some other random block (let's say, a block B containing completely random data) - this produces a new block C which is a mathematical version/ combination/ "encoding", of block A. We add this new XOR block C into the store, and we can discard the original block A, since by running XOR again, but on blocks B + C, we are able to produce the original block A; of course we must store the XOR block map somewhere too, so we remember which blocks to XOR. The new block C is therefore quite arguably an encoding of the original copyrighted block A. And now, this new block C also looks like completely random data, and statistically it is, just not when XORed with one very special (in relation to block C) yet otherwise completely random, block B. Next we wish to add another block D copyrighted by some other party entirely, and you happen to randomly choose as your "random block for XORing" block C, producing block E (which you add to the block store) and again discarding this time block D. Original copyrighted, now discarded blocks: A D Block store: B (pure random data), C and E ('encodings' of A and D) Who owns the copyrights on the various blocks?: Block A is regenerated using B XOR C. Block D is regenerated using E XOR C, where C was chosen completely randomly. Block C is an encoding of A. Block E is an encoding of C, so E is also, quite evidently, an encoding of A, and in fact E { XOR C XOR B } gives A, so copyright holder of A can quite legitimately, within the assumption that he has copyright over all encodings of A, claim copyright over block E. But this would probably not be considered satisfactory to the copyright holder of block D, who can also with mathematical certainty, demonstrate that block E is an encoding of block D. --------------------------- In the "free speech" version (HTML paper courtesy grarpamp), this principle was used with a distributed "random data" 128KiB block store - sort of P2P, although it wasn't automated and this was 2000, so the link protocol was FTP, with the intention being the ability to distribute messages over the internet, exposing those messages "at some time in the future" via "just happened to notice these blocks ABC XOR to produce message XYZ". --------------------------- Utility appears to be confounding copyright holders. Utility for "free speech"? Not so much, since: - "speech", such as chatting and email demand various "reasonable maximum" latencies - for email, a few minutes max latency is desirable, often much longer can be tolerated, but still only up to "hours" - for chat/text/forum, a typed message needs to appear within seconds, ideally milliseconds What about storage requirements? Although some folks and systems are designed to record all history for a chat room, and email lists tend to work this way by default, there are many use cases for throwaway chat rooms and flippant discussions about the weather which most folks would never bother or want long term storage for. XOR/RAID-type block stores, where new blocks are created and added to the store based on randomly chosen prior blocks, have the apparent (on first look at least) requirement that all older blocks are kept and never deleted - there may be some other blocks in your store, or in the block store of some peer, depending on your old block. Secondly, except that compression is applied before storage, there is no compression of compressible data (this is solvable in end user software of course - just compress all new blocks before storing, and remember to notate the compression algorithm used). Thirdly, deduplication is not part of the above systems, and would not appear to add much utility anyway... most material is new material and some git style content mapping/ addressing solution is what's really wanted in an upper layer anyway. So we have a significant unavoidable problem built in to this type of system: - an ever expanding block store, where older blocks can never be deleted since they may be XOR encodings of newer blocks, in yours or other's' (in the case of a distributed store) block stores --------------------------- Storing interesting content?: Some content is illegal in one jurisdiction, whilst being legal in another jurisdiction. So what about the case where you happen to be in a jurisdiction where such content is illegal in your jurisdiction?: Someone with access to your block store, can run permutation XORs up to large counts, with enough computing power. This can be described also as "pot luck" - do you want to entrust your defence against local laws to pot luck? Of course, blocks can be hidden with encryption, but then we've already got veracrypt, so what does the extra XOR/RAID layer add? Nothing AFAICT. And if you're storing copyrighted content in your block store to which you simply don't have lawful right to access/view/share, then your block XOR maps must be stored somewhere anyway, with an application that can read and present you with your illicit copyright infringing library of content, for local viewing. That app could put a password on that, but now we're back to password management, crypto password salting, key blocks for multiple keys and etc - i.e., we're back to veracrypt/luks, and again, why bother with OFFsystem? --------------------------- Conclusion: XOR/ RAID stripe type block mixing appears potentially great for confounding copyright holders in an actual court case. This could be a good way for a library to store their digital media - "no Judge, if we remove those copyrighted blocks, we are removing the encodings of many other digital works we store; can't do, won't do". "Potentially contentious" media would be consistently followed by a bunch of other media, all intermingled (this is another time factor problem - in OFFsystem, earlier blocks get more dependencies on them, to later blocks).

1 1

Psychological Warfare... Destroy the alt-right Symbols
by Razer 26 Oct '19

26 Oct '19

On the #MAGA front: https://auntieimperial.tumblr.com/post/188596454164 Rr Sent from my Androgyne dee-vice with K-9 Mail

1 0

Cryptocurrency: Crypto For Activism - Rojava, Liberland
by grarpamp 25 Oct '19

25 Oct '19

> Manifesto for a Democratic Civilization, Vol I - Civilization: The Age of Masked Gods and Disguised Kings - Abdullah Ocalan ISBN: 8293064420 ISBN13: 9788293064428 > Manifesto for a Democratic Civilization, Vol II - Capitalism, The Age of Unmasked Gods and Naked Kings - Abdullah Ocalan ISBN: 8293064463 ISBN13: 9788293064466 > https://www.goodreads.com/author/list/693443.Abdullah_calan > http://new-compass.net/publications/manifesto-democratic-civilization-vol-i > https://www.akpress.org/manifestoforademocraticsociety2.html > https://en.wikipedia.org/wiki/Abdullah_Ocalan > > https://en.wikipedia.org/wiki/Kurdistan_Workers'_Party > https://en.wikipedia.org/wiki/People's_Protection_Units > https://en.wikipedia.org/wiki/Women's_Protection_Units > https://en.wikipedia.org/wiki/Anarcha-feminism > https://en.wikipedia.org/wiki/YPG_International > https://en.wikipedia.org/wiki/International_Freedom_Battalion > https://en.wikipedia.org/wiki/Rojava_conflict https://en.wikipedia.org/wiki/Rojava https://en.wikipedia.org/wiki/Constitution_of_North_and_East_Syria https://mesopotamia.coop/rojava-administration-to-impose-tax-system-in-nort… There are now "government" "constitution" "social contract" "income taxes" "democracy" "courts" "police" "political parties" "public schools" etc ruling over the region. While unique on many levels, governments have a history worldwide, so the region might not remain any particular bastion of say libertarian cooperative over future decades. Any more than say... Liberland https://www.youtube.com/channel/UCh29cq8F3Iz7iqyI_LRhyVQ/videos Anything potentially more free than the rest of the world are still worth trying, getting involved with, following.

1 0

Cryptocurrency: Crypto For Activism - Micah White and Amir Taaki - Books
by grarpamp 25 Oct '19

25 Oct '19

2 2

India starting to stand up for her own people - [PEACE]
by Zenaan Harkness 25 Oct '19

25 Oct '19

Many like to take sides, express preferences, and judge as armchair generals, especially Western gen-me sycophant snowflakes in glass houses of relative luxury. Some are under the "Christian dogma" thumb of "do not defend nor stand up for yourself, your family, nor your principles", a sad and lame twist on "turn the other cheek", instead cowtowing to politically correct "dogma nartsees" with no insight into the tyranny and slavery under their own feet. India no more denies her right to stand up for her own people, having faced down China in a months long border standoff, and the USA's sanction threats for ponying up for Russia's S400s, doubled down with French Rafaale fighters, and has in just recent years begun to deliver some serious eye for an eye responses to her Muslim neighbour's "message by mass murder" zealotry (see extract below). India's message is being heard, the USA has backed down, and dignity and partnerships are on the rise. "Nice to see dignity on the rise." New India lauds Mahatma Gandhi on all but one important matter https://www.rt.com/op-ed/471539-india-modi-gandhi-pakistan/ ... Gandhi was the “apostle” of peace and non-violence who offered the other cheek when slapped but the India of today would rather leave a black eye on its aggressor as it did on Pakistan with retaliatory heavy shelling in Pakistan Occupied Kashmir (PoK) on Sunday, which left at least 6-10 Pakistani soldiers dead and blew up three terrorist camps into thin air. It was a grim fresh reminder to Pakistan that India has the doctrine of an eye-for-an-eye in its new rulebook and the “surgical strikes” and “Balakot airstrikes” which followed the terrorist attacks in Uri (2016) and Pulwama (2019) are the new philosophy and not an exception. India is still an adherent to “non-violence” and has an unbroken history of peaceful coexistence, never eyeing others’ territory but the painful lessons of the past demand it puts a premium on the integrity of its Union. India's National Security Advisor Ajit Doval often reminds his audience that India was overrun by invaders despite being arguably the most advanced civilization of its time. It never protected its seas even though they straddle three of its four corners. It led to the servitude of almost a thousand years. It faced wars imposed by Pakistan on three of four occasions: 1947-48, 1965 and 1999. It didn't use 90,000 prisoners-of-war as a bargaining chip nor did it advance deep inside Pakistan after winning a conclusive war in 1971 which led to the creation of Bangladesh. India was seen as the epitome of a “soft” nation as terrorists kept crossing the Line of Control (LoC) through Punjab and Jammu and Kashmir and cost tens of thousands of civilians and soldiers’ lives since 1990. The horrific attack in Mumbai, India's commercial capital, when terrorists from across the border sprayed machine guns on civilians on the streets and five-star hotels, known as 26/11 in the nation's damaged psyche, evoked no retaliatory response from India. Worse, the very next year in 2009, the same United Progressive Alliance (UPA), returned to power without any retribution from its masses. All this has changed for good. India today is driven in its bid to modernize its army: It has only recently ceded its top spot to Saudi Arabia as the biggest arms importer of the world — the Stockholm International Peace Research Institute (SIPRI) reckons India accounted for 12 percent of the total global arms imports for the 2013-2017 period. It has lapped up Russia's S-400 advanced missile system defying the threat of sanctions from the United States. It has gone ahead with its purchase of France's Rafale fighter jets even though the move threatened to derail Indian Prime Minister Narendra Modi's bid for a second term on unfounded charges of corruption this year. India today is literally taking the fight into the enemy camp: It raked up the issue of Balochistan and its independence from Pakistan; it has vowed to wrest back the control of PoK for a unified Kashmir and its Defense Minister Rajnath Singh has already debunked the ‘No-First-Use’ nuclear doctrine. India stood up for its ally Bhutan and stared down China in a face-to-face standoff between the two armed forces in Doklam in 2017 which lasted months. ...

1 0

DMARC + DKIM info for list admins - [sysadmin@gnu.org: Fyi: this list, bug-mailutils, just had it's subject [tag] and footer removed]
by Zenaan Harkness 25 Oct '19

25 Oct '19

May be of interest to some... ----- Forwarded message from sysadmin(a)gnu.org ----- From: sysadmin(a)gnu.org To: bug-mailutils(a)gnu.org Date: Thu, 24 Oct 2019 16:15:40 -0400 Subject: Fyi: this list, bug-mailutils, just had it's subject [tag] and footer removed List-Id: Bug reports and feature requests for GNU mailutils <bug-mailutils.gnu.org> The Free Software Foundation has changed the GNU Mailman settings on this list. The short version is that any subject prefix or message footer has been removed, allowing us to turn off DMARC from munging. Any list administrator for this list is free to change these settings back, instructions are below. The change is to better deal with increased adoption of the DMARC email standard. The default Mailman settings were causing messages sent from users with strict DMARC policy domains like yahoo.com to be rejected when sent to list subscribers by Mailman. See the end of this email for a technical overview of DMARC and DKIM. There are two main ways to fix the issue by changing Mailman list settings. The first option, and the preferable way for discussion lists, is what we call the "unmodified message fix." There are Mailman list settings which modify the messages by adding a subject prefix (e.g. [list-name]) or a footer. Modifying the message breaks DKIM message signatures and thus DMARC, so we just turn those off. Many lists are already this way and there is no change for them. Instead of using the subject prefix to identify a list, subscribers should use the List-Id, To, and Cc headers. List footer information can also be be put in the welcome email to subscribers and the list information page by list administrators. We changed the default for new lists to send unmodified messages, and are now updating existing discussion lists to the new default. We emailed all list administrators and moderators and Savannah group admins to allow them to opt in to the alternate fix before we made this change. However, not all lists had a valid administrator contact. The second option is for lists which want or need to continue to modify the message, for example with subject prefix or footer settings. In this case we turn on a Mailman list setting called dmarc_moderation_action: "Munge From". With this, if a strict DMARC sender sends to the list, we alter the headers of that message like so: A message sent to the list: From: Anne Example Person <exampleperson@examplepersonsdomain> Is modified by Mailman and sent to subscribers as: From: Anne Example Person via Alist <alist@listdomain> Reply-To: Anne Example Person <exampleperson@examplepersonsdomain> Without going into all of the details, here's a few points about why we concluded the unmodified message fix is better for discussion lists. Email clients don't all treat munged messages the same way as unmunged, and humans read these headers so it can confuse people, causing messages not to be sent to the expected recipients. GNU Mailman has an option to do "Munge From" always, but does not recommend using it[1]. While we're not bound by what others do, it's worth noting that other very large free software communities like Debian GNU/Linux have adopted the unmodified message fix[2]. The unmodified messages fix avoids breaking DKIM cryptographic signatures, which show the message was authorized by the signing domain and seems like a generally good security practice. Tools to manage patches, for example patchew, use the from field and are tripped up by from munging. For any Mailman list administrator who wants to change or look over the relevant settings: The dmarc_moderation_action setting is under "Privacy Options" subsection "Sender Filters". The only options that should be selected are "Accept" or "Munge From", along with corresponding changes to the subject_prefix option under "General Options", and msg_footer is under "Non-digest options". If no list administrators or moderators are around for this list, anyone should feel free to try to track them down or figure out who should become one and explain in detail by replying to sysadmin(a)gnu.org. Please be patient, this process may take several weeks. Please send any questions that should be public to mailman(a)gnu.org. For private ones, just reply to sysadmin(a)gnu.org. For the general announcement of these changes, please read https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018… and https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016… A short DMARC technical overview: DMARC policy is a DNS txt record at a _dmarc subdomain. For example: $ host -t txt _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:address@hidden;"; The only important thing there for our purpose is p=reject. p=reject means that conforming mail servers that receive mail with a from header of *(a)yahoo.com will reject that email unless it was either 1. sent from Yahoo's email servers, or 2. its DKIM signature is verified. A DKIM signature[5] is a public key cryptographic signature of the email body and some headers included in the message header "DKIM-Signature". A verified DKIM signature means that email body and signed headers have not been modified. Comprehensive resources about DMARC tend to downplay or ignore its problems, but some that have helped me are Wikipedia[6], the Mailman wiki[1], dmarc.org wiki[7], and the DMARC rfc[8]. [1]: https://wiki.list.org/DEV/DMARC [2]: https://lists.debian.org/debian-devel-announce/2015/08/msg00003.html [5]: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail [6]: https://en.wikipedia.org/wiki/DMARC [7]: https://dmarc.org/wiki/FAQ#senders [8]: https://tools.ietf.org/html/rfc7489 Ian Kelling | Senior Systems Administrator, Free Software Foundation GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF https://fsf.org | https://gnu.org ----- End forwarded message -----

1 0