Group: GNU Social P2P/OnionRouting
(→Scenarios, Other Notes) |
(→Modifications to Tor) |
||
| Line 7: | Line 7: | ||
[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. | [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. | ||
| − | = | + | = 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. | 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 is prohibitive in terms of bandwidth. | + | 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. | + | 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. | 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. | ||
Revision as of 03:03, 7 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 connections.
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.
