On Mon, Oct 21, 2019 at 06:06:15PM +0000, jim bell wrote:
On Monday, October 21, 2019, 04:00:16 AM PDT, grarpamp <grarpamp@gmail.com> wrote:
On 10/13/19, jim bell <jdb10987@yahoo.com> wrote:
arbitrarily-long hops (256 hops? 65,536 hops? An even larger power-of-2 hops?)
Hops, alone, don't add much protection beyond a good routing of 3 to 9 or so. They're more for fucking with traditional jurisdictional log reconstruction trails, than dealing with GPA's, GT-1's and GAA'a including Sybil that can just follow traffic patterns across the mesh bisecting in real time, or more generally... sort and match traffic patterns between all sets of two edge hosts.
Okay, I was just joshing about the "256 hops" part. While there may not be any hard limit built into the system, I believe I later said that 16 hops would be enough for anybody.(Somehow, didn't I remember about 35 years ago that Bill Gates said something like, ""640 kilobytes of main memory would be enough for anybody? We see where THAT led!)
If applied together with other tech, especially regarding nets where you want any kind of useable stream (even delivery of storage or msgs is in a way a stream), beyond those hops is going to get really unperformant, and less security return than thought.
You can demo today by recompile Tor and Phantom and tweak I2P, to set arbitrary hop levels beyond single digits... are you more secure from G* as result... probably not.
However, one use of "many" hops would be the generation of chaff 'traffic'. The goal, presumably, of adding chaff is to disguise the real traffic.
Sort of. The goal of chaff is to fill the blanks - so when I'm not sending wheat, in Tor land, it's obvious that I've stopped sending. Chaff means when I stop sending, my node still send chaff - just purely random filled packets, so that an observer cannot tell whether I've begun or ended a connection, or whether I'm sending anything at all. (Same for the receive loop of course too...)
To do that, it would be desireable to make that chaff look as much as possible like real traffic.
Ahh, I see the thought. Yes, that thought makes sense on first blush, but the problem is, if our encryption is so poor that chaff packets are distinguishable from wheat, our chaff system is broken. And yes, as above, chaff is to fill the gaps, not to create flows or streams that are not otherwise needed - the goal is simply to disguise traffic, not to create completely arbitrary fill traffic (and if the encryption is not broken, all traffic should look completely arbitrary - this is a fundamental 'broken' with Tor's non chaff filled TCP flows).
A packet sent through all, or a large number of nodes will have a genuine path.
Yes, "chaff paths" is the concept here, now I understand. I believe that would be counter productive to network utilisation, and as coderman points out, for too little gain. I can see how chaff paths could possibly make sense in the Tor network. Also, but more fundamentally, what we are aiming for with chaff fill, at least in a packet switched network, is something better than "chaff paths": - we want streams to not be distinguishable - this is a known (and fundamental) problem with Tor - chaff packets seeks a functional improvement on this fundamental problem with Tor - the reason Tor is so bad, is that entry and exit nodes are dominated by GPAs, and the "default set up of Tor Browser" for an end user is therefore fundamentally broken - this is why I stress the importance of running your own home node (if you're using Tor at all), and more so, running that as an exit node if you want any reasonable plausible deniability Covfefe net hopes to overcome this fundamental Tor (as it stands) problem.
Assuming the spy bugs one node, he will see traffic come in, and leave for another. Just like an ordinary instance of traffic.
"chaff fill" is a misnomer perhaps leading people's' thoughts astray, we should say something like: Chaff packets: 1) Are, to an onlooker or snooper, indistinguishable from wheat packets, both in their size, and in their timing of delivery, and in all consequential timing for packets returning, or outgoing, from the node that receives a chaff packet. 2) Are only ever used as padding to fill gaps, so that stream begin, and stream end are not distinguishable (to the snoop), and also so that stream data, and surrounding chaff packets, are also not distinguishable from one another. (A stream is a packet flow such as a request, and the corresponding response for the content of a web page.)
An alternative would be a system where each node spontaneously generates chaff. Spying on a node would see such spontaneous 'traffic' generations. Maybe it would be clearer that that was chaff?
Yes, this is the Covfefe model - chaff packets, to fill the gaps, so the snoop cannot tell whether any data or streams are being sent, or not, at all.
But I'm just throwing out ideas. I assume that the 'chaff' issue has been professionally detailed in some academic papers.
Possibly - if someone has a link, I'd be happy to read it, but the principle seems to jump out and smack us in the face, but I can imagine that there could be some useful academic analysis of chaff and network theory - if such exists...