It lays out some ideas that helps to significantly reduce forms of traffic analysis where the attacker doesn't have to be participating in the network to see whats going on. The ideas and other methods can be expanded upon to secure the traffic flows against attackers operating inside the network on a majority scale to a decent extent.
As a preface, known data of any kind is the enemy. If everyone could have their own privately protected fiber line to every other node that would be almost ideal, but it is not realistic. Eventually even then each line or major junctions of lines would be monitored. That doesn't mean you should give up on privacy and anonymity, which I believe plays an extremely importatnt role in protecting open free speech.
Basically this post very generally tries to implement ideas from what I imagine a true mixnet would use. Complete data encryption/obfuscation, full transportation freedom with multi-homing, data aggregation, and raiding/striping. (Don't say homomorphic encryption, don't say homomorphic encryption..
) https://en.wikipedia.org/wiki/Multihoming https://en.wikipedia.org/wiki/Link_aggregation https://speedify.com/blog/combining-internet-connections/link-aggregation-router-software/ https://www.connectify.me/blog/wifi-bridge/bridging-vs-bonding-explained/ https://ieeexplore.ieee.org/document/880788
Jun 27 '19: https://youtu.be/rLjMrIWHsxs?t=1349
#3 There is no way to connect to other nodes without showing who you are immediately connected to. There are ways around this but no one would casually use it; If it required you to buy expensive hardware and bounce signals off the moon, or an alternate method of communication using Line-of-Sight/Transparent data communications that is of no obvious origin and offering no single redirection point, making it difficult to track but not impossible [EG point-to-point and point-to-multipoint wireless backbone hauls but with terahertz optics
In reality the best way would be to never have a handshake between nodes and instead start with a constant stream of encrypted data with a rolling key [Preshared EG via carrier pigeon, codeworded news stories, broadcast in ciphered morse by hooking a capacitor to the prison bars, or sent in a charge controller chip with PGP over ebay
], to never require your network traffic to travel over known monitored trans-regional and international backbone junctions, never be easily tied to a unique IP address or MAC or subscription to an ISP, never worry about attackers running dozens of analysis and sniffer nodes in the network, and ideally never worry about "what you say can't hurt you".
Icu2/P (I see you, too!
) suggested modifications to anonymous network architecture
Node = A computer participating in the I2P network. Hopefully it isn't a network tap, or a virtual node in a honeypot network.
Tunnel = How I2P gets traffic from one end to the other, through many nodes, using many protocols, in a semi-anonymous fashion.
Pipe = Idea to make I2P much safer from outside attack and analysis, and a little bit from evil snitches.
Anonymous = A joke.
Single Point of Failure = You name, address, SSN, DoB, leaked WebRTC IP address, nontransient online pseudonym, permanenet node ID, cross domain browser or hardware fingerprint, software exploit, operating system telemetry, leaked permacookies, hidden x86 MSR RISC backdoors [Intel's AMT, Supermicro BMC, AMD PSP, etc
], email address, background photo siphoning, correlation exposing conversations, keyloggers, speculative execution and caching attacks, ...
Buffer = A pool of data that can act as a shock/lag absorber
VPN = A single encrypted container around network traffic, usually non-continuous and never truly anonymous. >~85% bandwidth efficiency.
Obfuscation = Tries to avoid deep packet inspection and next-gen application firewall signature matching. Might be able to combine with Pipes.
Operating System = What a real anonymous network could be.
Quality of Service [QoS] = A feature in better routers that will allow you to have a stable dedicated pipe architecture at the same time as your games and videos, necessary on shared networks unless the Analysis Security Certainty Factor has a good AI adjuster behind it.
ISP = Internet Service Provider. If you have ATT or Verizon you should stop reading ... >here<
(IX still needs to add a shield on Kansas City
- Pipes are encrypted omnidirectional bandwidth containers for all direct node-to-node overlay network traffic.
- Pipes are always on. They need as stable throughput, hop-to-hop, and packet tx&rx processing/timing delay as digitally achievable.
- There is one pipe per direct node-to-node connection through which all traffic flows. There can be many pipes, or a few, depending on how many connections to other direct non-anonymous [see the moon bounce method] nodes there are.
- Data can be split across pipes, meaning: over network interfaces [wifi(s), cellular(s), fiber(s), cable(s), satellite(s), P2P, mesh, ionosphere, ...], aggregation/ combination of all network bandwidth [can speed bandwidth to one direct node or increase rudundancy or anonymity by splitting data until an anonymous aggregation tasked node or the final end node], split tunnels, multi-homing in case a route goes out mid-way, etc. This has a major anti-analysis (read "anonymous network killer") bonus. Almost as big as that gained from constant pipe data and delay, if done right. [Aka Data should be completely free to roam around the network, in part or in whole, taking varying paths and routes to its destination. Even if evil nodes see some spidered incomplete traffic, they cannot piece it all together with certainty without network dominance.]
- All pipes to and from a node act and nearly look the same [should be completely pseudorandom no patterns]. No actionable details about nodes or tunnels should be observable by analyzing pipes, packet headers, packet data, bandwidth, or packet delay except that data which is used to create and sustain the pipe over the Clearnet. Extremely robust stream ciphers are needed, and packet type should be as low overhead with the least operating system Nagling buffer as possible. It should be the formally verified hardware's job, whereas operating systems may introduce additional delay according to processor load or other insecurities that could jeopardize the anti-analysis protections. [OS, NIC, and Routers can introduce screw ups because of packet conformity and standardization, see Vault7 FluxWire]
- The pipe stream can be built using a buffer of pseudorandom data (not simple padding), with real information, like tunnel creation requests, injected into the stream as not to cause any delay to the transmission or reception of the working pipe's packets or other pipes' packets of the node or connecting nodes.
- Pipe stream data, post-injection and before transmission, should further be securely encrypted as to remove injection point AND structured data markers in the transmitted stream. You may choose a perfectly sized authenticated block cipher here, or an authenticated stream cipher. Prefer the latter. https://competitions.cr.yp.to/secret.html
- Additional tunnel delay should be added by nodes every inter-hop, and of pseudorandom duration with respect to tunnel/circuit identifiers giving up routes. (Not based off a hard-coded or weakly generated seed, changes at same time other identifiers and codes change, might need PTP node groups to synch, see Jun27 update linking to topology grouping and role assignment on /Kovri) Again, not in a way that affects pipe packet transmission or reception, bandwidth or timing in a statistically determinate manner. Don't use tight or otherwise predictable delay windows. This is to negate any delay ananlysis nodes an attacker has running inside the network. You can't delay everything by 1 +/- 0.5 seconds and expect it to create random deviation. Modifications will need to be made to give long-standing evil nodes a hard time. [Relays batching and mixing stream 'cloves'.]
- Anonymous tunnels may adopt features of pipes [and other Anonymity network designs like Loki,Tor,I2P,Sekreta,HORNET,Nym,Loopix,Jami,Freenet,WireGuard...] to combat attacker nodes running analysis that are able to see within the pipes and overall network layout and participation by design. I am unsure whether I2P does this effectively enough with any connection protocols.
- Each pipe is monitored and ranked for its bandwidth, delay, traceroute, connecting node temporary identification, headers, data incongruities, fluctuations of the aforementioned, node schedules, and general reliability. This is used to balance a node's total stable network-ability among pipes and groups of pipes or nodes [or groups of nodes]. Data from each node can be collimated, particularly traceroute and path statistics via opt-in, to create shared databases of slow internet providers, blockage, throttling, bad routers, nodes, attacks taking place, etc. This data may be accessible on a node's administration statistics page with different kinds of graphical charts available, pertaining to graph theory. If loading peered network statistical data is done insecurely and without sanitization, as is anything else, a redesign is in order (and a kick in the @$$).
- Each pipe and grouping of pipes is adjusted for stability according to the node admin's "Analysis Security", or 'preventative certainty factor'. This can be automatically adjusted using PID, machine learning, manually, or otherwise. Recommended options are if they want the pipe bandwidth to fluctuate 16, 8, 4, 2, or <1% of the time according to their ISP interface connection stability. [Or a custom default value that is even lower variation, due to the months-long attack studies everyone is doing. Good QoS comes in for the win here.]
- Warning: If pipes are allowed to be throttled significantly enough to impact tunnel formation and tunnel traffic flow then a well organized [read "anyone with a plan"] attacker can force a known route to be taken or use it to improve their 'statistical' flow analysis. Pipes by themselves being steady as a rock makes it much harder to follow versus the standard unidirectional one-to-one or NTCP2 padded packet tunnel.
- Tunnels now have a much simpler job: make sure attacker nodes get as little information as possible while forwarding traffic. Permanent node identification, tunnel creation, eepsite discovery and name registries, reseed servers, exploratory tunnels and everything else need to be reenvisioned to not give any good lasting information to an attacker(s) operating inside the network. Refer to: "single point of failure", because it only takes one.
- Copious amounts of data leak and exploit prevention are recommended. Isolation is a key factor, but is too often used as a crutch for bad code. [See 'reasonably secure operating system']
- Edit Jun 27 - Over time, the statistics gathered by all direct nodes, along with the tracking of changing temporary node identifiers allows a few scattered anonymous direct nodes to maintain tabs on your connection to the network (aside from the fact you have a unique connection signature over the clearnet). Having these ephemeral / transient accountability and statistics tables nets some innate ability to keep tabs on who might be a slow or evil node, or whose connection is straight garbage. Attacker nodes can track and make their own tables regardless of whether everyone else is or not. Node ID changes should occur frequently and be accompanied immediately, via delayed, random rolling or otherwise, having some or all direct nodes disconnect from the interface, thus establishing a new connection to new nodes with a new ID to avoid large statistics tables and attack windows. Using multiple interfaces enables your local client node(s) to maintain different sets of now-transient identifying information. Most users will only change their real singular IP address every few weeks when their modems request a new DHCP address from their ISP.
To be fair to the engineers, you should run pipes through tunnels, not tunnels through pipes. Just never say that it can't be done.
That took a little while to type. I had space for a new point inbetween 9 and 10 on the notes from 2 years ago, so theres probably more knocking around in there somewhere. I'm here for questions if you need me to explain something.Edit: It may read redundantly, but I'm not sure how many ways I have to explain something for someone to get the picture. Advice welcome.
Edit May 25: I've been thinking about the timing reliability that all the Pipe VPN packets would need to be sent at, and want to suggest that something like Precision Timing Protocol be used to accurately determine [to a much higher degree than any form of NTP
] the clock drift and other statistics between nodes with the standard continuous-bandwidth Pipes. I know that timing can be determined to <100 nanoseconds using PTP over leased dark fiber lines [from NIST on one side of the country to USNO AMC in Colorado Springs
], and less so with standard backbone communications equipment [due to processing time and queuing
]. Using anything but highly accurate and precise methods can allow fingerprinting and traffic deobfuscation both inside and outside the network. Also a highly accurate sort of fingerprinting would be possible knowing these clock timing & drift statistics.
Edit Sep 2 [Changed wording again, added WireGuard in #9 refs
]: Modern high end network tap equipment can copy packets and tag them within 5ns, synchronized to their own local UTC source within 3ns at the extreme end of the bell curve, which is only ever off from UNSO-UTC or NIST-UTC by about 40ns. Traffic flow and timing analysis attacks are a real threat to anonymous networks.