No worries, I never take logic personally do poke away.
It’s not really an address limitation issue or even number of open ports (say 2 per connection * 64 connections) There are u16 ports available. Up to 1025 they need admin privs, after that then you are OK. Some are supposed to be for specific things (see /etc/services file for guidelines). The issue is open files or inodes (or file descriptors). In OSX for instance you run out after only 256is. You can increase this via ulimit.
The issue becomes the actual number of resources used, so ports open in the router, files open in the OS etc. So this is what I meant by physical (unlikely to even get 65000 is sockets you are allowed to theoretically) .
There are tweaks you can do if in hack mode (like ulimit etc.) but the resource issues does come into play, so when we are attacking we need to consider this. So then it’s bring in the botnet time and it starts gettting harder for us to get botnet agreement and message passing to do this (much harder than DDOS attacks for instance).
All good to look at for sure. Biggest hassle for us and every p2p thing for sure is NAT traversal and that as well brings in hassles for attackers to, I wish ipv6 would allow NAT to die, but ISP’s will keep it as it’s a great control for customers, unfortunately.
This is true if you’re thinking on the classical attack of thousands of connections to try to achieve a majority in a group. But I wasn’t talking about this kind of attack. You have misunderstood me or I did not express myself well.
Anyway, I’ll try to demonstrate this vulnerability, although I really hope I’m wrong.
I think I get it. It’s one way only. Like it’s always at front and never at back. I’m close to the guy at front of me so I just need a step to join him. But the guy at front can’t step back so he have to do around the world before he can reach me. Is that correct?
But anyway you compute the closeness of the potential node from the perspective of the destination node. The attack seems valid for me.
It could be improved because the nodes that were created in the first iterations of the loop might not be close enough anymore at the end of the algorithm due new nodes added by other people in the mean time, but basically the ingredients of a successful attack are here.
You just explained what I said. There is no difference. The question I ask you, how far the Guy A is from Guy B? But I agree this attack can still be valid. I just wanted some clarification about how DHT work.
Yes is like you explained for the Guy A and Guy B, but not for the C or D
DHT of Guy A: → Guy B → Guy C → Guy E → Guy F
DHT of Guy B: → Guy C → Guy D → Guy E → Guy F
DHT of Guy C: → Guy B → Guy D → Guy E → Guy F
DHT of Guy D: → Guy C → Guy E → Guy F → Guy G
I mean, that not always is asymmetric. Now, the Guy B and Guy C are symmetric.
This is it, but can be further shown that you have a few nodes in the network, 4 nodes (say) A B C, D So
A has B as closest
B has C as closest
C has D closest
D has A as closest
Then you apply this to groups and not just single nodes and it is more representative. So then you have a group_size and quorum. The difference being the error_rate, this error_rate is to cover the asymmetric cases (this is where the binary tree is not balanced (evenly populated)).
So SHA512 should evenly populate an address space (the security of a hash is this really).
As the network grows it certainly becomes more balanced (even).
i.e. for a normal DHT (Kademlia say) with a SHA1 address space, the initial 2500 nodes have a completely unbalanced tree and analysis on these network show that up to circa 2500 nodes all measurements are all over the place, only after it settles do you see patterns that are anywhere near repeatable on multiple runs.
This is identical to an ant colony (say harvester ants) where the colony size up to X is unstable and does not function effectively. Our X in traditional Kademlia is circa 2500. So this shows a nice correlation between a natural autonomous system and what we are working with here.
If I am a node that belongs to the close group of A, how does SAFE prevent me from communicating with the other nodes that belong to the close group of A. Is this obfuscated in some way or could I find them?
Yes, question is about after you have joined a close group (which isn’t your choice). In other words, if you belong to a close group of some node at some point, how does SAFE prevent you from bribing the other nodes of the close group (by method of communication and offering them money for example) into cooperating with an evil plan?
They would need to be running a broken node which can somehow tie them to an id you can communicate with. Or you may be able to try tracing the IP (perhaps, but if global then hard).
So a vault ha no way of communicating some evil plan to each other, it would take out of band comms, then the problem is finding who is running those vauults.
As the network is fully distributed this becomes more difficult and when we get the nodes down, so even Iot and small devices are using it then it gets even harder.
tl;dr there is no way that is easily recognisable as a mechanism to identify vault users as this is a pretty huge part of security that is core to the network.
So clients can communicate with each other by sending messages to each other in XOR space but vaults have no way of doing this?
Edit: thanks, that explains
Normally yes, the nodes will be evenly distributed in the address space, but this won’t be true anymore if some hackers game the system.
This is exactly what @bcndanos does: he creates a local heap of nodes that he controls around the destination node. To be more precise: he let the source group create them by connecting to the source node with carefully selected temporary ids that will generate ids close to the destination.
Issue is you cannot do that, the network ultimately provides the destination ID (your attempt is always relocated) and it’s based on a hash, so any tiny difference will distribute the nodes and do so with the same level of even distribution as any other node.
In fact you can, because you know the formula the network will use to relocate the ID. This is the formula in @bcndanos code:
let new_name = Hash(pair_key.public_key + originClosest.0 + originClosest.1);
All you have to do is to test this formula repeatedly on random IDs until the relocation formula returns an ID that is close to your target. Then you connect with this random ID and the network will relocate it to the desired ID.
do poke away.