- cypherpunks - lists.cpunks.org

high latency low b/w ping circles: random vs clocked
by Zenaan Harkness 27 Oct '19

27 Oct '19

Here's an obvious in hindsight thought: Use case: A (hidden, encrypted etc) ping circle (some combo of star or token ring yet to be designed) amongst a group of friends who may at random points in time, wish to send wheat txt sms in the chaff of the regular circle ping. Usually the ping is chaff. Any particular ping can be wheat (an sms/txt/email). If the ping is clocked, and there is any leakage of the clocking, then a GPA jamming my ISP link for say 5 seconds, right at the time I'm about to send my regular ping, would expose the other node(s) I am pinging. If the ping is not clocked, but is timed (clocked) to a statistically random time within a configured window, the GPA cannot know when to conduct their latency injection attack, and any dropout by me, would be seen by those who failed to receive my ping or received a delayed ping, as nothing but white noise, since every ping is randomly timed anyway. [To state what ought be obvious, the pings, though high priority when they are sent at extreme high (compared to normal web traffic) latency intervals, are still sent through 'regular' chaff-filled links, and so except for my local links temporarily dropping out, a GPA stalker should not be able to determine destination nodes for my ping, with any latency injection attack. The reasons we can make such an assertion and believe this holds true: - active latency injection attacks operate on the principle of statistically modifying the distribution of packets across a route (in time (for latency) or some other metric e.g. size) - in the case of extremely high latency packets (say, 1 hour between packets) at least when sent between nodes trusting one another or via nodes which, if they introduce a few seconds or minutes of latency, cannot meaningfully impact the ping, the relevant statistical "distribution of packets across time" is in the order of (in this example) hours - the b/w consumed by such ping circles very low - those in my ping circle, have little incentive to close such low b/w "chaff filled links" on the outgoing side - and in fact, those who want to see freedom of anonymous speech, will actively support such links (again, due to their low network costs) - and so those nodes which do NOT maintain such links when requested, naturally increase their stalker score (as viewed by others). ] "Treat each use case for its unique snowflake characteristics, and we provide for the possibility to optimize that particular use case."

1 3

latency injection attack mitigation
by Zenaan Harkness 27 Oct '19

27 Oct '19

There are two primary network stream origin node "latency injection" identification attacks, passive and active. Each attack begins with the attacker establishing one or more network streams through a target node to stalk, and attempting to manipulate its io streams. ## Passive latency injection attacks A passive attack involves stalking two nodes to ascertain whether they are the same node, or to ascertain whether one node is in the path of the other or otherwise effects the other. Our garlick/pipe/iqnets net attempts to mitigate such passive attacks with chaff file, packet switching with pre-agreed routes and pre-agreed b/w, and recording and booting nodes which fail to deliver (whilst we must also consider an innocent end user node who is under attack, and how to identify and correct for this). ## Active latency injection attacks An active latency injection attack is performed by having control of a physical node directly in the path of a stalked node - in practice the simplest version of this is the first physical hop for an end user node, which is typically one of their ISP's routers. Attacker simply suspends a stalked node's entire internet connection for a suitable number of milliseconds (say 57ms, or whatever is large enough given typical/ default iqnets config), and if attacker sees a stream somewhere else under the attacker's watch, display's a latency spike of around 57 ms, the attacker has with high probability identified the target they are stalking. If attacker's probability of ID of stalked node is only say 30% (due to network jitter or whatever), simply repeat the latency injection a couple more times, to increase to certainty. Such low magnitude latency injections (only 57ms, or even less), can be readily used over dozens or hundreds of targets, to bisect a large set of stalked nodes, to determine specific nodes of interest. The ONLY (caution, absolutism in operation here!) obvious mitigation to such active stalking (and still only for some cases) is: - create/use dark links, not just govnet links (you need at least one "first hop" link you can trust, which also means hardware you can trust) - "link" as in physical connection, i.e. "immediate/ first/ next hop from me" - maintain govenet (ISP) routes for others, not immediately for yourself - only use govnet for yourself as a fall back, and if you don't care about being actively stalked - monitor all first-hop/friend nodes, including dark links, for signs of latency injection attack/victim in operation ## Other mitigations: - stream splitting, possibly to a high degree ("many micro streams") and separate routes for each micro stream - widely and finely dispersed content addressed content distributiona and retrieval, thus: - eliminating fat streams - eliminating single points of failure - thereby reducing possible identification of that nodes which fail, and nodes that up/download - server-less web "applications" - content addressed DHT based forums, web sites etc - requires effective (incentivized) distributed cacheing models - for rare/old content, "cache of last resort" is an hopefully solvable problem - in the case of clear net content producers, presumably such content producers have an interest in making their content available, except when they don't or when they modify older content, mitigated with - content addressed content (git style ob stores) - distributed cacheing - end users who take an interest in archiveing old content and holding content producers/ reporters to account for what they did in fact say - for phone calls, which require real time / low latency, fixed rate streams, you're going to need dark links, or you are going to be exposed to active latency injection attacks (although, in the middle of a phone call, if the overall network params are right, latency injections should be audibly identifiable at least)

1 0

print 93 page PDF as 3-up landscape, but reduce margins?
by Zenaan Harkness 27 Oct '19

27 Oct '19

Anyone know how to convert or print a large PDF as 3-up, whilst reducing margins so that so much white space is not wasted (and so the text is more legible)? Here's the paper of interest: A Wire-Compatible TCP Implementation for Low-Latency Applications http://blog.cerowrt.org/papers/bbr_thesis.pdf

1 0

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