This is missing the point of my responses completely. I’m not being defensive and have tried to encourage more work on the attack. I’m saying that to be useful this attack description needs to be fleshed out in detail, quantified as far as possible, and I’m giving examples of where I find it needing to be more specific, based on analysis, clearly reasoned.
1 Like
if you have one chance in a hundred to find a suitable chunk, you have one in ten thousand to find two, one in a million to find three and one in a hundred million to find four.
You also need a temporary conjunction between the four vault since the network churn can take away the control of the specific chunk at any time.
You need to know, at all times, the status of all attackers nodes because otherwise you can not perform the deletion. This means a lot processing power and bandwidth.
And also you do not know if there exist another copy of the chunk.
In my view, a theoretical attack but next to impossible (except massive power), especially when the network has grown in size.
2 Likes
I’ve not been following most of this discussion, but how would you get ‘a list of bad chunks’. It is the starting assumption, but it might be less evident than it seems at first sight.
A second and maybe more interesting point is this to consider: if in your attack plan you query the network to find who has those bad chunks; you can do that by requesting to get that chunk.
The network upon a get will leave a copy of that get_data in the temporary cache of every node it hopped over. So when you first query where the 4 holders are by getting it; before you would have received the response the data would be cached on many more nodes nearby, by the act of finding out where that data was. So even if you can then precisely time the attack to remove all ‘archiving’ nodes at the same time, the data manager group will simply notice the nodes gone offline and request the data.
They should be able to request the data successfully because it is going to be cached in many nodes nearby; from that point they simply assign new archiving nodes.
4 Likes
It’s much like trying to pick up a drop of water* with your fingers. You’ll move it by trying to get a hold of it.
*or mercury for those arguing about adhesive forces 
4 Likes
But the more potential target chunks you have the larger the odds become. If it’s a file of 10 GB, that’s 10.000 chunks. You may only need to destroy 1 chunk to make break the file.
Only 4 attacker nodes, those who have the 4 chunk copies.
Identified public data, so simply from the unencrypted data map.
This is not a part of this attack, but true, if any third party recently requested the chunks odds are they are likely cached somewhere.
Sorry, I reread the original attack plan. A first comment now is that it would hard / impossible to achieve this type of attack as a SAFE app. A SAFE app runs as a shielded temporary client and does not get the information of what the actual Vault is processing in the background.
If your attack-app would be monitoring the disk to identify chunks stored then that would be made hard by the fact that chunks and data maps are locally again encrypted with pure local keys before written to disk.* The reasoning is here that a datamap can contain encrypted small files (< 3KB) and as a user running the vault, doubly encrypting it before storage, ensures no-liability to that content.
So to achieve such an attack-app a user would have to be willing to uninstall the SAFE vault binary and replacy it with the-centrally-censored “SAFE” binary; and at that point I think we are logically at an end of the discussion. If a majority of the network contributors chooses to exchange a decentralized backbone with a centrally controlled backbone, then we are not talking about the same network anymore.
It is a valid discussion nonetheless, but I don’t think it would be as “infectious” as convincing people to instal a “morally right app”
*this feature has not been ported over to the latest implementation yet, and some questions were raised on the necessity for that; maybe we will keep it now 
5 Likes
Actually, this is a very valuable discussion. With great progress on the new-logic new-language first small testnets in-house, previously stalled plans on robust testing of the production network are resurfacing.
Netflix for example has a very nice testing model, where in production code they have deliberately put “disruptive” code, brilliantly named ChaosMonkey (and higher forms of disruption all the way up to ChaosGorilla). For a decentralized network, like the SAFE network, such decentralized destructive testing is the holy grail of testing.
This “simian army” only causes statistical disruption. But maybe we can consider “holy war waging monkeys as well”, that would collaborate and on randomly chosen chunks try to achieve this targeted attack from within the core (so not just as a SAFE app). It’s a great way to train and improve the immune system of the SAFE network. We can call it “CorruptMonkey”, or other names can be suggested 
5 Likes
Totally agree.
Had forgotten about that, yes, this is something we could make good use of: tame network disruptor ants (not monkeys ). Or maybe anteaters!
1 Like
Hoolig ants… 
…
4 Likes
Hoolig ants is a good name ! LOL
1 Like
This is a somewhat high level answer. The more specific stuff will have to come from someone who’s gotten farther in the code than me. I hope it helps none the less.
All requests will come from data managers. It won’t matter if it’s for churn purposes or as a request for a client. Every chunk has its own “address”. When a file is requested, all the chunks are requested from their own addresses (and I assume the data managers will also know the name of the chunk, though that would need to be confirmed. It only makes sense for “correctness checking” ) when the chunk at that address is received, the content of the file must match the file name - it’s a sha512 hash of the content. If it does, the address was correct, the name was correct and the content was correct. If you can fake that, you’ve put WAY more cpu power into faking something that will, at best, give a small reward. Potentially no reward because safecoin generation is a lottery.
1 Like
What is this delete of which you speak!?.. I thought there was a space saving based on that one chunk could be a contributor to many files. Deleting one chunk surely is a liability for any file it’s part of? When I heard talk of the timed delete before I expected it was just an access to that data feature, rather than removing the data by deletion. 
edit: still confused by what this attack is but found a description of the normal process for deletion… Multiple Store/Delete | by MaidSafe | safenetwork | Medium
To be clear - this is a theoretical proposed attack that may or may not even be possible.
Yes, deleting one chunk would indeed be a liability to the file it is a part of, hence it being an attack and not a feature.
I just brought up a point that I thought should be looked into, as this could be a way to attack the network in a way it’s not supposed to be supported.
As for the delete feature you linked to, I believe that is no longer an option that is being built into the core / may not be possible as all. It leads to some other security risks.
2 Likes
Having read a bit more of this, the surprise here is in your last thread that
*Users can see what chunks they hold
If there were a few big data centres then the chances are greater but still obviously the catch all 32 problem remains. That would be an attack on the network not just the file concerns though, so perhaps unlikely that data centres would be so reckless. Interesting that there the chucks held aren’t obscure though.
Chunks are never deleted, and because this applies too data maps as well, all previous version of a file are preserved and can be retrieved.
2 Likes