Go back to the Ultimate FAQ index
500. Security questions
501 Will not attack X break Freenet's anonymity?
Short answer: Probably yes.
Freenet does not offer true anonymity in the way that the Mixmaster and cypherpunk remailers do. Most of the non-trivial attacks (advanced traffic analysis, compromising any given majority of the nodes, etc.) that these were designed to counter would probably be successful in identifying someone making requests on Freenet.
On Freenet, whatever you do, your identity is still revealed to the first Freenet Node you talk to, and even if you limit yourself to talk only to trusted nodes (a feature that will be implemented in the future), they will have to talk to the rest of the network at some time or another. The anonymity that Freenet offers is really just obscurity in the fact that it is hard to prove that your node wasn't proxying the request for or insert of data on behalf of somebody else (who might also just have been proxying it).
The problem is that the only way that you can offer true anonymity is if the client can directly control the routing of data, and thus encrypt it with a series of keys of the nodes it will pass through (a la Mixmaster). Freenet's dynamic routing cannot offer that, so to attain true anonymity you have to send the message through an external network of anonymous remailers first (a future SMTP->Freenet bridge would make this possible).
It is our intention that Freenet's node-to-node communications should be encrypted, but that has not been implemented either (with the current state of the network we are more interested in testing if the theoretical ideas regarding the routing carry over into reality; you have to have a house before you can lock the door).
502 Is Freenet vulnerable to flooding attacks?
Short answer: no.
Long answer:
We don't think so. Aside from protecting freedom of speech, Freenet is also designed to be an efficient dynamic caching system. If information is requested a lot from a limited number of nodes, the nodes that the requests pass through will cache the information, lowering the load on the network. If information is inserted on a limited set of nodes and then subsequently requested a lot from a separate set of nodes, with repetition, the sets will close in on one another in the network topology until they are "neighbors" and only the originally targeted nodes are suffering from the attack.
In other words, in order to harm Freenet with a flood you need to consistently change your point of entry into the network and continually insert and request new data, and you will still only increase the workload for the network that is linear to your own. Given an immense will and capacity greater than the total of the entire network, it is possible to cripple any public network (including the Internet itself) with floods, but it is our intention to always keep Freenet as resistant to this as theoretically possible.
503 Why hash keys and encrypt data when a node operator could identify them (the data) anyway if he tried?
Hashing the key and encrypting the data is not meant a method to keep Freenet Node operators from being able to figure out what type of information is in their nodes if they really want to (after all, they can just find the key in the same way as someone who requests the information would) but rather to keep operators from having to know what information is in their nodes if they don't want to. This distinction is more a legal one than a technical one. It is not realistic to expect a node operator to try to continually collect and/ or guess possible keys and then check them against the information in his node (even if such an attack is viable from a security perspective), so a sane society is less likely to hold an operator liable for such information on the network.
504 What about hostile "cancer" nodes within the network?
The existence of malicious nodes within the network is the most difficult problem that a distributed network must face, and has been the bane of many previous ideas. Many systems (such as multiplayer gaming networks) try to avoid malicious nodes by keeping the protocol and code closed, but we have yet to see an example of that working in the long run. And anyway it is opposed to Freenet's philosophy.
Freenet is based on a balance of positive and negative feedback loops that bring requests for information to a node when it is functioning well, and keep requests away from it when it is not. The key to avoiding "cancers" is (as in the body) to make sure these loops can correctly identify even the most carefully designed malicious node and not keep sending requests to it. This issue is not fully dealt with by the current test code, but you can rest assured that a number of possible solutions (for example allowing clients to vote on the validity of the information returned on requests, and enforcing that all information be indexed by a hash of the contents at the lowest level) have been on the table and discussed for some time now.
505 If I run a Freenet node, can others access information on my computer?
No. Freenet nodes only serve information that has been deliberately inserted by someone who wanted the information to be shared. Since the code for the project is all open, you can examine it yourself to verify this. Of course, if you or someone else _does_ deliberately insert information that you would rather keep private, you have little recourse.
It is likely that the damage caused by leaks of personal information to Freenet will be small in any case. When the source of such information is identifiable, traditional legal remedies can be applied. When the source is anonymous, such information will have no credibility.
506 What about attack X?
Freenet is still in testing and there are bound to be attacks found that we have not dealt with yet. So if you do manage to figure out a truly new kind of attack, we are interested in hearing about it. Please keep in mind what Freenet is and what it is not, however. No single network can offer everybody everything, and there are security issues (like anonymity, discussed above) that Freenet, by it's nature, will never deal with to extent you might wish. If this upsets you, all of our code is freely available, so you are free to take as much of it as you like and write your own distributed network that suits your desires. (
- Bah, Priggish developers suck.)