A successful attack on Freenet

What was mentioned as more likely (since you can’t decide that you want to hold a particular chunk) was to be the node that passes the chunk to the actual downloader, because you know his IP address. I can’t find that thread, but here’s a similar (thankfully we have 5 topics on each subject).

What wasn’t sufficiently emphasized is that for public shares, because they’re public, one can know each chunk’s hash.

In case Tor relay nodes are Web servers that act as HTTP proxy to the SAFE network, they’d have to break the both and ID the relay node plus the Tor user. It’d still be possible (to use this approach to ID users of public shares) but harder.

I don’t see what that has to do with DHT. The Last-1 node transfers stuff to teh Last node. There’s an IP connection between the two.

Well it wouldn’t be a hack if they deployed 5000 cheap VPS in a 1000 node network and just waited to see the right chunk passed to the ultimate destination.
That’s how it sounds like. We’ll see if they were stoopid enough to exactly explain what they did.

And how do you connect to known nodes, when you start with a set of MaidSafe seeed nodes which government agencies can spoof? I don’t think this can be so easily dismissed. They somehow did find those guys.

They just need to own one “Last-1” node that passed 1 chunk of 4700 you download in a full length public DVD file, so if you’re spraying your requests all over the network, it seems you’re guaranteed to get one requests routed through a LE system. Maybe I’m wrong, but can someone explain why?

Reddit: so how’s that different from what I said? (On Freenet, you need to add only trusted nodes, so they probably gained trust of some users and then served as a routing node (aka The Last - 1) for them; on SAFE that’d work differently).

There was this thread the other day that discussed a similar scenario, and I have to say I am pretty confused. Like one year ago or so I had the impression that @dirvine said that even chunks belonging to public files are encrypted on the way from the vault to the client in a way that even the last node can not know what it is serving (in an onion kind of way like TOR, in addition to the self-encryption, which does not really matter for public files). Now it seems that chunks belonging to public data are just routed in plain text. Did I misunderstand something a year ago, or has the protocol changed in the meanwhile for performance reasons? Thnaks for clarification!

Files longer than or equal to 3072 bytes are split in chunks that are encrypted and compressed before being put in the network. This process generates a data map which can be inserted in either a public or private directory. So no worry, chunks are always stored encrypted in the vaults.

I understand from that recent thread that I couldn’t find but DrVecctor also mentioned, that data from public shares is encrypted, but of course since it’s published as public, you can say that everyone has access to the key used to encrypt it.

Not at all. I think it’s best to ignore most of what @janitor posts, because it is usually wrong on the technical details, and goes on to make false criticisms of the network.

If @janitor wants to have this or future posts taken seriously, and not just removed, he’s going to have to start backing them up with references to allow them to be checked more quickly, because clearing up the misleading information he’s posting is taking too much time, and he’s devaluing the forum.


Spoof, like in imitating that they are the seed nodes?? No way. PKI is coded in, so when you connect to a seednode from Maidsafe it’s encrypted from byte 1. If someone would “spoof” a node like that they need to have the private key. I wish them all luck brute forcing the PKI.

1 Like

No, not in plain text. It is encrypted using self_encrytion but the hashes to decode the chunks back to the original data are public as well. So everyone who wants to use/see the file can do it. But they still need to decrypt the file.

You won’t be able to sniff the network and say: “Hey, Chunk ABC was just passed to IP” Even if you are the relay-node that passed chunk ABC to the address.

This one needs a little update, but the main assumptions are still correct IMO.


I understand what the self encryption does, and I don’t think that it is really any kind of encryption as long as the datamap is public (because I know that chunk ABC belongs ot illegal file XYZ). But if it is true what @popolrene says, that nodes don’t know what chunk they are relaying (like TOR), then I think there is not much to worry about. To make it clear: I am not at all asking about self-encryption, I am asking about additional encryption that actually prevents relaying nodes from knowing which “self-encrypted chunk” they are actually relaying,

I would trust your recollection of the previous discussion - mine concurs - but if you doubt that it would help clear up the confusion created on this thread if you could dig it out for us. :wink:

You didn’t misunderstand. Here (and check out the two comments before this one):

On this same page this is David’s comment that seems to indicate that this threat potentially can be dealt with (i.e. isn’t dealt with in any way right now, as far as I can tell from the comment).

Reading the later comment (the first URL) I understand that encrypting public file chunks with the last node’s public key isn’t going to be useful when the node before the last knows its content and the last node’s IP address.

Of course they aren’t that stupid. They need to ensure your MaidSafe package contains the “right” keys. While I doubt they’d use that to catch some Piratebay schmucks, more serious users can be targeted this way.

Okay, I look forward to explanations about those public data chunks…

1 Like

@happybeing: thanks @janitor, this was exactly the thread I was having in mind…

1 Like

Well done @janitor, that’s a useful post.

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…


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…


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:

  1. 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.)
  1. 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.
  1. NAE Manager sends request to the Network and starts recieving those chunks. (via XOR)
  2. NAE Manager sends chunks to Relay. (via XOR)
  3. 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