- cypherpunks - lists.cpunks.org

F2F UDP mesh net prototype proof of concept "Covfefe Net"
by Zenaan Harkness 28 Oct '19

28 Oct '19

On Sat, Oct 19, 2019 at 03:52:30PM +1100, Zenaan Harkness wrote: > On Fri, Oct 18, 2019 at 09:06:09PM +0100, Steven Schear wrote: > > Isn't that why networks like i2p exist? > > There is at least 1 attempt to rewrite I2P, and he is not even > interested in the core improvement - chaff fill. > > Tor is fundamentally compromised, as Juan correctly points out: > > - TCP, not UDP, as base protocol > > - no chaff fill > > - independent "core router" operators, e.g. Jacob Applebaum, have > been purged from Tor core group - in a rather brutal public > lynching manner (classic CIA psy op) > > > I2P is not government funded, and so "new user/ high speed internet/ > low latency" experience, is not enticing to said new users. This ought be fixable with a suitably compelling design. > A fundamental difference from Tor's "core high performance routing > nodes" and TCP (connection base mode) compromises (along with chaff > fill), are: > > - mesh network > - UDP connectionless base network > - chaff fill > > For any network, your entry nodes are a fundamental privacy problem/ > issue. > > Tor settled on "choose 1, stick with it for a few months or more, > since the more you hop, the greater the chance you hit a compromised > entry node anyway". > > A fundamental difference for an alternative needs to be F2F - friend > to friend connections. You -must- find meat space humans who join in > your freedom/liberty network, if you want the possibility of not > being immediately GPA statistically sniffed. > > I'll have a look see... OK, most of the bits I am comfortable with, although it will take some weeks to code up a Java GPL3 Linux based proof of concept. This shall be an attempt to establish what we need to know, so will almost certainly be rewritten at least once, as we figure out what we didn't know, and need to do, to make something approaching a "proper" design and implementation. See https://github.com/zenaan/covfefe if you wish to follow along with this exploration. Some basics: - UDP base protocol - at least initially - (lower/ higher/ HTTP tunnel bridges etc later) - 100% P2P, no central auth needed - trust metrics for "friends" (the F in F2F) - configure default provision/ reservation of available bw for friends/ various "trusted peer" levels of trust - the rest can make do with the rest of the available bw - TUN/TAP based, Linux is comfy here (OpenVPN has Windows drivers), this allows ready userspace development iteration - back of envelope calc for 24/7 connection at 8 Kibit/s (1 KiB/s): https://en.wikipedia.org/wiki/Data-rate_units seconds / day = 60*60*24 = 86400 bytes / day = 86400 * 1 * 1024 = 88,473,600 MiB / day = (bytes/day)/1024^2 = 84.375 GiB / month = ~2.5 - end user node originated routing (similar to Tor) - implies a node needs to know about other nodes - peer nodes provide info about their immediate peers - possibly also about peers they've been informed of - peerInfo contains asserted trust metrics - third hand trust is below first hand trust - meat space trust assertions are primary trust source - with Tor Browser and no local node, user is with high certainty exposed to deep pocketed GPAs running majority of entry nodes - you NEED at least 2, possibly more (need thought on this) "trusted" peers to have sane net entry - Sybil attacks: We are out-competed in any trustLESS network (well funded GPAs); - so we have no option but to establish at LEAST 2, possibly at LEAST more than 2 (idk yet), meat space "trusted" humans, at least for certain or most network entry - in a very real way, in this way CovfefeNet will mirror real relationships in our day to day life - yes, you may choose to trust someone you've never met, but have built a long term communication relationship with online for example - you must decide who and for what purposes, you trust any individual - initial F2F connection is a control socket (UDP) and one or more uni- or bi-directional data sockets (UDP) - If you have NO one you can trust in meat space, you're Shit Outta Luck, sorry... your #1 job is to engage with real live humans and establish actual relationships - you might have to go through a few dozen - or a few 100 - to find the gem you can trust. There is no other way. Sorry about that, but reality is our tutor by default. - serialization (of e.g. control messages), some combo of: - YAML, or a YAML subset - protobufs - DJB's nacl crypto - possibly Linux LUKS volumes for local store - LUKS supports also Veracrypt for Windows compat - STUN etc NAT router port busting libs and protocols - if you want something approaching "secure", don't even consider MS Windows or MacOS - available node bandwidth us known/configured, and/ or established over time - available node bw may drop off a cliff, e.g. when shaped by ISP - available node bw may suddenly rise, e.g. when unshaped by ISP - strict bw control qdisc (Azureus Vuze seems to do rather well) - strict priority queueing for control sockets - possible "realtime" data socket qdisc (QoS) for e.g. phone calls - preference for Friend peers - reserve headroom X KiB/s for friend peers - hand out remaining [CONFIGURED KiB/s] to incoming requests - connect to known contacts/ peers/ "friends" - peer provides set of 1r (once removed) peers, they provide 2r (twice removed) peers etc - additional connections may be made to additionally known peers - maintain peers (metrics) db over time - "friendly" control / intention notifications, optional - "I intend to stay online until T time" - "I seek 2.5 hours at 10KiB/s rt QoS" (e.g. phone call) - "I am about to go offline, in D duration" - possible friend response request "Please give me +10 minutes" - possible responses ACK, NAK, or no response Has anyone here coded, or knows someone who's coded network stream queueing and shaping code for bittorrent or similar? I'm not clear on how best to individually shape (i.e. strictly control) a few thousand UDP connections - think data structures. - Not reading from a peer's incoming port will presumably cause the sender's queue to block up, but we're doing a "request BPS bw for T time period" model, so we can do much better than relying on OS queueing, namely we can stay below "known bandwidth" of our respective (local) physical links Short of direct answers as to functional ADTs (maps, rings, cascading priorities, etc), I shall investigate torrent clients and bone up on qdiscs. Keep in mind, at least primary routing decisions are all made by the origin peer - although the possibility of mid-hop multi path stream setup of some sort might be useful (but imagine your GPA killing your lone origin connection to establish that yes, it's you sending/receiving that particular stream in the middle): Multipath TCP: an overview [2013] https://lwn.net/Articles/544399/ Upstreaming multipath TCP [2019] https://lwn.net/Articles/800501/

5 29

Oxford University bans clapping to "stop triggering anxiety" - [PEACE]
by Zenaan Harkness 28 Oct '19

28 Oct '19

Universities are bringing down the hammer on free expression, to keep their spaces safe for clapping triggered anxiety snowflakes. When will this ongoing madness end? Probably not before the looming USD global financial reset, since TPTB (the (((central bankers and investment bankers))) of the world) want us to stay focused on petty problems, and not the core issue... ... remember the Fed ;) Oxford University Bans Clapping At Student Union Events To "Stop Triggering Anxiety" https://www.zerohedge.com/political/oxford-university-bans-clapping-student… What kind of grudge do British universities have against clapping? Roughly one year after the University of Manchester Student Union banned clapping at its events - choosing to instead ask audiences to use 'jazz hands' to show their appreciation for a performance - students at the University of Oxford are working to "replace clapping" because it could "trigger anxiety." Like their peers in Manchester, they will ask audiences to use silent hand-wave motion called "jazz hands". The motion to "mandate the encouragement of silent clapping" successfully passed in a vote taken by the school's Student Union during their first meeting of the new school year. The ruling will apply at all student union events, and if successful, might spread to over organizations and events at the school. "Jazz hands" is the British Sign Language movement to express applause. It is considered a "more inclusive" gesture. "The policy was proposed in order to encourage the use of British Sign Language clapping during our democratic events, to make those events more accessible and inclusive for all, including people who suffer from anxiety," said Sabbatical Officers Roisin McCallion. And "inclusivity" is one of the universities' founding virtues, Metro UK said. And, of course, it's only a matter of time before "excessively vigorous jazz hands" and any significant vocal expressions are banned with only "gentle waving" allowed, in order to "stop triggering anxiety" in those who are triggered by rapid or vigorous muscular motions... Methinks SOME folks need some counselling...

3 4

pre-crime National Disruption & Early Engagement Program arrives in the USA - down it comes - [PEACE]
by Zenaan Harkness 27 Oct '19

27 Oct '19

Freedom has a price. Free people pay the price for freedom. The rest are slaves. We exist with the right to be presumed innocent. We exist with the right to communicate freely and anonymously. We exist with the right to travel freely and anonymously. Science fiction becomes rights-violating reality: With Little Fanfare, William Barr Formally Announces Orwellian Pre-Crime Program https://www.zerohedge.com/political/little-fanfare-william-barr-formally-an… https://www.mintpressnews.com/william-barr-formally-announces-orwellian-pre… Last Wednesday, U.S. Attorney General William Barr issued a memorandum to all U.S. attorneys, law enforcement agencies and top ranking Justice Department officials announcing the imminent implementation of a new “national disruption and early engagement program” aimed at detecting potential mass shooters before they commit any crime. Per the memorandum, Barr has “directed the Department [of Justice] and the FBI to lead an effort to refine our ability to identify, assess and engage potential mass shooters before they strike.” The Attorney General further described the coming initiative, slated to be implemented early next year, as “an efficient, effective and programmatic strategy to disrupt individuals who are mobilizing towards violence, by all lawful means.” More specific information about the program is set to follow the recent memorandum, according to Barr, though it is unclear if that forthcoming document will be made public. ... However, the memorandum differentiates suspected terrorists from the individuals this new program is set to pursue. Barr states that, unlike many historical terrorism cases, “many of today’s public safety threats appear abruptly and with sometimes only ambiguous indications of intent” and that many of these individuals “exhibit symptoms of mental illness and/or have substance abuse problems.” Thus, the goal of the program is ostensibly to circumvent these issues by finding new and likely controversial ways to determine intent. As will be shown later in this report, Barr’s recent actions suggest that the way this will be accomplished is through increased mass surveillance of everyday Americans and the use of algorithms to analyze that bulk data for vaguely defined symptoms of “mental illness.” Barr also suggested the likely courses of action that would follow the identification of a given individual as a “potential mass shooter.” The Attorney General notes that in past cases individuals deemed a violent or terroristic threat before they commit a crime are subject to “detention, court-ordered mental health treatment, substance abuse counseling, electronic monitoring”, among other measures. Ostensibly, the new program would then apply these same practices to individuals in the U.S. that federal authorities believe are “mobilizing towards violence,” as Barr put it. ... Barr went onto say that “warrant-proof encryption is also seriously impairing our ability to monitor and combat domestic and foreign terrorists.” Barr stated that “smaller terrorist groups and ‘lone wolf’ actors” — such as those involved in the series of mass shootings in California, Texas and Ohio that occurred in the weeks after his speech — “have turned increasingly to encryption.” Barr later noted that he was specifically referencing encryption used by “consumer products and services such as messaging, smartphones, email, and voice and data applications.” To overcome the resistance by some private companies — who do not want to renege on their right to privacy by giving the government backdoor access to their devices — and American consumers, Barr tellingly anticipated “a major incident may occur at any time that will galvanize public opinion on these issues.” Shortly after this speech, several mass shootings, including one at an El Paso Walmart took place, which again brought the issue to the forefront of political discourse. As MintPress reported at the time, Barr’s uncanny prediction and a litany of other oddities related to the El Paso shooting left many answered questions about the FBI’s foreknowledge of the event. In addition, the tragedy did appear to serve as the very “galvanizing” event that Barr had anticipated, as the solution offered by President Trump in the wake of the shootings was the creation of a government backdoor into encryption as well as calling for the very pre-crime system Barr formally announced just last week. The pre-crime dragnet takes shape ... [worth reading in its entirety]

1 1

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