It made me wonder if it would be possible to attack a piece of structured data with a known id, if you quickly start and stop a big group of vaults and then squat every vault that happens to land in its close group?
You can not (should not be able to) start a vault with a particular ID and have the network accept it. The network selects the ID you will use and it is randomised across the network.
If you want a close group then you need to have over 80% of nodes on the network to get any group, not a specific group. This means on a 100 node network you will need more than 700 nodes. We do not have that group size in these tests to allow us to shape traffic etc. and measure.
No, but if you know a Structured Data ID you want to attack, can you then find out which ID your vault got assigned by the Network? Can you determine or reasonably guess if you are in the close group for an ID? Could you restart or recreate a vault repeatedly until that randomly assigned ID happens to be close enough to some other ID?
It is proportional to network size, so maybe several thousand/million attempts etc. but then the close group will probably have changed. Then you need to do this with every group member (beat existing members).
Good question @Lazarus_Long, it’s something I’ve been concerned about as well.[quote=“dirvine, post:2, topic:10007”]
If you want a close group then you need to have over 80% of nodes on the network to get any group, not a specific group. This means on a 100 node network you will need more than 700 nodes.
Irrelevant? That is if you start a vault, leave it on the network and keep adding vaults.
Is there a solid reason floating around as to why this kind of attack isn’t feasible?
Leaving a vault on will mean that over its lifetime it will be part of many groups. As nodes come online and offline each group will change as in the nodes that make up the group. Even as quick as minutes or faster at times.
To gain control in the live system you need 28 of the 32 nodes in the group around the particular SD. For a very small network this maybe easy to achieve. If your network is only 100 nodes then real easy.
But when the network exceeds 10,000 nodes with nodes going on/off line to get 28 of the 32 will be very difficult.
If you want to disrupt then it seems you only need 5 out of 32 nodes in the group around the SD. This is much easier, but if the network is over 100K nodes then it becomes very difficult.
While not impossible, on a large network you are going to use so much resources to attack a particular SD as to be effectively impossible. When the network exceeds 1 million nodes it will be almost pure luck you can get even 2 nodes in the group controlling a particular SD.
So when it comes to launch, will there need to be a big number of nodes initialized by Maidsafe, prior to general admission? Say, a rack on each continent with thousands of dockerized nodes each that can be taken offline gradually once the network has a native 100k count.
I am unsure. I suppose if they have a general trust of the early adopters and the fact there is few SDs existing then it is not so important. BUT if the policy of trustless is used then a certain number of nodes prior to general admission would be wise, very wise.
As to how many then I guess it will be a trade off. How many other nodes will come on line in the first hour? Just how many nodes are needed to make this attack take longer than the rate of nodes joining to make it near impossible?
Would be an interesting exercise in maths and maybe the tests being done now will give some sort of country guess to the initial rate of new nodes to a new network.
I chose 100K to be sure it is effectively impossible, maybe 10K is all that will be needed to make it take days before any chance of achieving one SD a problem. And if 1K worth of nodes are being added every hour for the first day then its blown out to many months to achieve one SD a problem.
With the secure node join, I don’t know if now is implemented, create Vaults It is not so easy. And develop thousands and thousands of Vault in a short time is beyond the scope of anyone without enormous resources.
1.A node (A) creates a keypair and connects to a group (X). 2.Group (X) then take the closest nodes to this. 3.The resultant hash of these closest nodes yields the target group for the node to join (Y). 4.Group (X) then GetGroup (Y) and return this group to the client. 5.Client (A) signs a JoinGroup request for (Y) and sends this back to (X). 6.Group (X) then sends this valid request onto group (Y). 7.Group (Y) then hold this request in a join cache (lruCache) of GroupSize 8.Node (A) then generates keypairs until it generates one that would fall within group (Y)
The required XorName will comprise a signing key as first part of address and append an encryption key to last part (64 bytes in all) 9.Node (A) then sends a join request for this newly created ID to (Y) but signs this with the previous key for (A). 10.Group (Y) receive this request and check their cache, if accepted then joining resumes as normal, This new ID is added to expected nodes and group (Y) wait on ConnectRequests from node (A)'s new ID. ’
I recall Irvine said recently that the initial phases of final release will be secret until the network reaches a size hardly attackable.