I don’t get what you mean. How can they target more serious users? If you use a public key (hardcoded) to encrypt data and send it to the Maidsafenode, how would they get in between??
If they can interfere with the data coming from a github server or from the maidsafe website (in case the public key is displayed on the maidsafe website) they could do the spoof. Otherwise probably not. But I am still more concerned about the liability of relay nodes to check every chunk they relay for not being illegal. If they have to do this, we can just as well use bittorrent (apart from the incentives that safecoin provides).
1 Like
My guess is an attack on the PC directly and intercepting the private keys, either through physical access or infecting the hardware/OS. But for that, you already have to be a target and there is no real protection against that kind of attack.
1 Like
@DrVecctor as with all other roles, relay nodes are just randomly allocated nodes that operate as a relay (or any other role). This makes it impractical to target them - also as churn means that the structure of the network (who is doing what for whom) constantly changes - and nodes that don’t perform the role they are performing are constantly being checked for their behaviour by other nodes. So a node that is not doing what it should (e.g. filtering out chunks it doesn’t like) is going to be disconnected from the network. So I don’t see the problem you mention.
Further, as @janitor has now pointed out, recognising chunks is easily defeated according to David. I suggested this was the case, and @janitor has found the reference for us. I think all bases are covered (though of course, not necessarily in the first test network - one step at a time).
1 Like
I think depending on legislation (I don’t know the details, but there was this other thread about germany, austria and apparently also australia) it is enough for police to watch one node relaying a “plain text” part of an illegal file to accuse them (even worse, i think in this particular case the relaying node didn’t even know what it was relaying, Idon’t know what happened to plausible deniability there). And I think, as @janitor says, it does not matter if this is just the last hop before the client or any other hop, since the police node can be at any other position in the “chain”, and they will know the IP of their “nearest neighbours”. As far as I understood @dirvine’s fix was only referring to the last hop before the client. In my opinion (and I am not a computer scientist, but I think understand the whole problem, more or less) the only safe way is to use onion routing from vault to client, in case of public files. For private files it doesn’t matter because of the self-encryption. And regarding nodes adhering to the rules, I am totally aware of this, but if nodes get in conflict with the law when they adhere to the rules, they will most probably shut down (not all of them, but most of them, in the affected jurisdictions). I don’t feel that we are trying to “criticise the network”, but merely pointing out what appears (at least to us) to be inconsistencies about the reported workings of the protocol over time, or problems that could arise for users of the network in certain jurisdictions, in order to help a successful network to be built. I think it is normal not only in scientific, but in all result-oriented circles, to honestly bring up concerns and then discuss if they are valid or not, ideally using rational arguments…
2 Likes
I think so too, and the proposed improvement only encrypts the chink, so the telco or other sniffing on the last node’s traffic can’t (easily) figure out what’s being sent, but the node before the last one can. So the issue is obviously that with enough taxpayer money thrown on these transit nodes, the gov thugs can ID the down loaders of public data.
Okay. Now, I think this is actually not so bad. Why? Because it will help the network and organization deflect accusations that it enables blatant copyright violations. Just like with BitTorrent, any public downloader a will be identifiable. In the same way illegal porn will be post-able but not downloadable without the risk of being ID-ed. At least safe download won’t be possible without additional measures.
A problem is that anything that most people consider “good” may be just as exposed, so we’re back to square one. The main difference vs Torrents is there would be no way to talk good or bad stuff down. This somehow strikes me as a better outcome, all things considered.
And if public data is going to be cheaper, perhaps it’s better to leave it unencrypted all the way. Mildly discourage the sickos and Torrenters and get them out of public sight. That wouldn’t be too bad in my opinion.
What of those that want to access videos of government wrong doings in oppressive regimes? Or those who desire to research material that their hosts country deems damaging to their control. Leaving flaws in the system for the sake of better PR is a recipe for death in some extreme cases. Lets not forget the meaning of the acronym SAFE. This is an example of the case I made previously in regards to social paralysis induced by our attempts to hide perversion from ourselves. These things disgust me but I refuse to be terrorized by their behavior and the resulting advances toward further abatement of my inherent liberties. Without complete anonymity, SAFE is little different than many of the evolving solutions we already have. I’m tired of imagining how some in more restrictive settings still hesitate to communicate their thoughts due to the gamble that is using weaker systems. The thought of those whose false sense of security has resulted (regardless to their ignorance) in their demise infuriates me to the point of jarring palpitations!!! No more should governments retain their informational advantage over their employers! Communicative freedom should be the default. Humanity needs to attack this garbage at the root and stop implementing patch solutions. These half-assed fixes will suffocate future generations who inherit our increasingly flawed world. Like cell division with cumulative errors in their iterative construct. I’ll leave it at that. If I go any further, I’ll grind my teeth to stumps. I’ll be back sometime later with a little imperfect idea I have. I need to cool off…
3 Likes
Not necessarily - or obviously for that matter.
If your vault is a relay node one day, it has the potential to be any different persona the next. Actually, since it’s constant change, there is no telling when your vault (node) can change personas. But let’s suppose that they are in control of a relay node…
I’d be happy to.
To set this up, consider the pathway as follows:
- Client sends GET request to Relay (via IP)
- Relay is “dumb” - does not know what it recieved (could be PUT request, etc.) or to what type of persona it is destined for (Client Manager, Data Manager, etc.)
- Relay sends GET request to NAE Manager (via XOR)
- NAE Manager knows that this is a GET request for files, but doesn’t know who (in XOR space and IP address) requested it. All it knows is that it came from a Relay who is representing someone who has them in their close group.
- NAE Manager sends request to the Network and starts recieving those chunks. (via XOR)
- NAE Manager sends chunks to Relay. (via XOR)
- Relay sends chunks to Client. (via IP)
In this scenario, LE would have to be in control of both the NAE Manager as well as the Relay to potentially obtain the IP address of the Client. But that’s not impossible, so let’s dig a little deeper. As it turns out, you are technically wrong on this point:
Now if you had said that it wouldn’t be useful if LE has access to the raw chunk (encrypted with the public key that is in the datamap) when forwarded by the NAE Manager as well as the chunk that the Relay passes (raw chunk encrypted by Client’s public key) I might say that you are correct. Here’s why:
The NAE Manager indeed knows what is being requested, but it doesn’t know the IP address of the Relay that it’s sending it to. The address that the NAE Manager is sending the encrypted chunk to is not an IP address, it is an XOR address, and as such must go through normal routing procedure.
So what? If LE knows (and can verify by finding their vaults’ XOR addresses) that they are in control of both the NAE Manager and the Relay, it seems like they would be able to figure out what IP address requested the chunks of a certain datamap.
In order to do so, the chunks must be able to be determined to be the same as the one passed from the NAE Manager to the client via the Relay node.
Since that is transmitted from the NAE Manager, LE obviously has the Client_public_key, and can test-encrypt the chunk with it to see if the Relay has passed any chunk that matches that test-encrypted one.
Although this is a (mathmatically) improbable scenario, I do believe that (my correction of) your statement is true. Which leads me back to my original point: Having your IP discoved when participating in anything less than a network that is completely operated by LE would be an outright hack of the Network.
I’m (to some degree) agreeing with @janitor on a technical issue you guys…anyone wanna set me straight on this one?
P.S. @janitor, please use correct terminology when discussing technical matters.
1 Like