F2F UDP mesh net prototype proof of concept "Covfefe Net"
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/
Where basics (important stuff that an I2P replacement must consider or handle) are missing, please mention that.
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/
On Sun, Oct 20, 2019 at 09:21:13AM -0400, John Young wrote:
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.
Build out a physical net not owned and operated by Government. That's another step... Then you need CPUs and NICs that are not owned.
On Sunday, October 20, 2019, 06:15:29 AM PDT, John Young <jya@pipeline.com> wrote:
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.
Why does 'technology' take so long to implement? The Federal government had headaches too. I remember when I first heard of Clipper https://en.wikipedia.org/wiki/Clipper_chip in 1993. This article said it was "defunct" by 1996. We might imagine that Clipper was intended to head off the then-imminent (?) development of wireline encrypted telephones. (Why else propose encryption, yet not proceed to build something)? Did the average person (in America...) actually want phone encryption? Yet 26 years later, the wireline phone is genuinely dying. I also remember in the late 1980's speculation that 'Someday, people might actually give up their wireline phone and have only a cell phone!'. That possibility seemed quite remote, 30 years ago. In hindsight, however, a phone that is with you all the time is much more useful than one attached to your house. The house my parents bought, in 1967, was probably built in 1937. There was only only telephone outlet, as I recall, and that was in the kitchen. That was probably considered "normal" during that era. Today, while they probably wire new houses with twisted-pair telephone lines to most rooms, it's probable most houses use cordless phones, or they don't buy landline phones at all. An anonymizing network is essentially intended to partly compensate for the lack of security measures made for the benefit of ordinary people, rather than the government, over the last 40+ years. It's a start. Jim Bell
On Sun, 20 Oct 2019 20:58:37 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
See https://github.com/zenaan/covfefe if you wish to follow along with this exploration.
"covfefe"? - you might want to first explain why you chose that name and then change it. Until you do, it may be safe to dismiss you as a fascist trump agent.
On Sun, Oct 20, 2019 at 07:22:12PM -0300, Punk - Stasi 2.0 wrote:
On Sun, 20 Oct 2019 20:58:37 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
See https://github.com/zenaan/covfefe if you wish to follow along with this exploration.
"covfefe"? - you might want to first explain why you chose that name and then change it.
Until you do, it may be safe to dismiss you as a fascist trump agent.
Doesn't matter if it's Antifa Rayzer who wishes to speak, Trump or Juan who wishes to speak. The right is sacrosanct, and notwithstanding if anyoen of these call to censor (or worse, murder, in the case of Rayzer), they have a right to say what they wish to say. If we cannot stand for the right of those with disagree with, to say what they wish to say, we don't deserve our own freedom of communication. I could have called this RayzerNet, which has a better ring to it, but came up with the acronym for Covfefe first, so that'll do... it's the principle, not the bacronym.
On Mon, 21 Oct 2019 09:30:02 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
On Sun, Oct 20, 2019 at 07:22:12PM -0300, Punk - Stasi 2.0 wrote:
On Sun, 20 Oct 2019 20:58:37 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
See https://github.com/zenaan/covfefe if you wish to follow along with this exploration.
"covfefe"? - you might want to first explain why you chose that name and then change it.
Until you do, it may be safe to dismiss you as a fascist trump agent.
Doesn't matter if it's Antifa Rayzer who wishes to speak, Trump or Juan who wishes to speak. The right is sacrosanct,
right, and that has fuck to do with the name you chose. A free speech platform is unbiased. The name you chose isn't unbiased at all.
and notwithstanding if anyoen of these call to censor (or worse, murder, in the case of Rayzer), they have a right to say what they wish to say.
If we cannot stand for the right of those with disagree with, to say what they wish to say, we don't deserve our own freedom of communication.
and what has that got to do with you creating an account at github-MICROSOFT-NSA and naming it after some fascist bullshit 'meme'?
I could have called this RayzerNet, which has a better ring to it,
yep, but you don't need to call it anything. We can discuss the basic architecture without you using it as an excuse for your fascist propaganda. So, what about defining only the core features of an hypothetical system? 1) peer to peer - no 'directory authorities' 2) are all nodes equal, bandwidth wise, or are there bigger nodes that provide some kind of 'convenient' (and less secure prolly) routing services? 3) virtual-circuit-switched, or packet-switched? Is packet switiching the most expensive and the most secure option? Packet size? 4) any other fundamental feature I'm missing?
On Sun, Oct 20, 2019 at 08:40:09PM -0300, Punk - Stasi 2.0 wrote:
On Mon, 21 Oct 2019 09:30:02 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
On Sun, Oct 20, 2019 at 07:22:12PM -0300, Punk - Stasi 2.0 wrote:
On Sun, 20 Oct 2019 20:58:37 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
See https://github.com/zenaan/covfefe if you wish to follow along with this exploration.
"covfefe"? - you might want to first explain why you chose that name and then change it.
Until you do, it may be safe to dismiss you as a fascist trump agent.
Doesn't matter if it's Antifa Rayzer who wishes to speak, Trump or Juan who wishes to speak. The right is sacrosanct,
right, and that has fuck to do with the name you chose. A free speech platform is unbiased. The name you chose isn't unbiased at all.
My expressions in this world are at base, events of my exercise of my right to communicate freely, pursuant to my will. Rail on muffa :) BTW, such reaction, ironically, is the very motivation, and further motivation, for further memeing, which to some is just hilarious and the source of endless giggles. But in this case I intend to get on with the work at hand - a meme name is enough for me and covfefe has more public traction than Rayzer, and besides, some domain squatter is trying to sell covfefe.com for ~ USD $8,000 :D
and notwithstanding if anyoen of these call to censor (or worse, murder, in the case of Rayzer), they have a right to say what they wish to say.
If we cannot stand for the right of those with disagree with, to say what they wish to say, we don't deserve our own freedom of communication.
and what has that got to do with you creating an account at github-MICROSOFT-NSA and naming it after some fascist bullshit 'meme'?
I am inclined to create a git account somewhere else - I created my github account before it was purchased by MS, if you must know... so, momentum. But if you suggest an alternative, I'd be glad to swap actually - been wanting to get off of github since they sold out. You are of course free and encouraged to create your own forks, originations, deployments and etc under whatever meme suits ya - I was pretty sure I didn't need to say that but hey, feel free to chomp on another tastily rabbit hole bated meme hook ;) I'll reply to the tech discussion in a separate email.
On Sun, Oct 20, 2019 at 08:40:09PM -0300, Punk - Stasi 2.0 wrote:
On Mon, 21 Oct 2019 09:30:02 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
I could have called this RayzerNet, which has a better ring to it,
yep, but you don't need to call it anything. We can discuss the basic architecture without you using it as an excuse for your fascist propaganda.
I certainly don't need to call it "anything" - plain English words are a bitch for search terms ... seriously. Glad we agree on this one.
So, what about defining only the core features of an hypothetical system?
1) peer to peer - no 'directory authorities'
ack
2) are all nodes equal, bandwidth wise, or are there bigger nodes that provide some kind of 'convenient' (and less secure prolly) routing services?
all nodes equal, in the sense you use the word equal every node is of course a unique snowflake - i.e. a unique set of ISP, possibly >1 network connection, possibly >=1 dark fibre links (off public network back links) such as N2N (neighbour to neighbour ETH or WIFI down your street/ suburb), cpu, ram etc
3) virtual-circuit-switched, or packet-switched? Is packet switiching the most expensive and the most secure option? Packet size?
Now this is a good question. We must consider the limits, and for sanity compare with existing global Internet. There are ~7 billion people on Earth. The existing physical network (phys net), is clumpy - nations, in particular island nations including Australia, have backbones running around them joining cities, and branches out to regional areas, which ultimately branch out to individual premises (a home, an office). It's kind of a fractal of a star network, so sort of centralized. At each aggregating point or "layer", is a router, routing within that clump, and routing externally to other clumps, to other "star networks". With mobile phones (literally pocket supercomputers by the standards of 3 decades ago), we have more dynamic possibilities, and demands from users: - we -should- make use of physical peer to peer "ad hoc" wireless mesh networks, but this has yet to be solved in any production environment, except "sort of" by the occasional burning man etc set up - which have AIUI so far just been an "off grid" local star network replacing the traditional network - when known friends are near to each other, our phones should send text messages BYPASSING the national/ centralised govnet Avoiding physical correlation of nodes is probably unwise, due to such possible benefits. This implies inherent network "clumpiness". So, back to routing - we can assume, with IPv6 at least, a flat global node address space - at least, we can do this in a virtual layer above govnet. But do we want to? We want to replace govnet, not assume govnet. This means we want to in some sense create a practical physical alt net, which is not govnet, and so our design MUST cater for this from the get go, even though many links shall in the early days make use of govnet.
On Mon, Oct 21, 2019 at 06:28:01PM +1100, Zenaan Harkness wrote:
On Sun, Oct 20, 2019 at 08:40:09PM -0300, Punk - Stasi 2.0 wrote:
3) virtual-circuit-switched, or packet-switched? Is packet switiching the most expensive and the most secure option? Packet size?
Re circuit switching, Tor does what's called onion routing, using TCP circuits per onion layer. This means A connects to B with a (encrypted) TCP connection, and requests of B a next hop connection to C. So B decrypts A's first layer incoming connection, which contains A's encrypted connection to C, and B forwards the packets of that connection, on to node C. This layered encryption means B cannot read the contents of A's connection with C. It also is supposed to mean that because A's initial connection to B is effective double encrypted, external onlookers should not be able to determine that A is connecting to C, only that A is connecting to B, but in practice to actually deliver this promise would require an effective chaff fill mechanism, to actually obfuscate when and how much data A sends to B, etc.
On Mon, Oct 21, 2019 at 06:28:01PM +1100, Zenaan Harkness wrote:
On Sun, Oct 20, 2019 at 08:40:09PM -0300, Punk - Stasi 2.0 wrote:
3) virtual-circuit-switched, or packet-switched? Is packet switiching the most expensive and the most secure option?
More on "Is packet switching the most expensive"? Packet switching is actually the least expensive (in CPU and bw overhead), optimal (in bw usage) base layer. The simplest reason this is so, is that TCP (or any other connection oriented protocol) as a base layer, incurs various oveheads - re-transmission delays, latency due to (required for TCP) re-ordering queues, and other attack and timing issues related to the specific protocol in use (TCP for Tor), and the point being: - these issues/overheads, are incurred for all streams, even packet based streams which do NOT need TCP overhead.
On Mon, Oct 21, 2019 at 06:28:01PM +1100, Zenaan Harkness wrote:
There are ~7 billion people on Earth.
Napkin calculations are important when it comes to such numbers as 7 billion. In terms of routing, if we create a flat "whole earth altnet" address space, this also implies that each node needs to know, or may need to know, or may be directly contacted by (sooner or later), every other node on earth - all 7 billion if we assume on average one node per human. So we can say things like: - assume that node identification and all node metrics, are stored in 1KiB of data and so each node will sooner or later need to store, at an absolute minimum, 7 * 10^9 * 1024*8 (1KiB of bits) / 8 / 1024^3 ~= 6,675 GiB ! So we must compress that (again, assuming a flat virtual network for the time being, ignoring natural physical proximities and natural physical grouping/clumpiness). Let's say a node_info requires: - IPv6 altnet address - 128 bits - say 5-bits per metric, and 6 metrics (stat fields) = 30 bits - a few booleans (node blocked by me, "friend", "known" etc) - say 30 bits - a display name is desired, say on average compressed to 160 bits IF the above is sufficient, we have now ~348 bits per node, instead of 8192 (1 kibibyte = 1024 * 8 = 8192 bits), and our node static storage requirement (for end user routing) becomes: 7 * 10^9 * 348 / 8 / 1024^3 = ~ 283 GiB Now we reduce storage costs by assuming that, from my personal node perspective, the majority of people in the world (the majority of nodes) will fit within a bell curve of "average", and can be treated as such, until and unless they identify themselves as not average (either preferred, or avoided or blocked, again, by me) - other than that, most folks will not distinguish themselves to me, they will be in the set "unknown" and otherwise uninteresting. https://en.wikipedia.org/wiki/Normal_distribution Ultimate bell curve density is an empirical matter, but for now we can make the averaging assumptions, pluck a random normal deviate out of thin air statistics to please ourselves and say it'll be a standard normal distribution and that the only interesting nodes (out of 7 billion) are gonna be beyond the second sigma - i.e. no more than about ~5%, as ~95% will be "normal". (Defining "normal" in the context of "empirical metrics for a node I am currently connected to" shall come later.) So, 5% of 7 billion = ~350 million nodes of interest, multiplied by ~348 bits (for long term per-interesting-node storage) gives: 7 * 10^9 * 0.05 * 348 / 8 / 1024^3 = ~ 14 GiB Still too high for a mobile phone, albeit in the realms of "possible today". We can obviously get rid of display names (these are bulk "interesting" but not "known friends" nodes), and assume for now 5 instead of 30 state bits per node: 7 * 10^9 * 0.05 * 163 / 8 / 1024^3 = ~ 6.6 GiB And if we change our random normal distribution assumption to 3 standard deviations being "normal" (~0.3% abnormal/metriced), we get: 7 * 10^9 * 0.003 * 163 / 8 / 1024^3 = ~ 400 MiB And finally we're in the realm of "possibly reasonable". Of course, the most interesting sets are "those I choose to regularly connect to" and "those I completely block", so we can likely get that 400MiB down a bit further still...
On Sun, Oct 20, 2019 at 08:40:09PM -0300, Punk - Stasi 2.0 wrote:
3) ... Packet size?
Check out MTU: https://en.wikipedia.org/wiki/Maximum_transmission_unit Most ISPs deliver an IP network. There's a bit of a movement to push ethernet out to the home: https://en.wikipedia.org/wiki/Ethernet_in_the_first_mile MTU is a known/solved problem - basically for streams to be efficient, you must use packet sizes which correspond to the minimum packet size in your circuit, otherwise you introduce things like buffering, packet dis/reassembly and therefore latency and/or link inefficiencies. Garlic routing https://en.wikipedia.org/wiki/Garlic_routing is intended as an improvement over onion routing where smaller messages get combined, to improve anonymity - but the principle can improve link efficiency too of course, so that's a win win. In any case, with UDP base layer, or rather, packet switching, folks can experiment with variations of these concepts much more easily than with a TCP base layer.
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia. anyway : https://www.mixminion.net/minion-design.pdf
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Thank you, I'll have a read.
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet, but one of the stream covfefe will "recommend as a default for all users" is a really low bandwidth ("bw") and high latency, permanent connection. 1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain. But let's consider just 512 bytes every 10 minutes (a single small UDP packet): 1 * 6 * 24 * 30 ~= up to 4320 separate "message sends" per month each message send can contain up to 512 / 128 = 4 "std tweets" therefore 17,280 "std tweets" at 10 minute latency at 512 * 6 * 24 * 30 ~= 2.1 MiB bandwidth per month NOW we're talking some serious chaff for high value random tweets at any time, with a maximum latency of 10 minutes, for only 2.1MiB of bandwidth per month! No doubt some folks can imagine some nice applications for this "recommended baseload" stream :) Now, if your mixing, then those 17,280 tweets need to be divided by the "mixing hop count" to work out actual payload, so let's say your actual tweets go through 10 hops, we have (up to) 1,728 high value tweets per node, per month, with possibly up to 10*10=100 minutes maximum latency (although I'm confident we can eliminate most of that with nodes cascading off one another in waves, so that maximum latency should be at most say 30 time units. If we need lower latency, say 1 minute, we're still only talking 21MiB bandwidth per month - and as a bonus we have 10 fold message capacity, for 1/10th the latency, a win win (except on the bw front of course). To repeat a key point from a previous email: by treating different types of streams for their own nature, we can not only reason about network impact and various performance metrics, but we can ensure that any design caters to include that type of stream.
On Tue, 22 Oct 2019 11:03:59 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain.
well it depends on what kind of activity you want to hide. If you want to make a VoIP call at say 4 kilobytes/s (or less?) then your link must operate at that rate for 'some' time before and after you make the call. Say, a day? ...so a good (best?) solution may be to run a file sharing service and serve 'pirated content'.
But let's consider just 512 bytes every 10 minutes (a single small UDP packet):
so ypu're stuck with that rate of traffic. If you send more that one packet every 10 minutes you're leaking a certain amount of information. And 512 bytes every 10 minutes seems kinda slow...
On Mon, Oct 21, 2019 at 09:47:40PM -0300, Punk - Stasi 2.0 wrote:
On Tue, 22 Oct 2019 11:03:59 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain.
well it depends on what kind of activity you want to hide. If you want to make a VoIP call at say 4 kilobytes/s (or less?) then your link must operate at that rate for 'some' time before and after you make the call. Say, a day?
Indeed. Phone calls, and high-value txts, are different streams.
...so a good (best?) solution may be to run a file sharing service and serve 'pirated content'.
HA :D
But let's consider just 512 bytes every 10 minutes (a single small UDP packet):
so ypu're stuck with that rate of traffic. If you send more that one packet every 10 minutes you're leaking a certain amount of information. And 512 bytes every 10 minutes seems kinda slow...
Yes. It's a type of stream, that's all. Teenagers probably need 10KiB/s just for text messaging their "friends" :) Different stream types are needed for different activities. covfefe net is not limited to one stream at a time. covfefe net is not limited to one stream type at a time. I would personally be inclined to run a "regular txt" stream (which can obviously cater for high value texts), as well as a "phone call stream" - and yes, you're right, because we're packet switched by design, we're just choosing a baseload - and if you can't afford that at all times, then you run it for periods of time when you can afford it, and/or can afford to provide that to your friends.
On Tue, 22 Oct 2019 11:03:59 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet,
there's a good deal of handwaving bullshit in there "The adversary can delay messages...The efficacy of this attack is poorly understood, but it may well be quite damaging" so they admit that their own fucking system is 'poorly understood' by their own fucking selves and may be 'quite damaged' - well I guess that's at least half honest. "Dummy traffic is an old approach to improving anonymity, but its efficacy is still not well analyzed." oh really? "We need stronger intuition about how to use dummy messages." ...stronger...intuition...? "While many people have speculated about the benefits of dummy traffic, we have not yet seen any convincing analysis." .... "Exit attacks - Use the mix network to send hate mail" "ISPs do not tolerate systems that potentially deliver hate mail" ...'hate mail'? agents of the child murdering pentagon like dingledine are worried about 'hate mail'...? bottom line for me is that the system is (a lot) more complex than I expected - and doesn't seem too reliable either. The 'acknowledgments' section is kinda 'intersting' too.... cohen and 'zooko' wilcox get mentioned and..."We further thank all the unnamed cypherpunks out there who have worked on remailer issues for the past decades." isn't the collaboration between 'cypherpunks' and the pentagon quite touching.
On Mon, Oct 21, 2019 at 10:38:55PM -0300, Punk - Stasi 2.0 wrote:
On Tue, 22 Oct 2019 11:03:59 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet,
there's a good deal of handwaving bullshit in there
"The adversary can delay messages...The efficacy of this attack is poorly understood, but it may well be quite damaging"
so they admit that their own fucking system is 'poorly understood' by their own fucking selves and may be 'quite damaged' - well I guess that's at least half honest.
"Dummy traffic is an old approach to improving anonymity, but its efficacy is still not well analyzed."
oh really?
"We need stronger intuition about how to use dummy messages."
...stronger...intuition...?
"While many people have speculated about the benefits of dummy traffic, we have not yet seen any convincing analysis." ....
"Exit attacks - Use the mix network to send hate mail" "ISPs do not tolerate systems that potentially deliver hate mail"
...'hate mail'? agents of the child murdering pentagon like dingledine are worried about 'hate mail'...?
bottom line for me is that the system is (a lot) more complex than I expected - and doesn't seem too reliable either.
The 'acknowledgments' section is kinda 'intersting' too....
cohen and 'zooko' wilcox get mentioned and..."We further thank all the unnamed cypherpunks out there who have worked on remailer issues for the past decades."
isn't the collaboration between 'cypherpunks' and the pentagon quite touching.
Indeed. covfefe net is the UDP network layer chaff fill, packet switched network. This is where chaff fill - those "dummy messages" mentioned above - needs to be done, in the network layer. The reason? Once available, any "message" or "stream" type can layer on top (including TCP) - the nature of a network layer of course.
On Tue, 22 Oct 2019 12:40:25 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
covfefe net is the UDP network layer chaff fill, packet switched network.
1) can you stop your stupid trump nazi propaganda? there's no 'covfefe net' 2) can it be (virtual) packet switched actually? 'Onion routing' means ones has to set up a 3 hops route using public keys to get 3 symmetric keys etc. That's done once per circuit in tor. Doing it once per packet may be a bit too much?
This is where chaff fill - those "dummy messages" mentioned above - needs to be done, in the network layer.
The reason? Once available, any "message" or "stream" type can layer on top (including TCP) - the nature of a network layer of course.
On Mon, Oct 21, 2019 at 11:03:40PM -0300, Punk - Stasi 2.0 wrote:
On Tue, 22 Oct 2019 12:40:25 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
covfefe net is the UDP network layer chaff fill, packet switched network.
1) can you stop your stupid trump nazi propaganda? there's no 'covfefe net'
Stop getting triggered, snowflake ;) You can name your version whatever meme suits you. I'll kick it off for you right now - you can probably improve this tho: - Juan "I am not a snowflake" Net
2) can it be (virtual) packet switched actually? 'Onion routing' means ones has to set up a 3 hops route using public keys to get 3 symmetric keys etc. That's done once per circuit in tor. Doing it once per packet may be a bit too much?
You're right - we can't set up per packet, but instead set up (exchange PKs, negotiate a session key), per-node. Remember, I must be able to control my own routing/hops decisions, for my chosen routing of packets within any circuit of my choosing. Once I've established a "symmetric session key" for the nodes I want to route through and nodes I wish to talk to, I can then send any number of wheat or chaff UDP packets (which must be indistinguishable from each other), to any target node that I've negotiated such session keys with. Session key's might be long lasting - I need to bone up on perfect forward secrecy though (PFS); TODO.
This is where chaff fill - those "dummy messages" mentioned above - needs to be done, in the network layer.
The reason? Once available, any "message" or "stream" type can layer on top (including TCP) - the nature of a network layer of course.
On Mon, Oct 21, 2019 at 11:03:40PM -0300, Punk - Stasi 2.0 wrote:
On Tue, 22 Oct 2019 12:40:25 +1100 Zenaan Harkness <zen@freedbms.net> wrote:
covfefe net is the UDP network layer chaff fill, packet switched network.
1) can you stop your stupid trump nazi propaganda? there's no 'covfefe net'
OK, to play politically neutral (which is the intention), this project has been renamed from covfefe to iqnets. IQNets is neither an acronym nor a backronym/bacronym, simply a suitably short and politically neutral name which had at least one old fashioned tld available - in this case both .net and .info from memory. To update your local repo, run this one secret command for a fabulous new snowflake friendly experience: cd $covfefe_git_dir git remote set-url origin https://github.com/zenaan/iqnets.git Enjoy your shiny, new, new and shiny, trigger free repository name ;) (Of course, once the second or third prototype is done and the design has settled down etc, a politically neutral name may be useful for attracting a userbase which includes (far) left leaning in-duh-viduals, which should eventually be a win for everyone..)
On Tue, Oct 22, 2019 at 11:03:59AM +1100, Zenaan Harkness wrote:
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet, but one of the stream covfefe will "recommend as a default for all users" is a really low bandwidth ("bw") and high latency, permanent connection.
1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain.
But let's consider just 512 bytes every 10 minutes (a single small UDP packet):
1 * 6 * 24 * 30 ~= up to 4320 separate "message sends" per month
each message send can contain up to 512 / 128 = 4 "std tweets" therefore 17,280 "std tweets" at 10 minute latency
at 512 * 6 * 24 * 30 ~= 2.1 MiB bandwidth per month
NOW we're talking some serious chaff for high value random tweets at any time, with a maximum latency of 10 minutes, for only 2.1MiB of bandwidth per month!
No doubt some folks can imagine some nice applications for this "recommended baseload" stream :)
Now, if your mixing, then those 17,280 tweets need to be divided by the "mixing hop count" to work out actual payload, so let's say your actual tweets go through 10 hops, we have (up to) 1,728 high value tweets per node, per month, with possibly up to 10*10=100 minutes maximum latency (although I'm confident we can eliminate most of that with nodes cascading off one another in waves, so that maximum latency should be at most say 30 time units.
If we need lower latency, say 1 minute, we're still only talking 21MiB bandwidth per month - and as a bonus we have 10 fold message capacity, for 1/10th the latency, a win win (except on the bw front of course).
To repeat a key point from a previous email: by treating different types of streams for their own nature, we can not only reason about network impact and various performance metrics, but we can ensure that any design caters to include that type of stream.
A high value but rare text message, still has at least one recipient. An adversary will seek to discover "who are the end parties sending messages to one another". Besides cracking end user computers, one can imagine GPA stalker nodes introducing say latency jitter at one point in the net, and detecting that jitter at another point in the net. Such attacks are why the only sane entry to IQNets is via at least one 'trusted' friend. To increase stalker difficulty, we can imagine: - sending encrypted message to multiple friends - either in a star/ multi cast model - or in a token ring/ each always sends to next hop model - my first hop could just be a standard route ABC, where B is a 'trusted' net entry friend providing me his node as a hop which I may use to enter the network - then, my next hop to C could be to another friend/ 'trusted' node which runs a low-vol high-value text message "repeater" to everyone in my little circle, and possibly the odd random target (by sending a chaff fill packet); this is the star topo - alternatively in the token ring topo (topology), the 1st recipient sends the message to the 2nd, who on sends in to the 3rd etc, and the last in the ring finally sends it back to me (they don't necessarily know or realise that I originated this particular message) - once I receive my own message back, I know everyone in the ring has at least received it - this has the effect of total propagation duration (the total time for everyone to receive the message) scaling (increasing) according to the number of recipients/participants in the ring - to receive confirmation when using the star (as opposed to ring) topo, I receive an ack from each recipient; - this scales the number of ACKs according to the number of recipients - so different models have different properties - the low volume, potentially high value, relatively high latency text message stream, if it involves an ACK, can be considered a form of ping - a group of texting friends in a ring has the problem that if one recipient drops out, the next recipient may lose a message, and therefore needs to know about the prior hop in the ring (the node before the friend who dropped out) to ask for any messages or pings that have been dropped/missed, and similarly, the node before that if both nodes drop out, etc - star topo is how the typical internet "chat room" works
Multi casting text messages, is associated with terms such as: - pub/sub (publish and subscribe) - chat rooms - star vs ring topology - switching and routing - repeater - 1-M (1 to many) - M-N or M-M or N-M (many to many) It is unlikely that any automatic 1-M mechanism, which is not restricted to work only with known 'friend' nodes, would not be immediately used to try to create DoS (denial of service) escalation attacks. - DoS escalation attacks are however naturally mitigated in IQNets, since the primary (and preferred/ preferential service at network layer) mode of operation, is for nodes to connect to 'friend' nodes - if a friend node starts "behaving badly" by flooding me, they are automatically outside of the wheat/chaff negotiated links established, and thus are no longer friend nodes, but self evidently compromized nodes
On 2019-10-22 10:03, Zenaan Harkness wrote:
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet, but one of the stream covfefe will "recommend as a default for all users" is a really low bandwidth ("bw") and high latency, permanent connection.
1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain.
But let's consider just 512 bytes every 10 minutes (a single small UDP packet):
1 * 6 * 24 * 30 ~= up to 4320 separate "message sends" per month
each message send can contain up to 512 / 128 = 4 "std tweets" therefore 17,280 "std tweets" at 10 minute latency
at 512 * 6 * 24 * 30 ~= 2.1 MiB bandwidth per month
But you want to tweet to everyone, or everyone who is subscribing to your tweets, or to everyone a group. So assume every participant is subscribed to various groups, and flood fills the data around throughout all members of the group, and all members subscribed to that particular poster. Well, most people will not be posting every ten minutes, but a typical message will contain the hashes summarizing the previous state of the groups at the previous multiple of 2^15 seconds, plus a bloom filter for the messages since then. And if you have a bunch of groups, and a bunch of people you are subscribed to, it is going to add up.
On Mon, Oct 28, 2019 at 10:17:55AM +1000, jamesd@echeque.com wrote:
On 2019-10-22 10:03, Zenaan Harkness wrote:
On Mon, Oct 21, 2019 at 06:58:57PM -0300, Punk - Stasi 2.0 wrote:
courtesy of tor scum dingledine and matheson and a GCHQ guy, danezis who now works for facebook-NSA as well. Wait, facebook, nsa, gchq, university of london, etc so many aliases for the same mafia.
Have not begun to read that yet, but one of the stream covfefe will "recommend as a default for all users" is a really low bandwidth ("bw") and high latency, permanent connection.
1KiB/s is much too fat, and at 80MiB/day (2.4GiB per month) folks will complain.
But let's consider just 512 bytes every 10 minutes (a single small UDP packet):
1 * 6 * 24 * 30 ~= up to 4320 separate "message sends" per month
each message send can contain up to 512 / 128 = 4 "std tweets" therefore 17,280 "std tweets" at 10 minute latency
at 512 * 6 * 24 * 30 ~= 2.1 MiB bandwidth per month
But you want to tweet to everyone, or everyone who is subscribing to your tweets, or to everyone a group.
You're right of course, but I mislead the thinking by using the word "tweet". "Tweeting to followers" is actually a different, and equally valid, use case, one which we must consider separately. The present use case is private short text messages sent to a very small number of recipients, which are highly valuable/important, and can tolerate relatively high latency between pressing the send button, and the recipient(s) receiving the message - this is a niche use case, but one for which we must cater, along with all other use cases.
So assume every participant is subscribed to various groups, and flood fills the data around throughout all members of the group, and all members subscribed to that particular poster.
Well, most people will not be posting every ten minutes, but a typical message will contain the hashes summarizing the previous state of the groups
That's an arbitrary design imposition - that may or may not be useful, depending on your app.
at the previous multiple of 2^15 seconds, plus a bloom filter for the messages since then. And if you have a bunch of groups, and a bunch of people you are subscribed to, it is going to add up.
Aye. Indeed.
https://www.freehaven.net/anonbib/cache/back01.pdf This attack reveals what seems to be a fallacy in theoretical definitions of security. For example, in [28], the authors state that if links are padded or bandwidth is limited to a constant rate, one can ignore passive eavesdroppers8. This is technically correct if a passive eavesdropper is defined as someone who cannot access the network as a reg- ular user and compute timings on the network (which is implied by the definition used in most theoretical work). However this attack model is not very interesting and defi- nitely misleading. The latency attack pointed out above and the next attack we present demonstrate that if an attacker can simply compute timings (which is as passive as one can expect an attacker to be in practice), or use the system, link padding or bandwidth limiting links to a constant rate does not protect the system against easy traffic analysis attacks.
This appears to be a great paper thats right on topic - thank you. Will have time to read tonight. Offhand, in first 2 pages they use term "synchronous network" - does anyone know, exactly, what they mean by this? TIA On Wednesday, October 23, 2019, Punk - Stasi 2.0 <punks@tfwno.gf> wrote:
https://www.freehaven.net/anonbib/cache/back01.pdf
This attack reveals what seems to be a fallacy in theoretical definitions
For example, in [28], the authors state that if links are padded or bandwidth is limited to a constant rate, one can ignore passive eavesdroppers8. This is technically correct if a passive eavesdropper is defined as someone who cannot access the network as a reg- ular user and compute timings on the network (which is implied by the definition used in most theoretical work). However this attack model is not very interesting and defi- nitely misleading. The latency attack pointed out above and the next attack we present demonstrate that if an attacker can simply compute timings (which is as
can expect an attacker to be in practice), or use the system, link
of security. passive as one padding or bandwidth
limiting links to a constant rate does not protect the system against easy traffic analysis attacks.
participants (5)
-
jamesd＠echeque.com -
jim bell -
John Young -
Punk - Stasi 2.0 -
Zenaan Harkness