Goals

I'd like to offer up these goals for the network. What goals are missing? Please respond with your thoughts on how these goals are already met by an existing network, or how they could be met by a new network.
  1. Security of transactions. Uploaders, Downloaders, and Data Facilitators must be protected from their transactions.
    1. This goal must be maintained assuming some fraction of participating nodes are subversively working in collusion, and that all network traffic between participants is visible to the attacker.
    2. This is the highest priority and no compromise outside of the necessity for practicality will be made at the expense of this goal.
    3. Note, security from participation is NOT a goal. That is the goal of a darknet.
    4. Protection of Data Facilitators excludes the use of public exit points from the network. These serve as legal and technological attack points.
    5. Specific entry points for data should also be avoided. These also serve as legal and technological attack points.
  2. Anyone at anytime can participate in the network given a computer and Internet connection. It should be a public network, not a private darknet.
    1. Darknets require existing relationships with others already participating. This would exclude a large portion of the population that would like to participate but know of no other people already participating or willing to participate.
  3. Trust is dispersed over a user defined number of nodes.
    1. Trust is based on the probability that some faction of nodes known are NOT evil. This faction is defined by the user on a per access basis.
    2. The plain text of the transaction must not be revealed until it has passed through enough nodes that the user is comfortable with the probability it has passed through a trustworthy node as compared to the risk of the transaction.
    3. This is one of the biggest problems with many anonymous peer to peer networks. Requests and transactions are plain text to immediate nodes. The legal recourse is that you could simply be passing the request through from someone else. However, for some networks an immediate node could perform statistical analysis of the transactions to yield a fairly strong certainty of a user's general network activity.
  4. No centralization.
    1. Centralization is very tempting, especially given the previous goals. There are many benefits including performance, reliability, and security. However, centralization provides a small number of attack points to cripple or completely disable the entire network.
    2. Proper centralized servers can also be expensive, requiring solicitation for donations, or other money making schemes such as advertisements.

Wednesday, September 26, 2007

more on I2P

I started a thread in the I2P forum:
http://forum.i2p.net/viewtopic.php?t=2312&sid=cf45852623189b0b40182162d4ade5cd

It turns out that there currently isn't a distributed file system for I2P. We could implement one or try to resurrect the existing attempt (upon review). Then there's the possibility of leveraging I2P's existing user-base to grow more quickly. However, the I2P API would have to have deep hooks into the NetDB for efficiency. Even if the existing API's don't have the necessary hooks we could participate in the I2P project to implement them. A worse case scenario would require changes to the NetDB that are incompatible with the existing deployment. I'll take some time to further explore this.
Posted by at No comments:

Tuesday, September 25, 2007

I2P

I'm giving I2P a review. It actually looks quite promising. Although, I haven't seen where there's a good distributed file system attached to it yet. I'm of the strong opinion that data shared should be distributed across the network for anonymous storage.

Another thing that troubles me a little is the way inbound tunnels are constructed before use and have an extended lifetime (10 minutes by default I believe). I'd much rather see routing information simply attached to the payload and revealed as the packet is delayered. Responding nodes would have to be supplied with Reply Onions (prior art). Responding nodes would protect themselves from 0 length reply onions by simply adding their own layers to the reply onion (mimicking an outbound I2P tunnel).

I think I simply need to study it some more. I can't believe no one would have attached a distributed FS to it yet.
Posted by at No comments:

Thursday, September 20, 2007

I'm back!

I'm back after being away for a while. Now I have time to focus on our network again.

I got excited about GNUnet, until I started reading the papers. Censorship seems to be their primary concern, which is noble but fails to meet our goals. What good is defeating censorship if an attacker wants data to be shared in order to identify the publishers and readers. The problem is observability of active nodes. GAP, like Freenet, allows for statistical analysis of CHK requests from a node over time, and IBlocks greatly help this analysis.

ECRS search also fails to properly protect requests. Even a modest machine on the network could mount a dictionary attack on requests, especially a targeted one. Over time a statistical view of a node's requests can be made.

In the end GNUnet also leans on legalities of plausible deniability and fails to provide strong technical anonymity given a modest Sybil attack. Plausible deniability offers no protection when people can be imprisoned without due process.

I also took a look at RShare. Technical documentation (English) seems almost nonexistent, but from what I can tell requests are plain text to directly connected nodes. It also seems to be written completely for windows, which is a poor platform to force someone to use for an anonymous network.
Posted by at No comments:
Subscribe to: Posts (Atom)