A successful attack on Freenet

[smacz]

@janitor

So the issue is obviously that with enough taxpayer money thrown on these [Relay] nodes, the gov thugs can ID the down loaders [sic] of public data.

Not necessarily - or obviously for that matter.

@happybeing

churn means that the structure of the network (who is doing what for whom) constantly changes

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…

@janitor

They just need to own one [Relay] 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?

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.)

2. 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.

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

@janitor

I understand that encrypting public file chunks with the [Client’s] public key isn’t going to be useful when [NAE Manager] knows its content and the [Relay’s] IP address.

@dirvine

@Seneca

Or do [NAE Managers] address [the relay] through the DHT with an XOR address?

This is correct

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.

@dirvine

the address of the client…contains (NodeAddress, Client_public_key)…then the routing node [in XOR space one hop before reaching the Relay after the chunk has been sent from the NAE Manager] can encrypt the whole [chunk] to the client…

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.