Group: GNU Social P2P/OnionRouting

From LibrePlanet
Jump to: navigation, search
 
Line 3: Line 3:
 
We would like to protect the social graph by preventing traffic analysis.  In order to accomplish this, we intend to use Onion Routing to communicate between nodes. Onion Routing is a time-tested conceptual anonymity system, and there are stable implementations available that allow us to avoid re-inventing the wheel, in keeping with our goal of composing existing privacy-enhancing technologies when possible.
 
We would like to protect the social graph by preventing traffic analysis.  In order to accomplish this, we intend to use Onion Routing to communicate between nodes. Onion Routing is a time-tested conceptual anonymity system, and there are stable implementations available that allow us to avoid re-inventing the wheel, in keeping with our goal of composing existing privacy-enhancing technologies when possible.
  
−
= Tor and the Core =
+
= Implementations =  
  
−
[https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf Tor] is a close match to our requirements for an OR.  It prevents traffic analysis by obfuscating the source and target for packets.  However, it assumes that the Onion Proxy (OP) is trusted. Since the Core is not trusted, it cannot be allowed to create the OR path or to transmit data to arbitrary routers on the path.
+
We plan to initially use Tor as a drop-in onion routing system, tunneling the Agent-to-RemoteCore API over Tor. This satisfies our privacy constraint of not revealing the social graph while minimizing implementation overhead.  
  
−
= Adjustments to the Tor Protocol =
+
From there, we will extend the Agent and Tor to use existing Social-P2P Cores as onion routers. This will enable us to introduce a friend-to-friend aspect to the routing system, and make circuit selection social-aware.
  
−
Instead of having the Core create the path, the path will be created by the Agent with the Core acting as a proxy to the first hop.
+
To summarize, the Agent creates Tor paths and uses Tor paths in the forward direction.  Cores only use Tor paths in the reverse direction, to respond to requests from Agents.  
  
−
Since we cannot have the Core handle the OR circuit keys, it can't be relied upon to encrypt the content with the keys.  Shipping the content back to the Agent for encryption prior to sending it is prohibitive in terms of bandwidth.
+
== Tor Drop-In Implementation ==
  
−
Instead, we have the remote Agent create a reverse circuit to the local Core. ['''This doesn't work if the remote Agent is down. But that's okay because we can just leave a notification and have the remote Agent retrieve the info later.''' ] The local Core sends out data only through the Tor reply method, which involves just the remote Agent circuit key. The Core is therefore unable to break anonymity by communicating with intermediate cores.
+
[https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf Tor] is an existing, stable, free onion routing implementation. Our initial onion routing implementation will use Tor as a drop-in solution.
  
−
To summarize, the Agent creates Tor paths and uses Tor paths in the forward direction (through the local Core as a transparent proxy).  Cores only use Tor paths in the reverse direction.
+
Tor will be bundled with every Agent, and the Agent will use Tor for the Agent-to-RemoteCore API.
 +
 
 +
== Social-Aware Onion Routing ==
 +
 
 +
To further enhance privacy and move away from dependence on the Tor network, we plan on replacing Tor onion routers and directory services with Cores. To summarize:
 +
 
 +
* Agents will construct paths using both Tor ORs and Cores, with a preference for Cores calculated via a reputation metric (to be determined -- this is an open research question)
 +
* Agents will become aware of cores by syncing its lists with friend Agents
  
 
= Scenarios =
 
= Scenarios =
Line 22: Line 29:
 
* Agent wishes to retrieve content from peer: Agent connects to remote Core and performs a 'get'.
 
* Agent wishes to retrieve content from peer: Agent connects to remote Core and performs a 'get'.
  
−
= Other Notes =
+
= Notes =
−
 
 
−
Cores never initiate circuits.
 
  
−
The circuit encryption keys are created for the lifetime of the circuit, which is short.  It is safe for the Core to have access to the one key for the remote Agent on the reverse circuit, since it cannot be tied to long term identity.
+
Cores never initiate circuits. This would violate our notion of Cores as untrusted.
  
 
The Agent is trusted and has circuit keys for all the nodes of a circuit in the forward direction.  It also knows the mapping of these keys to the long term identity (public key) of the remote Agent.
 
The Agent is trusted and has circuit keys for all the nodes of a circuit in the forward direction.  It also knows the mapping of these keys to the long term identity (public key) of the remote Agent.

Latest revision as of 19:27, 5 December 2010

Overview

We would like to protect the social graph by preventing traffic analysis. In order to accomplish this, we intend to use Onion Routing to communicate between nodes. Onion Routing is a time-tested conceptual anonymity system, and there are stable implementations available that allow us to avoid re-inventing the wheel, in keeping with our goal of composing existing privacy-enhancing technologies when possible.

Implementations

We plan to initially use Tor as a drop-in onion routing system, tunneling the Agent-to-RemoteCore API over Tor. This satisfies our privacy constraint of not revealing the social graph while minimizing implementation overhead.

From there, we will extend the Agent and Tor to use existing Social-P2P Cores as onion routers. This will enable us to introduce a friend-to-friend aspect to the routing system, and make circuit selection social-aware.

To summarize, the Agent creates Tor paths and uses Tor paths in the forward direction. Cores only use Tor paths in the reverse direction, to respond to requests from Agents.

Tor Drop-In Implementation

Tor is an existing, stable, free onion routing implementation. Our initial onion routing implementation will use Tor as a drop-in solution.

Tor will be bundled with every Agent, and the Agent will use Tor for the Agent-to-RemoteCore API.

Social-Aware Onion Routing

To further enhance privacy and move away from dependence on the Tor network, we plan on replacing Tor onion routers and directory services with Cores. To summarize:

  • Agents will construct paths using both Tor ORs and Cores, with a preference for Cores calculated via a reputation metric (to be determined -- this is an open research question)
  • Agents will become aware of cores by syncing its lists with friend Agents

Scenarios

  • Agent wishes to notify peer of new information: Agent connects to remote Core and performs a 'put' with the notification body. If remote Agent is down, the notification will be processed once it comes online.
  • Agent wishes to retrieve content from peer: Agent connects to remote Core and performs a 'get'.

Notes

Cores never initiate circuits. This would violate our notion of Cores as untrusted.

The Agent is trusted and has circuit keys for all the nodes of a circuit in the forward direction. It also knows the mapping of these keys to the long term identity (public key) of the remote Agent.

Glossary

Onion Proxy

The client program that constructs the onion route and sends data over it for the user. Tor operating in client-only mode is an onion proxy.

Onion Router

A node that forwards data at the request of the onion proxy.

Exit Node

The onion router positioned in the last hop on the onion route, where traffic exits the overlay network.

Circuit

A set of onion routers set up to relay traffic between a source and an arbitrary number of destinations.

Retrieved from "https://libreplanet.org/wiki?title=Group:GNU_Social_P2P/OnionRouting&oldid=19896"