With respect for gold diggers, how is it decades after setting up the internet by officials and their consultants there continue to be dreamy and futile efforts to use the "lawless" tool without being observed. Its like the shrewd peddlers of picks, axes, pans and pussy to obsessed diggers of land salted with tiny nuggets and dust and comely STD lasses, licensed assayers arrayed to measure the findings and spread hope via whispers, leaks, news rags, bars, whores and as ever lawyers licensed by the state to regulate the mayhem, avarice, cheating and taxable land at every higher rates. California a prime real estate Ponzi of this charade from the Gold Rush to Silicon Valley to Forever War Production. Cypherpunks a California dream of outwitting The Man which made early adopters wealthy, arrogant and notoriously seductive with Pretty Good Crypto freely available to avid challengers of authority, cosmeticized with official prosecution, glorified and exported as if Western Movie-made Outlaw. MS, Google, Apple, Amazon, Boeing, Lockheed Martin, Los Alamos, Berkekley, Nevada Test Site, Supermax, Hollywood, E Frontier F, on and on, theology of Home on the Range without fences, censorship workarounds, no matter cellphones and IoT tracking rascals online and off. Keep digging fabulous fortunes and reps being reaped regularly as the 5-Eyes et al, national laboratories, WMD enforcement marshals, DoJ and IRS keep careful watch and BOP continues to expand Guantanamos for the Jims, Julians, Jeremys, Chelseas, Pseudos and Anons. Has there ever been as effective a gelt-planted sting as WikiLeaks, cpunks conceived? Yes, PKCalifornia. At 05:58 AM 10/20/2019, you wrote:
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/