Group: GNU Social P2P/OnionRouting
(→Modifications to Tor) |
(→Other Notes) |
||
| Line 24: | Line 24: | ||
= Other Notes = | = Other Notes = | ||
| − | Cores never initiate | + | 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. | 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. | ||
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. | ||
Revision as of 15:22, 14 November 2010
Contents
Motivation
We would like to protect the social graph by preventing traffic analysis. In order to accomplish this, we intend to use Onion Routing (OR) as the routing layer.
Tor and the Core
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.
Adjustments to the Tor Protocol
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.
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.
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.
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.
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'.
Other 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.
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.
