SAFE Network concerns from an old employee

Ok, this is interesting. I would be interested to hear what @dirvine has to say about this.

If it is trivial to create a group, why would there be so much emphasis on preventing malicious nodes from joining a group? I understand that when you attempt to join he network, there is a neotiation that occurs, which places you into a different group (that you cannot choose). This is to prevent attackers from targeting groups which are know to contain specific data.

Naturally, I assume this effort would be relatively worthless if an attacker can just create a group and do with it as they please. In fact I would assume that new groups could only be created by splitting other groups which are considered too large, to form two separate groups. The same process of registering a node on the network could then be reused.

You can’t - you have to choose one owner or the other. Whatever is used to measure whichever the ‘best’ group is would influence this decision.

For blockchains, the longest chain wins. With safenet, i am not sure what metric is currently used. Maybe the longest data chain would provide a similar decision making mechanism?

Well, this is rather key and relates to my first answer. My understanding is that you cannot fake a group easily, but I admit that I do not understand the specifics of how. I am assuming that is a gap in my knowledge though, considering the efforts made to prevent unauthorised entry into existing groups.

@dirvine, is there something we can see to help the understanding of he new groups are formed and how the network prevents fake groups from being created?

Just wanted to clarify, that this patch gets a little crazy with nodes popping in out of a group. The expected vote count can vary from machine to machine. Placing machines under load (DDoS) can affect some of this behavior. I am going to guess that people are considering this attack out-of-scope, etc. Which is fine. The behavior in all cases will take some time to work through, which is the concern.

The problem is verifying that its the correct group. Prior suggestions were to ensure that the network chose where a node was placed on the network. That would work, except for the case where someone joins and then forges valid messages from a group that isn’t on the network. I have not seen a way for a node to rule out that possibility when receiving messages. Its just really, strange.

To prevent a fake group attach means not even create a group, fake one on network hops and claim it’s a group. Disjoint groups RFC is your best bet. There are a lot of things to prevent though, fake groups is a huge one and covers a huge area really. In any case we do cover it, but a lot of info.

To disallow the off line address attack then secure name shows the process as now (it is also documented and set in diagrams in routing repository docs)

Of course data chains is a really big help as well. There is a repo and blog posts.

The sentinel part of the language of the network blog post also helps.

The docs are pretty good
http://docs.maidsafe.net/routing/master/routing/index.html Thre are flow diagrams an dsequence diargams for joiing etc.

Also for routing table which is in the routing repo now 0.23 branch.

Also some RFC’s covering beyond joining faking etc.

The part we are working on is targeting (i.e. restart continually) words are chosen carefully in these above posts though I think for other purposes. We are saying in all the tests, we have not yet secured the groups and turned down parts etc. as we are testing different things so “per current implementation” can be really misleading. So attack is on design then test code etc. This is all messy and misleading. Outlining how this all works then critiquing it would be helpful instead of backwards,

Now I am again not working but answering huge questions :frowning: a difficult balance. Perhaps this is the goal of such statements in the OP? I take some comfort in the rest of the team are not stopped working like this or we would be going backwards. Not a dig at you @Traktion questions are great, but we do need to get better ways of getting through them all or some way to index all the papers docs etc. in an easy to find knowledge base.

There is also a paper on vault security in the WWWF and I think on the IEEE as well (not 100% sure its on security though). I am sure a lot more but the search for this perfect answering machine seems to continue :frowning:

8 Likes

Can you explain how this can work with disjoint groups?

2 Likes

I have asked specifically for you to describe the process here and show us the security issues you state we have. It would be helpful as now it seems to be all about partitions and bitcoin. There is too much movement here to even attempt to get a grasp of the issues you are stating exist in the process I have asked about.

SAFE Network concerns from an old employee - #123 by dirvine

2 Likes

Have a look at this one. Even if you could fake a group, your group can’t do that much harm. The node you are misleading can’t really do a thing on the network as it’s not the real network. And you can’t get it’s private keys or log in details or coins. What’s the purpose of faking someone in a fake network anyway? And explain to me how your fake group could fool Sentinel.

5 Likes

Getting into a disjoint group is a proof-of-work problem, with an easy difficulty. You try hash keys until you get a matching prefix. People generating vanity address for bitcoin are doing something similar already. If you notice, they have some pretty long prefixes. I have personally found a 40-bit public-key prefix for the secpk1 curve on a newish-i3. Took less than 36 hours I think, nothing too crazy. Adding a hash to the step will slow down the guessrate some, but not significantly. You could introduce scrypt or something to slow it down more, but I would advise against that because its still an advantage to someone with more CPU power. You could also increase the prefix length of the disjoint groups, but then you risk having empty groups. Even 2^32 is a pretty large number.

In fact, this is something else strange I have noticed. When the network decides to split a group, there does exist some probability that the group is empty. Seems like that would have to be coordinated or figured out.

Anyway, after generating my prefixes I either join the group legitimately (assuming the network is not enforcing anything else), or I join the network and start sending fake messages as-if I am the disjoint group. More specifically, if I am the proxy-node for a client I send spoofed responses from the non-existent group and never forward the request message.

Eh no it’s not, Can you show where this is the case?

2 Likes

Maybe define this assertion as well, Why would an empty group split (or even exist)? If it’s empty it’s not a group. If you have seen a bug int he current commits to the 0.23 branch it would be good to know.

I will link this once more. It would be really helpful if you explain the process and point out the issues.

7 Likes

@dirvine I hope you have a hard limit to the amount of time you spend on the forums.

Maybe MaidSafe could hire a hacker dedicated to breaking Safe, and part of their job would be to respond to forum posts describing hypothetical attack vectors.

10 Likes

You are kidding right? What’s your next claim, that SAFE has a hidden blockchain somewhere inside which you can easily fork to get someone’s Safecoin?

This is how you join the network (and therefore your group). You can’t pick your own group nor your address. You can’t target an address whatever calculated prefix you use. It’s like total nonsense. Same for empty groups. “Hi there, we are a bunch of connected nodes on SAFE but we are in an empty group!”. You are part of a group or your not. Nothing in between.

10 Likes

I really like the idea, but it’s probably too early. Or a bounty program, would be good later on.

Oh yea, I think the community is very important so am prepared to spend a lot of time here and bounce info back to the team. There is a limit but a ton of great info comes form the forums so it’s a fine balance. We do not often have super long posts like this, but occasionally folk do appear and have a bunch of all over the place points to make. So the balance is a tenuous one at times, but the community awareness is well worth it.

We are hiring outreach people at the moment who will take up much of that work though as well as the dev forum where more of the Engineers will frequent for deeper technical discussions. So all shaping up well, I always feel a small company should hurt before it expands and that is cool. So expansion time is long overdue for us :wink:

The Engineers working on this are pretty good at attacking every line of code and idea as well, so there are hangouts that last many hours debating some of the finer points. These are tiring for sure, but again well worth it.

Bug and security bounties are 100% going to exist, but we need to be further along before they are helpful instead of a hinderance. That time is getting very close now though and most of the guys are looking forward to that AFAIK.

11 Likes

Are you saying that Proof-of-Work exists only on the context of blockchains? As far as I know it was invented as anti-spam measure for email, and email has nothing to do with blockchains…

Nope, it probably will be implemented in some SAFE Apps or protocols as well. But it’s definitly not part of Disjoint Groups. To say that POW is part of DG is like saying a Tesla does have a combustion engine. It’s very far off.

2 Likes

Thanks very much for the links - I shall study them before commenting further.

Remember, this is still work and arguably important work. I know I get the same feeling when someone is pulling me away from some code, but sometimes you are the go to man on things and that can’t be helped. I appreciate your time on this and I am sure others do too who want to be sure everything essential has been thought of.

Maybe a technical FAQ would help? A lot of what is in these threads is tremendously valuable, but it needs curating to stop the same things being asked repeatedly.

1 Like

No worries, hope it all helps, there is a faq and wiki as well :smiley:

1 Like

Wow man, no need to go there … Just returning to this thread, but to answer your question—and to ignore your tone—I was reporting on a discussion I had with someone in the Trollbox. So probably FUD, but they didn’t come across as ill-motivated. As I mentioned, the tech details are out of my wheelhouse. Just thought I should pass it along regardless, if another community felt the issue was “unresolved.” Totally free to ignore, but … The MAID community should be strong enough not to lash out when another member tries to inform them of what seems to be going on in other circles.

1 Like

Just returning to this thread, but … I admit the details are really out of my wheelhouse. It didn’t immediately strike me as intentional FUD, so thought I’d mention it here just b/c it seemed like the opinion was taking place in a community / beyond one person’s personal viewpoint. Mostly I mentioned it as a “marketing awareness” thing, not b/c I thought whatever claims were being made had any validity (again I can’t judge on that level, and trust the team 100%), or necessarily required a response. My apologies, though, if this was an unnecessary side-track. I haven’t heard anything more about the issue, so am assuming it … wasn’t one :).

1 Like

Not a worry in any case, glad to know really when things are being said so we can check we don’t miss anything we should have been looking at in terms of the tech. Better to know than be surprised. :smiley:

6 Likes