I wouldnt go as far as giving him that kind of credit. Trouble isnt the word. Annoying may be the word. It may be part of his shtick. He has a little momentum going here and is milking it.
I say play his game but play it better.
Its an extremely good assumption considering SAFE has always operated this way, and so has every DHT design I can think of.
Are you sure you used to work for MaidSafe? You seem to have come into this discussion with a few basic assumptions that are clearly wrong.
Proof-of-work is not something that is used in Safe, as far as my understanding goes.
I think if you were to discard your preconceptions and learn how Safe works from the ground up, you could better critique it.
3 Likes
He think he was saying sha256 (secure hashing algorithm) is technically a proof of work algorithm?@vtnerd is not an idiot but heâs throwing all of his time/mental resources at this, enduring criticism, and maintaining composure, which leads me to believe he has a motive. Heâs throwing out very in depth edge cases and when wrong or it leads to nowhere he continues to dig deep to come up with whatever he can that will continue to waste time.
8 Likes
This 
+1 
Beautiful. Just beautiful.
@vtnerd is a side stepping pin. @dirvine needs to corner him and get that spare.
3 Likes
I think anyone reading this can quickly see what is going on here, even with a lot of the tech-babble going over most peopleâs heads.
Thanks for sticking around and proving what we all suspected from the start vtnerd.
FUD pwnage ftw
2 Likes
Read the example on the bitcoin wiki.
You push an input through a hash-function hoping to get a value within some range. Since you cannot predict the output and there is even distribution, this scheme is generally trial-and-error. Thatâs the proof-of-work scheme you see everywhere. The verifier knows that the probability of you âguessingâ a value within a small range is going to be more âdifficultâ than one with a larger range.
Disjoint groups is trying to divide the network into groups by a prefix. A prefix implies a range. In the naive implementation, trying to get into the group, or generating forged messages as-if in the group, is identical to a proof-of-work scheme. You just keep âtryingâ public-key->SHA256 until you get the prefix you want. Its obviously not the intent, and I used that phrase thinking everyone would make the connection. I pointed to the thread on bitcointalk because people are finding pretty long ranges, and the network would have to be extremely large to defend against this (i.e. 2^32 is 4.4 billion) unless something else is done. Bitcoin uses the secp256k1 curve, while SAFE is currently using curve25519. Generating curve25519 public keys should be slightly slower than secp256k1 since it lacks the endomorphism, but I would not expect it to be much slower.
The difficult problem (IMO) is forged messages. How does a client even know a received message was from a node on the network? Legitimate nodes are randomly generating public keys too, so its difficult for the client to know what to expect in the source address of a message (other than an expected prefix). And a client does not have connections to the entire network. Perhaps you could try multiple paths to see if you get a response from that node on all of them?
4 Likes
Thanks for going into more detail. Sorry for being quick to judge you.
I donât know the details of how disjoint groups work, so maybe youâre onto something here.
However, Iâd assumed (yes, now itâs me making assumptions 
) that Safe worked around some sort of web-of-trust principle so that all nodes have relationships that could be traced back to your direct peers. Thus, when the network assigns you an ID, that ID is verifiable as coming from the network rather than being generated externally.
4 Likes
This implies that when you have a âprivate keyâ to create address A2333 you could become part of the group that has that address in itâs range. So it implies you could become part of group A23xx where you are now number 33. This is not correct. You canât pick your own address on the network. You canât insert or activate an address, even if you have the private key. Itâs more like:
- Iâm a brand new node and my public key is âABCDâ. I can sign whatever to prove Iâm the owner of this public (and private) key.
- In Crust a request is sent to be accepted in a group somewhere.
- A group called âHBGGâ has a spot open for you and you are allowed to join them.
- They all agree your address is: âHBGG12â and from now on thatâs your address.
- If they want you to sign a message or anything they want you to use your private/public key âABCDâ to prove you are indeed âHBGG12â.
So even if you have the private key to create the right SHA256 = âHBGG12â you still canât become it. The network has a different opinion about who is âHBGG12â. The network will tell you: âHBGG12â= node which can prove to be âABCDâ and thereâs full consensus in group âHGBBâ that this is the case as they applied that address to this node (GetNetworkName (response)). The routing table is also agreed on by the close groups of âHBGGâ like âHBGGaâ and âHBGGbâ. Thatâs why I kept saying in this topic that computation is useless if you want to target a group. And Iâm still convinced this is the case. Maybe I missed some details, but I stand by my claim.
Here it is in the bootstrap diagram:
Thereâs no part in the diagram that says: âLook at the SHA256 of the node and determine from that value where a node belongs in the network.â It says: âGetNetworkName (request)â which asks other nodes to provide an address in a group. Look a bit further and youâll see the GetNetworkName (response). Thatâs the one you canât target by POW or any other way. It is given to you.
This is where SAFE is far different from any Blockchain technology.
11 Likes
@vtnerd whatâs your motivation in posting here and on github?
Are you excited to contribute to a project you see as close to coming to fruition, or are you trying to warn people away from something you see as fundamentally flawed? Or perhaps something else?
I think you should assume that MaidSafe developers are approximately as smart as you and have put far more work into thinking up failure modes, so what you can think of off-the-cuff probably isnât too valuable. Perhaps you should wait for the beta release, and then write a hostile client POC to show a specific vulnerability in the network.
As a relative outsider with development experience, I admit that I find the apparent attack surface of Safe to be terrifying, but I havenât yet come across something that I would judge as a permanent barrier to success.
6 Likes
The thing is these explanations are so âin depthâ that they are technically vague and fail to answer the real questions. David and the rest of the team mull over these things and all are welcome in the RFC process. Not everything is implemented. If Iâm following what has been being said recently is that these current iterations are about data republish and THEN security. Also currently there seems to be a push to get outside developers to start building on the platform which makes sense so they can have all the tools they need to build while maidsafe then concentrates on security going into (possibly) alpha 2 or 3? Or Beta. Not sure how that will play out yet as far as what falls where in release terms. But this back and fourth on this thread has achieved nothing, itâs baseless and itâs fruitless folks.
1 Like
Good question.
Your gut is always truthful.
Way too much effort being put forward here by @vtnerd . This has not been productive. There are no obvious reasons for him to so passionately carry on.
He is not employed and is putting his reputation at risk.
Yes.
Money?
Personal Vendetta?
3 Likes
Letâs keep on topic people. And please leave out the personal attacks and insults. This topic is about the technical claims and the replies by several people.
EDIT: As no other mods were online I deleted several replies which are not in line with the guidelines. For questions PM @moderators.
9 Likes
Not just technical. As you can clearly see some are perplexed about motives. Its also about the reliability and motives of the source of the apparent claim of âserious issuesâ. .
3 Likes
This discussion started when David asked me how I would forge messages. I pointed out that the client was currently trusting and communicating through a single proxy. That single proxy could generate forged messages easily and the client would not be able to tell even if it knew the prefix of the group it wanted (because it could be easily generated by the malicious proxy node). An entire data chain could be forged too. The main takeaway is that messages can be forged easily in this system.
Knowing every member of your group, and the adjacent group is not web-of-trust exactly. Its more like strength in numbers - you donât necessarily know who is running any of those nodes (although you might make a dedicated connection to a friend). The ideal situation is that somehow a client can immediately detect a forgery by âknowingâ that the network address was not provided by the network. I am not sure how to do this, so the system has to eliminate scenarios where a client chooses the wrong one (like the single aforementioned proxy case). Again with the bitcoin, if you have 8 peers and 7 of them are maliciously working against you, the single peer forwarding the longest chain is enough to determine the valid messages (assuming the whole 51% thing). Very simple.
The client could connect to multiple proxy nodes in an attempt to collect multiple responses. If it gets different results, which one does it trust? The âclosestâ nodes (previous attempt) is probably not a good idea. The quorum? Can the system guarantee that quorum will never drop in this environment (through churn, etc.)? Does it then just become a majority âvoteâ? If you decide to let quorum drop (for churn, etc.) then it creates an incentive for a malicious node in the group to forcible delay responses from its peers (via overload) to influence the âvoteâ going through the system (which of course depends on how low of a âvoteâ can be accepted). And then thereâs the possibility of me continually joining the network through different IPs to be ârandomlyâ assigned to the same group. The number of groups is based entirely on the size of the network and targeted group size with disjoint groups. Has anybody thought about the expected number of groups, and the probability of an attacker getting into a desired group?
I will refrain from saying much further, because it is easier to review with an implementation. Its difficult to know exactly (due to subtleties of language, etc) what the team is planning based just on some RFC. Just think about: (1) An attacker can generate a public key within a certain prefix, (2) an attacker can generate messages claiming to be from that group, and (3) how does the client detect forgeries. Data chains can be forged too.
The design is still allowing legitimate correctly functioning nodes to have a history fork in ways that can be hard to predict (IMO). Eventually consistency implies that somehow the recorded history forks, and then later merges. Can an attacker induce this behavior to their advantage?
I can influence the vote count by placing a machine under load. I mentioned on github on how the vote gets tallied incorrectly. This one is more difficult than the DDoS case for sure, but is heavily dependent on the implementation (especially data structures). I would look for a data structure that allows me to remotely control the length of time required to complete a function call on the path that I wanted to slow down (i.e. a linear search that I can add entries to remotely). So its heavily dependent on the implementation, which hopefully isnât changing very often.
The single malicious node in the group is also an issue in that patch. Assuming the network chooses a location for me, how long will it take for me to get a single node in the group I want? Once I am in there, the attack is even easier than before. I send two opposing messages from the client like before, and then I âsplit the voteâ (from the single node I control in the group) giving each half of the group I different value. Now my value is the deciding âvoteâ for the quorum. Reverting the recent patch would fix this, but I still have the prior attack and potential usability issue (3-writers is the funny case).
You are absolutely correct. I was speaking to the current implementation specifically. I stated this earlier, my first thought (thinking like an attacker) would be finding a way to generate a key I wanted, then find a way to get nodes in a position to forge a network join. I would need more detailed information than this diagram though.
But one thing to think about - the number of groups is directly related to the size of the network and the target for the group size. How many groups are expected? How difficult would it be for an attacker to take 50 machines and slowly attempt rejoins until they are in the same group? Its going to be easier with a small network.
This is a great question. I actually thought about this for a few minutes, because I am not sure myself. No one has publicly requested for my feedback directly, and this is taking up too much of my time. I cannot see any sort of payoff for me in this - monetarily or mentally.
This is my main concern. Lots of moving parts. The details change frequently too, which makes it hard to analyze.
2 Likes
This is so hypothetical itâs crazy. Iâm actually getting what youâre saying about the attack vector but youâre also not sure how you would do it. Also things ARE changing rapidly so it should be hard for you to so solidly say there are security holes when some things havenât even been implemented.
1 Like
Ok, but arenât all messages signed, so you can validate where theyâre from?
As long as signed messages describing the existence of peers are obtained from multiple sources, it seems pretty robust.
If you could take over an entire group, that seems like it would offer some fairly devastating attack vectors.
Well, the pursuit of truth is a noble goal, and I thank you for all efforts towards that end.
1 Like
I would have loved to join the bleeding hearts here but itâs clear this has gone from âFormer Maidsafe Engineer outlines what appears to be serious issuesâŚâ to "Former Maidsafe contractor changes story and now sums it up with âits hard to analyzeâ "
4 Likes
Also, @vtnerd,
I just read @anon40790172âs post detailing Sentinel, and it appears to address your concerns.
4 Likes
But afaik sentinel is not part of the current design anymore.