SAFENetwork verifying signatures, confirming node age?


#1

Is there a possibility we could do something like this?

Say I get a signature from someone - supposedly being a node in SAFENetwork - and I send it into SAFENetwork, and get some information back, like: yes this is an elder node, this and that age, section prefix this and that - and maybe something else of importance.

I have not had time to think very much about it, but I think this could let us create overlays which can rely on SAFENetwork member security, instead of having to build that all over again.

Sure, what is verified is restricted to what SAFENetwork verifies, but in many cases that will be what we need, if we have the presumption that we trust the validity of SAFENetwork.
So, let’s say I want to create a secure group for a system relying on network agreed logic. I could then have agents take part in that network, based on their membership in SAFENetwork, which would lower the barrier for me creating such a system. The section prefix information would let me shape some logic around closeness, and how groups in my system are formed, which would (perhaps) be important for the security.

Wouldn’t that be a major service provided by the network? Seems to me it would not have security / privacy implications, expecially if it can only be provided if the signature is over a message that is specifically generated for this purpose - meaning the signer has been signing it with this very intention, and it is not just any signature sniffed up somewhere.

Any other implications / drawbacks?


#2

The chain will give more info on not only the signature, but be able to prove the sig was form a valid node at some point in the network. Secure message relay for instance will give assurance that the message was signed by valid nodes, but via group consensus. So if we code the network properly then you can trust that for that instant. Chain gives you historically validatable proofs, if that makes sense.


#3

OK, that’s really good.
Yes it makes sense, it says something about that moment, but of course anything I see is stale the moment I see it, so it doesn’t say that it is actually still the case when I see it.
And so, I guess there will be some API for this. What would it look like for example? Would it be publicly accessible or needing to have an account (I’m guessing the former)?


#4

For sure there will be, the chian component itself will have an API and docs. Interestingly though it is contained and not necessary to be on the network as such. So you can grab a chain and then run analysis on that chain for a single section without touching the network API as such. So think a self contained list of proofs with analysis tools.


#5

Aha, grab a chain. very interesting. But the membership chains are reset when sections merge (and split?), right?

Do you think that it would be possible to make other networks secure, based on that chain information from SAFENetwork (a lot else disregarded of course)? Like, would it at some level be possible to derive security from that alone?


#6

wouldn’t any signature that shows a node to be an elder need to be by the section, otherwise its more a self signed (non) proof. EDIT: Ah I see David answered this with the chain’s info.

Now the other issue is that you have the problem of bad actors that behave until the time is right to misbehave. So you get say 1000 elder nodes for securing your network. How do you know that none or even just a few, are bad actors.

They could act good on the safe network and earn themselves a pretty penny, but then they get chosen for your network then they could be designed to disrupt, subvert, malice, etc. your network while remaining good elders.

These could even be good nodes and the person who runs them may be a competitor to your network or just hate the idea. So they wait for the chance to be a part of your network.

tl;dr
How can you be sure the (perfectly good) elder nodes chosen don’t act with malice against your use of them? Just because they hate your network.


Another point to watch out for is that they may not have spare capacity to help secure your network. The chosen node could be a vm instance running on a machine that is loaded. Will it have the spare capacity to help you. What if per chance you got more than one node runing in a vm instance that is actually on the same loaded machine?


#7

Yes good points @neo.

I think relying only on that would mean exposure to those weaknesses, no doubt.

I wonder though, if it could be used at some level as a basic filter, requiring less of the second network. So let’s say I do have consensus rules for decisions, and a simple, non deterministic algo based on the elder ID in SAFENetwork, have I not somehow weaved in the inherent protection against collusion from SAFENetwork?

There’s no way of forging the SAFENetwork membership, and if ratios there are good, with a reasonable update rate, ratio of malevolence in the second network would be the same. Now, this requires that there is nothing about the other network that is negative for SAFENetwork, because that would increase the likelihood of malevolence, since the majority of nodes in SAFENetwork - at some level - have proven to be protecting the network.

So really, the more beneficial the other network is to SAFENetwork, the higher the likelihood that random set of elders from SAFENetwork will protect also this network.

What I’m talking about is actually bringing about the biology references again; symbiosis.

And I guess it would naturally weed out which networks that actually could do this.


#8

I think so definitely. Are you going to need similar complexity though as the safenetwork uses? Yes you may have a vetted list, just remember this only covers the ageing aspect of saefnetwork’s node validation system.

I think though one disadvantage is that while you can choose your nodes to use, will they say yes to doing work for you? This might mean that its more likely to have the malicious (to you) nodes agreeing. So instead of say 1% chance you might have 10% chance if most vaults owners do not wish to do free work for you.

Just some thoughts to help you formulate a plan.

Could this be done as an APP on the safe network. Dunno but something to consider.


#9

Thanks neo, always good with that piercing eye on things :slight_smile:
If free, then absolutely, the opportunity to cause disturbance would be a motivator that would have a higher relative weight.

I hadn’t thought it would be free work though (I don’t think it’s possible to get sustainability with a single directed flow of resources, it has to be good in both ways). But secure and fair reward is a nut to crack nevertheless. I had a conversation with mav in another topic, about how we could reward this kind of work outside core network code. And, one suggestion, that I hold among possible options, without having spent anywhere near as much time on it yet as I want, would be that they take turns in expenditures (PUTs on SAFENetwork), and are rewarded randomly by staying long in the group.

Not sure I understand. You mean to say that it might well require near the same complexity anyway, or just straight asking if I have something in mind that would require same? :slight_smile: (oh text, and the multitudes of interpretations)


#10

The thought came by as I keep thinking about network agreed logic, that I want to build apps that do this, and I always end up having written the whole SAFENetwork to ensure the necessary security etc., and I sigh and think but then it would just be better if MaidSafe built this app from the start :slight_smile:

And so on one of those regular turns trying to find a way into that nut, I just thought maybe some of the benefits of the network could be provided as a service. And then I thought that it could be a major thing for any kind of app that needs some sort of trusted agents to do something; by “recruiting” power from SAFENetwork.


#11

Basically similar malice detection and PARSEC at a minimum. Plus your own form of ageing. Since the nodes you get maybe vetted for the safenetwork but not for yours.

I was simply asking if you had thought of this yet.

Maybe in a later version the safenetwork could provide a consensus service (for a fee of “X” PUTs) where you can ask the safenetwork to sign off and do the consensus for you.

Just thought, this could solve @mav’s thoughts on atomic transactions at the APP level also.


#12

Parsec yes. Was very happy when they announced they would be adding c headers and bindings in some languages (the last part not sure if they said or if I just hoped). Would of liked that for crust too… But there were no plans for that last time I asked.
Some internal ranking yes, that would be needed. I have parts of that already in my SAFE.Exchange simulation from like two years ago (don’t go look, the code is probably horrible :smile:)
Malice detection though is one of those things that I was hoping could be less necessary.

Mm, but we are very close to “computing” in SAFENetwork by that.
I think that is part of what makes this so hard. Will it be something app developers should do, will SAFENetwork do it? maybe yes both, are all quite possible answers, which just makes it all harder :slight_smile:
The early phases of new technological waves are no easy ride. In 25 years this will be looked at with same awe as when I see that memory was once knitted :joy:


#13

crust is harder, cause

  • it’s built on async io, so we would need to map those to callback function calls
  • it’s using rusts generics to make the encryption stuff swappable, so it can only be initialized from rust code
  • it’s called crust for a reason :wink:

#14

More work, yes. But those things are not insurmountable. Client libs bindings heavily rely on callbacks, which works fairly well. The c#-bindings actually had a problem with garbage collection of these callback delegates, which I discovered, and possibly have some left - at least that’s what my tests indicated / EDIT: This was not with normal usage, rather when stressing it hard./ (So, yes, not entirely trivial).

But none of that is insurmountable.

The generics part is not a hinder. You’d have to limit the API to the 90-95% most common implementations, and just not have the rest. Which would be OK.


#15

This was what I was referring to:

But does this mean that the chain is lost? I.e. asking the sections for it and they won’t have it.

For the idea I’m playing with it’s not a problem though. (The problem is if there is any value to be derived at all from the fact, but I think that if you trust the SAFENetwork, there has to be at least some value there - in the scope of security. Big enough value to be able to use it?).

This since there could be a periodical check of a participants status within SAFENetwork.

It’s basically the concept of the network as a trusted authority (at some level), and how to use it outside of the network.


#16

No t necessarily. At the moment history is maintained in each section until split/merge, but it is likely able to be purged. So similar to losing it. However there is a bit of work to be done on the detail of purging and it is related to how much history should they maintain. So for instance a node comes on line after a short period, it has a chain, that chain will have the last record in it that also exists in a current live chain. That is all good. However if off for a very long time then it may have a chain that has no record any network node has and therefore it becomes invalid, or does it?

Chains are valid bidirectionally so you can prove from where I am back to where you are as in the above example if I am a network node and you are the re-joining node. However if my chain goes back to genesis then it is also proven on the network regardless of where your chain is.

So these are a couple of points to consider, it is likely the outcome is that you hold a short chain (no genesis) and it can become old and not provable, but if you hold a full chain (from genesis) then it is provable, but if you hold a short recent chain then it is also likely provable.

I know I am not clear here, but intentionally. These are just some options we will be addressing very soon, not huge problems, just some thoughts. To me short old chains are OK to be useless though, but much more thought in the detail is required. I suspect many nodes will not purge old section chains on split/merge, but maintain them and that is also OK as any node with a current good chain history that can go back to your short old chain is all you need for your proof.

Hope that helps.